You just saved my life. Thank you! I had recently deployed an application using vercel and NextJS v13 and was panicking when recently added data through the client side was not immediately reflected in the front-end. I double-checked whether data was added or not in my MongoDB database and sure it was recorded. I avoided both client-side and server-side caching by the help of your video. Thank you!
Josh, I believe all these issues are popping out because react (and by implication nextjs) is moving to a full stack solution. It will get better in time, but at the moment they are stuck on reinventing the wheel and catching up with solid libs/frameworks that have been around for years. I come from a react + express background and everything was working just fine. I decided to pick up nextjs because of SSR. I've since only used nextjs for its file system based routing and SSR and won't attempt to use anything else it has to offer for at least 5 years until the technology has matured enough. Regarding this caching issue... you basically want the random number to be different on every page hit, regardless if its a reload or a navigation. I'm pretty sure that means it has to be a client component with the default rendering strategy (initial server side render into hydration on the client). From my (maybe limited) experience, I've noticed that as long as you don't go too deep into nextjs then everything works pretty ok. If the component doesn't render static html, then it's probably not supposed to be a server component.
Honestly this. I feel like some people are still confused when to use client vs server components and how next/link is inherently a client utility. Didn't matter in the pages dir because everything was fetched from client, but now we that we are fetching from server you should probably use an a tag or change to a client component.
Well said man! Yeah this makes sense. Innovating as much as these people do inevitably leads to stuff like this, and it's not a huge deal either. Wish they can make this stuff more clear, other than that next is just an incredible tool
@@trebturnerwe should never be using an a tag in next. An a tag reloads the entire route which defeats the optimizations next provides with prefetching. Each page should have an option to just be a fresh load every single time. The moment you build any interactive application with the app router it feels like a giant hack imo. Caching issues, client component props not updating when calling router.refresh. Parallel layouts not showing loaders correctly
I found the cleanest solution to be just wrapping that piece of code in a client component. So everything works the same, and you are able to successfully re-render only that part of the page without doing any fancy workarounds.
But still the back button shows cache, even you do all force dynamic etc. since they cache it for 30s regardless if you apply all their methods to clear cache
I've shipped a couple of projects in nextjs 13 now, my solution to this problem was to implement my own Link component for hard refresh. changeRoute = (url) => { router.push(url); router.refresh() } This way, at least worked all the times. I really didn't bother much about this "bug" because i was quite never needing this. But i totally agree with the concept that this example should be on a client component to do it in the right way. I made my own doc about it, if it's dynamic but doesn't come from a fetch then use a client component. In some cases the right alternative would be to create a route api to generate the data and then fetch it.
Yes! That exactly what I thought I would do in that kind of scenario (like the movie) route handler/server action or client comp (but I would go for route handler since I don’t need state operations / web APIs)
The core problem for me seems to be that NextJS is built around static generation for docs, blogs or e-commerce. As soon as you have something more dynamic, it's hurting more than it helps.
Not really, Josh just missed that it should be a client component, not a server one. At our company we have a huge interactive web app all in NextJS, works fine.
@@zzzyyyxxx Oh it can work fine for sure! I should have specified I was referring to React Server Components. If you're not using RSC and keep the bulk of the code on the client, then you're just doing React. I like using NextJS for the nice dev experience though, had my fair share of webpack configs and shit 😂.
I found a temp workaround until I understand or find real solution. On my client, I make call to an empty API POST request. And my client always refreshes. A GET won't do it. It was a temp solution until I was going to figure out the truth.
Remember we are all still really happy and proud of the entire community pushing forward our react stack. We will get this polished just like everything else. Thank you for highlighting the issue Josh.
You have to import dynamic from next for it and use {ssr: false}. But you gotta use the {Math.random()} as a component. After that you can see the magic. 👍
This is the best solution. Instead of switching the whole page to a client component by using "use client", you keep server rendering the page but turn the dynamic bits (where you use state or need client calculations) into their own child components, and use "use client" on the top of that component. Will work flawlessly and is the best of both worlds.
Having you explain all of these for someone that had to research the answer of this problem 7 months ago, when these information were not even fully released, it’s great. Could you please try to do a short video on what could be the available quickfixes for this issue at this moment? Thanks, love your videos.
//Here's a solution that runs every time you navigate to a page causing the cache to be refreshed. Found it on someone's twitter. "use client" import { useRouter } from "next/navigation" import { useEffect } from "react" export function ForceRefresh() { const router = useRouter() useEffect(() => { router.refresh() }, [])
@@LeprekusGaming This is a solution that doesn't require refactoring and still has any advantages you're utilizing from RSC afaik. You can do it any way you want.
I totally agree with you. I recently faced the exact same issue. My temporary solution is to pass a Math.random() to the query parameters to force Next.js to fetch the data again. I hope they will fix it soon.
so basically you want client side reactivity on that random number section. you can simply use a client component + effect hook (if necessary) to achieve that
This happened to me I thought I was doing something wrong am the API slice on till I monitor my network. I found out that the cash stores the data in other to render it faster whenever it's called again. An the problem is with the behavior of Link element which manage cashing navigation.
That's a server-side component. The Math.random runs on the server-side. Consider the server-side code is PHP and the rest is jQuery, you get the same result. Imagine you are mixing PHP and jQuery in the HTML file. Now they turn into React and the HTML becomes JSX. Tada!
It's a side effect of innovation and I find it totally acceptable. Stuff like this is very frustrating, hence the video. In the grand scheme of things, it's a rather small part of nextjs that will get better with time
@@joshtriedcoding i still think its a bad design, which they insist not to change :) caching everything is kinda insane just imagine this in a extremely complicated web app
after 6 months the problem is still the same, even the documentation says the same.... guys are you facing still the same issue, or there is a solution already?
What about using revalidateTag? For example, I needed a way to request an updated API access token when it expired. Of course, NextJS cached the function requesting the token and so it would not rerun when I needed it to. However; in the fetch request, I added a tag (e.g. fetch('url', {next: {tags: ['api-token']}}). Then I call revalidateTag(['api-token']) upon receiving a 401 status, which invalidates the cache for that function and allows for the token to be requested again. I think this only helps when using the Fetch API, though.
I too had the same problem while working on my side project. Nextjs caching is too aggressive. For invalidating the router cache, they provide router.refresh method although it only works for the current route.
It is just so bad, I was changing my RTK Query API Calls, the body of it, and my Next App still send the data in the old format until I made a hard refresh with cache busting in my browser. Or do you think that was browser caching? :D
Sometimes the simplicity of a full page reload is just good enough, like in those "old" PHP days :) It's so simple and easy to understand what's happening that it doesn't need a full fledged war map about the caching strategy.
Is there a way I can skip routes prefetching data at build time ? Basically I can use 'no-store' or 'force-dynamic', but with that I won't be able use data cache at all in run time.
Hasn't bothered me in web apps, but we've stuck it in capacitor and made an android app and I think it's causing issues...can you do an advanced react hook form video, like with inputs that change based on other values, I.e maybe a discount type and value, which could be a time period a percent or a dollar amount and how you would handle that. Also dealing with null in forms, like let's say a phone number could be a string or null, rather than dealing with empty strings as null, is there a better way...all these things seem to have little quirks like using onChange doesn't make the field dirty...
Right? I was testing NextJS before the development and started facing this issue. The problem is, that not always we can revalidate manually (especially when the data are from the remote/external servers). I would like to cache it for 5 seconds on a backend but at all on a client but... this is not doable right know. AND there is another strange behaviour: When I wait those 30 seconds which Router Cache will cache your page, then the new page/load is not cached at all. So after 30 seconds, every click on a makes an request. Which is WTF. :D
Honestly seems like Next is just getting in the way at this point. Glad things like Remix and Svelte are getting more traction since this app router mess
I think devs should be careful when using server components excessively. It's great for static content which doesn't require JS such as footer or some static sections of the page, and most importantly server-side fetch. However otherwise, "use client" is the key for everything most of the time. For the sake of argument, adding "use client" to root layout.tsx allows to render the app exactly like Next 12 (pre-rendering html and then hydrating on client). That being said, server component is a nice addition, it comes with many advantages yet there is nothing wrong with using client side components. Yours is a pretty unique case actually and it should be handled by using a client component I guess. But it doesn't change the fact that this new paradigm becomes frustrating sometimes.
For new or personal side projects, I'd say yes. Things will definitely evolve and hopefully change for the better. For well established or big projects I'd say stick to the pages router. It will inevitably become legacy code, but that's pretty normal in tech. New tools appear every year and the old ones get replaced by improved ones. Because of this, there's not really much of a point in trying to keep your project up to date with the latest trends. Just focus on delivering a good product with the most accessible tools at your disposal.
The server-side component you see when you click the back button comes from the browser. That’s more of the default behavior of the browser than the act of Next.js framework.
If you have data that change a lot and don't want cache, wouldn't you simply do a fetch on page navigation? I'm just trying to see the problem from another angle...
It is unfortunate but you can always just fetch on the client like we used to do back in the pages folder. Im sure they will eventually have a solution for this.
hi, i am new in nextjs but i think this is a rendering problem?? you have decleared this math.random() code in React server component. which sends RSC Payload which get's catched later on the client so you don't need to refech the same payload. you should use `use client` create a react client component use math.random() there and import that into your server component. now that a pure client component and will be processed and render on the cilent side.
My question will be, Next JS is meant to help pages load fast, have your pages rebuilt and served as static (if need be - ISR), so if you want your page to avoid caching on the client, then why can't you go directly with Django, or even wordpress that doesn't do the entire caching?
@@abdirahmann And we will keep complaining to every issues, ie, fast-refresh had to perform full reload even if it has no visible effect on the app itself🤣🤣
I think this behavior is intended. Usually, you'll be using fetch instead of Math.random() to generate data for pages, and calling revalidateTag() or revalidatePath() will ignore client-side cache. Try using fetch to a random data API instead of Math.random() in /other, and then calling revalidatePath() from / page before navigating back to /other. It will invalidate client-side cache. It may look weird calling revalidatePath() or revalidateTag() before navigating, but in a real case scenario, you should be calling revalidatePath or revalidateTag after mutating data that can affect some page
Nextjs appears to favor complexity over simplicity, and that Vercel was compelled to write a detailed article explaining caching levers so devs get back to expected behavior is another red flag that the framework is going awry.
Dude I’ve been working on a Jupyter like app and *_MY GOD_* I can’t stand this caching issue. I have to restart the dev server every 10 refreshes. I love Next but this cache issue… especially in development is insane.
Mostly everting i can think of: Blog: You update the title of your blog from /post/[id]/edit... you got back to /list_all_posts -> Title is not updated... Dashboards: You just paid for a subscription for a service. You go back to the dashboard just to find out you're not yet on the paid plan. Shops: You update the price of a product in your shop from the database. Everyone who's viewing your website won't see the updated price (unless they wait 30 seconds)
@miro-hristov oh..hmmm... not to argue, but wouldn't your examples be updated based on the apis not being cached? I would think the page would saturate with the updated state. No?
@@venicebeachsurfer Sure. I'm also new to Next but I think what's happening is Next is now a backend-first framework meaning it renders everything on the server (as flat html maybe). If you want to send JS to the browser you define "use client". So Next is the one pushing for this new (or old) paradigm to render on the server and not the client. You wouldn't need an api because the html in the route already provides the data. It's a good idea but it just needs opt out of client cache option or modify the hard-coded 30 seconds time period.
i really don't feel like app router is production ready… it's really amazing and so much more interesting than pages router, but there are so many issues that just aren't thought through yet. so for now, i'll stick with pages router, it's still pretty amazing as well
That is the main reason im not usong nextjs, I keep starting small project on vite and at work they use vite as well since the server is most of the in another language like go or managed by another team. I wish they did not force you to use so much stuff.
tbh, this is so much complexity to manage. In my current role I support various teams that need to spin up clients for their AI/ML apps or other data vis, all of these features the next team has introduces combined with RSC is too much and forcing me away from the nextjs/react world. SvelteKit seems to be striking a better balance, and I've enjoyed the DX thus far. Regardless I'm looking forward to the future improvements, but it's too much rn.
Hey Josh thanks a lot. I still want to ask, I believe despite this challenge you still use Nextjs for your current projects. Obviously complex applications as well. Has this really affected you in any of those projects so far?
Personally, I think the Pages directory is still a good option to use. It's not as flexible as the app directory, but you also don't have a thousand settings to tweak and be aware of. Vercel also said that they'll support both Pages and App directory for the long term
It has, for example in highly dynamic apps like the reddit clone. I just went with using anchor tags instead of links and felt kinda weird about that. I still use next for my projects because it's an incredible tool nevertheless, I feel much more productive than comparable frameworks
@@joshtriedcoding yeah I noticed in the refit project. Thank you lots. Also, Josh you used editorjs, I wish to ask if by any chance you ever tried facebook’s lexical.
Don’t see a real use case for it. And i think if you want to get the value updated, you can just convert your component to the client side component. I your example it’s a server side component. With that the html is rendered once on the server side. Nothing wrong with it.
And it's still the same! I'm confused as hell at this caching behaviour as a newbie; it works differently in dev and prod! This video was really nicely explained tho.
I think what Josh talks about is Server Components which are different from Server Actions... There's already a way to to do in in SA... revalidatePath(`/admin/shops`);
It’s actually like angular reuseRoute default behavior. The angular dev add flag to change the default behavior. I don’t understand why nextjs dev can’t add mechanism to change the default behavior *shrug* The crud way to fix it is by adding some random query string on the url path 😮💨
Who in their right mind thinks opt-out caching is a good idea? I feel like they’re trying to provide a solution to a problem that never existed in the first place.
Thanks for providing clarification on the inner workings, you are able to break it down neatly. You come across negative, almost condescending. Perhaps a different tone would do better justice to your hard work? Of course a framework focused on SSR is going to aggressively cache. It's the whole point of wanting to use it in the first place. If you need fine grained control over (the validity of) your data, then why would you want to use this in the first place? It's like you're trying to masquerade that a Lamborghini is not that great at plowing your land
Im all for improvements to Next.js, but this against the React rendering model isn't it? When a page changes, it renders a new page. When you go back to home page it should re render, and give a new Math.random. This is just another React footgun / caveat to make the DX even worse.
You are using this as a server side component - why would it change, if it was decided on server side ... cache is fine you have to make it client side component, so it will be new value every time -> client wont handle it as "server knows its way" :)
Not exactly. If you keep clicking back and forth every 20s, the data would remain stale INDEFINETLY (for as long as you keep clicking). You need to really wait 30s without interacting with the app or website for it to update.
@@miro-hristov I know it buddy, it’s just a cool off statement I made 🫣, if you want to fix it just use router.refresh() inside a useEffect in a empty client component and add it in the page 📄
Senior engineers: premature optimization is the root of all evil
Next team: let’s cache eVeRYtHiNg
Reminds me of that quote "There are only two hard things in Computer Science: cache invalidation and naming things"
Better, lets add 4 caches and make them wonder which one has the problem
absolutely right
@@trebturner"there are only two hard things in CS, naming things, cache invalidation and off-by-one errors"
You just saved my life. Thank you! I had recently deployed an application using vercel and NextJS v13 and was panicking when recently added data through the client side was not immediately reflected in the front-end. I double-checked whether data was added or not in my MongoDB database and sure it was recorded. I avoided both client-side and server-side caching by the help of your video. Thank you!
Josh, I believe all these issues are popping out because react (and by implication nextjs) is moving to a full stack solution. It will get better in time, but at the moment they are stuck on reinventing the wheel and catching up with solid libs/frameworks that have been around for years.
I come from a react + express background and everything was working just fine. I decided to pick up nextjs because of SSR. I've since only used nextjs for its file system based routing and SSR and won't attempt to use anything else it has to offer for at least 5 years until the technology has matured enough.
Regarding this caching issue... you basically want the random number to be different on every page hit, regardless if its a reload or a navigation. I'm pretty sure that means it has to be a client component with the default rendering strategy (initial server side render into hydration on the client).
From my (maybe limited) experience, I've noticed that as long as you don't go too deep into nextjs then everything works pretty ok. If the component doesn't render static html, then it's probably not supposed to be a server component.
Honestly this. I feel like some people are still confused when to use client vs server components and how next/link is inherently a client utility. Didn't matter in the pages dir because everything was fetched from client, but now we that we are fetching from server you should probably use an a tag or change to a client component.
Well said man! Yeah this makes sense. Innovating as much as these people do inevitably leads to stuff like this, and it's not a huge deal either. Wish they can make this stuff more clear, other than that next is just an incredible tool
@joshtriedcoding couldn't agree more! Definitely needs to be documented even if it's just to remind people. Love the direction they are headed though
@@trebturner you just happened to remind me me that next/link is inherently a client utility. Thanks. I always forget.
@@trebturnerwe should never be using an a tag in next. An a tag reloads the entire route which defeats the optimizations next provides with prefetching. Each page should have an option to just be a fresh load every single time.
The moment you build any interactive application with the app router it feels like a giant hack imo. Caching issues, client component props not updating when calling router.refresh. Parallel layouts not showing loaders correctly
This... is probably the best explanation I found on caching with Next.js 13. Thanks Josh!
hey man, I am getting better at next and things are getting difficult, videos like your really help. Please keep posting it's really helpful.
I found the cleanest solution to be just wrapping that piece of code in a client component. So everything works the same, and you are able to successfully re-render only that part of the page without doing any fancy workarounds.
The component should be a client component when you use next/link and want refetch server data. I think the Nextjs team just needs to clarify this.
that's interesting behavior, and yeah the must add that to the docs
But still the back button shows cache, even you do all force dynamic etc. since they cache it for 30s regardless if you apply all their methods to clear cache
I've shipped a couple of projects in nextjs 13 now, my solution to this problem was to implement my own Link component for hard refresh.
changeRoute = (url) => {
router.push(url);
router.refresh()
}
This way, at least worked all the times. I really didn't bother much about this "bug" because i was quite never needing this.
But i totally agree with the concept that this example should be on a client component to do it in the right way. I made my own doc about it, if it's dynamic but doesn't come from a fetch then use a client component. In some cases the right alternative would be to create a route api to generate the data and then fetch it.
Yes! That exactly what I thought I would do in that kind of scenario (like the movie) route handler/server action or client comp (but I would go for route handler since I don’t need state operations / web APIs)
The core problem for me seems to be that NextJS is built around static generation for docs, blogs or e-commerce. As soon as you have something more dynamic, it's hurting more than it helps.
Yep, people using Next to build more app-like stuff should really just use React with Vite...
Not really, Josh just missed that it should be a client component, not a server one. At our company we have a huge interactive web app all in NextJS, works fine.
@@zzzyyyxxx Oh it can work fine for sure! I should have specified I was referring to React Server Components. If you're not using RSC and keep the bulk of the code on the client, then you're just doing React. I like using NextJS for the nice dev experience though, had my fair share of webpack configs and shit 😂.
5:25 I love when Josh remembre when he was coding in PHP 20 years ago circa 2003
Yeah, like 20 years ago him as a baby already stepping through xdebug breakpoints 🤣
@@CistiC0987 hahahah
This messes with mediastream too. The camera stays on even after u turn it off!
I found a temp workaround until I understand or find real solution. On my client, I make call to an empty API POST request. And my client always refreshes. A GET won't do it. It was a temp solution until I was going to figure out the truth.
Remember we are all still really happy and proud of the entire community pushing forward our react stack. We will get this polished just like everything else.
Thank you for highlighting the issue Josh.
Hey Josh, you have an update about this?
You have to import dynamic from next for it and use {ssr: false}. But you gotta use the {Math.random()} as a component. After that you can see the magic. 👍
Oh really ?
Doing this somehow makes the component to act like a client component yeah ?
This is the best solution. Instead of switching the whole page to a client component by using "use client", you keep server rendering the page but turn the dynamic bits (where you use state or need client calculations) into their own child components, and use "use client" on the top of that component. Will work flawlessly and is the best of both worlds.
2:50 something tells me next does not do this, react query is doing it. It sounds like a lazy not flexible react query implementation 😢
Having you explain all of these for someone that had to research the answer of this problem 7 months ago, when these information were not even fully released, it’s great. Could you please try to do a short video on what could be the available quickfixes for this issue at this moment? Thanks, love your videos.
//Here's a solution that runs every time you navigate to a page causing the cache to be refreshed. Found it on someone's twitter.
"use client"
import { useRouter } from "next/navigation"
import { useEffect } from "react"
export function ForceRefresh() {
const router = useRouter()
useEffect(() => {
router.refresh()
}, [])
return
}
I found the best solution is to just move it to a client component.
@@LeprekusGaming This is a solution that doesn't require refactoring and still has any advantages you're utilizing from RSC afaik. You can do it any way you want.
I totally agree with you. I recently faced the exact same issue. My temporary solution is to pass a Math.random() to the query parameters to force Next.js to fetch the data again. I hope they will fix it soon.
did the same. Called it &nonsenseNextjs13. It will remind me very visibibly to stay up to date and remove that annoying workaround
what is the hint in doing the math.random in a client component?
so basically you want client side reactivity on that random number section. you can simply use a client component + effect hook (if necessary) to achieve that
With nextjs 15, it looks like they are less aggressive with caching... I check random number is changing with SSR.
This happened to me I thought I was doing something wrong am the API slice on till I monitor my network. I found out that the cash stores the data in other to render it faster whenever it's called again. An the problem is with the behavior of Link element which manage cashing navigation.
hey josh how to use redux or any other state management library in nextjs13 approuter can you make a video on it properly using it
You can also use react query and pass the initial data from the server component to react query. Then use react query for refetching.
Bro in the first moment I thought that was my comment HAHA
@@martapfahl940 two brothers have met each other in wild xD
@@whotfevencares xd
That's a server-side component. The Math.random runs on the server-side. Consider the server-side code is PHP and the rest is jQuery, you get the same result. Imagine you are mixing PHP and jQuery in the HTML file. Now they turn into React and the HTML becomes JSX. Tada!
But it's cached on the client, dude.
i think vercel is very obsess about speed. next 13 completely destroyed my stack.
Window.location.reload() on router.back() ?
I noticed it's running out of memory and shutting down the server, I am so frustrated
The amount of education NextJS need to put and still not getting anywhere means only one thing :)
Its not intuitive anymore :)
It's a side effect of innovation and I find it totally acceptable. Stuff like this is very frustrating, hence the video. In the grand scheme of things, it's a rather small part of nextjs that will get better with time
@@joshtriedcoding i still think its a bad design, which they insist not to change :) caching everything is kinda insane
just imagine this in a extremely complicated web app
after 6 months the problem is still the same, even the documentation says the same....
guys are you facing still the same issue, or there is a solution already?
What about using revalidateTag? For example, I needed a way to request an updated API access token when it expired. Of course, NextJS cached the function requesting the token and so it would not rerun when I needed it to. However; in the fetch request, I added a tag (e.g. fetch('url', {next: {tags: ['api-token']}}). Then I call revalidateTag(['api-token']) upon receiving a 401 status, which invalidates the cache for that function and allows for the token to be requested again. I think this only helps when using the Fetch API, though.
What happens when you read directly from your database and can’t use fetch?
cant we use server components for this usecase?
Josh, thank you so much for the explaination. Perfect timing!!!!!!
bro next js routing is to slow for big project how to handle this
I too had the same problem while working on my side project. Nextjs caching is too aggressive. For invalidating the router cache, they provide router.refresh method although it only works for the current route.
Is it possible to use react query to handle client side caching instead of nextjs client route caching?
It is just so bad, I was changing my RTK Query API Calls, the body of it, and my Next App still send the data in the old format until I made a hard refresh with cache busting in my browser. Or do you think that was browser caching? :D
Sometimes the simplicity of a full page reload is just good enough, like in those "old" PHP days :)
It's so simple and easy to understand what's happening that it doesn't need a full fledged war map about the caching strategy.
I did use that anchor tag in the end😅
i tried your last example, but can't seem to replicate what happened in the last part of the video. is it because of a next update?
Is there a way I can skip routes prefetching data at build time ? Basically I can use 'no-store' or 'force-dynamic', but with that I won't be able use data cache at all in run time.
2:15 But this is only the case if you use fetch, right? Things like Prisma or Axios calls are not automatically deduped I think.
No. What he's talking about is browser cache. It doesn't even hit the server
@@miro-hristov I think hes talking about both the server and client cache
@@codinginflow True! But he gives ways to "opt out" of server cache. The real point of his video is the inability to opt out of client-sided cache.
@@miro-hristov Right but my comment is not related to that part
@@codinginflow I see. My bad then
Hasn't bothered me in web apps, but we've stuck it in capacitor and made an android app and I think it's causing issues...can you do an advanced react hook form video, like with inputs that change based on other values, I.e maybe a discount type and value, which could be a time period a percent or a dollar amount and how you would handle that. Also dealing with null in forms, like let's say a phone number could be a string or null, rather than dealing with empty strings as null, is there a better way...all these things seem to have little quirks like using onChange doesn't make the field dirty...
whole team is facing the issues cause of this, we were almost done with the things and then see this behaviour and we are like WTF
Right? I was testing NextJS before the development and started facing this issue. The problem is, that not always we can revalidate manually (especially when the data are from the remote/external servers). I would like to cache it for 5 seconds on a backend but at all on a client but... this is not doable right know. AND there is another strange behaviour: When I wait those 30 seconds which Router Cache will cache your page, then the new page/load is not cached at all. So after 30 seconds, every click on a makes an request. Which is WTF. :D
The only thing I could find to workaround this was a client side cache busting link
Have you used angular before ?
This is exactly what is bugging me at the moment😢 any solution??
Honestly seems like Next is just getting in the way at this point. Glad things like Remix and Svelte are getting more traction since this app router mess
What’s a real world use case for this?
Putting a clock into a client component ? Would re-render every time. You can keep page parts on “client”.
I think devs should be careful when using server components excessively. It's great for static content which doesn't require JS such as footer or some static sections of the page, and most importantly server-side fetch. However otherwise, "use client" is the key for everything most of the time. For the sake of argument, adding "use client" to root layout.tsx allows to render the app exactly like Next 12 (pre-rendering html and then hydrating on client). That being said, server component is a nice addition, it comes with many advantages yet there is nothing wrong with using client side components. Yours is a pretty unique case actually and it should be handled by using a client component I guess. But it doesn't change the fact that this new paradigm becomes frustrating sometimes.
There's an obvious contradiction between "being careful with server components" and "making them the default" by React.
Hey josh, so do you recommend nextjs 13 still?
Still experimentary, things definetely will be changed until 14.
For new or personal side projects, I'd say yes. Things will definitely evolve and hopefully change for the better.
For well established or big projects I'd say stick to the pages router. It will inevitably become legacy code, but that's pretty normal in tech. New tools appear every year and the old ones get replaced by improved ones. Because of this, there's not really much of a point in trying to keep your project up to date with the latest trends. Just focus on delivering a good product with the most accessible tools at your disposal.
@@dan_____ Agree, Next.js 13 features will get sophisticated in the next versions. At this point, you can migrate legacy Page Router as well.
yes
The server-side component you see when you click the back button comes from the browser. That’s more of the default behavior of the browser than the act of Next.js framework.
He presses the back button in the webpage not the browser button.
If you have data that change a lot and don't want cache, wouldn't you simply do a fetch on page navigation?
I'm just trying to see the problem from another angle...
It is unfortunate but you can always just fetch on the client like we used to do back in the pages folder. Im sure they will eventually have a solution for this.
Damn. I agree Josh. It is really frustrating.
Finally I understand this caching mess... Thank you Josh.
Does remix have this problem?
hi, i am new in nextjs but i think this is a rendering problem?? you have decleared this math.random() code in React server component. which sends RSC Payload which get's catched later on the client so you don't need to refech the same payload. you should use `use client` create a react client component use math.random() there and import that into your server component. now that a pure client component and will be processed and render on the cilent side.
My question will be, Next JS is meant to help pages load fast, have your pages rebuilt and served as static (if need be - ISR), so if you want your page to avoid caching on the client, then why can't you go directly with Django, or even wordpress that doesn't do the entire caching?
because we want to write react code 😂😂
@@abdirahmann And we will keep complaining to every issues, ie, fast-refresh had to perform full reload even if it has no visible effect on the app itself🤣🤣
Rich Harris is whispering: "Josh try sveltekit now"
I think this behavior is intended. Usually, you'll be using fetch instead of Math.random() to generate data for pages, and calling revalidateTag() or revalidatePath() will ignore client-side cache.
Try using fetch to a random data API instead of Math.random() in /other, and then calling revalidatePath() from / page before navigating back to /other. It will invalidate client-side cache. It may look weird calling revalidatePath() or revalidateTag() before navigating, but in a real case scenario, you should be calling revalidatePath or revalidateTag after mutating data that can affect some page
Nextjs appears to favor complexity over simplicity, and that Vercel was compelled to write a detailed article explaining caching levers so devs get back to expected behavior is another red flag that the framework is going awry.
First video. Subscribed!
Dude I’ve been working on a Jupyter like app and *_MY GOD_* I can’t stand this caching issue. I have to restart the dev server every 10 refreshes. I love Next but this cache issue… especially in development is insane.
What would be your use case in which you do NOT want client side cache?
Mostly everting i can think of:
Blog: You update the title of your blog from /post/[id]/edit... you got back to /list_all_posts -> Title is not updated...
Dashboards: You just paid for a subscription for a service. You go back to the dashboard just to find out you're not yet on the paid plan.
Shops: You update the price of a product in your shop from the database. Everyone who's viewing your website won't see the updated price (unless they wait 30 seconds)
@miro-hristov oh..hmmm... not to argue, but wouldn't your examples be updated based on the apis not being cached? I would think the page would saturate with the updated state. No?
@@venicebeachsurfer Sure. I'm also new to Next but I think what's happening is Next is now a backend-first framework meaning it renders everything on the server (as flat html maybe). If you want to send JS to the browser you define "use client". So Next is the one pushing for this new (or old) paradigm to render on the server and not the client. You wouldn't need an api because the html in the route already provides the data. It's a good idea but it just needs opt out of client cache option or modify the hard-coded 30 seconds time period.
i really don't feel like app router is production ready… it's really amazing and so much more interesting than pages router, but there are so many issues that just aren't thought through yet. so for now, i'll stick with pages router, it's still pretty amazing as well
I would try wrapping the Math.random call in an IIFE and seeing how that affects the way the cache treats it.
thank you, It is very useful
That is the main reason im not usong nextjs, I keep starting small project on vite and at work they use vite as well since the server is most of the in another language like go or managed by another team. I wish they did not force you to use so much stuff.
I just switched back from nextjs to regular react with wouter. I swear nextjs 13 is too problematic.
tbh, this is so much complexity to manage. In my current role I support various teams that need to spin up clients for their AI/ML apps or other data vis, all of these features the next team has introduces combined with RSC is too much and forcing me away from the nextjs/react world. SvelteKit seems to be striking a better balance, and I've enjoyed the DX thus far. Regardless I'm looking forward to the future improvements, but it's too much rn.
Hey Josh thanks a lot.
I still want to ask, I believe despite this challenge you still use Nextjs for your current projects. Obviously complex applications as well. Has this really affected you in any of those projects so far?
Personally, I think the Pages directory is still a good option to use. It's not as flexible as the app directory, but you also don't have a thousand settings to tweak and be aware of. Vercel also said that they'll support both Pages and App directory for the long term
It has, for example in highly dynamic apps like the reddit clone. I just went with using anchor tags instead of links and felt kinda weird about that. I still use next for my projects because it's an incredible tool nevertheless, I feel much more productive than comparable frameworks
@@danshilm you make a great point. Thank you. I truly love the flexibility of the app dir. it’s a genius venture.
@@joshtriedcoding yeah I noticed in the refit project. Thank you lots.
Also, Josh you used editorjs, I wish to ask if by any chance you ever tried facebook’s lexical.
Don’t see a real use case for it. And i think if you want to get the value updated, you can just convert your component to the client side component. I your example it’s a server side component. With that the html is rendered once on the server side. Nothing wrong with it.
omg now I understand why I can see my homepage even though I logged out. Its a serious problem
Give sveltekit a go! 😊
Imo caching should be completely disabled unless you configure it.
And it's still the same! I'm confused as hell at this caching behaviour as a newbie; it works differently in dev and prod! This video was really nicely explained tho.
Hey Bro did you find any solution??
Next 13 deployment is a nightmare))
if you really need all time updated value why you are creating a server component, make it a client component and play with fetch api+local js
What if you generate the random number server-side?
change it to client component
router.refresh?
We are staying with /page route. Works fine
Nicely explained
They are currently working on new caching behavior in server actions to make it behave more like router.refresh()
I think what Josh talks about is Server Components which are different from Server Actions... There's already a way to to do in in SA... revalidatePath(`/admin/shops`);
It’s actually like angular reuseRoute default behavior. The angular dev add flag to change the default behavior. I don’t understand why nextjs dev can’t add mechanism to change the default behavior *shrug*
The crud way to fix it is by adding some random query string on the url path 😮💨
Why cache client side?
Don't browsers do that already for us?
What's total cost vs. benefit of having that?
it's like they focused too much on e-commerce and forgot about anything else
Who in their right mind thinks opt-out caching is a good idea? I feel like they’re trying to provide a solution to a problem that never existed in the first place.
Next.js 13: Think Caching.
Thanks for providing clarification on the inner workings, you are able to break it down neatly. You come across negative, almost condescending. Perhaps a different tone would do better justice to your hard work?
Of course a framework focused on SSR is going to aggressively cache. It's the whole point of wanting to use it in the first place. If you need fine grained control over (the validity of) your data, then why would you want to use this in the first place? It's like you're trying to masquerade that a Lamborghini is not that great at plowing your land
Well im fucked then
That is insane. Caching should always be opt-in.
Sounds like I’m going to Qwik City when pages router is deprecated.
You can use the no-cache directive, no?
Im all for improvements to Next.js, but this against the React rendering model isn't it?
When a page changes, it renders a new page. When you go back to home page it should re render, and give a new Math.random.
This is just another React footgun / caveat to make the DX even worse.
i am seeing no issue with nextjs here
You are using this as a server side component - why would it change, if it was decided on server side ... cache is fine
you have to make it client side component, so it will be new value every time -> client wont handle it as "server knows its way" :)
I would prefer they would let people to opt-in for caching instead of finding a way to opt-out!
It’s a matter of 30s 😅
Not exactly. If you keep clicking back and forth every 20s, the data would remain stale INDEFINETLY (for as long as you keep clicking). You need to really wait 30s without interacting with the app or website for it to update.
@@miro-hristov I know it buddy, it’s just a cool off statement I made 🫣, if you want to fix it just use router.refresh() inside a useEffect in a empty client component and add it in the page 📄
If something has to be real time make it a client component
But what if you want to preload the data on the server? This makes no sense. Back in paved route it worked just fine.