10 common mistakes with the Next.js App Router

After talking to hundreds of developers and looking at thousands of Next.js repositories, I've noticed ten common mistakes when building with the Next.js App Router.
This video will share why these mistakes can happen, how to fix them, and some tips to help you understand the new App Router model.
0:00 - Introduction
0:13 - Calling Route Handlers from Server Components
1:59 - Static or dynamic Route Handlers
7:00 - Route Handlers and Client Components
9:03 - Using Suspense with Server Components
12:35- Using the incoming request
13:59 - Using Context providers with App Router
15:10 - Using Server and Client Components together
15:41 - Adding “use client” unnecessarily
17:51 - Not revalidating data after mutations
19:11 - Redirects inside of try/catch blocks
vercel.com/blog/common-mistak...
#nextjs #react

[@user-sh5qp6uu1e]

I thinks the biggest issue with NextJS now is that it's going too fast and docs lack any in-depth information about any new paradigm you introduce.

[@shahrazedsakhri9610]

So true, new users struggle with the lack of docs especially most of the vids and articles are with the old vers

[@martiananomaly]

Yep. I learnt NextJS fairly late and was up to date with most new stuff.. until they added more and more new paradigms which is getting really annoying. This is on top of all the new bugs in the dev mode.

[@patolorde]

The heck you talking about, next has one of the best docs outhere

[@martiananomaly]

@@patolorde The docs are decent and broad in scope but really not that deep. It takes stack overflow or GitHub issues to find in depth information about certain stuff when you run into issues.

[@collatedcopies]

​​​@@martiananomalyAgreed. When you go beyond the basics with the NextJS, the documentation, is usually not sufficient and you have to rely on forums, comment threads on GitHub issues, repos, blog-posts, videos, etc to solve your problems. The problem is, because of how fast NextJS is moving, most content on the web is outdated and use deprecated/outdated features of NextJS (ex. using the pages router or older methods of routing instead of the app router). There isn't enough up-to-date content to learn and reference. Even AI tools can't keep up. Let NextJS mature and give developers time to get familiar with it. Ideally focus on incremental improvements / bug fixing instead of trying to revolutionize framework with every version. To be fair, this is sorta expected from any bleeding edge framework. Immediate rollout of features at the cost of a steeper learning curve. Best you can do is just stick to a stable version and move on if you have to.

[@georgemwaniki]

Caching should be an opt-in feature, its confusing having a project work in dev n then think its broken in production

[@dinhkhanh]

and some streaming-related features

[@patrickroza3073]

Just make the behavior in dev and prod equal, that is the more important thing.

[@TheMr82k]

truw been saying the same to keep caching an opt in config but it will be bad for Vercels server less architecture which charges you by compute time

[@danpiths2847]

according to my understanding, having dev mode with caching turned on would make it super difficult for you to update and see changes because that is the whole point behind HMR/live reload. you cannot expect "dynamic" reloads on code change and then also have caching, i could be wrong here but imo no-caching feels necessary for dev mode. if i've misunderstood the question or if you have a different outlook this, I would love to discuss! :)

[@patrickroza3073]

@@danpiths2847 you can invalidate the cache on code change. Which is analogous to a new build

[@muhammadhossam8557]

I think the best and most important thing now for vercel team, is to add more videos like this, with more details on how things work, and concentrate on daily things for most of the developers like best practice patterns for managing state for example, as I think how things work will not be enough without suggested practical patterns for how to use those things

[@leerob]

Open to other suggestions!

[@dynerushd7517]

@@leerob Also clearing these practices up like you did perfectly in the video, but in the NextJS documentation would be a great help for most people. Having structured and in-depth docs especially with NextJS growing this fast is almost a must.

[@ra2enjoyer708]

Nah, enjoy a hot new bundler written in Zig instead.

[@jonathansantosfb]

Question.. State managent with tanStack Query or pure Next.js 14+ ?

[@WebDevCody]

I'm thankful for Lee, Vercel, and all of the developers working hard on Next.js. This video is a gold mine of useful information, and I hope to see more content like this published from this channel (or Lee's channel).

[@BBxx19]

The confusion regarding caching is partly the fault of how it was introduced. It is simply too aggressive and most devs need to opt out manually every time. E.g.: There is maybe a 1 in 100 case where someone would need to cache an API result during build-time, so making it default is completely counterintuitive and expected to cause confusion and bugs.

[@bryanngen5572]

I think Vercel feels strongly about this new caching behavior, in that it’s “better”. and they’re just pushing devs through the pains of learning to make it the new norm. that’s the vibe i get from Guillermo’s tweets. i agree it is aggressive but something that will probably be considered the norm when everyone has shifted their mental model.

[@divinelogik]

​@@bryanngen5572mental models have nothing to do with it. Most, if not all web applications require non-stale data, be it enterprise admin apps or e-commerce sites. Vercel built their caching API with only blog posts and other similarly static data sites in mind. App router nuked the behavior devs had come to rely on in Pages router. As a result, Vercel has stated the caching API is changing in an upcoming release, as they've heard this feedback constantly since App router was introduced. Changing your mental model can't fix a poorly designed API.

[@leerob]

Definitely think we could have explained it better when we first released things! We have some ideas for ways to simplify the model further as well we're working on.

[@samithafernando6432]

@@leerob if the dev runtime is different from prod when it comes to cache pattern, could you print a warning or info message so new developers are not going to get confused?

[@pranavrajveer6425]

@@samithafernando6432 Yes, @leerob I think you should print a warning when movng from dev to prod, which has default caching

[@nobodysaysmynameright]

I can't stress enough how important these videos are. Not only moves you closer to your end costumers (us developers) but also does a better job explaining the changes / how to work with the tools. I've been using nextjs since it was a little cool project and I'm very impressed with 13 onwards but definitely requires so time getting used to. Congrats Vercel team

[@dwolrdcojp]

More of this. I’ve definitely encountered all these learning opportunities while using the app router so should help a lot of people.

[@TheMotivatorYouNeed-uj1jx]

I really appreciate that someone finally is explaining how nextjs is working and how to work with it. Please share more of it so we can develop awesome apps!

[@NoRefund17]

I honestly would like to see a whole video just on the relationship of "use client" and "use server". Just examples to exhaustion on how you can interweave and combine the two (and how you can't). Cause i'm still super confused on all the details. I have gotten some basic interweaving done myself, but i don't even know if it's the best way to do it or if i'm using sever components as often as I could be. Specifically around data fetching and the interaction between the two.

[@tradfluteman]

When I got started, I began adding "use client" and "use server" to my files, only to get weird errors from React. Whoops, turns out "use server" is only for sever actions, it's not the reverse of "use client" at all lol

[@martinquintana2458]

All components are Server Components by default, you can switch to Client Components by using “use client” and the components rendered inside a Client Component are also Client Components but NOT the props of Client Components, those can still be a Server Component passed via props (children in the video example). And lastly “use server” is only used to define server actions either on a top file level (all functions inside the file are server actions) or top of a function (only this function is a server action). Confusing but with time you get the idea! 😅

[@NoRefund17]

@@martinquintana2458 awesome great place to start thank you :). There are tons of things that still confuse me though like Where do you do server action data fetching, or pass server components from to avoid having to load that data before UI loads. like my final product is use client because i want to filter data and useEffect / useState etc etc. But do i load that all in the main page, and pass it down through props. Will this cause a lag while server gets data. is there a way to do this so that everythign that can load loads, and the data loads once it's ready? How do you do that, where do you do that. i remember the docs saying "fetch data from where you need it the system knows how to get rid of that duplication if the data is used twice. But this confuses me also because does this mean i can fetch data in anyway, anywhere? or are there specific ways to do this. Will this work with planetscale/database or do you have to use fetch() for this to workj. I'm also confused about, how does all this interact with eachother. If you have a part of a component that needs data, so you want it to be a server component because it fetches data, but you want to be able to sort and search that data, so you need that data to be used in use client hooks and components, how do you acomplish that? sorry, all the data fetching stuff and how it interacdts with server / client is just super confusing to me. I've found ways to "do it" of course (right now i just fetch on the top server component page and pass down through props), but i don't know how to do it "properly" hope this big ramble makes sense lol.

[@tradfluteman]

​@@NoRefund17 I've been turning this stuff inside and out and applying it to a real website with hundreds of daily visitors, so feel free to ask any questions that you want. These patterns have recently started to "gel" for me. First question: you probably shouldn't fetch data in server actions, unless you want to keep your page fully static, because a server action is always called from the client. You probably want the speed and caching benefits of server-side data-fetching, if you don't need to fetch personalized data. BUT it sounds like you don't want to block your UI while that data is loading. You can and should do this with Suspense boundaries, so you would put this: in your code. The skeleton/default/placeholder UI can be whatever you want the user to see while your data is loading. This is really under-emphasized honestly. React 18 and RSC exist in part just to integrate with this pattern, because it is so flexible and powerful (and if you fight it, lots of things will more painful than they need to be). Just one of the things it does is to get rid of "loading as state". You can fetch data with "await" anywhere inside the children of a Suspense, and then the component where it happens blocks until that call completes. The entire React tree suspends as well until it hits your Suspense. So you can precisely delimit which portions of your application are rendered by the server on each "render pass", including the first pass (usually a template of sorts), and which portions delay their rendering and then stream to the client afterwards. (this is awesome, but keep in mind that users should mostly not experience this loading behavior, when it can be avoided, if you cache properly) Second question: You should probably use the unstable_cache() function to fetch data. Next is ironing out the API for it, but the functionality itself is stable, and it allows you to create custom-cached calls for your ORM or retrieval function of choice. Next is signaling that they may deprecate their monkey-patched fetch() API in a future version. But before you do this, you have to understand why caching is more than just a convenience in Next 13 and 14, and how it differs from memoization. And it really helps to understand SSG/ISR/PPR as a form of render-caching that is supported by data-caching. I've written another autistically long comment on a different Next video, which I'll paste again below this comment for reference, that breaks down these terms. After that comment, I also recommend reading the Next page on caching; it is long but worth it. Third question: when you need data to be globally accessible you should think about "crossing" data through the server-client boundary from server components into client components through props (it needs to be serializable), then using those client components to "lift the data up" into React context, or your state manager of choice. It may be confusing to think that you need a server component just for fetching data and a client component just for receiving it. Why two components? It's because you only rarely want them to be the "same thing". Most of the time server components will be big layout components that need to access lots of data and client components will be small "leaf" components that need custom JS interactivity, like buttons, but only some data. If the "leaves" need to talk to each other they should use something like context; if not, they can get their data directly from server component parents. This spreading out of the client components forces you to componentize correctly and to keep your application lightweight. I've found that it's a lot harder just to blindly pass things around to "where they're needed" in this world; occasionally you should pass big data objects, more often just properties, other times components into other components (the woefully underutilized composition pattern), and still other times the data should be consumed through context. Once you come up with a system that works for you, your code will be easier to read and faster to implement. But it's normal for implementation to be slow at first. I hope this helps clear up any confusion. IMO, Next has introduced some great tech, but they haven't done the best job naming or explaining it.

[@tradfluteman]

​@@NoRefund17 Feel free to ask any questions you want. I've been recently turning this stuff inside and out and applying it to a website with hundreds of daily active users and this stuff is starting to "gel" for me. Also, KZbin deleted my long reply where I answered all of your questions, without telling me, because I used a playful pejorative slang term for myself. And now I have to start from scratch (ugh). So forgive any terseness. First question: You should probably use Suspense boundaries on the server if you don't need to do personalized data fetching on the client. So your code should look like this: If you do data-fetching with "await" **anywhere** inside , the component where it happens will "suspend" and then the whole React tree will suspend until it hits this barrier. This is really under-emphasized: React 18 and RSC exist in part just to extend this pattern to the server, because it is so powerful, and resisting it will make your life more difficult. Just one of the things it lets us do is eliminate "loading as state". (this is awesome, but remember that users should largely not experience loading UI if you cache properly) Second question: You should probably use unstable_cache() to do data-fetching. Next is signaling that they are likely to deprecate their monkey-patched fetch() in a future version, and this function allows you to access the Next Data Cache using any third-party library for data-fetching. Before you do this, I highly recommend trying to understand why caching in Next 13 and 14 is more than just a convenience. Key Next behaviors like SSG/ISR/PPR are forms of render-caching supported by data-caching, and I break them down in a (long) post I made on a different Next video, re-pasted below this comment for convenience. I also recommend reading the Next page on caching; it's long but worth it. Third question: when you need to access data globally, think about "crossing" data through the server-client boundary from server components to client components as props. If what you pass is serializable, React will take care to serialize/deserialize it as it goes over the wire. Once the data is in the browser environment, think of "lifting it up" into context, or your state manager of choice. It may be confusing to think that you need components just for sending data and other components just for receiving it. Why two components? They are rarely meant to be the "same thing". Server components are usually large layout components that consume a lot of data while client components are usually small "leaf" components that consume only a little data but need custom JS interactivity, like buttons. In general I've found that it's a lot harder to blindly pass things to "where they're needed" in this world, which is actually a good thing IMO. Occasionally you pass data in large chunks, more often as properties, sometimes you pass components to be rendered by other components (the underutilized composition pattern in React), and still other times you define data requirements through the Context api. I hope that helps! I think Next has introduced some great tech, but maybe not explained it or named it very well.

[@developerpranav]

Highly appreciate videos like these. accelerates the learning process so much when you tackle common mistakes directly!

[@oussamasethoum1665]

Thank you lee, this clarified a lot of misunderstandings for me especially the "use client" thing.

[@mathiasriissorensen6994]

I have learned all of those mistakes the hard way, but thank you for reassuring me. 🙏

[@codewithguillaume]

Lee, you are an amazing teacher. Very inspiring to me. Continue!

[@golden_smiles]

Thanks for the 0:32 "API" in quotes, thats all we need to know about the Vercel's approach.

[@iAmTheWagon]

I really appreciate these videos. Highly informative and elucidating. Now I’m waiting for the video on parallel routes and route interception.

[@katanaut]

Great video, I wish there would be more of these next.js tips and best practices!

[@leerob]

Let me know what else you'd like to see!

[@sudiptomitra6899]

​@@leerob In one of my projects I used local storage, but it showed an error. in my case it was not in any components, I was using local storage in redux's slice. so, checking window!== undefined was not working also. Another thing is that the Next js Image component is a great thing, but in one of my cases, random images were coming and they were in different sizes, if I used the height and width properties it was not working well for small images, same for the fill property. what we can do in this case?

[@FamilyGuyVids11]

thank you for this video! i really find this type of thing helpful for developers. i learned a few things i never knew about the router

[@Cooper-kg2ru]

I really appreciate these videos, my issues have been that I am starting fresh with a production application and while the basic concepts took a min, I am getting stuck on specifics and there is not enough documentation to get to the bottom of it. Somewhere between MSW, next-auth, Jest, etc there are so many errors coming up that I cannot resolve, and most of the response from individual maintainers is "this isnt an us problem". I really do love what is happening here, but it feels like it was released too soon and the iterations have been tough.

[@splodys]

Thanks again! Great binge watching to keep up to date!

[@VidozMusic]

Is Lee getting back-issues from carrying all of us newbie App Router developers? Just kidding. Really love these types of videos. They're super informative and clarify so many real-world issues. Learned a ton! 🥳

[@samuelizevbizua]

Thank you Vercel Team for this, really clarifies a lot of speculations for me and I also learned new thelpful and productive tips

[@MrManafon]

Great video, thanks so much! One thing that keeps bugging me is the context problem , where server components are children of a client component, lets call it server-children. It is a very easy concept to grasp. The missing info isn’t “how to get it working” instead it is “does it render children as html, or does it apply them during hydration”. This is super important info when combined with contexts and caching. A simple confirmation would get us to use it.

[@DorianDevelops]

This was super helpful for someone like me who is just getting into Nextjs!

[@faizanahmed9304]

Thank you Lee, definetly need a video on suspense 12:32.

[@iwanttopunchtheosface]

I like how you frame it as the "devs common mistakes" rather than "nextjs !clean (i'd like to say it but) implementation of how to do things so deal with it". 😇

[@toparamennoodles9652]

Imagine complaining about a free framework . Go use something else bro

[@muhammadmejanulhaque3305]

Thanks for this video. learned a lot. I am recently migrating my project to app router. it will help a lot.

[@AlanMartin-nt7cy]

Great video, very helpful. I would love to see a video about consuming a graphql endpoint outside of the next app!

[@an11111100]

Thanks. All warring questions were answered.

[@eddiejaoude]

Thank you for this video! Many of those definitely caught me out

[@51Grimz]

Nice those were all super helpful! I definitely used route handlers in my server components at first lol.

[@gonzaloalecha302]

Nice video lee, thanks for this explanation!

[@pratiksavaliya3890]

It's easy in simple applications to differentiate and weave server components....but as complexity grows...it becomes real crazy real fast....and boom all are client components....but again i just started using nextjs...i hope later it becomes second nature

[@atifali3485]

took me a couple of hrs to figure out the static behaviour of route handler in build xD

[@oussamasethoum1665]

The devtools for understanding which part is running on the client and which is running on the server will be helpful a lot.

[@VincentFulco]

Awesome, clears up a lot.

[@dukeselwood]

Excellent video, very clear and helpful, thanks

[@denniscual4618]

Nice vid Lee! For me, one common mistake is thinking Suspense, directives, form action, useFormState, useFormStatus, etc are provided by nextjs. We need to clarify and set a boundaries between next and react to have better understanding. I mean it looks like next is now becoming the new version of react.

[@ra2enjoyer708]

The whole server components stuff is only implemented in NextJS so all downstream interfaces might as well be considered as NextJS things.

[@DannyBLV]

great clarifications, thanks!

[@morchellemusic2829]

I love this series keep it coming

[@user-sj2pg7tz7i]

I love everything about Next JS, however I feel Next team need to impose more opinionated pattern when structuring. frontend and backend code, client-components and server-components etc. I think this would make things much simpler when it comes to the debugging side of things! I'm not just talking about the folder structures, but also how imports generally working when attaching a client-comp inside a server-comp etc. Thanks for the video, I hope to see move and more of these easy-to-follow tuts!

[@codinginflow]

Very nice list. I'm happy to say that I'm doing zero of these mistakes 😊

[@theDanielJLewis]

This was great. Thank you!

[@david.thomas.108]

Great idea for a video topic and super useful thanks.

[@jay-cm]

Thank you, I was definitely using Suspense wrong on one of my components without knowing.

[@leerob]

Same, been there!

[@The_starko]

Amazing video didnt make these mistakes but finnaly helped me figure something big oit, now i finnaly get it whyy we dont need an express server - mindblown finnaly make more of these

[@DrJoeNjenga]

Awesome clarification

[@nilskch]

Awesome, this helps a lot!

[@jensadria]

NextJs: "Here's a lot of confusing untested new features that will turn your DX a living nightmare" Also NextJs: "Actually you're the problem"

[@aryankathawale9269]

wow soo informative , i would also love to learn about metadata and page transitions per dynamic requests , lmk if its in the works , love nextjs , love your work

[@flnnx]

This type of content is awesome

[@IntrovertDeveloper]

these are super useful thank you

[@PhilipAlexanderHassialis]

The explanation at 17:45. This thing should be in bold red 72 point text in every part of the App Router. The magic word is {children} - that way you can have a server component > client component > server component > client component > etc chain. Please write this text in bold red 72 point text in every page in every doc concerning the App Router. This is perhaps the most important thing - it will help people finally get how this thing works.

[@ra2enjoyer708]

It doesn't need to be written in bold, it just have to state that `use client`/`use server` are syntactic directives. It didn't help that NextJS itself spread a disinfo about client components not rendering on server at all, when in reality they can be seen as standard non-page components used in `pages` router but with stricter environment separation.

[@luizfcavalcanti]

First, thanks for the video and please do more of these. About the whole caching, the solution is to provide a global setting to change the default caching behavior to opt-in and leave the default option to opt-out as is now, that way whoever needs a different behavior has the option to do it.

[@DominikSipowicz]

Amazing video! Thanks Lee!

[@eduardocouto112]

I personally don't agree with the point that it's unnecessary to "use client" directive to a component that is already inside a client component. I think we should always explicit say whenever a component is client, because I already saw some colleagues trying to ship env variables inside a component thinking it was a server component (because the use client was not declared but the component was a direct child of a client component). Besides that, revisiting a next with app dir after some certain months and having little context and not knowing right away if a component is a client or a server is hard. I think that we should always add "use client" directive even if it's redundant in some cases.

[@cjthedeveloper]

good take

[@muhammadhossam8557]

very true, it is very confusing and can cause a lot of unintentional things, giving errors is a lot better.

[@Patinhow100]

true! I always put the 'use client' to not get lost.

[@NovaAquarius]

It would be great to have such tips and best practices written in docs. Next.js version 13 was not only update in framework but a whole paradigm shift. So more examples and guides IN THE DOCS would benefit everyone. As in I feel videos are more cumbersome for vercel to produce and less discoverable and refer back for developers I am starting a new nextjs 13 project with app router where backend will have auth and connect to mongodb. Very simple crud app. I will see how it goes with the tips from the videos. Because last time when I tried reading the docs, I was unable to make it work properly

[@albiceleste101]

I only use svelte in my projects but still this is great, condensed content to be up to date with Next

[@akuoko_konadu]

Thanks Lee, I've made a couple of these mistakes myself, especially using the redirect inside a try catch block 🤣 Also we are happily waiting for the dev tools you were talking about. And I don't know if you guys can include a directive which we can call in our client components so that they can be skipped when rendering is happening on the server, because let's say the client component need a data and that data is only located on the client, when that client component is mounted it'll say `hydration error` because the client component does not match what was rendered on the server before hand and this happens since the client compoentn now have that data and is using that data to probably change the jsx(say loading somehting from a redux store and maping over them, those things probably won't be on the server, but they'll be available client side). And lately we have been using the lazy loading of next dynamic to skip ssr rendering of client components on the server by setting the ssr to false, which is a bit of a work around. So I don't know if you guys can let us export something like `export const ssr = false` which will disable prerendering of client components on the server. Or is there something like that which I don't know about? 😅

[@leerob]

You're on the right path with next/dynamic and ssr: false!

[@0xPanda1]

Very informative video thank you

[@tsykin]

Thanks, very useful 😊

[@InspirasiMedia]

Hi lee, that was great video. but I'm still confused about what the preveState on server action is for? I see it has been declared, but never used

[@kaanxweb]

Thanks! More video please

[@lasindunuwanga5292]

He is very humble compared to other KZbinrs

[@_hugo_cruz]

Excellent!!!!🙌🏻

[@ariell121]

11. Using the unstable app router. Just stick with pages router until app router is stable and production ready

[@victoreleanya4375]

Thanks for sharing

[@kristianrykkje4255]

Great video!

[@alfianlensun5040]

Nice work

[@ynonrahamim]

Exellent tips! I think i got 10 / 10 😂 Thank you

[@ondrejlangr9248]

I like that you used bun for this :)

[@javascriptes]

I think although the fire at NextJS is mostly about the confusion with cache, it is its best attribute if you think about it. Cache will save you from hitting that db toll. Although there is certainly room for improvement we as developers need to understand how it currently works.

[@compsigh]

yeah ngl most of the naming is confusing lol, but huge kudos to Lee & team for working hard to make it clearer

[@vronus007]

Very helpful video. Regarding the route handlers: If I am planning on a React native app in addition to my webapp (but with the same functionality), I would say that route handlers are necessary, otherwise the native app would not have access? Is that correct?

[@ecoded3033]

Very helpful

[@lucascaton]

Amazing video, thanks! Constructive feedback: it'd be great if you could re-enable the VS Code feature that shows the full file path under the tabs. That'd make it easier to follow, especially when your sidebar isn't visible or when there are multiple files with the same name (page.tsx for example) 🙂

[@user-gx8bg5wc1m]

Good staff, thx

[@noahginsburg6140]

Is the server side data cache only utilized by requests initiated with the fetch api? Per the first few examples of the video, if we're mostly making direct calls to say a database and not utilizing custom routes handlers or even calling the fetch api from a server component, does the data-caching provided by the fetch api play any meaningful role? There just seems to be so much documentation around caching with the fetch api while the nextjs server component paradigm, and this video, mostly suggest you won't be using the fetch api. Will the "cache" function hopefully be the answer for caching any kind of data returned as a promise similar to react query? One more, when you cache a route handler, what are you caching? The NextResponse? Thanks for the video and your commitment to outreach and engagement.

[@VercelHQ]

We'll have a new video tomorrow walking through caching with the App Router that will hopefully answer your question. It will show how to use unstable_cache() for instances where you can't or don't want to use fetch(). In this video, caching of the GET Route Handler isn't caching the response, but instead prerendering the response during the build. That's how it can generate files. You can still adding caching headers to Route Handler responses when the handler is dynamically rendered.

[@MightyArts]

I have a couple of questions, which I hope I'll get some feedback on. Thank you in advance. 1. Regarding "Calling Route Handlers from Server Components": - First of all I always think of "Route Handlers" as API endpoints - is that correct, or am I making a mistake here? This comes from the fact that I can access the route handler / API endpoint (e.g. "api/example") from anywhere I want such as Postman. - If I have a server-side rendered page, then instead of having a dedicated route handler that exposes a "GET" method, I can move that logic within the page component itself and just fetch the data directly. This is fine and I agree its a better option getting everything you need in 1 request to the server, instead of sending one request to get the rendered page, and then sending another request while rendering that page on the server (?) to the same server to get some data. - What happens with the other types of route handlers (API endpoints) like POST, PUT, DELETE? Is it okay if we have dedicated route handlers for them, or is that also considered a mistake? Do we must use "server actions" in that case? 2. You said that "most of the time I see route handlers, its usually for webhooks or handling external requests". Okay, but if we default to using server actions, does that make Next JS as the non-preferred option in case we want our data to be accessible by multiple applications (e.g. the web app and then a mobile app)? Afterall, if we're using server actions for everything, the mobile app won't be able to interact with the same API, correct? 3. Regarding using "Route Handlers and Client Components" (this kinda ties with #2): - I understand the part that instead of defining the route handlers I can use server actions and have the functionality defined there. But what I fail to wrap my mind around is - is this the "preferred" way of doing things, or is it fine if I want to still define route handlers for mutation actions (e.g. POST, PUT, DELETE actions)? I have seen many people, both on Reddit and NextJS's discord channel saying that "No, you don't have to use server actions, you can use route handlers", but then videos like these come out and it makes it confusing as to which is the preferred way to do things. - Is it okay to combine fetching data directly in our server side rendered page and then defining route handlers for mutation actions? I haven't used Next JS previously with the pages router, therefor I'm completely focusing on the App Router (as recommended). I've been working on client-side focused web applications (dashboards), and I know that this now requires a bit of a mindset change, but sometimes a more "opinionated" direction would be best, especially for someone starting out with the framework, so we don't wander left and right and get confused with different options that are available to us. Is the optionality great? Sure is. Does it makes taking decisions which feature to use, early on when learning the framework, confusing? It sure does.

[@CarlosMarquez-co9eg]

I have been pondering the same questions. Accessing data directly on server components or using server actions might be cleaner, but it is limiting the ability to integrate with other clients (e.g., a mobile app). If we are thinking of having a web application + mobile app, we have two options: 1) Disregard the first common mistake mentioned in this video and still use route handlers as API endpoints. Therefore, all data fetching goes through API requests. 2) We can follow the advice in this video and access data directly in server components and server actions, but we would need an external API to manage our business logic, which can be consumed by the web and mobile app. I like the idea of decoupling the API from the frontend; although, on the other hand, it feels like we are not fully taking advantage of the NextJS framework, since we would have two backends. I guess another option is to follow the recommendations in this video and fetch data directly in server components, and still expose route handlers to be consumed only by the mobile app. We can extract the functions to fetch data so it can be reused by the server component and the route handlers without duplicating the business logic. What are your thoughts?

[@psyferinc.3573]

between client and servers its important to distinguish the difference between a component owning another or having it passed as a child. server components can be passed as children to the client components but cant be owned by them.

[@derekgygax9928]

These are all great, thank you. However I am still running into problems with the revalidateTag and revalidatePath. I have set them up in my server actions and they are linked to the unstable_cache() with the corresponding tags. It works on a production build I do locally but does not work on a Vercel build. I have seen this error reported by others and have been following to see if it is addressed. Any information would be much appreciated.

[@UwU-dx5hu]

Nextjs team should make 1/2 hour long educational content about caching. Their vague documentation is the worst

[@kkornac]

great, thanks.

[@serkan_bayram]

8:31 as you say putting an action like that simplify a lot of things but I think it lacks of "client side validation". I am pretty new to web development but when I try to use an action I always go like: create an handleSubmit function, check user input in that function, call action according to that validation. Is client side validation not that necessary? Or can we send feedback to user from that action?

[@codlp780]

route handlers are pretty useful if you need to access your data from native app too

[@KennethSpencer-fc5zc]

Thanks for this. I finding that so much of my time in the app router is spent trying to divine the narrow path that will achieve the result that I need. My current challenge has been trying to figure out how to pass configuration data (non simple objects) into server actions. Seems to work when imported directly, but when the setup gets more complicated, this is not always an option. Any other way I have tried to pass in confiugration data I either get an error, or it appears to work only to revert to an empty state (empty singleton) later on. I would love to see some material on advanced scenarios with server actions. I always seem to end up having to convert my server actions to API routes because they work.

[@leerob]

Could this configuration data be a function versus versus passing around an option? So you'd call the function inside of the action. Then, if you want to de-dupe that function call, you can use React's cache() function.

[@27sosite73]

ty mr.Robson

[@mandeepchoutapelly2939]

Doesn't revalidatePath apply globally to the entire project, thereby affecting all users accessing that path? If that's the case, wouldn't revalidating the / pathname after inserting a 'todo' (as depicted in the video example) result in a revalidation and consequently a cache loss for all other users as well?

[@user-ld3uq4vv7u]

In the "Using the incoming request" section, you deconstruct params and searchParams. Is there any typing available for page components props? For now on, we are just typing it ourselves through a shared library

[@HelloCoop]

Would love to learn how to write component library that can work both in client and server - ie detect where it is and do the right thing

[@heytraile]

I really hope to see more of these type of videos! Also, I have a lot of issues with next font not loading google fonts all the time. It seems to load them when it feels like and it's really distracting when you cant see the correct fidelity as you design because it's using some fallback font. I follow the docs but still get issues, maybe you can do a video on that as well if it's a common issue! If it's not a common issue please help me out here in the comments to figure out what I may be doing wrong.

[@leerob]

This is likely from font-display: optional, and not from next/font itself. You might be wanting font-display: swap, so you're always guaranteed to swap in the custom font.

[@kanishkchaudhary9683]

thanks sir

[@alexg7282]

Thank you

[@MrEnsiferum77]

How u can migrate outlets from CRA? Especially when root page makes immediate redirect to some page that's having a outlet and some component is injected there?

[@javascriptes]

Awesome ❤

[@en_kratia]

Hello, did you try "Suspense" with nextjs? If yes - does it should work without unstable_noCache? Because it does, but in the video Lee is saying that we should use unstable_cache()

[@javascriptes]

@@en_kratia I have not tried to be honest. I just started migrating a big project from the pages directory and I am not there yet.

[@carlosricardoziegler2650]

Great Video, will be nice if some real examples with internationalization :)

[@codePerfect]

What if I want to get pathname/url inside a server component. Is there any way apart from making a middleware and adding it to the headers?

[@dimboump]

Sidebar on the right gang here!

[@leerob]

I've converted

[@elvispalace]

great video

[@danhamilton6169]

With a form submission, how would you handle this situation in this order: do a client operation, do a server operation, then update the client from that? It’s not working if you put it all in a form action? An api route in the middle is normally how you dealt with that…

[@heysahilsingh]

At 17:25 you passed a server component as a child of client component. What if server component requires some props to be passed in, and in client component I am doing some calculations ( which could be only happen in client component) and what’s to pass the result of that calculation as a prop in server component, then how can we do this?

[@FeFeronkaMetallica]

You cannot pass from client to server

[@shineLouisShine]

​@@FeFeronkaMetallica this is how he cannot to this, not how he can ;) With that being said, I wish I knew how to respond that question with an answer instead of responding this comment for the question..

[@ra2enjoyer708]

Then there is no point in a server component, since it depends on browser APIs it will never have access to.