Sitecore JSS-next — Deep dive
Last week I was literally doing a deep dive into the new JSS that released part of Sitecore 10.1. Part of my investigation, I was doing these below:
- Setup JSS project and understand how does it work with the new Nextjs.
- SSG (Static Site Generation): How does it work with Sitecore JSS
- How different data fetching mechanism works within JSS
- How can we fetch data and apply SSG at the page level and component level
- How to extend JSS to be able to communicate to Sitecore ContentHub
- ISR (Incremental Static Re-generation) how can we leverage this in JSS
- A different aspect of Rendering hosts and how to change it to Nodejs or HTTP
- etc
My POC is not that fancy. It does look like below. I am not a FE designer. So beg my pardon about the design of my application.
Setup JSS project and understand how does it work with the new Nextjs:
For those who did work with an earlier version of JSS, it’s more or less the same structure. The only difference I found in the “pages” directory. This basically came from “nextjs”. We know NextJS has an automatic/dynamic file system routing kind of thing. In order to support that dynamic routing, Sitecore brought this up. Interesting is, it uses a generic [[…path]].tsx which is also the feature of nextjs. The idea is, any route that you will use in JSS will be matched with this route. (Including without path, i.e “optional catch all route”).
So if you use these routes in JSS, all of these routes, we will have [[…path]].tsx to be handled
SSG (Static Site Generation): How does it work with Sitecore JSS:
This part is quite interesting. Normally if we follow NextJs, it has the SSG/SSR functionality at the page level. Sitecore implements this in [[…path]].tsx file.
[[path]].tsx implements GetStaticPaths and GetStaticProps (SSG). So if we need to load any static data (SSG) or data loading via ISR approach, we need to use this implementation. Sounds good. But here we have a generic problem. What if we need to load different data based on different routes? I guess to solve this problem, Sitecore brought another data fetching approach called “Component Level data fetching via SSR/SSG”.
How different data fetching mechanism works within JSS:
In page-level data fetching, we will be using [[…path]].tsx implementation. Where to use those contents in your application? I guess we can fetch data from page level and can use them in the different layouts of the page. If we need to provide some data in the header/footer or any common section of our page, we can load that data in page level and can be able to serve them in different routes hence pages without spending any time.
Component Level Data Fetching:
Sitecore does some magic here. It extends the “getstaticprops” or “getserversideprops” in the component level. Anytime if we write “export const getStaticProps: GetStaticComponentProps = async ()” in your react component, it will be using the same way but at the component level. We will be needing this feature in many areas. So, when we want to display some data (based on SSR or SSG) on our component, we will be implementing this and will allow our component to be able to use this approach. For example, I have used this feature to load my different services (or teaser) at the component level so that it loads really fast (below image). Well, it’s fast without any doubt but it’s not live data. We will see how this will be solved via ISR (Incremental Static Re-generation) approach of NextJs.
How to extend JSS to be able to communicate to Sitecore ContentHub:
I guess this part needs a brief description and will require a full article. I will write another article next to cover this part. But when I was working with “Sitecore Content Hub”, I knew the importance of the ISR approach. Idea is, You should not load your content (from the hub) every time which is fine and will be covered by SSG, but at the same time, I will not be allowing the content to be freeze and stuck there in a static way forever. We need an approach to pull/refresh the data in a regular interval. That’s when incremental static regeneration (ISR) comes into the picture.
Incremental Static Re-Generation (ISR):
How easy it is to implement this? Well, just a single line. When we return the data from “getstaticprops” method, we need to pass another extra property “revalidate: [seconds]” which will tell when to fetch/refresh data next time. “NextJs” will track this time. So the idea is, if we use “revalidate: 60” means, the content will be re-fetched after 60 seconds. Now, imagine, we have a big chunk of static data generated during build time. Next 60 seconds, this data needs to be updated, right? What “next” will do is, it will serve the data from the last cache and will trigger an update/refresh so that the cached contents will be updated. Until that time, the user won’t wait, but to serve the last cached data. Pretty cool. Just love it.
export const getStaticProps: GetStaticComponentProps = async (rendering) => {const url: any = rendering.fields?.hubUrl;const response = await GetContentFromHub(url.value);return { data: response.data, revalidate: 600 };};
Here, I am going to refresh my content every 600 seconds.
I guess that’s all for today. I will continue my article and will publish another one soon. There I will cover:
How to connect to “Sitecore Content Hub” from JSS and pull data from there and apply SSG, SSR or ISR there.
Till then, bye and have a good day.
Arif
Note: If you need any code sample, knock me on my LinkedIn profile:
