Intermediate Next.js

Wrapping Up

Scott Moss

Scott Moss

Superfilter AI
Intermediate Next.js

Check out a free preview of the full Intermediate Next.js course

The "Wrapping Up" Lesson is part of the full, Intermediate Next.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott wraps up the course by sharing some best practices and answering a question about strategies for limiting bundle size. He also shares some next steps and tips for getting better at building with Next.js.


Transcript from the "Wrapping Up" Lesson

>> Scott Moss: There is another page to be done, but I'm gonna leave that page for you guys to do for extra credit, to get some more reps in. So the other page is gonna be, I mean, the code is here in the notes, but it's basically the attendees page, I believe.

So, yeah, need to make a getGuestList function that does this super complicated SQL query that I don't even think it works the way it should. But do that and make a page for it and then add that query, pretty simple. But I figured you can always get more reps.

Yeah, as far as I wanted to cover here, this was it. I think, if you know how to take advantage of these things, these are things that I use all the time in production. I think you're gonna have a pleasant experience, you're gonna be getting the best out of the framework.

There are other things in here that I did not touch. I talked about intercepting routes and combining them with route or parallel routes to make modals and things like that. But I'll be honest, I just never did that, I've built it before just to see how it works, but I've always had problems with it.

There was always gotchas and I didn't really seem to care about having a modal be bound to a URL, which makes sense. It's great, you can go back and forth and close it and open it, it's great. But, I don't know, I never really did it. I also use state machines for my UI, which kinda solves a lot of that anyway.

So, didn't really think about that, there was a lot that goes on with the fetch function in Next.js and caching. I didn't talk about that as much because like I said, I don't really use the fetch function that much directly on the server side. On the client side, maybe a little bit, but I don't really use it as much anymore.

So I didn't really feel the need to talk about it. And if I don't use it in production, if I'm not building with it, I'm not really gonna teach about it. So, the other things that might be interesting in Next.js that I didn't really talk about, that you might wanna go look at.

This piece right here talks about different patterns and best practices around getting data, like, how do you actually get data and what are different patterns? So they talk about loading things in parallel, they talk about streaming, they talk about sequential data fetching. Here's an example where they preload the data so you export a function that calls the thing that you need, you just don't await it, you just call it.

And then you can preload it before someone actually goes to that route, and then you can can just check to see if it's available. So you could really speed things up. There's some really cool stuff there. There's some scenarios where they talk about, yeah, here we go, you can run these two things in parallel.

These are both functions that return promises, but you don't have to wait on them here, right? So you just kinda resolve them together. So there's a couple of cool concepts in here that you might wanna check out, that are quite helpful. I don't use any of this stuff in production, so I didn't talk about it, but I did think it was helpful.

It did help me figure out what I wanted to do in my app, but I don't actually use these patterns in production. We have another best practices question with regards to performance. As your application grows, any kind of like gotchas or things you should look out for to make sure your bundle doesn't get really, really big or things like that.

Yeah, for the most part, Next.js does a really good job of optimizing your bundles, right? It basically starts with splitting on the routes, it starts from there. So you can think of every single page you have in here is it's its own route, right? Because that's kind of where it starts.

So it won't load up any of its parents or anything like that, so every page is its own app. From there, what you might find out is that, cuz at the end of the day, you're just trying to protect the client, so you gotta start thinking like, okay, I'm importing these client components everywhere.

Do these client components have to be inside, like, do these client components have to be loaded before the file is downloaded? And if that's, it's probably not the case, what you could do is you can use the next dynamic, right here, which basically uses suspense and lazy loading from react.lazy together.

To basically stream in that client component inside of another component. So you could do things like that to speed things up, it'd be very situational when you would use that. I haven't had the issue where I'm like, if I didn't have this, this would have been really bad.

So, I mean, it's cool. For the most part, people use this function to bypass server-side rendering. Like, if you have a client component that you don't want to be server-side rendered, because remember everything gets server-side rendered, even if it's a client component. But if you don't want that client component being rendered server-side rendered, because maybe it's using some library that you installed, that internally uses Window and you can't change it.

So that's breaking on the server. So you would dynamically import that and through here, you can tell it SSR false. So don't render this on the server, and it'll bypass that. So that's the thing. I would say, other than that, I would try to, what I found out is it's best practices to like take out code that you reuse and put it into its own.

That's why I make multiple files like this and utils, because it helps the compiler, like understand what code needs to go where and help it de-dupe it. Versus, if it's all stuck in one file or one place, it's hard to split, it can't split within a file, but it can split on a file basis.

So if I have all these other files, it can just like, all right, you know what, this isn't being used in this module tree, so just don't even add it. Whereas, If I have all this code in the file, let's say I have 20 functions being exported and one of those functions I use somewhere else, it's gotta get that whole file now, even though I'm only using one function in there.

So, it's like doing things like that helps out a lot. Yeah, for the most part, I would say, that's it, and then I would say, try to get as close to static as possible. So if your app doesn't need to be dynamic, as far as like the data that it gets, then don't make it dynamic for no reason.

So try to get the static, push everything down to the client. So your client components are super small, they handle one interaction, that's it, and you'll probably go really far. So what I recommend as far as what you should do next, go pick some app that you like, you use, it could be a web app, it could be a mobile app.

Something that probably seems impossible or at least extremely complicated to build, and then try to build it in Node.js. That's gonna force you to use things you've never used before. If you pick something that's easy, you probably won't finish it, or 2, you won't reach for tools you've never had to use before.

So I would say, try to do something that's a little outside of your skill set or your capability, and use Next.js to build it. Just struggle, even if this is like something you do, like, I'm just gonna work on this on my lunch break to do some stuff and it takes you three months to do, you're gonna learn a lot through that struggle.

That's really how I learned this stuff. I'll just pick something that I have no business trying to build and I'm like, cool, that's how I'm gonna learn Python. [LAUGH] It'd be like the craziest thing and I'm like, okay, I learned it. That was terrible, but now I know it.

Whereas I realized if I just like, I'm just gonna go build it to do up right quick, I don't really learn anything or I never finish it because I'm not interested in it. I have to be interested, so how do I recommend doing that? And then, once you do that once or twice, you'll be comfortable, you can teach anybody this stuff when it comes to folks at your company that might need to use it.

Yeah, other than that, that's it, that's what I wanted to cover, I hope you guys got a lot from the course. I try my best to fit everything that I think was valuable and useful from my own perspective but also how other people might see it. But then also take into account what Next.js is putting out there in the community, and trying to align what they're saying, I don't want to be saying, they're not saying the right thing, or I'm not saying the right thing.

I'm just trying to make sure everybody's benefiting from all this content. So that was really the most difficult part, but I'm glad we got it out, and I hope you guys got some value from it, and thanks for coming.
>> Student: [APPLAUSE]

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now