Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions packages/docs/src/pages/tutorial/introduction/ssr/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -5,16 +5,16 @@ layout: tutorial

In the previous tutorial, `useWatch$` is used to update the list of GitHub repositories as the organization value changes. In that example, `useWatch$` features an early return when executing on the server to ensure it only runs on the client. Let's dive into why this behavior is important.

When doing server-side rendering (SSR), the server needs to know when to take the snapshot of the application and send it to the client. Snapshots are taken when rendering is complete. Deciding when to take a snapshot is tricky as the server may need to fetch data used in the response. The problem is that the server needs to know how long to delay the rendering of the component until the data is ready.
When doing server-side rendering (SSR), the server needs to know when to take the snapshot of the application and send it to the client. Snapshots are taken when rendering is complete. Deciding when to take a snapshot is tricky as the server may need to fetch data used in the response. The problem is that the server needs to know how long to delay the rendering of a component.

Qwik's way to solve this problem is to ensure `useWatch$` is run before rendering the application. On the server, required data is fetched before a component is rendered. The problem is that `useWatch$` can't block component rendering. So if `useWatch$` is asynchronous, there is no way to delay execution of component rendering.
Qwik's way to solve this problem is to ensure `useWatch$` is run before rendering the application. On the server, required data is fetched before a component is rendered. The problem is that `useWatch$` can't block component rendering. So if `useWatch$` is asynchronous, there is no way to delay rendering.

If the server's early is return removed, the server would execute `useWatch$()`. Since `useWatch$()` can't delay the rendering, the component would render before it had data. Rendering a before data is available results in a component stuck displaying a loading message. So `useWatch$` is the wrong tool for this job, but Qwik has the `useServerMount$()` function for just this purpose.
If the server's early return removed, the server would execute `useWatch$()`. Since `useWatch$()` can't delay the rendering, the component would render before it had data. Rendering before data is available results in a component stuck displaying a loading message. So `useWatch$` is the wrong tool for this job, but Qwik has the `useServerMount$()` function for just this purpose.

The `useServerMount$()` function executes before rendering and blocks rendering until processing is complete. This delay allows `useServerMount$()` to fetch data and hold off on rendering the component until the requested data is available.

Your goal is to use `useServerMount$()` to fetch the data on the server.

To help you understand the order of operations, the code features a series of `console.log` statements to help you see what's happening.
To help you understand the order of operations, the sample code features a series of `console.log` statements to help you see what's happening in order.

Notice that `create JSX` is called twice, but only the second JSX response is used for rendering the component. There is a `console.info` from server `QWIK Dropping render. State changed during render.` This message indicates that the Qwik recognized that the initial JSX response is invalidated after `useServerMount$()` has resolved, and so the second invocation of component is needed to rebuild the JSX and finally render the component.
Notice that `create JSX` is called twice, but only the second JSX response is used for rendering the component. There is a `console.info` from the server `QWIK Dropping render. State changed during render.` This message indicates that Qwik recognized that the initial JSX response is invalidated after `useServerMount$()` has resolved. This process shows how the second invocation of the component is needed to rebuild the JSX and finally render the component.