Dynamic Content Q&A

[00:00:00]
>> Any questions on this?
>> You said that, when you are on Next.js environment you can use node code, that also means that I can use something like, child process to execute operational system processes, or something like that.
>> Because we can use node code inside of Next.js functions, I guess static props.

[00:00:22]
Does that mean I can do things like spawning child processes in the background? Well, you have to ask yourself. Can you and would you do those things on their traditional like node server? And the question is, yes, then the question would be yes here, too. I don't recommend doing that.

[00:00:43]
But because, everything that's gonna be inside of these functions is gonna be blocking. As in the page is not gonna render until everything is done right. So, if you have some ongoing tasks, that's, well, I guess a background drop isn't technically blocking. But if you have something that was blocking, then the page isn't gonna render.

[00:01:02]
So, if this function took forever to process, seeing how this one's getStaticProps, this is gonna increase your build time. If this was a getServersideProps, that's gonna increase your run time, your load time at run time. Right, so, it's probably not the best place to put those things, because these things aren't meant for long running processes.

[00:01:25]
I would probably still put those things in, like, background jobs on my hosting provider or somewhere else and not inside of these. But you can run it. I'd be curious to see. What the side effects of that would be, all right. If this hasn't blown you away already.

[00:01:43]
Don't worry. It only gets crazier from here. But this [LAUGH] blew me away, when I learned this about next year, when I first started using it. so, yeah, pretty intense. So, the next thing you wanna do is just wanna kind of do this-
>> One second, question around caching, if you're gonna get into that later.

[00:02:02]
>> Depends on what type of caching. I could talk about the caching that we get for free right now. Next, as does cache the static pages for us, which can be served by CDN. So, if you're worried about every time someone goes to your page that this is gonna execute every single time.

[00:02:22]
Well, it's not true not in the case of this page at least. Because we're doing a getStaticProps and it only happens at build time. And then you're good to go. If this was a getServersideProp, whatever is in here will be executed every single time someone hits your route that this dysfunction is on.

[00:02:40]
So, it would be up to you to figure out how you're caching those resources that you're trying to get data from, right, cuz you might be hitting. I don't know two different things in this function. One is a database, one's an API, one third party thing. I don't know some something in Redis, who knows, like, it's gonna be depending on how you cache that stuff there.

[00:03:00]
Because at the end of the day, next year, is just waiting for that function to finish, to bottom out so it can actually return those props. And while that's happening, the page is going to be in a loading state. So, it's going to definitely slow down your experience.

[00:03:14]
If that's the type of caching you're talking about, then yeah. The other types of caching that we're talking about like performance on this site and front-end stuff. That comes down to the provider that your deployed is on. But at the end of the day, everything static, it's mostly going fast.

[00:03:31]
>> Like I can clearly see there's some CSS on this post, but I cannot see where those time files?. There is just one file called Global.CSS, but I don't see any other files.
>> [LAUGH] Yeah, that's because I'm using a component library called evergreen whereas it, I don't think it's in here.

[00:03:54]
It's not on this page, but I'm using, Here it is. Yeah, I'm using evergreen UI, which is a segments component library. And it just comes with a bunch of styles for free. So, yeah, I don't really have a lot of styles that I wrote myself. I just NPM install the library.

[00:04:12]
>> Why would I need this GetStaticProps? Wouldn't it work if I just don't have it and try to load some ID?
>> Well, let's get past the part where Next.js has these hard checks on if you have a dynamic page. And it doesn't have getStaticProps that'll break. Let's assume that, that doesn't happen, okay.

[00:04:30]
Let's assume it does try to attend to load this. So, what would happen? Well, if it's hard to attend to load this, one, we'd find out that these props would be undefined. There would be nothing here cuz these props actually get injected by the function that we were just making.

[00:04:43]
So, there'll be nothing here. So, let's say all right, this doesn't take any props. So, that solves that problem, okay, cool. Okay, well, then how would you get the content for this page? So, then you might ask, well, if my content is on a CMS or somewhere with API, I just make an API call right here.

[00:05:03]
Isn't whatever flavor window.fetch sure. And you will go get it. Yeah, absolutely, you can do that. At that point, you're basically building a single page app, right? That content wasn't rendered, it wasn't there statically. So, therefore, if crawlers like Facebook's crawler or Twitter's crawler like you're not gonna see that being indexed on those crawlers.

[00:05:24]
I think Google can handle it now, obviously. So, it's basically this it's not gonna be rendered on the server, it's not gonna be cashable, it's going to be dynamic. It has to be computed every single time someone hits that, which is what you wanna do for like user data.

[00:05:37]
So, if you were like making a call to get the signed in user here. Yeah, you would always wanna do that. But for content that's meant to be static, you probably wanna get that before this page render. So, yes you could totally do without these functions. But then at that point, you're basically just building a single page app.

[00:05:52]
>> So, if you state your fallback to be true. And you're dealing with same API point or a file path that doesn't yet exist, how would you deal with that kind of failure? And what if the data does appear five minutes later? Would it kind of cache the bad data or the fact that it doesn't exist?

[00:06:09]
>> It would only cash it, if the getStaticProps didn't break, if it didn't error out. So, you can throw an error in here, like we're gonna write the code but, you can handle however you want. And you can even, you could literally do whatever you want. You can send back a different some HTML.

[00:06:26]
I mean, there's a lot of different things you can do. You can do a redirect, I think the best thing, because you gotta think about it, like, what type of experience do you wanna show a user, right. What do you wanna do? Typically, I think a 404 looks is probably the best way.

[00:06:43]
So, showing them a 404 might be good. What I've been doing is just like throwing an error. And having like the the provider handle it. And use the provider just shows a 404 page, it'll just show whatever 404 page you registered there. So, there's a lot of different ways you can kinda do it, but I think 404 is like, that's what I would expect would happen about once page didn't exist.

[00:07:04]
>> Sure, and then just to understand if there's no caching, then every person who goes there were just like a three second load time didn't have to wait three seconds and both.
>> no no no, so like, let's say, I went to a route that didn't exist. Lets it was called \learntocode, okay?

[00:07:19]
And then it generate it for me. And say, it took three seconds to generate, okay? And then two seconds later after I did it, you did it all the way from London, you went to the same route. It's cached for you, you don't have to wait that three seconds.

[00:07:33]
Okay, yeah, the question was, if getStaticProps failed because it was a dynamic page that didn't exist. Does the next day has cached that failure. So, the next person doesn't have to wait to get a failure. No, I don't think it, I think it depends on how you fail it actually, right?

[00:07:50]
Like if you do what I call like a soft fail, where you don't actually throw any errors inside of your getStaticProps. And instead you actually do render a page. Let's say for instance, if you determine that, wow, this thing doesn't exist, it's a fake page. So, now, I'm gonna send down a prop.

[00:08:05]
And I'm gonna send down a prop here called 404 true, right? I'm gonna do something like that. And then up here, you can get, you can just see if it's a 404, right? You'll be like, hey, is there 404 here, right? And then if it's a 404 you render a 404 template here that gets cached, right, that would be cached.

[00:08:30]
So, if anyone goes to that same broken route again, they're gonna see a 404 page, right? Because technically, as far as Next.js is concerned, you've rendered a page for that route. You did, that's what I call a soft failure. If you throw an error, I don't think they're gonna cache that.

[00:08:45]
I don't think that they're gonna know that, that function broke last time. I think they are gonna be optimistic and hope that you fixed it. So, someone hits it again maybe it'll work this time. So, that's why I would prefer to probably do like a soft failures, what I call, whereas Next.js.

[00:09:00]
As far as they're concerned, you did render this page so it exists, so, they cashed it. But technically, you're just rendering a 404 inside of your template, or whatever you want to render, cool. Answered your question, okay. Any other questions?
>> Can I use this getStatic route to fetch some data that I have in my state management?

[00:09:23]
>> Good question. So, you cannot access anything client side in either these functions. So, these functions have no access to anything react. Because even though they're in the same page, they're executed at completely different times and completely different runtimes. The colocation of these functions in your JSX is intentional, because they should be thought of at the same time.

[00:09:47]
But just cuz they are in the same file, they actually don't get executed next to each other in any way. These things get executed on the server way before this even gets rendered. And in fact, these are what is in charge of rendering your actual app. So, unfortunately, you won't be able to access it.

[00:10:04]
But if you could, maybe tell me the use case that you're trying to solve. I could probably show you how you might be able to do it within the context of these things.
>> I guess that order of execution of functions is, that first we get the path, then we get the props and then we render, right?.

[00:10:23]
>> 100%, yep, you get the paths, you get the props, and then you render. Yep, pretty much it and if you have fallback, then it skips the paths, it goes straight to the props. And then it attempts to render, for a route that isn't already been generated by the paths.

[00:10:41]
So, if you have fallback true and you hit a path that wasn't already there, then it doesn't hit paths again, because it was never there. It's not gonna be there now. So, it's gonna go straight to props.