I think if use hook implemented the conditional checking like rtk query, that would result in a much cleaner code. We could pass a null value to say don't fetch instead of having to add if blocks there.
I agree, React query and swr are gonna be go to used, but creators of these libraries will have these hooks to use and improve their performance, api, etc... :) So all in all, it's an awesome addition, even if we "users" don't use it to fetch client side.
Thanks for always keeping us up to date with this stuff! Regarding the outro question: of course we would like to see you talk about the server side also 👍🏻😂
But use+cache can be used in React Server Components and doesn't need explicitly passing the data through props to hydrate components across SSR boundary. At least as of yet... they're still discussing how to support RSC.
@@dealloc "use+cache can be used in React Server Components" I'm just a guy trying to stay current but I thought he had to use "use client" because RSC doesn't support this?
So nice to hear that this finally landed in React. It'll further help libraries like react-query. At the moment, does React provide a way to invalidate the cache?
@jherr 15:13 in this particular case the standart flow is to reogranize your useUserId like this: const useUserId = () => { const context = useContext(UserIdContext); if (!context) { throw new Error("Put your useUserId inside UserIDContext provider!"); } return context; }
Great video! Very curious to learn more about what the cache invalidation story is, as you say at the end… obviously a great solution for static JSON data, not so great for any data that can become stale during the lifetime of a user’s session in the app. Thanks for your work.
Great job as always..Jack. I recently found ur channel and I must say ur content is very high quality. This is off the topic but it would be nice if you can create one video about how u keep track of all this tech updates.
Great job as always, Jack! I've been watching your videos for a while now, and this is my first comment. I have a question: What would happen if the data fetched was changed in real-time by another user? I plan on testing this on my machine when I get the chance, but I was just curious if you had already tested it yourself. Keep up the fantastic work!
If it's cached you are always going to get the value from the first time it was fetched. That's why I mentioned that with a SPA you are going to need to figure out some cache invalidation strategy.
Very nice explanation. Like it... I'm using RTK query and conditional call is better, ease and clean. Monorepo with separated store as a package is for me best option. For smaller project cache is solution to go.
Wow, React is turning into a mess, hope this "innovation" with use\cache will be either deprecated or used only by library builders that would decide to support RSC. Anyway, thanks for the video, Jack!
Memo is exclusively a way to mark a component as "memoized" based on its input props. Where `cache` is a generic memoization function similar to what you might find in lodash.
After this video, I started searching for SWR tutorials on youtube but there isn't any new ones with NextJS13. Can you please make a video for next13? that would be the best thing...
Love this new addition to React. I've used useSWR for a while now and I'm super happy with it. If there are minor cases where I would opt for this, I don't see it right now. But great addition. Thank you Jack!!!
You can use the `useˋ hook in React server components, i think it is a better drop in replacement for async components that don’t work natively with typescript.
Very cool. Would be interesting to see a video that explains how to use this cache mechanism to create complex data (header + children) for preparing a create / update to remote database operation
Great video as always React has been getting more and more tiresome for a long time by including more and more rules unnecessarily, but now it seems to be including even more exceptions than rules It presents 1000x ways to do something and none of them are satisfactory, in the end it is up to the community to take these tools and transform them into a minimally decent solution It's really exciting that React has gathered around itself creators of fantastic libraries (like the tanstack team for example) but it's really disappointing that it's not possible to create even a toy app satisfactorily using React without having to resort to a third-party library
@@OnceABustAlwaysABust IMHO the state management primitives provided by React don't scale well beyond simple applications. The dependency arrays are too easy to get wrong.
Also it's unclear what the standard React methodology for fetching data is at this point. Which is why libraries like react-query and swr are so popular. And this use hook is just adding to that confusion. It seems to me like `use` is the promise hook that should have been in the original batch of hooks.
IMHO, no. I know that it technically can be done. But in my opinion, if it's important enough to be server rendered then it's critical functionality and I don't recommend using MFEs for critical functionality.
Thanks for the great video explainer Jack. I was under the opinion that this hook has very little use and would eventually lead to boilerplate. As expected they had to add a cache function for it. What's a bit shocking for me is that every API that they add to react has an affinity for infinite loops. Yet they claim this is the perfect library for managing UI. 😅 So many footguns are introduced after hooks
Would be super cool to see how this works on the server. But I couldn't understand why we get an infinite loop just by passing a query param. I get the distinction between a function reference and its contents but all that changed was the query param, right? Am I missing something here?
As it was told in the video, NextJS replaced native fetch with some "wrapped in cache", so i guess this implementation from NextJS is just work with requests with and w/o query params in different manner.
But when using error handling with error.js like so if (status !== 200 ) { throw new Error('Error fetching organization'); } We get Error not implemented when used in client components
beta.nextjs.org/docs/data-fetching/caching It's mostly about the server functionality, and there the fetch is cached and has invalidation controls. But that's server only currently.
To me, any cache has a progression of steps. Writing or setting a key is easy. Then you have to figure out how to refresh or invalidate. This is difficult (the meme). Many times time will be used when time is not really what we want. Then we start thinking in events. Then our app structure doesn't support this evented perspective easily. I need to write this up.
Great video Jack... you're my hero! Just one question, how can I invalidate the cache because of some mutation or something like that to force the network request again?
Wow great walk through on cache functionality. I am really wondering how useful would it be on server side. To be precise, cache returns the same data for same fetch function with same arguments by comparing it's ( value for primitive type and reference for non-primitive type ) right?. what if we send object ( body data ) as an argument. If such object come the component instead of from context , it would still make the fetch calls right?
5:01 Question 1)Home gets rendered 2)A promise and then reference is created 3)use sees this change and sends a request to backend 4)data arrives after some time 5)Home renders the data AND that causes steps to begin from 1? Di I understand the problem correctly? 🤔
@@vakhtangnodadze4802 Yeah, me too. It's just unstable. It shouldn't have worked the first time. To be fair, the NextJS docs say that use(fetch()) is a feature which is currently not supported. I showed it in the video to make folks aware of that viscerally and to give them some reasonable alternatives with `cache`.
The cache function itself isn't going to handle that. I'd add a function that gives you the current cache function and then replace that cache function every sixty seconds.
use/cache look great! However, if we had to work with dynamically changed data (or user changes his/her first name) the fetch workaround would still return the old value.
@@jherr could you make a video or a short explaining how you would revalidate the path or tag of that fetch request? Like on demand revalidation, after the user changes its name, for instance...
We are going in the SSR again. Indeed i just feel that I've wasted so much time in the react ecosystem. I could've done something worthy engineering stuff than just optimizing my fetch calls which still sucks. This react ecosystem is tiring now.
I'm glad they're making these additions. I'm not 100% sure if this would work, but for lightweight revalidation, in fetchUser you could maybe do something like let func = cache((id:number)=>{...}) const revalidate = ()=>func = cache((id:number)=>{...}) return {func, revalidate} of course you'd probably want to extract the inner function somewhere outside of cache, this could even be a wrapper for any function you want to be able to revalidate. But long story short, this would just invalidate the entire cache, since in revalidate we just reassign the cached function to a new one. React query still seems way better for things, but if you don't want to bring it in for whatever reason, but absolutely need some form of revalidation, this would probably work.
I'd go with your plan B, flush the whole cache. Have a cache getter function that would dynamically return the cache. Then another function to flush it and make a new empty cache.
i really hope when this is Outta experimental they also make useSwr automatically handle all of this on both client and server. while this is cool i really don't wanna think of how I'll need to handle my fetch requests based on if i call it on the client or server
I'll have to start calling you JsWizard at this point. Given your deep knowledge in the JavaScript Ecosystem, I wonder what would be your tools of preference for a social network application and why!? - Thanks in advance
hey Jack, is there has cancelation of fetch process like axios cancelation??, because if the data is big, that take a long time to post/recieve, is there any solution to cancel the process?
When is the cache cleaned? Looks like a terrible memory leak. I am using mobx for years and I am pretty surprised how many strange solutions come up all the time that solve parts of the problems that mobx solves "magically"
Hey I was trying to develope a website using next js and redux toolkit but I have no idea how to structure the project at all can make a video on project structure of enterprise level project structure for next , redux toolkit with material UI
I don't get the point of having a global fetch request thanks to cache, because we don't need cache to have that response at a top level RSC and have that RSC pass down the response as props to other children components. So the fetch call is now global thanks to RSC not thanks to the all new cache functionality. Correct me if I'm wrong.
i love you jack herrington
That's Jaime Oliver
I think if use hook implemented the conditional checking like rtk query, that would result in a much cleaner code. We could pass a null value to say don't fetch instead of having to add if blocks there.
I agree, React query and swr are gonna be go to used, but creators of these libraries will have these hooks to use and improve their performance, api, etc... :) So all in all, it's an awesome addition, even if we "users" don't use it to fetch client side.
That's exactly what I was thinking. Better primitives for the library maintainers like react-query.
Thanks for always keeping us up to date with this stuff! Regarding the outro question: of course we would like to see you talk about the server side also 👍🏻😂
This is great. But i think, for fetching SWR or React Query is much better as it uses SWR approach.
I'd use react-query instead, because lot of what it was done is already implemented by this library.
But use+cache can be used in React Server Components and doesn't need explicitly passing the data through props to hydrate components across SSR boundary. At least as of yet... they're still discussing how to support RSC.
@@dealloc "use+cache can be used in React Server Components" I'm just a guy trying to stay current but I thought he had to use "use client" because RSC doesn't support this?
So nice to hear that this finally landed in React. It'll further help libraries like react-query.
At the moment, does React provide a way to invalidate the cache?
I'm interested in seeing this work on the server!
@jherr 15:13 in this particular case the standart flow is to reogranize your useUserId like this:
const useUserId = () => {
const context = useContext(UserIdContext);
if (!context) {
throw new Error("Put your useUserId inside UserIDContext provider!");
}
return context;
}
Great video! Very curious to learn more about what the cache invalidation story is, as you say at the end… obviously a great solution for static JSON data, not so great for any data that can become stale during the lifetime of a user’s session in the app. Thanks for your work.
Great job as always..Jack. I recently found ur channel and I must say ur content is very high quality. This is off the topic but it would be nice if you can create one video about how u keep track of all this tech updates.
so clear walk-through and thoughts in the wrap-up in the end 👏👌
Love it Jack... Please make a video for server side handling too. Your videos are best when it comes to logical problems.
Awesome video Jack. I was just wondering the use hook behaved that way. Nice Vscode theme as well, what theme is that?
Great job as always, Jack! I've been watching your videos for a while now, and this is my first comment. I have a question: What would happen if the data fetched was changed in real-time by another user? I plan on testing this on my machine when I get the chance, but I was just curious if you had already tested it yourself. Keep up the fantastic work!
If it's cached you are always going to get the value from the first time it was fetched. That's why I mentioned that with a SPA you are going to need to figure out some cache invalidation strategy.
@@jherr Thanks! I see that make sense.
Very nice explanation. Like it... I'm using RTK query and conditional call is better, ease and clean. Monorepo with separated store as a package is for me best option. For smaller project cache is solution to go.
Wow, React is turning into a mess, hope this "innovation" with use\cache will be either deprecated or used only by library builders that would decide to support RSC.
Anyway, thanks for the video, Jack!
yes please server also. you the man, jack!
such a nice approach! thanks so much Jack!
would this work in plain React or just Next?
Great video as always, Jack! So if I understand it correctly, 'memo' memoizes based on input props, but 'cache' additionally memoizes the result?
Memo is exclusively a way to mark a component as "memoized" based on its input props. Where `cache` is a generic memoization function similar to what you might find in lodash.
Definitely will be useful to see how it works with server components
Love to see the server side fetch!
After this video, I started searching for SWR tutorials on youtube but there isn't any new ones with NextJS13. Can you please make a video for next13? that would be the best thing...
Thanks, Jack. I would love the server side version of this video.
I get your point in this, we shouldn't have to do the work Lol, react framework should've handled that caching thing in the use hook by default
Love this new addition to React. I've used useSWR for a while now and I'm super happy with it. If there are minor cases where I would opt for this, I don't see it right now. But great addition. Thank you Jack!!!
Thanks for the exploration! There's no better place to catch up with the daily breaking changes in the react community.
You can use the `useˋ hook in React server components, i think it is a better drop in replacement for async components that don’t work natively with typescript.
I didnt know that, thanks im deff going to give that a try 👍
Jack, thank you. You are awesome. You have helped me get better with React. This is
Very cool. Would be interesting to see a video that explains how to use this cache mechanism to create complex data (header + children) for preparing a create / update to remote database operation
This is really cool. How will it compare against react-query or apollo's normalized cache?
Probably under-featured versus those IMHO.
Judging by this video, it doesn't look like there's any way to invalidate the caches like you can in Tanstack query
Definitely want to see how it works on the server
Another Amazing video, I really liked this. I've use Apollo Graphql and it does the same thing out of the box ( Caching ).
Great video as always
React has been getting more and more tiresome for a long time by including more and more rules unnecessarily, but now it seems to be including even more exceptions than rules
It presents 1000x ways to do something and none of them are satisfactory, in the end it is up to the community to take these tools and transform them into a minimally decent solution
It's really exciting that React has gathered around itself creators of fantastic libraries (like the tanstack team for example) but it's really disappointing that it's not possible to create even a toy app satisfactorily using React without having to resort to a third-party library
Agreed.
Can you name a specific problem? I can totally create a toy app with nothing but React
@@OnceABustAlwaysABust IMHO the state management primitives provided by React don't scale well beyond simple applications. The dependency arrays are too easy to get wrong.
Also it's unclear what the standard React methodology for fetching data is at this point. Which is why libraries like react-query and swr are so popular. And this use hook is just adding to that confusion. It seems to me like `use` is the promise hook that should have been in the original batch of hooks.
Because React position itself as a UI library only.
Great server side handling too please. ! :)
Is there any documentation/link for this 'cache' feature ?
Thank U jack soo much for ur explanation and productiv contents
Hey Jack, started following you during your micro-frontend videos. Do micro-frontend make sense in regards to server side rendered projects?
IMHO, no. I know that it technically can be done. But in my opinion, if it's important enough to be server rendered then it's critical functionality and I don't recommend using MFEs for critical functionality.
Clicked all the buttons. Thanks. Could be interesting if there is a proper way to invalidate the cache.
Thanks for the great video explainer Jack. I was under the opinion that this hook has very little use and would eventually lead to boilerplate. As expected they had to add a cache function for it.
What's a bit shocking for me is that every API that they add to react has an affinity for infinite loops. Yet they claim this is the perfect library for managing UI. 😅 So many footguns are introduced after hooks
> So many footguns
Because it's not declarative but it was supposed to be. It started out not leaking abstractions. 🤐
would be cool to see how to revalidate the cache
Reselect works really great for memoization. 8:53
Would be super cool to see how this works on the server.
But I couldn't understand why we get an infinite loop just by passing a query param. I get the distinction between a function reference and its contents but all that changed was the query param, right? Am I missing something here?
As it was told in the video, NextJS replaced native fetch with some "wrapped in cache", so i guess this implementation from NextJS is just work with requests with and w/o query params in different manner.
@@ellipsoid8 That's a good assumption. Is that the reason Jack Herrington?
Hey Jack awesome video! Do you know if the use() hook will come to React Native?
AFAIK it will, it's part of core React.
Not related to the video, can you share the settings & extensions you use in VS Code?
Thank you for another premium video.
Omg thank you for the dark mode !!!!!
Next time I'll do it fully. The inspector isn't in dark mode this time.
But when using error handling with error.js like so
if (status !== 200 ) {
throw new Error('Error fetching organization');
}
We get Error not implemented when used in client components
Why did the url with the query param cause an infinite loop but not the url without it?
There’s a cool vscod extension called „multiple cursor case preserve“ which does exactly what the name suggests 🎉
I'll check that out.
let'sss see it on the server! 🎩 Great video!
Hey Jack, I can't seem to find docs on cache, how would one go about doing invalidation?
beta.nextjs.org/docs/data-fetching/caching It's mostly about the server functionality, and there the fetch is cached and has invalidation controls. But that's server only currently.
@@jherr ohhh, I see. I was looking for it on the react docs. Thank you!
To me, any cache has a progression of steps. Writing or setting a key is easy. Then you have to figure out how to refresh or invalidate. This is difficult (the meme). Many times time will be used when time is not really what we want. Then we start thinking in events. Then our app structure doesn't support this evented perspective easily. I need to write this up.
I would be interested to read. I m a cache noob and not so much information on, especially in comparison w other web stuff.
Great explainer Jack! Always love your content. 👏🏻
Thanks Jack for the guide. Will this beat memo function in all cases?
This does not do what the memo function does. You can't use it as a replacement for it, AFAIK.
What VS Code theme? BTW great video as always 👍
Yup do the server version! great video!
16:13 I have been using the 'multiple cursor case prevent' extension for moments like these.
Great video Jack... you're my hero! Just one question, how can I invalidate the cache because of some mutation or something like that to force the network request again?
Yeah, that would be entirely up to you though. You'd need to replace the catch them make the fetch.
Oooohhh got it, well, I will continue using React Query then hehe thank you!
@@rogerscript Oh wow, yeah, I would recommend that. Use/cache is nowhere near a replacement for react-query.
@Jack Why types are complaining that cache not exists in react module? Is singleton pattern can replace cache function?
Very interesting, will try to use this instead.
I'd like to see this working on the server.
this video could have been 5 minutes but this guy keeps making funny jokes that only himself laughs.
Is it possible to invalidate the cache or does this require making a whole new cached function instance?
I'm very interested in this video. Thanks 🥰
🤯Nice, more content like this!!! 🙂
Is "cache" essentially similar to or the same as other features in fetching libraries like Redux Toolkit Query?
Wow great walk through on cache functionality.
I am really wondering how useful would it be on server side.
To be precise, cache returns the same data for same fetch function with same arguments by comparing it's ( value for primitive type and reference for non-primitive type ) right?.
what if we send object ( body data ) as an argument. If such object come the component instead of from context , it would still make the fetch calls right?
Probably shallow compare on the references. Feel free to try it out and let us know.
@@jherr sure sir
5:01 Question
1)Home gets rendered
2)A promise and then reference is created
3)use sees this change and sends a request to backend
4)data arrives after some time
5)Home renders the data AND that causes steps to begin from 1?
Di I understand the problem correctly? 🤔
Yep, pretty much. 5 and 1 are both home re-renders. It's 4 that triggers 1.
@@jherr What I don't understand is why was that caused after you added the parameters? Why not before?
@@vakhtangnodadze4802 Yeah, me too. It's just unstable. It shouldn't have worked the first time. To be fair, the NextJS docs say that use(fetch()) is a feature which is currently not supported. I showed it in the video to make folks aware of that viscerally and to give them some reasonable alternatives with `cache`.
@@jherr Great. Thank you Jack. Keep up the awesome work!
Can you link to where in the documentation cache and use are explained?
Things are evolving really fast for a dev who's getting into react. I'm switching to svelte or vuejs
Hi great video. I have a question. What if I want to refetch the cached data? How can I do that?
Clear the cache. And if you are using the cached fetch there is a `{ cache: "no-cache" }` option that you can send.
@@jherr Thanks a lot.
Nice video! But how donwe invalidate this data? Lets say i want this to be cached for 60 seconds and next visit should make fresh fetch.
The cache function itself isn't going to handle that. I'd add a function that gives you the current cache function and then replace that cache function every sixty seconds.
Is there any benefit to using this over just using `react-query`?
When is use and cache actually coming to react without next? I can't find any docs on this
What about cache busting? Does it not have it?
Restart the browser. 😂
Why not just wrap the promise with useMemo? Is cache redundant?
Does this make the Nextjs's enhanced fetch redundant?
I always see this as a harder to *use* SWR.
PD: Now make your devtools dark mode, sir.
use/cache look great! However, if we had to work with dynamically changed data (or user changes his/her first name) the fetch workaround would still return the old value.
Correct.
@@jherr could you make a video or a short explaining how you would revalidate the path or tag of that fetch request? Like on demand revalidation, after the user changes its name, for instance...
Is there any way we can do a "cache flush" after certain time?
Not unless you write that yourself.
I don't know or even think that this will be better than React Query.
We're in 2023. I can't believe frontend engineers are still struggling to fetch data from an API in a clean way from the browser.
We are going in the SSR again. Indeed i just feel that I've wasted so much time in the react ecosystem. I could've done something worthy engineering stuff than just optimizing my fetch calls which still sucks. This react ecosystem is tiring now.
React query
@@amans6504 I feel the same. I wasted so much time in the react ecosystem.
is it uncool?
SSR only in not q solution. It should be the preferred/default approach, but there are many use cases to also do that client side.n
I'm glad they're making these additions.
I'm not 100% sure if this would work, but for lightweight revalidation, in fetchUser you could maybe do something like
let func = cache((id:number)=>{...})
const revalidate = ()=>func = cache((id:number)=>{...})
return {func, revalidate}
of course you'd probably want to extract the inner function somewhere outside of cache, this could even be a wrapper for any function you want to be able to revalidate.
But long story short, this would just invalidate the entire cache, since in revalidate we just reassign the cached function to a new one.
React query still seems way better for things, but if you don't want to bring it in for whatever reason, but absolutely need some form of revalidation, this would probably work.
I'd go with your plan B, flush the whole cache. Have a cache getter function that would dynamically return the cache. Then another function to flush it and make a new empty cache.
Why I don't have 'use' and 'cache' while using the same react and react types version with vite?
Got me man.
i really hope when this is Outta experimental they also make useSwr automatically handle all of this on both client and server. while this is cool i really don't wanna think of how I'll need to handle my fetch requests based on if i call it on the client or server
That's pretty cool ❤
What is that plugin on the terminal, for the auto complete?
Fig.
I'll have to start calling you JsWizard at this point.
Given your deep knowledge in the JavaScript Ecosystem, I wonder what would be your tools of preference for a social network application and why!?
- Thanks in advance
18:20 I very much want to see the server side of this
What browser are you using?
Arc
@@jherr Thank you
hey Jack, is there has cancelation of fetch process like axios cancelation??, because if the data is big, that take a long time to post/recieve, is there any solution to cancel the process?
No, if you want that kind of control use axios.
Yes intrested in cache with graphql
When is the cache cleaned? Looks like a terrible memory leak. I am using mobx for years and I am pretty surprised how many strange solutions come up all the time that solve parts of the problems that mobx solves "magically"
It isn’t cleaned AFAIK unless you clean it.
What's the actual use of "use"? Can it handle plain promises? What does when get other values? Is it some sort of state?
Hello Jack do you have a structured training course for software developers?
I have React and TypeScript courses on a playlist for free on UA-cam, just check the channel page.
What if data changes from backend, it will refetch it? Or just take the save result
It's a cache, it will return the saved results until you clear the cache.
If I hit the subscribe button again, I will unsubscribe. Love your videos and thanks for sharing your knowledge! Liked as always!
That is true!
Hey I was trying to develope a website using next js and redux toolkit but I have no idea how to structure the project at all can make a video on project structure of enterprise level project structure for next , redux toolkit with material UI
I don't get the point of having a global fetch request thanks to cache, because we don't need cache to have that response at a top level RSC and have that RSC pass down the response as props to other children components. So the fetch call is now global thanks to RSC not thanks to the all new cache functionality. Correct me if I'm wrong.