 Hello, hello everybody. Gracias. I don't speak enough Spanish to be able to give this talk in Spanish, but I'm happy to hopefully read a little bit of you have questions in it. But thank you so much for that introduction. My name is Cassidy and I work at Netlify and I am here to talk about Next.js with all of you. And so I will be doing some presentations with slides and then I'm going to get into some coding and I'll show you how Next.js application is structured and we can go from there and then at the end, there will be time for questions and so you can ask as many questions as you'd like and I will answer as many of them as I can. So let's get started. We've already said my name. I'm Cassidy. You can find me at Cassidy. Most places on the internet. Feel free to reach out on Twitter, Twitch, GitHub, anything at Cassidy. So first I wanted to talk to you about why Next.js. Why was someone use Next.js instead of just React. And Next.js first came about because React is a client-side rendering library. Everything changes on the client side in the user's browser. With Next.js, it brought server-side rendering to React. So when you have a Next.js application, first and foremost it was for server-side rendering where you can render components on the server-side and then have better SEO that way. That being said, last year, it's actually just been over a year now with Next 9.3 in March last year. They did a shift to static sites as well. And so even though it did support some static sites in the past, now if you were to use Next.js, you could build both a server-side rendering application and a static site-generated application and really use the best of both worlds. It's a very, very powerful framework. There's a lot of cool things that you can do with it. And I'm going to talk through how some of it works next. And so first of all, what features should you know about when you're actually putting Next.js application together? There's a lot of developer experience nice to have. And some of those include hot code reloading. And so when you're working on your application, it'll reload quickly on the side. You don't have to refresh the page. That's actually powered by React Fast Refresh. And in the past few days actually Next.js 10.1 came out. And with Next.js 10.1, it made Fast Refresh much faster. It was something like 20 times faster. So it's nice and fast. And what React Fast Refresh does is when you have an application that, let's just say you have a counter, a very simple counter. And as you increase or decrease the count, the background color of your application changes, something simple like that. As you change the colors or update your code, your state stays the same. And so if I were to say, okay, I really want to check the state at five. Originally before React Fast Refresh, you have to say, okay, I'm going to check my code, then click the counter all the way up to five. Okay, that's good. Change the code again. Click the counter all the way up to five. It will maintain the state now. And so that's what React Fast Refresh does. It's really, really nice. And there's some other performance things along the underbelly of the application, but, you know, Fast Refresh is a big one to understand for that. There's also a lot of styling options available with Next.js. With the styling options that come out of the box, you can use Styles.js, you can use CSS modules, you can use less, you can use SAS, you can use pretty much any styling option that you want. You can throw tailwind really easily. You can throw in Bulma really easily. It all will just work, which is really, really nice. And so the fact that those are out of the box, if you want to use it, you can use it. It also has TypeScript support out of the box. You don't have to install anything special to make TypeScript work. You just change your filenames to .ts instead of .js, and it'll work. So with environment variables, you can make a .n file and add environment variables in, and it will use your environment variables. And I'll talk a little bit more about how those work a little bit later. And then it also does automatic code splitting. And so if there's any JavaScript that you write, but it's not used on the page, when you bundle up your application, it will get rid of that code that you're not using, so that way you always have a performant bundle that's pushed to the browser. So the routing in Next.js is really, really interesting, and I accidentally pushed forward. So the routing in Next.js is page-based routing. So when you make a file in the pages directory, it automatically becomes a route. You don't need to set up, for example, as React Router, how you need to list all of your different routes in a giant routes.js file. You don't need to do that. It just works when you add a file to that routes or to the pages directory. I'll talk a little bit more about that and I'll talk about more of those later too when we're getting into the code. The API for Next.js is pretty simple. These are kind of the four main ones that people use the most. There are some other ones, but in terms of these ones, there's Next.Link. Next.Link is a glorified anchor tag. It wraps around links so you can link between pages. Next.Link actually does client-side transitions, so they're super fast, and so it does some preloading of pages as you navigate between pages, and so Next.Link is pretty nice for that. With Next.Head, that is a React component for the HTML head, so you can programmatically change your title or your meta tags or anything like that, and that'll happen in Next.Head. Next.Router is a React hook, and with that, that'll let you get query parameters, that'll let you get the current path, that'll let you do some redirects and navigation, that's what the router does. And then Next.AMP, that allows you to generate Google AMP pages, and so if you will have a very article-driven website, you can use Google AMP, and it's built into the Next.js API, and the Google team actually worked with their team on that. The API is very similarly simple. There's Next.Builds, which builds your site altogether. There's Next.Dev, which runs a development server, there's Next.Start, which runs a production server, and there's Next.Export, which exports your entire Next.JS application as a static site. Typically, you don't have to do much with any of these. You'll run Next.Dev to work on this on your own, but it'll be the host that you use, whether you use Netlify or AWS Amplifier, Vercel, or any of the other options. They will be the ones running Next.Builds, Start, and Export, but Next.Dev is really the one that you'll be using the most. You can add custom configurations, so let's just say you want more than just TypeScript support, you want to be able to add other elements to it. CoffeeScript, probably not CoffeeScript, but something else if you want to add those kinds of things to your application. There's a Next.Config.js, and with that it's just like Webpack modules. You can add whatever loaders, whatever things you might want into your Next.Config.js, and it's fairly simple that way. Now PreviewMode, this is a particularly interesting feature. And this feature and then the next one I talked about are particularly interesting because they're static first, but require some node code to work fully, but they're interesting. So with PreviewMode and Next.JS, what this does is it assumes your site will be a fully static website, but let's just say that you want to preview what a blog post might look like, what a copy change might look like, something with a CMS, and you just want to preview, okay, what will this look like in my application? Great, good. And then you go back to editing it. Typically, if you do a static site, you have to rebuild your whole site to see that preview and you can run a deploy preview with that. With PreviewMode, what it does is it enables a, what's called a cookie-based redirect, and with that cookie-based redirect, it'll actually server-side render that page so you can see what that looks like. And then if you're happy with it, then you can exit PreviewMode and then bundle your application. And I can talk a little bit more about that, but it's a funky feature. And another funky feature that's similar is incremental static regeneration. I have a lot of thoughts on this one, ISR, but I don't have time to get into all of them right now, so I'll give you a high-level overview. And I also wrote a blog post on the subject which you can read about and see more details about. But what incremental static regeneration is, is you have your static application, but let's just say that you have, I don't know, 100, 1000 pages that you want to render, but you don't want to render at build time. You want them to just kind of happen later. And what happens is you can have your user go to that page. You can go to a page that you didn't define statically, and that page will start to build in the background. And then when future users go to that page, it will be a part of the static bundle. It has some funky caching stuff under the hood. In an ideal world, it works really, really well and is awesome. But sometimes in non-ideal cases, it doesn't always work. And again, I wrote a blog post on the pros and cons of this feature, but it's really, really interesting to learn about the caching under the hood. So I will share a link to that blog post in a little bit. That being said, let's code. I wanted to show you a NextJS starter project so you can actually take all the things that I just told you and actually apply it. NextJS starter project is right here. It's at cast.run slash next starter and I'll put it in the Zoom chat as well, cast.run slash next starter. It's on my GitHub. I just made a little URL shortener for that. And that being said, I'm going to stop sharing just for a second so that I can start sharing my code. And now you can see my face. So one second as I move some windows over and then I will share my screen again. Sharing. All right. So we have our NextJS application. By the way, if the font size on the right is too small, let me know and I can zoom in. So on this left side right here, we have the basic NextJS starter project and this is the one that I just linked to you. NextJS starter is using create next app. That is a CLI tool that you can use for that. But it takes out some of the extra things that are built into it and then it adds a couple nice to haves that I always use when I start a new NextJS project. It will go through all of those with you. But if you click this deploy to Netlify button, it will automatically deploy that project to your Netlify server and then it'll also clone that to your GitHub or to whatever Git provider that you use. But anyway, this is what it looks like. And for those asking about my VS Code theme, this is called hack the box. Anyway, okay, so first I will go through some of the code and you can see what this app looks like a bit more under the hood. So first of all in my package.json, we've got the latest updated NextJS and then also react and react down. And that is it. It is very, very straightforward. Nothing extra beyond that. It's just next and react that's included. And then this index.js we have a pages directory right here. And again, if you can, if you can see it, I can, I can zoom in a little bit if you can't see it, but I'm going to do this so that way. So we can get all the code in there. This is some basic HTML. You've got the main which is the header right here that says welcome to my app. You've got a paragraph, and then you've got a footer right here that is this component right here. I have a components folder. And so in the components folder we have the header which is just it takes in the text which is welcome to my app. And the footer, it's very similar. But with this footer, we also have this footer.module.css and so I'm using CSS modules on the footer right there. And so those are the two components that are included. So the jsconfig.json you might have noticed and if you didn't, I can show you again, you might have noticed that I used at components inside of my index.js right here. That's because something that's automatically included in next js is absolute paths. And so I can define my components folder as at components and that means wherever I am importing something I can just use at components for it and you can think of this as really useful if we were to do like at design system or something and you wanted to just do or for example at design system slash buttons and that lets you avoid doing something like dot dot slash dot slash dot dot slash whenever you're importing something. It's really really nice to be able to do these kinds of absolute imports. I also did the same thing with styles I added some global base styles so I have styles folder the global base styles basically just do some normalization and nothing much beyond that. And there's a page here called underscore app.js. These two are the main ones that you will always have in a next js application your index.js which is your homepage. And then underscore app.js. This is where you add anything global. And this is also where I will say that there are caveats with next js router, because in the pages directory that's where you can add as many routes as you'd like. You can add a page in here by just doing new file and then contact.js and I could copy the index.js over into contact right here and rename it contact and I'll say contact me like this. And then if I were to save it and then over here go to slash contact. Hey, and so it's that simple to add a route that being said whenever you want anything global it has to go through this underscore app.js. And so that's where these global styles are coming from. And so if for example you want to share state across your application, you could do it in a context right here and so I could do a react context and then wrap this component like this, and then voila, you have a context that is shared across your application and that's how that works. The caveat is if you wanted to only share state across like two routes, you can't view if you wanted to share it across like four routes out of 10, you can't, you have to share it across all of the routes. And that's the caveat with with the with the router it wraps the entire application in there. And so that's just that's just something to know. So if I look at this and be just like, Ah, yes, this is a regular react component, there's nothing fancy in here, and that is where you're wrong there are a couple minor things that you can do that that can make a big impact and that's because page based components are very different from regular react components and so right here this is just a header again that takes in text. When you look at the index.js, a page component is actually, it's a react component in this part, but everywhere outside of this is node code. And so when you do when you want to, for example, do something related to querying data or something you would be using node fetch code outside of this actual function right here. And I'm actually going to show you a more complex example and we can implement something together, but I'm going to go to my GitHub really quick and I'll paste a link. And then inside of here, I'm going to find my next pranks repository. So this next pranks repository I actually, I gave a conference talk on this and it talks about it in here. But in this next pranks repository. I use some of that node code and this activates some of that incremental static regeneration that I mentioned before, as well as some other fun things and so in this prank I could be like, Cassidy totally nailed this presentation. And then I generate this link. And then this link when I click on it, it says it rickrolls you, and you didn't expect to be rickrolled today did you. And then it also says Cassidy totally nailed this presentation, not you've been pranked and it generates a news page. And it's pretty fun. And what's what's interesting about this application is it does that kind of node code side of everything but it does a little bit more with dynamic routes and everything and so I'm going to talk through it a little bit. So first of all, you see the homepage, which is very, very similar to the index.js that I showed you before it has some state, which state it's it's react state nothing particularly different in there. It uses next link. I'm going to zoom in a little more so you can see with next link. It's again it's just wrapping an anchor tag and so it generates a new link to for users to go to. I didn't expect to be rickrolled in a webinar. Well, you're welcome. And then also, you notice I have a folder called news right here. You can see that in the route it's very very small I'm actually going to paste this in the chat so you can look at this yourself. It's just slash news, and that's what shows up in the route, and then it has this Cassidy totally nailed the presentation. You might notice this file name right here is in brackets. When it's in brackets that means it's a variable, and you can program programmatically change that and so Cassidy totally nailed this presentation matched this variable right here. So inside of here we have two functions that are worth noting get static pads and get static props, and those are the big node functions to know inside of page components. Get static pads means whenever you query something in here that'll generate all the pads that are possible to be rendered in a next JS application so for example if you have a CMS, and you wanted to have blog posts and you wanted all of your blog posts to just be the pages that exist in there, you could call a fetch call inside of this function, and then you would populate this pads directory, or this pads array with with all of the strings that you want. Because I have an empty array that means that it's just a variable I don't have any predefined pads, it's just going to be a free for all. And this fallback is true means that if it's not inside of here we don't return a 404 if this were false then it would 404 if it was outside of this this path saying and I have more examples on this that'll talk about get static props is it actually passes props to the page components. And so what I'm doing in get static props is I'm getting the parameters of the URL. I'm converting it to a title so that way it can be the title of the article and added to the head of this application. And with that I'm then passing it to the article and it's generating the the Rick roll and everything like that. And so this is this is where your node code lives in get static pads and get static props. I'm going to show you another example. And this one is called next adventure. Someone mentioned redux. I'm not going to be showing redux but I will be showing X state and state machines to in this particularly particular example. And so this is an application that I made for Halloween called a lonely code filled night. It's spooky. And this was a particularly interesting application to build because it uses a bunch of different technologies. So first of all it uses X state for state management, and I make a choose your own adventure story with X state and I made I made a story which I will show you in a second. It also uses react, or Netlify forms, and it's a react form with Netlify, and it pushes to a Hasura database. And so, in the choose your own adventure story that I talk about. You can create a character here and I'm actually going to, I'll put the URL, put the URL in the zoom chat so you can check it out. So when you create a character you can put your name you can add the pronouns, put the characters favorite smell that comes up in the story, and then you can put your email. Then when you click this send button, what it does is it triggers a serverless function that then populates a Hasura database, which then randomly populates a story. And so this story is, it's different every single time with the different characters that are coming from the database. Don't abuse it please. And it says once upon a time there's a developer named Narwhal who's working very late at night very late at night on Halloween. And then it says Narwhal decided to take a break to get a snack he went to the kitchen couldn't decide what to eat. We can decide to eat an apple or eat some candy. I'm going to say we eat some candy he munched on the candy. Then he heard trick or treat that I could outside. We're going to either ignore the kids or answer the door. I'm going to answer the door he opened the front door but no one was there. It was very, very spooky. But it was probably good because he ate the last of the candy will ask if anyone's out there. He called out in the night who's there suddenly a werewolf comes up and said have you heard of type script and eats him the end. And so this is a very, very detailed story as you can imagine. But what's cool about this is is how it's implemented and not to brag about my own code but it's kind of neat. So here's what it says. First of all there's the underscore app.js that I talked about in that underscore app.js we have the global styles, but we also wrap the entire application in a react context. And this react context is something that I put in a context folder, and that shares the state across the entire application. The other pages are there's the make your own page and then in this make your own page that's where we have the form that I talked about, and it's otherwise a very very simple custom form there. I also have a success.js this is a page that shows up whenever you make a new character, and then index.js also just navigates between the different pages. Those ones aren't as interesting. I'm going to show you next the context because the context has very interesting elements to it so first of all an app context. This is creating a react context that pulls in a character which is pulling in from that character database that I that I mentioned in the first paragraph. And we generate a random character that we then pass to the rest of the application and then that character is the thing that is used in the story. For the rest of context we have a state machine and this state machine is generated with x state, and it is kind of, it's kind of hard to pull in all of the code into your brain right now because it's big, but what's nice with the state is it actually has a visualization so you can draw out the tree that you want in in their visualization library and then turn it into code. And so I have all of these first levels of the story where where you start the story and then there's the first level story the second level and the third level. I'm going to go deeper but this is this is how that works. And then I generate a state machine. And so for every single state, I have the starting value and then I have the story. And then every time you click to a different thing so the first button there was going to the kitchen. Now there it goes to the story and then there's two different states that I can go to and then it goes out into a tree. It gets fairly complex as you can see it, the code is long for generating this whole story, but that that's that's how it generally works. And then at the end, I create the state machine and I pass it to the react context that we talked about. One other thing that that was just kind of interesting was I made a pronoun generation library in here. This is not next JS I just thought it was kind of fun, where when a person picks masculine or feminine or non binary pronouns, it then passes that to the different story portions so that way it can be correct with the character that is passed in. Once we've made this state machine we pass it be a context to the rest of the application, then we can go to back to our pages and we have this S folder right here, this S folders the story. Now this is a more funky file name again where it's in the brackets, but also it has dot dot dot in it. And so it has dot dot dot story. That means that yes it's a variable name but it also can be spread. And so, when we navigate through the application if you were to go through it snack time will eat an apple this time. The path in there I'm going to paste it in the zoom chat so you can see a bit more. It has slash S which is the folder name start which is the start of the story then snack time, then eat an apple, because it has that dot dot dot in the file name. It spreads it out and so you can have as many paths matching that as you want. And still, if you want to define those kinds of paths you you would use the get static props and populate those pads. But in this particular case it's just that way we can keep track of where we are in the story. And so inside of here, I have the story block which pulls in the text from the state machine. And then whenever you click the button. What it does is it uses that use router hook that I told you about that that next router API right here. It pulls in the router and then it basically makes a little bit of a redirect and so it does a router dot push and so for every single pay page in the story phase of the story, however you want to call it. It adds it to to the different pages and so you can this is actually a very small component it's it's less than 60 lines of code. This powers the entire story with with that x state library. And so it's it's it's pretty interesting what you can do with these pages that are a combination of everything. The way that I did this this is actually client side routing to all of the different pages of the story. And at the same time, it's also statically generated, because we statically generated the homepage, as well as the make your own character page the success page, and then just the kind of shell this, this dot dot dot story page. We statically generate that that individual page but then we client side generate all of the other components in there because of how the link works and because of how the router works. It's kind of funky to wrap your mind around I admit even making this this demo I was kind of like, Oh, so if I do it this way. This will server side render that page but if I do it another way it'll client side render it. It kind of combines the all three of the worlds of client side rendering static site generation and server side rendering, all into one framework which which is very very powerful and so, for example, let's just say I wanted to make some kind of content. I could theoretically pull in a page statically have a database and then client side search through the directory and have it all live in one giant code base. And so I mentioned this code base before I'm going to paste it in there. I saw that there were there were some questions about testing this particular application I didn't test probably should have but I would probably use either just to react testing library for it. Um, so anyway, if you wanted to query an API you would use something like that that gets static props and get static pads. I want to be aware of time I think I have a little bit of time to query something and so we can do that really quick does anybody have any questions while I get ready to query something. I want to make sure that I get questions answered. I'm going to keep going in. And so let's just say I wanted to query an API right here. I actually have a gist. I'm going to pull up my gist on GitHub I have a gist where I query Pokemon somewhere. There's a Pokemon API that is nice and simple to use. Search Pokemon yours. I guess I don't that's fine. I'm just going to go to poke API dot co. And we have the Pokemon API here. So we can we can query that Pokemon API and and I can show you what that can look like in next JS and so let me pull up my starter again. And so let's just say inside of contact. Instead of contact I'm going to rename this to Pokemon. In Pokemon dot JS I'm going to do export a sync function. Get static props. And then in here this is where I'm going to fetch the Pokemon API. And so that's going to be this HTTPS poke API. Let's do that. Response equals a weight fetch. And then in here and then I'll do Charmander for now. Okay. In here what we want to do is we want to return an object that has props, and then props will have response right here and that response can be Pokemon. And we'll pass it right here and I might need to do some parsing. But we'll start with this. Now, this is this is the part where I wanted to talk again about the node and the react stuff. And this, this is just react inside of this, this is node. And so, if I were to do, for example, console dot log response right here. What will then happen is, let me actually restart my dev server and then refresh the page. Oh, I got to actually go to slash Pokemon. Okay, ooh, that's yelling at me. This is fine. When I do that it's this is giving me a node error. It's, it's, it's console dot logging down here and not console dot logging in the browser. Then this is my own fault I probably should have prepped my API call before doing this, this part of it, which is fine. One second. I think I have it written down somewhere. Yeah, we're just going to copy some of this really quick on my monitor and then paste it over here. Now, if I were to do a response. Okay, Pokemon is not defined. Oh, that's my own fault again. Ah, sorry about this. Again, I needed to copy and paste this. Oh, I need to call that Jason. Thank you. You're right. I'm going to a wait and then Jason. Thank you for that. The joys of live coding. Okay, beautiful. Okay, look at that we've got we've got the sprites we've got the name of the Pokemon we've got Charmander, all of that thank you for the dot j something I needed that. And so now we can actually pass that to our page. Okay, so I'm going to inspect element right here now again in the console we have nothing, but if I were to do console dot log response right here. This is actually going to be putting it into the browser console and so this is this is the context thing I was telling you about this is node. This is react. This is where the browser is is doing things this is where node is doing things. What's cool about this though right now we're just we're doing this as a developer we're doing this as run dev. But this happens at builds time when you deploy your site. And so if I were to deploy this site somewhere this is double a wait, I'm not going to question it right now. When we deploy our site, all of the fetches that we do inside of here will happen at build time. That means when the person who is going to your site accesses your page, they won't have to wait for the pokey API to return Charmander. It's just going to just work. It's just going to have the results of that API call from builds time. And so it's super super perform it when you have a site that is statically generated at builds time where where you make all of your API calls then, and then the user will just get what is returned to the browser it doesn't it doesn't care when those those API calls happened it'll just actually be be generated in there. Because it promises. Oh yeah. Again, it's doing it live. And so we have this response I could say like instead of contact me, I could say something like hello and then response dot name. And then look at that hello Charmander, and then we could pull in a sprite like this and so if I wanted to do an image tag I could do image SRC, and then in there. I think it's response. Sprite. Response. Sprite. front default. Yes, maybe save it try it. Yeah, look at that. We got Charmander. And so we could do this with all of the different Pokemon. We could actually do this where if we did get static pads and turned this into the the square brackets, we could generate a page for all of the different Pokemon, have that run at builds time. Whenever a user goes to slash Pokemon slash Charmander slash Pokemon slash Pikachu. So any of these things, those pages will already be generated and it'll just, it'll just work for them they don't have to worry about the pokey API going down or something, because the pages have already been generated. So dynamic paths parameters can you pass the values you want generated at build time. Yes. Yes, that's exactly what gets static pads does. And I'm trying to be aware of the time because I want to get questions answered. I'm going to try this really quick. And so, in here I'm going to make a new folder I'm going to call it Pokemon. And then inside of here I'm going to have a new file and I'm going to do in brackets pokey dot JS. I'm going to copy all of the code that we wrote in here and put it inside of here and I'm going to rename this to nothing, just to have that there. Okay, so now we have a 404 because of that that makes sense. But now we want to be able to go to Pokemon and then this pokey dot JS. So what I want to do is I want to do export a sync function, and then get static paths. And if here is where I'm going to get all of the different Pokemon names. And because I don't want to go through too many API calls I'm just going to say, we're going to return this object in here and then paths. I don't want to have three Pokemon, or say whatever Pokemon you like and I'm just going to put Charmander, and then ditto, and then whoever says the first Pokemon, I will put it in there, someone said mudkip. Nice. Okay, cool. Wow there's actually so many. Sure. I'll do it. I'll do a few other ones. Okay, anyway, I'll stick with these for now. So we get these we get these pads that are passed to the array. And I'm also going to do fallback is false because I want all other pages to 404 outside of these pages. Now with these pads I also need to do slash Pokemon and so it's actually going to be slash Pokemon slash Charmander. This is something that I think is a little quirky but it's okay. It's slash Pokemon slash all these different things. And now, inside of get static paths, or it gets that props I get the params, and then the params will be that Pokemon name. And then that Pokemon name will be passed inside of here and so it'll be params dot pokey, I think we'll see if that's correct. So I were to refresh the page now. Oh, it's slash Pokemon slash Charmander. Yay. Okay, it worked. And now if I did Pokemon slash mudkip. Yes, it worked. Yay. And so we're pulling in pokey because that's the that's the file name there. We're getting the different parameters to pass to each of these and then we're fetching all of that. So at builds time, we're going to get these four pads generated, as well as the response called at builds time and so our users don't have to wait for the API to be called they can just go to that page. Is this feasible with large data sets. Yes, we actually I don't know how much I'm allowed to say because I don't know which customers are secret of ours but some of our customers at Netlify in particular who do this exact thing. They generate there was one customer that we had recently that generated 400,000 pages. And because they did static for static builds really really fast. You can have a lot of serverless functions or anything you just want to generate the pages and call the call them in these functions. We had one customer that had thousands and thousands if not hundreds of thousands of pages and their builds time was I think four minutes for all of them. And so that's really that's really really not bad when you do purely static and then if you if you start adding more things like serverless functions and more detailed things, you will get longer build times but it's totally feasible to be able to do that. If you did want the user to load any Pokemon not just the four we define in paths. Then actually, I think I could do fallback is true. And I'm going to try this I'm going to say mute to and see what happens. Yeah, it didn't like that. That's fine. We do need to actually generate so more of these because it'll be upset. So what I would do here if we wanted any Pokemon and not just any of not just what's here. Because right now if I were to do fallback is false, it'll do a 404 if I did me to otherwise it errors out. What we could do is we have to do a bit more validation. You could query the Pokemon API right here, and then just get all Pokemon names. I have a demo of this somewhere but I don't know where it is off the top of my head. But you would query all the Pokemon names that you want, you would still pass it to the pads array and then you would get the prams the exact same way and get static props. Okay, I am now going to stop sharing my screen and start answering questions so that way we can get all questions answered and I can go back to showing code as needed but I see that there are a lot of questions here so I just wanted to check on that really quick. Okay. So, um, what happens if the request change after the after the build, there's a few things that you can do. And there's actually a really good case study on this on the Netlify blog that was just released like last week. Because that that one of one of the customers that we had dealt with that. And it was a very, very interesting case study. I'm pasting it in the chat. So, what a lot of people do is they have some kind of web hook. And so whenever the web hook is queried it'll just rebuilds the site with the new data. But also, one thing that we do with Next.js is let's just say you want to do incremental stack regeneration or you want to do server side rendered pages, you can still server side render those pages with serverless functions. And so we do it where if you were to do some more server side rendered pages which let's just say I did want to not just query Pokemon but query something else or or or have some pages that aren't included in the original build. I mentioned before that I have a blog post at cast out run slash ISR to talk a bit more in detail on that. You can do that and it'll just use a serverless function to query it and and so you can server side rendered those pages if you don't want to wait for the build every single time that is a possibility. That being said it's slower for your users and so it's kind of like you have to decide who who is more important your your developer time or your user time. There's no wrong answer there but that's that's something to consider for that. So what are the cash invalidation process or what are the strategies around how specific assets or pages work. Look at my ISR blog post because because that answers some of the the caching things we actually have some new things coming out next week around this particular subject. And so keep an eye out because I can't talk about it until then. The cash invalidation typically when you do a new rebuild. It's an atomic and immutable deploys and so you'll get a brand new cash and a brand new deploy with every single one. If you don't have Pokemon on the paths we could use get server side props. Yes, yes you can so you can use get server side props once again that's something that works in next JS but it kind of moves away from the the static first approach that they've been pursuing but get server side props works and that's where you server side rendered pages with the serverless functions. Any tips on moving from create react up to next JS. Honestly, create react up is great because everything kind of lives in a div. You can move your entire create react up into an index.js on your next JS app, and including including your router which will lead to some funky bugs but you can, and then slowly move out all of your different pages into the pages directory. It's a really smooth transition process. Depending on your application. You might want to decide if you want to do that. One, one thing that I just want to note is, again, if you have, if you have a large context object or a lot of states that you're sharing across routes. What I like about regular react is let's just say I'm using react router. I could wrap a context around like three of my routes, and just share state around those routes, and that and have it not affect any of the other pages. With next, your context has to wrap the entire application which can lead to some unusual re renders and stuff pros and cons pick your poison but that's that's something to note there. I'm beginning of the presentation that there are some set advantages like SEO. Could you explain deeper end of it. Yeah. And so that's actually something that look a bit closer at that next pranks application. It's, it's a silly application but it uses some interesting things under the hood and I'm going to particularly send you to this prank heads.js file I just dropped it in the chat. With static sites and with server side rendered sites your SEO is greatly improved compared to client side rendered sites because the pages are built ahead of time. It's actually best SEO is best on static sites. Next best on server side rendered sites and worst on client side rendered sites but again it's kind of a spectrum of things and SEO is improved every single day for for developers who want to do all of them. And this particular file that I sent. You'll notice that I programmatically update the title and I changed the Twitter card and and the og images and everything. That kind of stuff. You can programmatically change in next jazz really really easily. This is something that you can't do as easily in a regular react application. And so your SEO is greatly improved by just being able to use that next head API. So you can really programmatically update that. Let's see, you're able to use all the other react hooks right right, it's still just react, it just adds some structure to react but yes you can use all of the other react hooks. And again, you use them in the react part of it, not in the node part of it you can't use use effect in get static props or get server side props or anything. You do it in the components themselves. What about deploying. What can I tell you about deploying I don't know what what questions you have but actually I'll I'll pull up my next starter application for example, and show you a little bit about how that works. One second. I will share my screen again. And so here's here's for example where where I deployed this project right here. And generally how it works first of all, your domain name appears here whenever you, whenever you deploy it builds and then publishes and you can see that you can look at the logs for that particular deploy and see what things might have gone right what things might have gone wrong well warnings you might have it goes into pretty solid detail on that. And also there's a there's a few different things that you can do once you have deployed, you can change your domain name. And so you can change your, your site name here and add whatever custom domains that you want. You can roll back to any other previous deploys that you have you can add any build plugins. We automatically at Netlify install this essential next JS, you can uninstall it if you want but you won't want to. You can do a list functions happen here, Netlify identity is something for for logging in and out if you wanted to drop in logging in and out to your application and authentication. I have a blog post on that Netlify forms this is what I mentioned that I use in the next JS adventure of application I added Netlify to the form and it automatically pulls in all the form data. You can do split testing and that automatically lets you do a be testing across different branches. That is that is the high level summary about deploying that I think I can tell you, I don't want this to just be an ad for Netlify it's more about next JS but that's if you have questions about that I'm happy to answer them. Let's see not a question I want to say this is amazing. Thanks Jose. Do you actually recommend to skip an independent server and make all the next JS from projects if it in Adrian I'm not entirely sure what your question is asking would you mind rephrasing it. Let's see what is the best way of creating a multilingual application with next. Next does have a thing called next internationalization. And so they they actually have that built into the framework that being said, I think that there's some better internationalization libraries out there. And so I personally use other internationalization libraries rather than the one built in just because there's some funky base path things that can happen. But yes, you can, you can do that built into the framework. You mentioned that the request to the API are made during build time what happens if the API response changes. I kind of answered that before that you can either server side render it every single time so it'll it'll run on a serverless function, or you can rebuild the site and have a webhook or something when the API response changes. I'm confused is next is only for static sites, it can be used for static or server side rendered sites, it's fastest on next sites are on static sites though, and so I tend to recommend that because I like the speed of the static ones. What's the difference between react server side render and next JS good question react server components are very similar. I don't know where the demo is otherwise I'd send it to you we made an interesting demo with it basically a server component is still experimental so don't bank on it. I have regular meetings with the react team and they're all kind of like, you know server components are kind of an R&D we might throw them away, but they're there we're trying so don't go all in on server components yet. So there's still a lot of changes to be had there. That being said, with server components they can be run at builds time to for static sites or on a server side rendering things. Next JS provides a framework for react and for doing that sort of thing and they will probably implement react server components, but react server components are. It's basically just a separate library from from next JS at this point. Next will probably implement them but it's a separate thing. I hope that answers your question. If you're using TypeScript will the react function recognize the typing what gets died props returns. Yes, I am not a TypeScript developer, but yes it pays attention to that sort of thing and you can do full typing inside of the get static props stuff. Connect just handle pie time hope so. Coming from a view and next background I'm really liking all the stuff the react community is is coming up with yeah and and honestly next for view is kind of the same as next for react. I've heard that next actually has better a API support and everything and and does a lot of cooler things, but I haven't used it enough to be able to say if that's true but they both generally do the same thing next and next just if you prefer view or react. Let's see, does using less or SAS require extra config less does not SAS does require node SAS because of the weird pages thing that I told you about how it's like kind of node kind of react and and it's a combo of both. You will need to install node SAS for SAS, but that's it it's just npm install node SAS and it'll work. If you have an API call that changes a lot and create a static page from it how do you refresh the data from that static page. I would say it depends on what that API is for myself I tend to statically generate the page as much as possible, but then if there's specific parts of the page that require that I actually do a lot of client side rendering of those individual things and just have a util for that. I think it's very okay to use all three of client side server side and static site generation and mix them all together and figure out what is most performant for you. I think client side is still a perfectly valid way of doing things and and again it depends on on what you want to do because you can just keep regenerating a static site depending on how big your site is there there's one and let me see if I can find it. There's. I just totally messed up I was looking at my coworker Phil but I just looked up the name Phil and Phil Hawksworth which is very silly thing to do. But he made a very cool site called virtual lollipop. And I'm going to paste it in the chat here it's V lolly dot net. And he generates the site every single time and it generates really fast like 15 seconds, super super fast and it generates a new page every single time and and it's really interesting. It's great to continually generate your your pages, you just want to kind of decide how much you want to do that and and sometimes I like to save the build time and save the server time and just do client side rendering things but it's it's really up to you how you want to do that. And some next jazz projects I've always get the use, remove unused JavaScript and Google Lighthouse. So because of next. That's interesting because next automatic code splitting should be able to remove a lot of that. So, I'm not sure if that's because of next. And I'm sorry that I can't help you with that. I think we are out of time, but thank you so much for for all of your questions I'm happy to answer more of them I'm also going to be live streaming in a few hours. And so if you have more questions then I live stream on Thursdays at twitch.tv slash Casa do. And so I can answer more questions there if you have them but thank you all so much for your time it was really fun chatting with everyone. Thank you so much Cassidy for being once again at Weisland Academy for your time and for sharing your knowledge with entire community and for the entire community. Thank you very much for being here today. Don't forget to fill out the feedback survey get a chance to win $30 Amazon card. It is very important for us and for Cassidy as well to help us improve. See you in our future events and have a wonderful day everyone. Thank you. Thank you for having me.