I Hate Next.js 13 Caching Even More Now
HTML-код
- Опубликовано: 14 окт 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...
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
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!
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)
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
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 😂.
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.
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.
This... is probably the best explanation I found on caching with Next.js 13. Thanks Josh!
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
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.
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.
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.
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
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
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.
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
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
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.
Damn. I agree Josh. It is really frustrating.
what is the hint in doing the math.random in a client component?
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
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.
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.
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
Rich Harris is whispering: "Josh try sveltekit now"
i think vercel is very obsess about speed. next 13 completely destroyed my stack.
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...
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.
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.
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
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.
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.
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.
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.
Is it possible to use react query to handle client side caching instead of nextjs client route caching?
This messes with mediastream too. The camera stays on even after u turn it off!
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.
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 😮💨
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
cant we use server components for this usecase?
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
Josh, thank you so much for the explaination. Perfect timing!!!!!!
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?
We are staying with /page route. Works fine
I would try wrapping the Math.random call in an IIFE and seeing how that affects the way the cache treats it.
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🤣🤣
Hey Josh, you have an update about this?
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.
omg now I understand why I can see my homepage even though I logged out. Its a serious problem
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
Finally I understand this caching mess... Thank you Josh.
Have you used angular before ?
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?
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??
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...
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`);
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.
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 😢
Give sveltekit a go! 😊
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
Putting a clock into a client component ? Would re-render every time. You can keep page parts on “client”.
Next 13 deployment is a nightmare))
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.
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.
it's like they focused too much on e-commerce and forgot about anything else
I just switched back from nextjs to regular react with wouter. I swear nextjs 13 is too problematic.
I did use that anchor tag in the end😅
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?
Next.js 13: Think Caching.
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
The only thing I could find to workaround this was a client side cache busting link
That is insane. Caching should always be opt-in.
Sounds like I’m going to Qwik City when pages router is deprecated.
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.
Window.location.reload() on router.back() ?
I would prefer they would let people to opt-in for caching instead of finding a way to opt-out!
Imo caching should be completely disabled unless you configure it.
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" :)
change it to client component
First video. Subscribed!
bro next js routing is to slow for big project how to handle this
You can make a "client component" which is including "Math.random()", and then the server component include that component.
I noticed it's running out of memory and shutting down the server, I am so frustrated
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.
This is exactly what is bugging me at the moment😢 any solution??
Does remix have this problem?
I'm at the stage of deciding whether to do a new (quite large) project on next.13 (I had some contact with it). Is it on the 12++ version that I know well - with the old appRouter and without dynamic layouts.
What do you think ? I would definitely write it faster in version 12++, especially since there are a lot of hits to the rest api (mainly GET), and a lot of dynamic content.
However, using 13, I would probably learn more about the new next, and understand version 13 more.
What do you think ?
A genuine advice don't use nextjs if possible at all and if you must go with v12. Underwhelming docs, non existent best practices, too many hidden tweaks, slow dev server it's a nightmare choose wisely while you can mate
What’s a real world use case for this?
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.
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
Nicely explained
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 📄
Kindly give us a detailed video on the streaming server, How can we create a streaming server and pull the streams from IP camera and convert it to the hls format and then use it in the web. This is an interesting topic.
Well im fucked then
thank you, It is very useful
i am seeing no issue with nextjs here
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 is why I am against deep frameworks, when you are stuck you are stuck. This is why in C and Forth there's the "write it yourself" mindset, that guarantees that it's lean, fast but more importantly does what you want and will always work because you own it. For some reason this mindset of: "do it yourself" and actual system development, has gone away. Luckily I keep pushing that mindset in my projects because it makes you software life cycle so much longer. And your software so much smaller and more efficient, as it just does what it needs to do and not the whole shabang of the features you don't need and often cause security issues and maintenance headaches because there's security patches on it -- or libraries go out of support and you need to upgrade. Stop using deep frameworks and code it yourself, like a real man. Your dad's and grandad's did it that way. And the often didn't have highlevel easy to use languages like Rust, C++, Python (uggh) of TS/JS (blehhh).