Learn NextJS's Superpower ISR in 15 Minutes

hello and welcome to what the video title says this is in this video you're going to learn how to use incremental static regeneration meaning that you turn Dynamic next year as routes into statically pre-rendered routes making your site way faster if you use this in your personal projects in your freelance projects people you're working with are gonna think wow this guy knows what he's doing and by the end of the video you will so let's dive right into it okay so let's take a look at how incremental static regeneration the superpower of nexjs makes your app blazingly fast it really does make a big difference and to understand how it works let's take a look at this graph right here normally next.js has no idea I mean how should it what's your user IDs could be right so this is a dynamic route inside of next.js meaning if you visit the you know slash users slash John next.js doesn't know what Jon is and therefore by default it renders that route on the server at runtime meaning that as your users request that resource the information gets sent back from the server to the client resulting in pretty high latency and that's not ideal so what incremental static regeneration allows us to do is tell nexjs which user IDs are there and then at build time so when we run yarn build or deploy our application at that time all these Pages you can see here on the right side are already built out a static HTML and Json for the information that is displayed on the page and what that does is when a user comes into our application and requests for example the slash user one right so it's not John anymore it's now slash user slash one next year is already has that information knows what information to display on the page and can immediately give that page back to the user resulting in way less latency and they're way better user experience that's why ISR is so powerful and it is really the super power of nexjs and now let's learn how to implement it and also to check if you implemented it properly I'm going to show you a little trick to check that um to see if you messed anything up so this is a nexjs 13 application and in here we are gonna make use of the incremental static regeneration now let me zoom in you so you can see this is a bit easier and then to get started with ISR the first thing we need to do is obviously a route to use ISR in and we do that in Nexus 13 in the API directory because next.js13 has a file based routing system same as next.js in the previous versions which means we can have a and that was from a previous test let's do that together in the API folder let's have a folder called user so that way when people go to your application they can type in slash user and then the ID right so slash user slash one and to get access to the ID on the page we can put in a dynamic route and we do that by having these little brackets right here we also use for arrays in JavaScript we can initialize that press enter and then inside of this folder we're going to have a page dot TSX which renders out a functional typescript component however if you don't use typescript you could leave all this away and do just fine with regular JavaScript there's nothing typescript specific in this tutorial so when we run yarn Dev and start up the development server let's try out if we can actually go to that route so let's go to localhost 3000 and then I can't zoom in for you the URL bar but I'm going to type in slash user and then slash one and of course that didn't work um and I think the reason might be because we yeah we put that in the API folder that's obviously not correct this needs to go into the source folder and then the app folder but not the API folder so we just want this into the app okay let's see if that works and it does okay so we're on the page I typed in into the URL bar user slash one and for all users because this is a dynamic route it was it would lead us to the user ID and then the page.tsx if you're wondering how to get access to that user ID we can have the user ID passed as params so we can say the params object that gets past this page automatically by next.js receives a param that is the exact same name as what you put into these brackets right here so that would be user ID user ID is of type string and then this is a bit typescript specific and but this would work just fine with regular JavaScript as well you just wouldn't have to type out this yourself and then we get access to the params and if we wanted to display whatever we put in as the user so slash one slash John or whatever we could use the params.userid check if that works and we are on path one if I input John for example as the user then it would show John because that's what we get back as the params right here great so now let's see some interesting behavior from next.js and to check whether we are running this certain route on server-side rendering or on incremental static regeneration or static side generation which is kind of the same thing then we want to run yarn build and by building this app out this is not going to take long because it's a very small project we can see for each page that exists on your application how that is being rendered by next.js and if we take a look at the slash user slash user ID that we have just created we can see how much JavaScript it ships but we can also see which is way more important for us right now what kind of Route this is and you see this little Lambda sign right here I think I can zoom in so you can see this a bit easier you see this Lambda sign right here and if we take a look at what the slander sign means it means that this page or this route is a server site rendered at runtime route and now your alarm Bell should go off that's not what we want right that's what I meant in the beginning of the video in this little drawing right here next.js doesn't know which properties exist so it generates them at runtime resulting in pretty high latency to the road and in a worse user experience so the goal for us right now would be to change the Lambda sign that shows up right here for our Dynamic Road as the this dot right here because that dot indicates a static site generation and with Dynamic params that dot would look a bit different we don't even see it right now because no page fulfills that expectation but let's turn this dynamically Run route at runtime into a statically built route at build time because that makes it way faster and the way we do that in Nexus 13 is actually pretty straightforward so from our Dynamic route we can export a async function called Jenna generate static params and put those little curly braces and this is a function name that is reserved by next.js so when we call it that it will know what to do and if we just put some random stuff in here so cons hello is going to be equal to ASD that it doesn't recognize it doesn't make sense to nexjs and if you tried building this application again it would let us know you know what we are trying to to do in this function doesn't really work right so because this is a reserved name we can't just do some random um some random Shenanigans in there we actually need to return an array from this and inside of the get static params you can make calls to your database to get all the user IDs that exist in your database because that's what you'd want right I'm going to mock this out I'm gonna say const user IDs is going to be equal to an array and that's just going to have one two and three but normally you'd make a call to your database here like so await DB and then dot dot person for example dot find many and then just get all the in the select get all the user IDs like so and then you return that from your function but I'm gonna I'm not gonna make any database correct I'm just gonna mark this out as I said to get the point across and then what we need to do is return the array from the function and we do that in a specific syntax so from this function we are going to return and then the user IDs dot map and for each user ID so that means we go through every item of the array and then every item of the array is available to us as this user ID property right here and we are going to implicitly return an object we do that with this syntax right here with a parentheses and then inside of them the cardi braces which is essentially the same thing as if we were to say a function block and then we return an object it would be the exact same thing syntactically just JavaScript makes it a bit easier for us and then in here we could say the user ID and return that from the function and this needs to match whatever is in the brackets up here just keep that in mind so in our case that's going to be the user ID and now let's see what happened to our page generation that's the little trick I mentioned in the beginning of the video that lets you verify if you did everything correctly so if we run the build command again with yarn build this is going to be really quick it's just a small project and now we can check if we did everything correct by checking the little sign in front of our Dynamic route and as we can see the road is now not rendered by the server at runtime anymore but rather this there's a filled out dot right now instead of the Lambda that we had before and if we take a look at what this filled out dot means down here in the legend I think it's called it says SSG automatically generated a static HTML plus Json uses get static props and what we just did is pre-rendered the first three routes because we passed in those as the user IDs meaning if we were to access them now in the browser it would be way faster than generating the information we need for them them at runtime now you might be wondering Josh that's good and all but if I change something about the user IDs how would the page know because this is done at build time right where I have to build out would I have to redeploy my app every time there's a new user and the answer is no you don't there's something really really cool when we are working with Nexus 13 specifically that we didn't have access before or just in a different form we did have access to it but now it's way more convenient to use as a developer that is the revalidate option meaning that every certain time interval this information right here is going to get revalidated right so if a fourth user were to exist then we could check every so often if there is a new user or if there's less users and then render the pages accordingly the way we do that is by exporting a cons called revalidate and set that to an interval in seconds this is not milliseconds so if I were to pass in 60 you'd know the default relation time would be 60 seconds if we hover over this we can see what it means if you have enabled the typescript version in your project directory otherwise this wouldn't say anything so zeros specifying zero implies that this layout or page should never be static it will always be changed at request time or revalidated when a request comes in that's not necessarily what you want because you really don't benefit that much from this functionality in that case a better option for you would be to set the revalidation time in seconds just like I just did and that can be zero or any positive number that you want and the number you choose depending on how often your data changes for example if your data changes once every month because you get it from somewhere and then put it manually into your database it would not make sense to validate every minute every day whatever however if there's a lot of new users a lot of fluctuation in the users in the documents whatever your Dynamic route is about then it would make sense to actually use a number like you know one hour maybe 10 minutes whatever and if we set this as false this is the default and changes the fetch cache to indefinitely cache anything that uses Force cash essentially meaning it's rendered once and then not anymore so when we deploy the application it actually s goes ahead and checks all the user IDs that we passed it but then not anymore and we would have to redeploy in order for changes to for changes in this array to show up on your actual page and that is probably rarely what we want except the data is very stale and almost never changes now interestingly enough there's a lot of options to do this revalidation you could do this on every single page that you want however you could also do this in a layout meaning if we wanted to revalidate the entire page we could go into our root layout of this directory and also in here we could say the exact same thing we could say export cons revalidate is going to be equal to 60 and by doing that we have just declared that the whole project should be revalidated every 60 seconds if that's what we wanted similarly if we were using some fetch right here so cons you user IDs and I'm just going to put an underscore so there's no naming conflict it's going to be equal to a weight fetch then we fetch from some URL where we get our user ID information from we could pass this an object and if we take a look at what we have access to inside of this object in nexjs13 we get the next property and this next property takes a revalidate as well so instead of declaring it as a constant like before we could just do it like this on a per request basis where every time we fetch the URL that is going to notice okay should I invalidate the cache or not so if this was sent you know within 60 seconds twice the the second one would be cached however if the second request was sent over the 60 seconds like 70 or 80 or somewhere above that then next.js would actually go ahead and check is this state are still valid that I'm passing back to the user and revalidate the Integrity of the data that we're requesting and just like that we can check if we applied everything correctly using the yarn build and then checking this little icon right here in front of our routes we can also see if we did everything correctly the routes that it has preloaded at build time now for large scale applications like you know 50 000 Dynamic routes or a hundred thousand Nexus can handle that but it will increase your build time because obviously these are made at build time so that's the case you want to consider whether it's worth sacrificing the build time for a faster user experience or if you have a gazillion routes then it would actually probably make sense to not use these static generation features but instead render them dynamically safe on build time that's all I want to show you thank you share with you thank you very much for watching I'll see in the next one hope you enjoyed this one and until then have a good one bye bye

Channel: Josh tried coding

Views: 26,442

Keywords: nextjs, next 13, nextjs 13, isr, incremental static regeneration, generateStaticParams, tutorial, how to, typescript, react, nextjs static props, josh tried coding, joshtriedcoding

Id: UgseormfMc4

Length: 15min 35sec (935 seconds)

Published: Tue Mar 21 2023