I Hate Next.js 13 Caching Even More Now
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- I prefer Next over all the other frameworks. Makes me and many others insanely productive. But caching in Next.js 13? Aw man it sucks. Glad they acknowledge the problem with their article, but it's really frustrating.
Article: nextjs.org/doc...
-- my links
Next.js SaaS: splitter.gg
Discord: / discord
My GitHub: github.com/jos...
![[Live] ศึกมหึมันส์มวยไทยสังเวียนเดือด เวทีมวยชั่วคราวสวนสยาม | จันทร์ 30 กันยายน 2567](http://i.ytimg.com/vi/pM1k6f7JXUc/mqdefault.jpg)
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"
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
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
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 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
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
i think vercel is very obsess about speed. next 13 completely destroyed my stack.
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.
This... is probably the best explanation I found on caching with Next.js 13. Thanks Josh!
This messes with mediastream too. The camera stays on even after u turn it off!
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 📄
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.
Give sveltekit a go! 😊
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 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!
Next 13 deployment is a nightmare))
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
Imo caching should be completely disabled unless you configure it.
Hey Josh, you have an update about this?
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.
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 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.
Window.location.reload() on router.back() ?
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.
it's like they focused too much on e-commerce and forgot about anything else
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.
Well im fucked then
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.
Rich Harris is whispering: "Josh try sveltekit now"
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.
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
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
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?
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?
what is the hint in doing the math.random in a client component?
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.
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...
Next.js 13: Think Caching.
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
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.
Finally Next.js 15 fix this. That's good.
Damn. I agree Josh. It is really frustrating.
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`);
change it to client component
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.
thank you, It is very useful
Have you used angular before ?
i am seeing no issue with nextjs here
I think you don’t know the point dude
First video. Subscribed!
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
Youre just conceptually confused.
The behaviour you want to achieve is extremely inefficient for server side rendering, specially if you're hosting serverless-ly.
A client component would be the solution to that problem.
I think people are having an issue adjusting because they're still thinking in react, when at this point you should be thinking in a mix between Django/PHP and react, with out of the box optimization features to increase delivery speed to users, and save on computing resources (caching, memoizing/deduping, revalidation mechanisms)
Doing react server side is just not efficient at all, and also pretty unnecessary. Server components come in handy when talking about SSR, ISR and SSG.
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
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 😮💨
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.
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.
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.
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
Why do you need caching? Every video on caching is always missing the supposed real-world scenario that people have a problem with, that they believe cache can solve.
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" :)
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.
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.
I just switched back from nextjs to regular react with wouter. I swear nextjs 13 is too problematic.
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 doooo agree with you
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.
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 😢
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
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.
Nicely explained
Putting a clock into a client component ? Would re-render every time. You can keep page parts on “client”.
omg now I understand why I can see my homepage even though I logged out. Its a serious problem
Is it possible to use react query to handle client side caching instead of nextjs client route caching?
I noticed it's running out of memory and shutting down the server, I am so frustrated
This is exactly what is bugging me at the moment😢 any solution??
I would prefer they would let people to opt-in for caching instead of finding a way to opt-out!
The only thing I could find to workaround this was a client side cache busting link
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.
bro next js routing is to slow for big project how to handle this
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
Last
cant we use server components for this usecase?
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.
:'v
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.
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...
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.
Finally I understand this caching mess... Thank you Josh.
We are staying with /page route. Works fine
Stop using opinionated frameworks
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?
Welcome to the everything ssr No Sense 👎
I would try wrapping the Math.random call in an IIFE and seeing how that affects the way the cache treats it.
revalidatepath
doesnt this get very expensive when called for small actions such as liking something?
@@joshtriedcodingcheaper than switching the whole codebase to something else haha
@joshtriedcoding always use optimistic rendering for stuff like that
@@mr2octaviohaha that was actually funny
@@joshtriedcoding it still cheaper than opting out of caching like you suggested in the video, there is also "export const revalidate = 0" and on demand revalidation all is better than opting out completely
Josh, thank you so much for the explaination. Perfect timing!!!!!!
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.
What’s a real world use case for this?
And the worse part: if we use 'use client', we will loose all the other caching beneffits...
Turn the dynamic bit into a component with "use client". Then you get the whole page cached server side and the dynamic bits always fresh