10 common mistakes with the Next.js App Router

[@MeonisRP]

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.

[@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+ ?

[@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

[@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

[@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.

[@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

[@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!

[@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.

[@rewazilol]

So agree with this.

[@dwolrdcojp]

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

[@codewithguillaume]

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

[@iAmTheWagon]

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

[@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.

[@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.

[@jordanyefet2679]

Thanks for the video! I have one thing to mention about nextjs - using it doesn't mean you have to call to the DB from the server components/actions. I'm building an application that use nextjs as the client and nodejs as the backend, and I do it for lots of "DevOps" reasons, such as scaling, security and much more. So please stop misleading developers when you guys (nextjs influencers) say "you can get to the DB right from the server action", because what you're creating is a monolith.

[@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?

[@mathiasriissorensen6994]

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

[@DorianDevelops]

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

[@tushgaurav]

This is a must watch video for every Next.js developer!

[@golden_smiles]

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

[@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.

[@Racine14]

Can you talk about hydration? Up to now, I am very confused about this error.

[@MirrorMirror-km9wx]

Hi. Great tips! I would propose the first mistake is 'subjective' as, by explicitly doing the fetch , we are not tightly coupling the api to the application, for example, we move the api to another server. Having a middle man, a service to expose the fetch methods to keep things clean. Love to hear your follow up thoughts on that

[@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! 🥳

[@franciscosalazar8116]

I think that something you have to improve it's being more clear about despite you use the 'use client' your component is going to run on the server the first time, most people explain this like, ok, use 'use client' and your component will run on the client and yes, that's true, but it is also running on the server the first time, that's why we get errors while implementing browser APIs like the window object even when you already applied 'use client'

[@jaredgentry406]

11:29 So for a full page loading state, we should use a loading.tsx file instead of wrapping the whole return in a Suspense component?

[@developerpranav]

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

[@codinginflow]

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

[@codinginflow]

I've never used Next.js on a huge project. But for my smaller projects, the caching actually works exactly as I would expect. I like it and I wouldn't change the approach drastically. I like everything being cached by default (when possible) because I like my page being lightning fast.

[@oussamasethoum1665]

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

[@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

[@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?

[@oussamasethoum1665]

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

[@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.

[@vignesh_m_1995]

Suppose we have a table in a Next JS page and the table has a filter (client) component with interactivity. When we hit Apply, how do we pass the filter values from the client child to the server parent component. (The parent fetches the data and renders the table). I can see many suggestions to pass the data as params or queryParams using revalidate or nav methods of next. That works fine for a simple values like ID or search params. For example, if it is not just an ID but an object (advanced filter similar to the one in Amazon), should we just pass the entire object via the search params and make the URL bloated with so many values or are there any alternate way to communicate from client child (filter) to server parent component (where data is fetched) ??

[@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?

[@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

[@neilmerchant2796]

17:18 I'm a bit confused... you first mentioned how AnotherButton doesn't need 'use client' because it's already within the client boundary of the first button. so then why when you add children are they not also within the client boundary?

[@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?

[@henriquematias1986]

Regarding "Calling Route Handlers from Server Components" I think the idea here is that calling the function directly will mean that you end up with 1 function on the server component to call the data directly ( bypass API route ) and another one on React-Query ( or SWR ) to call the API and basically end up doing two different "getData" functions, one for server and one for client, which can up mismatched / confusing / harder to maintain ?

[@atifali3485]

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

[@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.

[@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…

[@vsol9284]

What about catching... Next Js cache http result, where there is no http how will the caching work?

[@AlanMartin-nt7cy]

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

[@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"

[@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?

[@akrishnadevotee]

Developers making 'common mistakes' can also be read as 'improper design' on Next.js' part. P.S. Not trying to blame anyone. I'm sure Nextjs will continue to evolve and improve 😊

[@Onedeag-qw3yc]

Could be the case but also any technology wil have devs making 'common mistakes'

[@voyager_ll]

On point all mistakes i made 😅 passing from server to ssg and client is causing me so many headaches 🙈 but getting there

[@samuelizevbizua]

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

[@muhammadmejanulhaque3305]

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

[@alexdin1565]

8:04 using server actions insted of routes I think its a bad idea because any one can see the actions if we call external API but no one can see the external API if we use it in the route

[@morchellemusic2829]

I love this series keep it coming

[@mickmister]

That route handler caching seems like a nightmare to debug. Is there a defacto way to know that it will be cached?

[@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

[@hasanaliyev5231]

@leerob what is the best way to identify performance issues in App Router? Any tools to use?

[@gabswile]

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

[@splodys]

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

[@tonytrinh]

12:10, you said: "This flicker means this bit should not be cached. It should be run dynamically." Why does the flicker indicate that? 🤔

[@nikb3713]

I spent 5 days and still couldn't figure out how to build a UI of catalog page for example. I have catalog data that I want to request directly from my db which make my page a server component. I also want to have filters on top of that page which are client component bc they need to use react hooks. So far I figured out how to do it by making all my page a client component and requesting my data via proxy router that requests data from my db. Is it correct approach or is there still a way to combine those two logics in one server component without using proxy router? In old pages routing I would do it with getServerSideProps, get my db data directly and then use filters in the jsx with all useStates I need and data as a props. But now it's all so confusing...

[@alexandremondaini]

how about when you want to fetch data , not mutate, say fetch from a database into a client component ? shall I use the route.ts , server actions or pass the data from page.tsx into props of the client component ? I have just started learning nextjs and struggling with it. I believe server actions are only for mutating data correct ?

[@edaxucles90]

I have a question, the first common mistake, I have a a method to retrieve data from blockchain, at the end this method using a library like viem to retrieve data use a http transport, if I just directly use the method is this data result is being cached automatically? Like if I use the same request from 2 server components those calls are de-duplicating by nextjs? In conclusion should need to worry about caching in this case or not? Thanks!

[@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.

[@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.

[@hasanaliyev5231]

@lerrob what is the best way to identify performance issues in App Router?

[@karanpunjabi3077]

Dumb Question: With all these server actions, route handlers, etc. I'm confused with just one question: Can we use "useEffect" hook on client side to fetch data from an api like we used to do for SPAs in React?

[@_rhythmsaha]

First, it's important to understand Vercel's main business model. They have made Next.js free and open-source, not generating direct revenue from the library itself. Instead, their primary revenue stream comes from their hosting and serverless offerings. The recent updates to Next.js, emphasizing server components and fetching data directly from the server, are designed to encourage developers to utilize Vercel's hosting and serverless platform. By promoting this approach, Vercel aims to increase adoption of their paid services and generate more revenue from developers leveraging their CPU runtime and infrastructure. While the App Router in Next.js is a compelling feature, the default behavior of rendering components on the server raises concerns, particularly for small-scale applications. Server-side rendering can lead to inefficient use of CPU resources, as even simple components are rendered on the server, potentially resulting in increased costs and performance issues, especially for those on low-budget or free hosting plans. Personally, I prefer to separate concerns and utilize dedicated backend frameworks like Django or Express for API development, as they are more scalable and better suited for this purpose. Attempting to fetch data directly from the server using Next.js can introduce unnecessary complexity and latency, as the request must first reach the Vercel server, which then proxies or duplicates the request to the actual backend API before returning the response. This additional hop can lead to decreased performance. For applications with an existing backend API hosted elsewhere, I recommend leveraging client-side data fetching, as it streamlines the process and avoids the overhead of server-side data fetching through Vercel's infrastructure. However, it's crucial to ensure that the backend API is properly secured, regardless of the data fetching approach used.

[@adreto2978]

Yes you can :). You just mark it as a client component and you can still fetch data on the client after the initial server render like normal. The guy above me is a part of the Vercel conspiracy theorists. Obviously Vercel makes money from hosting but you don't need to host Next apps on a server-less architecture at all, and also SSR is confirmed by google docs and the recent leak to greatly boost SEO its not just a meme.

[@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.

[@GeniusHawlah]

What about GET in a Client Component, can one still use server actions or route handler is recommended for GET? I tried using actions to fetch in a Client Component and it worked perfectly, but checking through my network tab, I realized it's sending a post request. I curiously checked the docs and using server actions to fetch was not talked about. Can you clarify that please? Thanks for great contents all the time!

[@Luisllaboj19]

Does revalidateTag work inside of route handlers?

[@lasindunuwanga5292]

He is very humble compared to other KZbinrs

[@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.

[@faizanahmed9304]

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

[@anargyrosstylidis2595]

On 12:03 how did you do that thing where the import appears at the bottom of your position? (unstable_noStore)

[@leerob]

Control + Space

[@VincentFulco]

Awesome, clears up a lot.

[@ZadSoleimaninia]

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!

[@ariell121]

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

[@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?

[@jay-cm]

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

[@leerob]

Same, been there!

[@Oliver-yu5kp]

How do you get i18n without redirecting to a subfolder /en for app router? Is this possible?

[@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.

[@Silverdagger258]

The most common misunderstanding regarding nextjs in my circle has been the existance of client side cache. People use the "dynamic" option on components expecting them to actually be dynamic only to get tripped by client side cache still caching the page. Imo this needs to be either A. Removed or B. given more control over (besides the experimental flag) per route. But definitely it needs to be explained in further detail in the docs.

[@aflahvp7535]

I have a requirement of increment a flag in database and setting a cookie for 5 minutes when a page loads, and when next time the page loads, check if the cookie is expired or not and increment the flag if it's expired. currently I'm planning to use a Route handler for setting the cookie and calling the Route handler when server component loads(because i want to increment the database flag and the page is a public page so can't use client side data updation), is this the right way ??

[@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) 🙂

[@zainkazi]

I just noticed revalidatePath doesn't work in the route handlers. Is it server-action-only feature or a bug?

[@eddiejaoude]

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

[@zaynelovecraft]

In the root layout component of my app, If I access cookies this automatically makes all paths server-rendered on demand. Is this bad though because what about some paths that I want to be static.

[@ericnemo8348]

Hey ! I am heavy user and familiar with every concept you mentioned, except for Suspense. I still dont understand the difference between suspense and loading.tsx ?

[@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

[@martinkinywa2512]

When are we getting NextJS database components?

[@gonzaloalecha302]

Nice video lee, thanks for this explanation!

[@alexandertarasenko3038]

If you put suspense, does it mean that if I disable js in browser I won't see data and will only see suspense fallback?

[@lecolecosa]

I don't know why but after change to app router, flicker the pages everywhere! If i use the useTranslation in a page with two Typography one with translation and other without the page flicker where have the translation. I dont know what to do!

[@LutherDePapier]

Is it a mistake to have revalidatePath outside the try-catch block but still inside the full function?

[@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

[@albiceleste101]

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

[@komilolimov2257]

Sorry, i'm just wondering where i can find your source code of your project "nextjs partial rendering"

[@SashankAryal]

So I can use sever actions for data fetching? The docs are not clear on that.

[@adreto2978]

You can but its technically not the intended use of server actions as they are for mutations on the backend. But Vercel is leaving this open and exploring how devs are using it for fetching data and potentially might use it if the pattern develops better.

[@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?

[@51Grimz]

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

[@flnnx]

This type of content is awesome