Simple/Client-Fetching SSR

In this section we will discuss server side rendering, what it means, how Solid implements it, how to use it and it's limitations. For a more in-depth explanation from Ryan, checkout the video above.

What is Server Side Rendering?

Server side rendering is simply the process of rendering your application on the server then sending the HTML to the client. This is opposed to the client rendering the application in their browser otherwise known as client-side rendering. Server side rendering has many benefits, but the most important two are that it allows search engines to crawl your application and it allows for your application to be client agnostic.

Server side rendering is good for search engine crawlers because they can't run Javascript code, so if your application is rendered on the client(browser) then search engines will not be able to crawl your application.

How does Solid implement SSR?

Solid.js implements SSR in 3 different ways depending on the type of application you are building. The 3 different ways are:

• renderToString: This is used to render a component to a string of HTML.
• renderToStringAsync: This is used to render a component to a string of HTML asynchronously.
• renderToStream: This is used to render a component to a stream of HTML.

In this section we will only be talking about the most basic of the 3, renderToString. The other 2 will be covered in the coming sections.

How does renderToString work?

The concept behind renderToString is very simple. It takes in a component and renders it to a string of HTML. The component that is passed in is called a root component. It renders what it can on the server (elements outside the suspense boundary) and hydrates top level components on the client. Asynchronous data is fetched and rendered on the client without hydration.

In this form of SSR, the client will be in charge of carrying out data fetching while the server is in charge of rendering the application. This is called client fetching SSR. This is the most basic form of SSR and is the easiest to implement.

renderToString is a function that takes in a component and renders it to a string of HTML.

jsx
import { renderToString } from "solid-js/web";
function App() {
  return <h1>Hello World</h1>;
}
const html = renderToString(() => <App />);

jsx
import { renderToString } from "solid-js/web";
function App() {
  return <h1>Hello World</h1>;
}
const html = renderToString(() => <App />);

The above example will render the App component to a string of HTML, <h1>Hello World</h1>. This string of HTML can then be sent to the client and displayed there.

How to use renderToString?

In order to use renderToString properly you'll need to have it run on the server. This can be done by creating a server using one of Node.js's many server frameworks. The most popular one is Express.

jsx
import express from "express";
import { renderToString } from "solid-js/web";
function App() {
  return <h1>Hello World</h1>;
}
const app = express();
app.get("/", (req, res) => {
  const html = renderToString(() => <App />);
  res.send(html);
});
app.listen(3000, () => {
  console.log("Server started on port 3000");
});

jsx
import express from "express";
import { renderToString } from "solid-js/web";
function App() {
  return <h1>Hello World</h1>;
}
const app = express();
app.get("/", (req, res) => {
  const html = renderToString(() => <App />);
  res.send(html);
});
app.listen(3000, () => {
  console.log("Server started on port 3000");
});

The above example will create a server using Express and render the App component to a string of HTML. This string of HTML will then be sent to the client and displayed there.

Limitations and benefits of renderToString

There are a few limitations to renderToString. The first one is that it is synchronous. This means that if you have any asynchronous code in your application, it will have to be run on the client side. This is because renderToString will not wait for the asynchronous code to finish before rendering the application. This can be solved by using renderToStringAsync instead.

A nice benefit to this approach to SSR is that it is very easy to implement. You simply need to create a server and use renderToString to render your application to a string of HTML. This string of HTML can then be sent to the client and rendered there.

Another benefit is that it is very fast. This is because the application is rendered on the server, so the client doesn't have to render it, which can be a very expensive process. However, in cases where asynchronous data is required, the client will need to fetch the data after the application has been rendered, which can cause the longest contentful paint to take longer.