**
Update (11/2/2023):** The code examples shown in this post have been deprecated. For the most up-to-date code examples on how to use Clerk with Next.js SSR, read the documentation. Additionally we have a new blog.
Updated: 25/08/2022
React was originally built to run on the client. Once React started, hooks would run to load data, and eventually a full page would be generated.
But since React is just a Javascript library, there was no reason it couldn't run on a server, too. Server-side rendering (SSR) runs React on the server to generate a page's initial HTML (a.k.a the first render), then runs React again on the client to provide reactivity.
Server-side rendering is particularly helpful for pages that must be indexed in search engines, since search engines cannot index pages that are rendered client-side.
The bigger benefit, though, is that server-side render can reduce the complexity of an application and lead to fewer lines of code. This is especially true in the modern era, where frameworks like Next.js provide helpers that drastically reduce the setup time for SSR.
Server-side rendering can be used by including export async function getServerSideProps() on any pages you need SSR. Below is an example of how a page would look when using SSR:
This example retrieves some data from api.example.com. Then, we pass the data to the UI using the return statement. Finally, in the UI, we present the data to the user.
You can read more about Server-side rendering in the Next.js SSR documentation.
Now that you have a basic understanding of how SSR works, let us investigate how Clerk and SSR can work together.
Clerk allows you to verify a user is authenticated and to retrieve user profile data when using SSR. Below, we will cover how to implement both.
With Clerk and Next.js SSR, we can check if the user is authenticated and, if not, redirect them to the sign-in page without rendering anything on the client. Clerk provides a helper called withServerSideAuth, which allows you to access authentication information:
The snippet above checks to see if there is a session. If not, it will redirect the user to the sign-in page. Once the user has successfully authenticated, Clerk will redirect the user back to the page they were initially trying to access. Here is a quick GIF showing the process in action.
If you want to see it in action, check out this fully functional example that contains all the code you need for SSR authentication with a redirect back.
Server-side rendering gives you the opportunity to retrieve data from 3rd party APIs and your own database. When using Clerk, you have the option of retrieving the user ID, or if you are using a Clerk integration such as Hasura you can also retrieve the JWT ready for use.
Below is an example of retrieving a Hasura JWT token ready to retrieve data before sending the page to the user.
If you aren’t using a JWT template or a Clerk integration you can just retrieve the userId and use that against your own database.
In some cases, you may need the full User object available to you. For example, if you need to retrieve the user’s primary email address
Clerk can use an additional network request to retrieve the full User object. To enable it, you will need to add { loadUser: true } to your SSR request. Then, the complete User object will be available:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。