It'll still be another year (or two) before we start using this in a production environment. The cost of getting the team to adopt something like this has to be considered. Think holistically about your projects and remain balanced. Don't jump on every new shiny thing that reveals itself
@@huge_letters using tanstack-query means that your website needs to load JS first, this would hurt SEO for web crawlers other than Google (Google web crawler can tolerate a js load on first visit). tanstack-query is a js library after all. While on the other hand, server components gives server rendered html, so that web crawlers could see it as html first, rather than to have to wait for js to load and initialize.
You can argue that it’s not that much useful or simpler. If you want to handle errors or loading state in multiple components individually you still need to wrap the components with Suspense and ErrorBoundary
I think part of the point is you can handle loading and error states for as many nested components as you want and each can have their own async data fetches. No managing loading states across components and such. Also dealing with loading and error outside the components can make for more readable components. Could be off on the details I've never used this, but we do use Error boundaries at work. Ultimately though, you're right, you still have to tell it what to do on error and load, and this is just a different way to write it.
@@MatanPresberg But if you wrap the error around everything then a lot of time you gotta do different things on error... So you have to create another async function to wrap around your call to give it some id or something to be recognizable... Its getting redux wibes again. The simpler the code the better. This is not cool.. I dont see why the use cannot just give you a onError & onLoading... this is half-made again.
@@kraldada6557 you get to choose what you wrap it around, React will just hit the closest Error boundary in the tree. If you wanted to set variants from components you could always use Context and have props passed in from Context to loading or error boundary. But if you don't like the pattern you don't have to use it. I'm just explaining it's use as best I can / as best as I understand
that can be achieved without even using "use" hook, any component wrapped in a suspense can throw a promise and cached that result in a map. We can make it work like if the data is not present in the map throw promise(fetch data) or if it's present in map(cached) use that
You're right. This is basically a promise to suspense (thrown promise) converter in some sense. But still something that should, in my opinion, have been a part of the Suspense release from the get go. And should probably also have been named to something a bit more descriptive that what it is now.
As I mentioned earlier, I'm an experienced React and Node developer. Therefore, I advise against using or exploring any experimental features in React. The 'use' hook has been marked as experimental for the past couple of months, and we're unsure whether it will ever become a production-ready hook. Therefore, it's best to focus on using only reliable and tested features. It's essential to be wary of content created by RUclipsrs who may produce videos simply to have something to publish. Although Kyle is a good guy, it's important to understand that every RUclipsr needs to produce content regularly.
Or.... you just extract your default fetch routine/Error handling/Loading component stuff inside a function/custom hook, you code it once, and you reuse it everywhere, and your error handling state is still local to your component. The error boundary thing seems like a nice fallback, but not a proper way to handle errors for specific requests. All these indirections kinda goes against the principles of a declarative react component IMO.
And these new fetch functionalities along with errors and loading states already have had their logic updated with the newest React Router. I don't see the point of this hook, maybe I just don't understand this new hook enough yet.
Cool video, but this example is a bit broken. Every render of Data component will trigger a refetch, since `use` takes in a simple expression which doesn't have a stable function identity. This can be fixed by wrapping `fetch` in a `useCallback` hook or by creating a function that returns a Promise outside the component scope.
What is this new gen z name for function reference :D, also I'm not sure about the usage of the word stable - implies that a function reference might be unstable? :)))) Also using useCallback is not the correct approach, defining the api call as a constant or a function will achieve the same effect, but will use less memory. You're welcome for the free PR review :DDD
@@eukante idk, in JS circles people mention stable function identity and stable function reference almost interchangeably, just went with whatever came first from the top of my head. “stable” has always meant that the reference is non-volatile or static or whatever you feel like calling it, basically that it just doesn’t change on its own, not sure why you are nitpicking this. I do agree that using ‘useCallback’ is not the prettiest approach, hence why I’m also suggesting to create a fetching function outside the component scope, just as you like it 👍 Memory concerns are a separate topic that I don’t really wanna talk about, but I don’t see this as a problem unless you’re running your JS code on an outdated engine inside of an embedded system lol. Engines are smart and preemptive micro optimisations are bad for your sanity.
Doesn't use+fetch.then cause infinite network requests? It's like the useEffect without deps footgun. You have to ensure the promise it stable across renders, and can use cache() for that, before handing it use()
Great video again Kyle. Only thing you haven’t mentioned is how does it get affected by component’s re-rendering (maybe I missed that part). I’m guessing it doesn’t re-render its function. If it’s so the question would be how to re-render it? (Refetch in this case)
Agreed. I also wonder about retry logic. I'd guess we have to handle it within the promise before finally deciding to resolve but then it would be difficult to give updates to the user during the process since Suspense retains it in the meantime. Could probably have some sort of handler in the parent but then that would require manually rerendering the component as well.
@@austinstewart1451 yes that’s a good point. So far the only benefit I can think of is running a promise without wrapping it inside an async function. It could be useful in useEffect.
Embrace yourselves for components full of nested and conditional use hooks. Good luck PR reviewers :D .. jokes aside this looks amazing, thanks for the video man.
Maybe I'm missing something here but with the original technique the 'loading' and 'error' handling were all contained in the original component. Now, with Suspense and ErrorBoundary we have pulled this logic out of the original component into the host component. So, every time we use the revised component we have to repeat this logic or, more likely, wrap it inside another component which contains just the ErrorBoundary, Suspense and revised component. Is this really an improvement? Am I just not seeing the light?
i agree, i dont really see anything different with the previous code and new code. in total it is 2x as much code because of the new components rather than just keeping the error and loading in the componenet.
Then we should wrap it with another wrapper component. Lol, yeah I agree with you, it looks like making the component cleaner, but actually it creates another problem or just another technique to solve nothing. But at least it's good for a content creator to make another video about React. Lol.
"This New React Hook Breaks All The Rules", sums up why many devs dread front-end development. JS allows (and often encourages) so much hacky code that it becomes a nightmare to maintain. Solutions to bugs/problems often involves hunting down yet another library or version update. I'm for constant-learning but this is madness.
It works but it gives me the error: "A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework." Any solution?
what example he is showing is wrong data fetching is done on server component and you have to pass the promise to client component to consume it using use hook
I didn't quite follow the Context bit at the end... does this mean you could use the "use" hook in the context to fetch data, then share it across multiple components?
My question is: HOW? The reason why hooks can't be used inside `if` statements is that they're tracked in sequence. A branch condition (or an iteration) breaks the sequence. This is important because hooks aren't named or tied to the component instance in any way, so React needs to keep a stack in order to perform the correct action. But if you can put `use` inside an conditional it means that's not actually tracked. So what's the secret?
I have no idea how it works behind the scenes but being able to run hooks conditionally? Hell yeah. I hated having to create container components that conditionally rendered just to be able to conditionally run a hook. Or doing things like passing `skip: true` to the hook that fetches gql data.
Doesn't it break the notion of component being self contained? You have to know about the component in order to use suspense and it effects rendering outside of the component being used. Thus this component is not longer isolated or testable as your going to handle loading and errors outside the component.
If they could allow a hook in an if statement, why did they restrict it in the first place (for other hooks - useState, useEffect,...) ? There must be some disadvantage that comes with it.
you can only implement Error Boundary using class component, there are libs that abstract the implementation into a functional component but, it basically just a class component
Neat, but it's just parts of react-query's useQuery. And if use() doesn't at least do what useQuery already does, why would I use use()? use use use use use.
Will be honest, i have been developing on the web for the past 6years, mainly in php woth jquery, react, and vue for the front, now i am using inertiajs and to be honest i dont understand all the hype with asynchronous requests, loading microcomponents in your main component, i have never found the use for it, plus most apps online kinda have one main big load then micro lazy loads on demand Besides showing us exemples of code can you also exemplify some real life examples of applications?
Another JavaScript library: What rules? Like seriously, one of most annoying things that every library has it's own way of working, on top of that it's changing every few years. It's like almost everyone does the same thing but it's own way. There is no standards, only different tools.
I love how they ran out of names for hooks so they just went with "use"
Makes you wonder how they decided on the naming.
@@aalaaplol
useAsdfadfsadf
useUse is still free
@@aalaap abUse?
Not only do hooks kind of break the rules of JavaScript, now there's a hook that breaks the rules of hooks. That's great!
Hi sir how do they break the rules of JavaScript? I am not disagreeing I want to learn. Thanks
@@xgtwb6473 they don't actually break the language, they provide a useful abstraction. his comment was in jest
@@cafebean
yes: in jest -
to test
who’s asleep
(or not…)
I didnt realize how much I was feeling the rules of React, seeing a hook inside a conditional statement makes me feel dirty
React keeps talking about how they’re going to solve this problem. All I say is, “promises, promises…”
It'll still be another year (or two) before we start using this in a production environment. The cost of getting the team to adopt something like this has to be considered. Think holistically about your projects and remain balanced. Don't jump on every new shiny thing that reveals itself
This also may be rejected and we wouldn't see it at all
Doesn't tanstack-query already exist for this kinds of problems?
@@huge_letters using tanstack-query means that your website needs to load JS first, this would hurt SEO for web crawlers other than Google (Google web crawler can tolerate a js load on first visit). tanstack-query is a js library after all.
While on the other hand, server components gives server rendered html, so that web crawlers could see it as html first, rather than to have to wait for js to load and initialize.
@@z-aru and this hook provides some SSR functionality which is not available with tanstack?
@@huge_letters Nvm, I was wrong about this new hook, this hook does run on client side and is the first one that could be used conditionally.
You can argue that it’s not that much useful or simpler. If you want to handle errors or loading state in multiple components individually you still need to wrap the components with Suspense and ErrorBoundary
exactly what i was thinking.. only the tools change
I think part of the point is you can handle loading and error states for as many nested components as you want and each can have their own async data fetches. No managing loading states across components and such. Also dealing with loading and error outside the components can make for more readable components.
Could be off on the details I've never used this, but we do use Error boundaries at work.
Ultimately though, you're right, you still have to tell it what to do on error and load, and this is just a different way to write it.
Will there ever be a official functional way of using ErrorBoundary instead of using a class?
@@MatanPresberg But if you wrap the error around everything then a lot of time you gotta do different things on error... So you have to create another async function to wrap around your call to give it some id or something to be recognizable... Its getting redux wibes again. The simpler the code the better. This is not cool.. I dont see why the use cannot just give you a onError & onLoading... this is half-made again.
@@kraldada6557 you get to choose what you wrap it around, React will just hit the closest Error boundary in the tree. If you wanted to set variants from components you could always use Context and have props passed in from Context to loading or error boundary.
But if you don't like the pattern you don't have to use it. I'm just explaining it's use as best I can / as best as I understand
that can be achieved without even using "use" hook, any component wrapped in a suspense can throw a promise and cached that result in a map. We can make it work like if the data is not present in the map throw promise(fetch data) or if it's present in map(cached) use that
Yeah lets make it rocket science
You're right. This is basically a promise to suspense (thrown promise) converter in some sense.
But still something that should, in my opinion, have been a part of the Suspense release from the get go. And should probably also have been named to something a bit more descriptive that what it is now.
Bro, no way thats easier 😂😂😂. React-query solves all of this in one line
Nice, you just sold me your course! Oh, it is free, lol :) Great work and I truly appreciate your content and the fact your course is free.
Can you do preact signals for react
use looks kinda like the syntax of SWR or React-query to me
As I mentioned earlier, I'm an experienced React and Node developer. Therefore, I advise against using or exploring any experimental features in React. The 'use' hook has been marked as experimental for the past couple of months, and we're unsure whether it will ever become a production-ready hook. Therefore, it's best to focus on using only reliable and tested features. It's essential to be wary of content created by RUclipsrs who may produce videos simply to have something to publish. Although Kyle is a good guy, it's important to understand that every RUclipsr needs to produce content regularly.
Thank you, please don't stop commenting to all videos giving newbies like me help we need.
"As I MeNtIoNeD eArLiEr"
... and then I stopped reading because you already sound full of yourself lol
we can use also swr or react query for this.
Or.... you just extract your default fetch routine/Error handling/Loading component stuff inside a function/custom hook, you code it once, and you reuse it everywhere, and your error handling state is still local to your component. The error boundary thing seems like a nice fallback, but not a proper way to handle errors for specific requests. All these indirections kinda goes against the principles of a declarative react component IMO.
And these new fetch functionalities along with errors and loading states already have had their logic updated with the newest React Router. I don't see the point of this hook, maybe I just don't understand this new hook enough yet.
Yep. Mine's called useDataFromAPI, what's yours?
Cool video, but this example is a bit broken. Every render of Data component will trigger a refetch, since `use` takes in a simple expression which doesn't have a stable function identity. This can be fixed by wrapping `fetch` in a `useCallback` hook or by creating a function that returns a Promise outside the component scope.
What is this new gen z name for function reference :D, also I'm not sure about the usage of the word stable - implies that a function reference might be unstable? :))))
Also using useCallback is not the correct approach, defining the api call as a constant or a function will achieve the same effect, but will use less memory.
You're welcome for the free PR review :DDD
@@eukante idk, in JS circles people mention stable function identity and stable function reference almost interchangeably, just went with whatever came first from the top of my head. “stable” has always meant that the reference is non-volatile or static or whatever you feel like calling it, basically that it just doesn’t change on its own, not sure why you are nitpicking this.
I do agree that using ‘useCallback’ is not the prettiest approach, hence why I’m also suggesting to create a fetching function outside the component scope, just as you like it 👍 Memory concerns are a separate topic that I don’t really wanna talk about, but I don’t see this as a problem unless you’re running your JS code on an outdated engine inside of an embedded system lol. Engines are smart and preemptive micro optimisations are bad for your sanity.
Doesn't use+fetch.then cause infinite network requests? It's like the useEffect without deps footgun. You have to ensure the promise it stable across renders, and can use cache() for that, before handing it use()
yeah. I was trying that and it caused an infinite number of requests
Great video. Thanks for taking the time to make this. Very helpful.
would love a comparison video on how this compares to tanstack query!
Great video again Kyle. Only thing you haven’t mentioned is how does it get affected by component’s re-rendering (maybe I missed that part). I’m guessing it doesn’t re-render its function. If it’s so the question would be how to re-render it? (Refetch in this case)
Agreed. I also wonder about retry logic. I'd guess we have to handle it within the promise before finally deciding to resolve but then it would be difficult to give updates to the user during the process since Suspense retains it in the meantime. Could probably have some sort of handler in the parent but then that would require manually rerendering the component as well.
@@austinstewart1451 yes that’s a good point. So far the only benefit I can think of is running a promise without wrapping it inside an async function. It could be useful in useEffect.
I love ur videos, thanks a lot for ur simplification and keeping it short.
Thanks Kyle!
I feel like in this use case the boilerplate changed and all it does to useit correctly is to move it around.
Might aswell use react query.
Embrace yourselves for components full of nested and conditional use hooks. Good luck PR reviewers :D .. jokes aside this looks amazing, thanks for the video man.
It seems like an easy hook to use. Pun definitely intended 😜
Maybe I'm missing something here but with the original technique the 'loading' and 'error' handling were all contained in the original component. Now, with Suspense and ErrorBoundary we have pulled this logic out of the original component into the host component. So, every time we use the revised component we have to repeat this logic or, more likely, wrap it inside another component which contains just the ErrorBoundary, Suspense and revised component. Is this really an improvement? Am I just not seeing the light?
i agree, i dont really see anything different with the previous code and new code. in total it is 2x as much code because of the new components rather than just keeping the error and loading in the componenet.
I was just about to respond with the same question. It seems more like code was just re-organized and not so much improved per-se.
Then we should wrap it with another wrapper component. Lol, yeah I agree with you, it looks like making the component cleaner, but actually it creates another problem or just another technique to solve nothing. But at least it's good for a content creator to make another video about React. Lol.
And this is probably why it’s experimental
Super są te kursy!
polska gurom
polska gurom
Dziękuję. (Hopefully that is right. I used Google Translate.)
quick and good for small projects, but still have to use react query or swr because of cache i guess
fetch promise reference isn’t stable so it will be infinite rerenders
React query is better choice, but this is a cool tool as well 👍
very useful hooks it simplify the service call, and tkx man
Thanks man, it's awesome!
I'll stick with react-query, but will keep an eye on this little hooky
Very good. Will wait for it to be officially released. Thanks.
Amazing 🤩 it’s so easy to use and understand
I wish I was as good as you, great content you got a new sub
"This New React Hook Breaks All The Rules", sums up why many devs dread front-end development. JS allows (and often encourages) so much hacky code that it becomes a nightmare to maintain. Solutions to bugs/problems often involves hunting down yet another library or version update. I'm for constant-learning but this is madness.
They wanna make JS devs look super smart.
I have created the exact use case for custom hook for fetching, they could have created a concept of utils rather than hooks.
Could you make video that will auto translation in different langauages
So useful! Thanks!
Thank you for suspense and errorBoundary.
This took them years but this is the first thing that has impressed me in years from react.
Bro please make videos on How to structure React App and how to write clean code.
What about pass cors when fetch external data
Promise/await not help if the external server don’t have cors enabled
This is for internal works
Can't wait for this new hook to be released :)
Thanks for video. Can you please make video about how to make react reusable form validator with minimal code
React in itself is a boilerplate for corporate abstraction
... So, they're basically moving the boilerplate code up to the parents and making everything more "magical" (aka confusing)
Amazing video Kyle
use Hook seems like a compression of all the previous Hooks. impressive
It works but it gives me the error:
"A component was suspended by an uncached promise. Creating promises inside a Client Component or hook is not yet supported, except via a Suspense-compatible library or framework."
Any solution?
what example he is showing is wrong data fetching is done on server component and you have to pass the promise to client component to consume it using use hook
I didn't quite follow the Context bit at the end... does this mean you could use the "use" hook in the context to fetch data, then share it across multiple components?
This was mind blowing!!
Weird how we still end up class based component just for ErrorBoundary
Did you do already a video on useSignal? Is it also in experimental?
u are the best with explaining new features ❤❤
My question is: HOW?
The reason why hooks can't be used inside `if` statements is that they're tracked in sequence. A branch condition (or an iteration) breaks the sequence.
This is important because hooks aren't named or tied to the component instance in any way, so React needs to keep a stack in order to perform the correct action.
But if you can put `use` inside an conditional it means that's not actually tracked. So what's the secret?
Much better, even in experimental it's already a 1000x better
Nice video. I wonder what's going to be if we use this hook with React Query
I have no idea how it works behind the scenes but being able to run hooks conditionally? Hell yeah. I hated having to create container components that conditionally rendered just to be able to conditionally run a hook. Or doing things like passing `skip: true` to the hook that fetches gql data.
May i ask how the getderivedstatefromerror trigger if we are using react redux query?
Support you sir 🎉
Seems like something any one of us could implement for ourselves in about 10 minutes.
I don't really see the value of "use" when it just replaces async/await??
Thanks
How is placing the error handling markup outside of the component it refers to better?
Doesn't it break the notion of component being self contained? You have to know about the component in order to use suspense and it effects rendering outside of the component being used. Thus this component is not longer isolated or testable as your going to handle loading and errors outside the component.
true I see this making the code as a whole just more complex, I personally dont mind having those extra lines of code in a separate component
because of that its especially usefull on ssr which is why next.js 13 want this feature so hard
Great kyle, thanks, Q: what about useEffect dependencies?🤔
loved !!!!
If they could allow a hook in an if statement, why did they restrict it in the first place (for other hooks - useState, useEffect,...) ? There must be some disadvantage that comes with it.
Yeah, I suspect it causes all sorts of component lifecycle issues.
Very nice!
So How Can I retry a new promise after my use hook promise rejected?
Awesomeness 🎉🎉🎉
They should name it useUse
This is classic React: introducing a brand new thing which is unlike anything you know but so much better!
solving problems made by react lol
so the use hook is basically react-query with less features.
This is so cool. Very useful. Can't wait for this to be GA.
Why was the Error Boundery a class component?
I thought you weren't supposed to use class components anymore?
Class components are not deprected and this is only way to create a error boundary so far.
you can only implement Error Boundary using class component, there are libs that abstract the implementation into a functional component but, it basically just a class component
@@FrameMuse huh, I thought always thought they were deprecated that’s good to know
@@justarandomname good to know 👍
Ur awesome man
the useEffect had the url in the dependency array so it won't keep fetching the data on every render, does use do the same?
I hope they adopt solidJS approach. It’s way simpler
Neat, but it's just parts of react-query's useQuery. And if use() doesn't at least do what useQuery already does, why would I use use()? use use use use use.
спасибо !
I'm lovin' it
Hi @Kyle and Everyone, Do we know when use() hook will be release in stable version of react?
Hey I imported experimental version of react but the "use" hook wasn't there. Anyone know what I might have done wrong?
This is not exactly the same though. The Error Boundary catches **any** error, not just a network error.
In my opinion, they should change the naming. "use" is a bad name since it doesn't tell what it does.
because it can do whatever you want it to, it just executes the stuff you pass into it
Is this hook able to be used within a JavaScript class?
I'm not very familiar with React. About how long is it before things go from experimental to "production ready"?
Is there a benefit to using this over react query?
is it possible to access error in Data component though? if not it's really bad
Will be honest, i have been developing on the web for the past 6years, mainly in php woth jquery, react, and vue for the front, now i am using inertiajs and to be honest i dont understand all the hype with asynchronous requests, loading microcomponents in your main component, i have never found the use for it, plus most apps online kinda have one main big load then micro lazy loads on demand
Besides showing us exemples of code can you also exemplify some real life examples of applications?
If I use this, this is not the only thing confusing about JS anymore.
I have a question about fetching data, I'm using react query in all my fetch requests, is that ok?
Sounds like a big WIN for react then!
this is pure gold, i´ll start use it in my daily job inmediatly, thanks a lot Kyle
Please don't.
But I guess this was satire and I got screenshotted into r/woooosh
Another JavaScript library: What rules?
Like seriously, one of most annoying things that every library has it's own way of working, on top of that it's changing every few years. It's like almost everyone does the same thing but it's own way. There is no standards, only different tools.
it's really a mess
It looks nice, but it feels like React is just reinventing JavaScript that you have to write with React syntax :P
Srsly? You’ll call fecth data on every render. This is huge mistake
I like everything but the error handling part. So much easier to just catch the error then wrap ur components in some weird class