I really appreciate that you're using Typescript primarily in tutorials Except Ben Awad & you I never saw anyone using Typescript primarily in tutorials
All the explanations are so tight, seeing the dependency diagram helped a lot! You're the only person I've seen on youtube that can explain things so well in a practical way while showing the technical aspect of it. Thank you so much for the content
It's so worth it to take the effort and time to watch and review ALL of Jack's videos. It really shows how much time and thought he puts into giving his knowledge to the community for FREE. Thank you for all you do Jack!
Without exaggeration you are one of the most interesting people I've ever seen on the Internet..., the way you teach makes me cry lol! I wish our world had MANY teachers like you 👌
Hey man. I love your channel so much! Like it is so hard finding a channel that dives more into the complex topics... You're absolutely stellar for more advanced info, especially since I'm now at Intermediate level :D Big
Thank you Jack for all of your high quality, in depth content. I'm so glad that i stumbled across your channel. You are explaining the concepts of React in a more detailed manner, which are often necessary when someone really wants to get a job as a React developer. Most React / programming channels on youtube only show the surface of some concepts. You explain more in depth, and in a way that it is really easy to understand. Your channel is truly underrated, I hope more people will find your channel.
Where is the love reaction button yt?? I need it because like this video isnt enough! Awesome work Jack! I just missed you commenting that in some scenarios it's interesting to separate each atomic intention (use-cases) of the user into separate hooks (and how useful this can be for large systems in terms of testing and reuse) eg useGetPokemons(filter ), useCalcPokemonMinPower(pokemons), useCalcPokemonMaxPower(pokemons), useCountPokemonWithPower(pokemons, threshold) and so on
Coming from Vue, I was watching and thinking "this is just like a computed property" and then you said that was just like it. I honestly was "afraid" of using useMemo when even the docs say to not use it often. But in your example, it does not only make sense, but I agree that having that list of dependencies makes clear that to "compute" this value depends on those other values.
useMemo and useCallback definitely have their place, but writing code like this you start feeling like you need them everywhere. It's a lot of boilerplate. It's can be worth taking a step back before you reach for them. 1. You could have achieved the same effect by instead separating the threshold input and count into a child component. 2. You get no value from memoizing onChange listeners if you are passing them straight to inputs anyway.
Another great tutorial. Your video quality has improved a lot, if possible can you do a video on recording or creating tutorials, and the setup that you are using currently.
Thank you, this was very informative. It was a bit hard for me to follow because of having two components in one file. Just a recommendation to consider separating out the components into their own files. Thanks!
14:45 min max could have also been achieved with useCallback(type: 'min' | 'max') and Math[type](...) , reducing the code duplication a little, I think ;) unless this would memoize only the callback, not what it returns, in which case we'd have to use useMemo anyway, which would not be the optimisation we wanted welp, sometimes over-optimisation hurts the performance, when you don't know what you're doing, which proves the point of this video :D
I think I was afraid to overuse the hooks like this before seeing this. So many articles say to not abuse useMemo because it leads to performance issues, but judging by your examples, it seems like the opposite is true. Basically cache everything, or wrap everything that changes.
There should be a separate comment section for all the praise and appreciation ;) I was scrolling through in hope to find someone disagree with you on this one - simply out of interest in other points of view, not saying I'm not buying your arguments, but when there are 2 programmers there are 11 solutions (
The legendary Bill Joy once told me that the fundamental flaw of the "management" panacea of adding new programmers to a team that is behind schedule is that the rate of new code generation per developer expands linearly while the rate of new idea generation per developer expands exponentially. Since overall team productivity is the ratio of the former to the latter, team productivity asymptotically approaches zero as developers are added.
Great content, thanks. It rather reinforced my feeling that I use hooks correctly than showed me something I didn't know, but still a good watch. Btw, why haven't you simply computed min and max within a single useMemo call, returning an object rather than a integer twice?
They are derived values. So the component can get re-rendered as many times as we want, but the min/max won't get re-computed unless the underlying data changes.
@@jherr i think useMemo should be used when we really wanna pass the value to other component? Since using useMemo uses memory and too many useMemo usage will eventually result a bad performance caused by first read-time to decide whether value will be memoized or not. I've seen a lot of apps using too many useMemo and instead resulting a slower app. or perhaps jack do u have any idea when it's the best time to stop useMemo? rather than memoized everything?
@@dellryuzi I haven't seen useMemo slow down an app. Comparing two arrays of scalars is a quick operation, and nobody is suggesting an app with useEffects is slower, and the dependency logic is the same between useMemo, useEffect and useCallback. If you're calculating an object or an array you should use useMemo because those are references, and if you do pass them somewhere to another component, or use that reference in a dependency array, you'll want it to managed by useMemo. If you are creating a scalar from useMemo then it's really a question of how long the scalar takes to calculate. If it's a simple expression then you probably shouldn't use useMemo, if it's the result of some iteration or a reduce, then you should probably use useMemo, otherwise not.
Hi ! from official docs -> "You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components." QUESTION: As long as there is a statement like that about useMemo, i really wonder how do people (including you:)) encourage developers to use it?
It manages referential identity, primarily. So if you are constructing arrays or objects, and those are passed to other components then, as of today, those will be referentially managed to not trigger downstream effects, memos, callbacks, or updates to memoized components.
@@jherr Well.. Please check what I expose in my comment :) Epecially this part: -> "In the future, React may choose to “forget” some previously memoized values and recalculate them on next render" . >>>IN FUTURE REACT MAY CHOOSE TO FORGET
@@erdemsoydan4117 First off they "may" do it, and they don't now. And then there is "choose", and I read that it that under some circumstances, most likely low memory, they may go into a mode where they will invalidate this simple first order cache. (BTW, it's important to understand that `useMemo` stores only the most recent value, not all possible outputs.) Because dependency arrays work on ===, and === works on value for strings, numbers and booleans, and references for objects, arrays, and functions, you have to have a mechanism to control references for complex object types for derived values, and those mechanisms are useCallback and useMemo. Without them you'd have to resort to pushing the derived data into mutable state, which is incorrectly modeling the relationship between mutable state, and data that we derive from that mutable state.
@@jherr Thanks for your precious time. I have been working on mid scale app and we are using Context API (yeah not redux :)) . That scale and and using context API made me have extreme attention on rerenders. So I have no problem about understanding them. I also use useMemo sometimes but whenever I use I was hesitating because of the remark about useMemo in official docs as I mentioned above. I have been waiting to ask about this to someone "a true expert" like you on this case. Thanks for your answer. (Also In your example, if I was working on it, I would use useCallback instead of where ever you used use Memo. e.g Count over threshold : {getCountOverThreshould()} . Is there any drawback about this? useCallback instead of useMemo?)
@@erdemsoydan4117 It's been a while since I've looked at the code in this video, but if the `countOverThreshold` is a simple value I don't really understand the value of creating an accessor for it. It's certainly less surprising from an API perspective to have it be a value, as opposed to an accessor that returns a value. Can you fill me in a little on your thinking and why you believe this approach is advantageous?
Great tutorial. One question is now I've learned about making forms with useRef to prevent rerenders, I like how clean and simple the code is vs storing state in useState. What do you think?
Math.min expects multiple arguments, like Math.min(10,20,30). If I do this Math.min([10,20,30]) then it just wants to min that one array. If I do this Math.min(...[10,20,30]) that turns into Math.min(10,20,30) and I get the min value.
Hi Jack, I've not seen this line of code used before "const [pokemon, setPokemon] = useState([]);". I mean, I understand and have used the useState part but specifically not the part in that position. Is that a Typescript thing?
Yeah. That’s typescript. You have to define what will go into the array. If you start with an empty array there is no way for it to know what you will be putting into it and making sure you always put the right kind of stuff.
@@jherr Thanks for confirming Jack. I've not used or read Typescript as yet. Trying to focus (reduce my learning curve) on learning JavaScript, React & Next.
@@simonedwards7101 I'm in the same boat. After more than two years of pretty much full-time React and NodeJS coding, I'm still struggling with basic syntax and "shortcuts" (such as the gazillion varieties of expressing an arrow function). I fully intend to use Typescript when I feel more confident of my understanding of the underlying Javascript that it relies on.
These tutorials are great but tutorials that explains logics might be even better, for example: I had a hard time implementing a data fetch on scroll app on how to do that from both frontend and backend. Same with tables that have indexing at the bottom, on how to fetch data on indexing change (again from frontend and backend).
react-use has some excellent hooks to track scrolling, and you can use the data from those as dependencies on useEffects to fetch more data. Same thing with a page index. If the page index is a dependency of the fetch useEffect then the fetch will fire every time the page changes to go and get the data for that page.
Great content, I'm really thankful for all the work you put in your tutorials !! stupid question, i m writing it mid vid, I m still wrapping my head around the useMemo hook etc and i ve been thinking, if it so necessary, why is it not the default for state ? Sorry for my english.
Fantastic video as usual. Thanks Jack! Lil question: Why did you end up wrapping onSetThreshold w/ useCallback? Looks like it is not being passed into a memoed child component, It also does not look like an expensive function. Thanks
I probably didn't have to. When it comes to useCallback expensive doesn't matter. That's just about useMemo and it's one of two reasons to use useMemo; maintaining referential identities and, as you point out, expensive synchronous computes.
But isn’t use memo doing triple equals too? If I have two objects I’m comparing and I change something deep inside the object .. it isn’t going to trigger the useMemo
@@jherr I have a useMemo that I use that depends on react query data..I change the object property deep inside the project on a post call api call success response… but my useMemo doesn’t rerun for the new values.. maybe i have to go deeper in the object for my useMemo dependency array?
Hey, thanks for sharing :-) I am not sure when you have a dependency you can use the use effect with his dependency array also, so when you need to use useEffect and when use Memo? BTW I didn't really understand what use Callback give us here because you show it without any dependency. Can you give an example please :-)
useEffect is "watch these values". useMemo is "compute this value from these values". and useCallback is the same thing but applied to functions. For custom hooks I would always use useMemo and useCallback because I don't know how the data and functions I return from the custom hook will be used. For component code, useCallback is optional, but I still recommend it if you are sending the callback to another component so that it retains referential integrity.
useCallback holds a function that needs to run when given dependency changes in this case, we wanted to fire it only with event.target and we didn't need useCallback's context to watch for updates from that dependent variable if we included "pokemon" variable somewhere in that "onSetSearch", it means we want useCallback to know about "pokemon" too i hope this makes sense ;)
Great video Jack! Question - Is it ok to disable my linter when I want to have an empty useEffect dependency array? It will usually tell me I need to have something inside or remove it entirely.
Heh -- I rely on the linter to tell me when I need useCallback. My perhaps naive understanding is that useCallback is the mechanism to break infinite loops in the rendering/useEffect code. As the linter explains, a function that is needed only by one specific useEffect hook can often be refactored into a local function within the hook -- eliminating the need for useCallback. Your mileage may vary. :)
That would be Github Copilot. Don't believe the FUD, it's not going to take your job. But it is going to accelerate your coding like I've never seen before.
For search is there a reason why you chose to refetch the data and do a filter rather than just filter the array that you already have locally? I guess refetching guarantees the latest data (which wouldnt help in this case) but on an onChange that seems like too many fetches imo. Thanks for the awesome video! Cheers!
The example is more about how to manage control flow. But in reality, yeah, it's a small dataset and in this case fetch is just going to returned the cached data anyway. I'd probably also add in some debounce tho. :)
Oh.... and this is why Solid uses functions instead of primitive values in their createSignal, right? So essentially, since you invoke the function, the runtime "knows" what is dependent to something and renders only the appropriate part... is this a correct assumption Jack?
I remember writing a filter table function with hooks , and suddenly something just clicked.
I really appreciate that you're using Typescript primarily in tutorials
Except Ben Awad & you I never saw anyone using Typescript primarily in tutorials
you may seen often if watching Angular tutorial :D
I love you Jack and what you're doing for the community, you're my inspiration
Same. A terrific teacher ☘️
indeed he rise the bar
100%
All the explanations are so tight, seeing the dependency diagram helped a lot! You're the only person I've seen on youtube that can explain things so well in a practical way while showing the technical aspect of it. Thank you so much for the content
nice as usual we are happy we have you as our senior
wow you are good. Always a couple steps over the average explanation.
It's so worth it to take the effort and time to watch and review ALL of Jack's videos. It really shows how much time and thought he puts into giving his knowledge to the community for FREE. Thank you for all you do Jack!
No matter how much experience one has, every time you would learn something new. Awesome explanation. Thank you so much.
Your videos is on another level comparing to other UA-cam channels. Thanks for the efforts
If you take a look at his code you'll see that he truly is a senior dev
Without exaggeration you are one of the most interesting people I've ever seen on the Internet..., the way you teach makes me cry lol! I wish our world had MANY teachers like you 👌
Hey man. I love your channel so much!
Like it is so hard finding a channel that dives more into the complex topics...
You're absolutely stellar for more advanced info, especially since I'm now at Intermediate level :D
Big
I come from a vue background and it was just so clear when you compared useMemo to computed values. Thank you!
Thanks you Jack , that was very informative, hope to see you diving more into the advanced topics in React.
Happy birthday Jack!
Thanks!
Amazing display,
The touch of proficiency is the diagram at the end of the video, no bs as usual!
Mr Herrington, I know you probably get this all the time, but you rock!! This was really elegant!!
Now, it feels, i was always using the hooks in a very much wrong way. Thanks to Uncle Jack for teaching us the right way:) Loved it, awesome
man the border radius on your webcam is given me old school CSS vibes
amazing content and presentation
Thank you Jack for all of your high quality, in depth content. I'm so glad that i stumbled across your channel. You are explaining the concepts of React in a more detailed manner, which are often necessary when someone really wants to get a job as a React developer. Most React / programming channels on youtube only show the surface of some concepts. You explain more in depth, and in a way that it is really easy to understand. Your channel is truly underrated, I hope more people will find your channel.
Where is the love reaction button yt?? I need it because like this video isnt enough! Awesome work Jack!
I just missed you commenting that in some scenarios it's interesting to separate each atomic intention (use-cases) of the user into separate hooks (and how useful this can be for large systems in terms of testing and reuse) eg useGetPokemons(filter ), useCalcPokemonMinPower(pokemons), useCalcPokemonMaxPower(pokemons), useCountPokemonWithPower(pokemons, threshold) and so on
You’re legendary. I watched almost all your videos. Thank you very much for the amazing content, keep it up 🥇🏆
I just had to subscribe after this Video. Awesome content keep it up!
Thanks!
Man your explanations are so clear. Well done. Wish I had this kind of tuition when I was starting learning JS and React.
Thanks for the great video Jack! Your content is gold!
I have never had anyone explain all of the React intricacies so well.
Love you, I think I am gonna watch all your react videos 😅
Really good stuff!
Just a small correction in the description: It's Kent C. Dodds, not Dobbs. Other than that awesome content, I learned a ton, from both of you! :)
Whoops, my bad.
So glad to have found this channel, great content!
Coming from Vue, I was watching and thinking "this is just like a computed property" and then you said that was just like it. I honestly was "afraid" of using useMemo when even the docs say to not use it often. But in your example, it does not only make sense, but I agree that having that list of dependencies makes clear that to "compute" this value depends on those other values.
Thanks Jack! Awesome content as always
useMemo and useCallback definitely have their place, but writing code like this you start feeling like you need them everywhere. It's a lot of boilerplate. It's can be worth taking a step back before you reach for them.
1. You could have achieved the same effect by instead separating the threshold input and count into a child component.
2. You get no value from memoizing onChange listeners if you are passing them straight to inputs anyway.
This is amazing content! Your examples are top notch
Another great tutorial.
Your video quality has improved a lot, if possible can you do a video on recording or creating tutorials, and the setup that you are using currently.
Thanks. I appreciate that. That's really cool that you think it's good enough to do a video on. I'll definitely think about it.
Thank you, this was very informative. It was a bit hard for me to follow because of having two components in one file. Just a recommendation to consider separating out the components into their own files. Thanks!
Thanks for the feedback!
Thanks for the great extension for diagramms)
Thanks!
14:45
min max could have also been achieved with useCallback(type: 'min' | 'max') and Math[type](...) , reducing the code duplication a little, I think ;)
unless this would memoize only the callback, not what it returns, in which case we'd have to use useMemo anyway, which would not be the optimisation we wanted
welp, sometimes over-optimisation hurts the performance, when you don't know what you're doing, which proves the point of this video :D
Most excellent video.. highly valuable.. thank u so much
Thank you very much Jack for this very informative and clear video.
brilliant demonstration
Ah that comparison with Vue's 'computed' mechanism really cleared up a lot for me - thanks!
I think I was afraid to overuse the hooks like this before seeing this. So many articles say to not abuse useMemo because it leads to performance issues, but judging by your examples, it seems like the opposite is true. Basically cache everything, or wrap everything that changes.
I'm learning so much from you thanks alot!!
You are a champion Jack! , Thank you
Jack is the Lead Senior anyone wish to have. But anyone can have a bit watching his video
There should be a separate comment section for all the praise and appreciation ;)
I was scrolling through in hope to find someone disagree with you on this one - simply out of interest in other points of view, not saying I'm not buying your arguments, but when there are 2 programmers there are 11 solutions (
The legendary Bill Joy once told me that the fundamental flaw of the "management" panacea of adding new programmers to a team that is behind schedule is that the rate of new code generation per developer expands linearly while the rate of new idea generation per developer expands exponentially. Since overall team productivity is the ratio of the former to the latter, team productivity asymptotically approaches zero as developers are added.
Congratulate me) I finally found what I was looking for
Dependency graph, actually is topological sort in data structure context, or something similar.
Fair. In this case I was looking for a term that captured the dependencies between the various pieces of state, derived state and effects.
What a fantastic resource!
You are awesome, thanks a lot!
Thank you very much Jack
really good example 👍
Thanks for the great video
amazing explanation, thank you!
awesome work!
Love to see a demo on dependency injection with react context And react ui architecture patterns
Great content, thanks. It rather reinforced my feeling that I use hooks correctly than showed me something I didn't know, but still a good watch. Btw, why haven't you simply computed min and max within a single useMemo call, returning an object rather than a integer twice?
Probably could have, yeah.
Where are you from? That background in the beginning looks beautiful.
Thanks for this video
Oregon. Although this is Lacamas Park in Camas, WA.
I already know this ones gonna hurt me
I love the pop culture references 😃
sorry jack what's the reason you usememo in min max too? when it's enough on pokemonWithPower to memoized the table?
They are derived values. So the component can get re-rendered as many times as we want, but the min/max won't get re-computed unless the underlying data changes.
@@jherr i think useMemo should be used when we really wanna pass the value to other component? Since using useMemo uses memory and too many useMemo usage will eventually result a bad performance caused by first read-time to decide whether value will be memoized or not.
I've seen a lot of apps using too many useMemo and instead resulting a slower app.
or perhaps jack do u have any idea when it's the best time to stop useMemo? rather than memoized everything?
@@dellryuzi I haven't seen useMemo slow down an app. Comparing two arrays of scalars is a quick operation, and nobody is suggesting an app with useEffects is slower, and the dependency logic is the same between useMemo, useEffect and useCallback. If you're calculating an object or an array you should use useMemo because those are references, and if you do pass them somewhere to another component, or use that reference in a dependency array, you'll want it to managed by useMemo. If you are creating a scalar from useMemo then it's really a question of how long the scalar takes to calculate. If it's a simple expression then you probably shouldn't use useMemo, if it's the result of some iteration or a reduce, then you should probably use useMemo, otherwise not.
Ur home looks amazing
Thanos joke was awesome
Really awesome 👌👏
Thanks for the great content! Btw: what keyboard are u using?
A Varmilo VA87M my daughter got me for my birthday.
i wonder what that vscode autosuggestions extension is. in 3:58
haha, I know it as i watching the video. copilot
Yep, it's copilot. Expect a video on that fairly soon.
Hi ! from official docs -> "You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components." QUESTION: As long as there is a statement like that about useMemo, i really wonder how do people (including you:)) encourage developers to use it?
It manages referential identity, primarily. So if you are constructing arrays or objects, and those are passed to other components then, as of today, those will be referentially managed to not trigger downstream effects, memos, callbacks, or updates to memoized components.
@@jherr Well.. Please check what I expose in my comment :) Epecially this part: -> "In the future, React may choose to “forget” some previously memoized values and recalculate them on next render" . >>>IN FUTURE REACT MAY CHOOSE TO FORGET
@@erdemsoydan4117 First off they "may" do it, and they don't now. And then there is "choose", and I read that it that under some circumstances, most likely low memory, they may go into a mode where they will invalidate this simple first order cache. (BTW, it's important to understand that `useMemo` stores only the most recent value, not all possible outputs.)
Because dependency arrays work on ===, and === works on value for strings, numbers and booleans, and references for objects, arrays, and functions, you have to have a mechanism to control references for complex object types for derived values, and those mechanisms are useCallback and useMemo. Without them you'd have to resort to pushing the derived data into mutable state, which is incorrectly modeling the relationship between mutable state, and data that we derive from that mutable state.
@@jherr Thanks for your precious time. I have been working on mid scale app and we are using Context API (yeah not redux :)) . That scale and and using context API made me have extreme attention on rerenders. So I have no problem about understanding them. I also use useMemo sometimes but whenever I use I was hesitating because of the remark about useMemo in official docs as I mentioned above. I have been waiting to ask about this to someone "a true expert" like you on this case. Thanks for your answer.
(Also In your example, if I was working on it, I would use useCallback instead of where ever you used use Memo. e.g Count over threshold : {getCountOverThreshould()} . Is there any drawback about this? useCallback instead of useMemo?)
@@erdemsoydan4117 It's been a while since I've looked at the code in this video, but if the `countOverThreshold` is a simple value I don't really understand the value of creating an accessor for it. It's certainly less surprising from an API perspective to have it be a value, as opposed to an accessor that returns a value. Can you fill me in a little on your thinking and why you believe this approach is advantageous?
Great tutorial. One question is now I've learned about making forms with useRef to prevent rerenders, I like how clean and simple the code is vs storing state in useState. What do you think?
Uncontrolled inputs are fine. Preferred in a lot of situations. Forms managers like react-hook-form primarily use uncontrolled inputs.
Why do you need to destructure the array in 14:03 ?
Math.min expects multiple arguments, like Math.min(10,20,30). If I do this Math.min([10,20,30]) then it just wants to min that one array. If I do this Math.min(...[10,20,30]) that turns into Math.min(10,20,30) and I get the min value.
Hey Jack thanks for the video. Can you share which font and theme you're using in your vscode.
Waiting for reply.
It's always in the description of the video.
Hi Jack, I've not seen this line of code used before "const [pokemon, setPokemon] = useState([]);". I mean, I understand and have used the useState part but specifically not the part in that position. Is that a Typescript thing?
Yeah. That’s typescript. You have to define what will go into the array. If you start with an empty array there is no way for it to know what you will be putting into it and making sure you always put the right kind of stuff.
@@jherr Thanks for confirming Jack. I've not used or read Typescript as yet. Trying to focus (reduce my learning curve) on learning JavaScript, React & Next.
@@simonedwards7101 I'm in the same boat. After more than two years of pretty much full-time React and NodeJS coding, I'm still struggling with basic syntax and "shortcuts" (such as the gazillion varieties of expressing an arrow function). I fully intend to use Typescript when I feel more confident of my understanding of the underlying Javascript that it relies on.
great content :D
You're really smart and stuff.
Hi Jack, interested to see if you have any thoughts on the new SolidJS library.
I have much much much love for SolidJS. This video me gearing up to show how SolidJS gets reactive state very right.
@@jherr Awesome, looking forward to it!. I've been looking at it's docs last weekend and it feels really well thought out.
@@jujijiju6929 Not only well thought out but blazingly fast. I wrote a search page for my BCC videos in it and it's insanely fast.
These tutorials are great but tutorials that explains logics might be even better, for example:
I had a hard time implementing a data fetch on scroll app on how to do that from both frontend and backend.
Same with tables that have indexing at the bottom, on how to fetch data on indexing change (again from frontend and backend).
react-use has some excellent hooks to track scrolling, and you can use the data from those as dependencies on useEffects to fetch more data. Same thing with a page index. If the page index is a dependency of the fetch useEffect then the fetch will fire every time the page changes to go and get the data for that page.
@@jherr Thanks for the advice, backend was also a challenge (in some way)
Great content, I'm really thankful for all the work you put in your tutorials !! stupid question, i m writing it mid vid, I m still wrapping my head around the useMemo hook etc and i ve been thinking, if it so necessary, why is it not the default for state ? Sorry for my english.
If you give me a time reference I'll give you my reasoning about useMemo.
React hook form might be an interesting idea for a new video 😉
I've done a couple previously on React hook form. I might add it to a speed run though. It's a great library.
Can you make a video about your VS code add ons and code formatting? I really need to step up my game after seeing u code!!
Fantastic video as usual. Thanks Jack!
Lil question: Why did you end up wrapping onSetThreshold w/ useCallback? Looks like it is not being passed into a memoed child component, It also does not look like an expensive function.
Thanks
I probably didn't have to. When it comes to useCallback expensive doesn't matter. That's just about useMemo and it's one of two reasons to use useMemo; maintaining referential identities and, as you point out, expensive synchronous computes.
@@jherr Got it! Thank you so much for the clear explanation.
Can someone explain the calculatePower function at 3:18 what are all of the + signs doing?
They're adding all the numbers in each variable together to get the total.
Can I add pokemon.length as dependecy in useMemo instead of whole pkemon array?
Sure, but... If you changed the pokemon array to a new reference BUT the length remained the same, then that dependency wouldn't fire.
@@jherr indeed, you made a greate point.
But isn’t use memo doing triple equals too? If I have two objects I’m comparing and I change something deep inside the object .. it isn’t going to trigger the useMemo
That’s correct. If the reference doesn’t change then it won’t fire. But… you can depend on the deeply nested value.
@@jherr I have a useMemo that I use that depends on react query data..I change the object property deep inside the project on a post call api call success response… but my useMemo doesn’t rerun for the new values.. maybe i have to go deeper in the object for my useMemo dependency array?
@@Knowwhentobluff you should depend on the values you use in the memo, deeply nested or not.
@@jherr even if useMemo is like “omg this is an unnecessary dependency”
Nice! Thanks!
What intellisense did you use around 3:54 I'm totally mind blown
That's Github Copilot.
Hey, thanks for sharing :-)
I am not sure when you have a dependency you can use the use effect with his dependency array also, so when you need to use useEffect and when use Memo?
BTW I didn't really understand what use Callback give us here because you show it without any dependency.
Can you give an example please :-)
useEffect is "watch these values". useMemo is "compute this value from these values". and useCallback is the same thing but applied to functions. For custom hooks I would always use useMemo and useCallback because I don't know how the data and functions I return from the custom hook will be used. For component code, useCallback is optional, but I still recommend it if you are sending the callback to another component so that it retains referential integrity.
useCallback holds a function that needs to run when given dependency changes
in this case, we wanted to fire it only with event.target and we didn't need useCallback's context to watch for updates from that dependent variable
if we included "pokemon" variable somewhere in that "onSetSearch", it means we want useCallback to know about "pokemon" too
i hope this makes sense ;)
@@jherr I think the conclusion need to be: do you want to make react to be Reactive? You need to use: useEffect, use Memo and use Callback :-)
seems like you are in love with Pokemon hahahah
Great video Jack! Question - Is it ok to disable my linter when I want to have an empty useEffect dependency array? It will usually tell me I need to have something inside or remove it entirely.
You should never ever have an empty dependency array. And no, you should not disable the linter, it is almost always correct.
@@jherr Thanks Jack!
what's your vscode theme color?
Night Wolf [black] and Operator Mono
Thank you.
Great content!
Can someone explain the need for useCallback? I couldn't get it.
Thanks!
Heh -- I rely on the linter to tell me when I need useCallback. My perhaps naive understanding is that useCallback is the mechanism to break infinite loops in the rendering/useEffect code. As the linter explains, a function that is needed only by one specific useEffect hook can often be refactored into a local function within the hook -- eliminating the need for useCallback. Your mileage may vary. :)
Great tutorial sir, I have a question whats the name of the extension for auto suggestions you're using.
That would be Github Copilot. Don't believe the FUD, it's not going to take your job. But it is going to accelerate your coding like I've never seen before.
@@jherr I've signed for it couple weeks ago but i thought ur using something else haha. thanks for the quick response btw🙏
Jack, you're the fucking man, thank you
Nice, thanks
I adore the diagram! Is this an extension or an OOTB feature? Thanks for the explanation about hooks, it was enlightening!
OOTB feature. It's always been there.
What is theme u r using?
For search is there a reason why you chose to refetch the data and do a filter rather than just filter the array that you already have locally? I guess refetching guarantees the latest data (which wouldnt help in this case) but on an onChange that seems like too many fetches imo.
Thanks for the awesome video! Cheers!
The example is more about how to manage control flow. But in reality, yeah, it's a small dataset and in this case fetch is just going to returned the cached data anyway. I'd probably also add in some debounce tho. :)
Thanks for replying! That makes sense and I didn't know debounce was a thing tysm!
Awesome!
Oh.... and this is why Solid uses functions instead of primitive values in their createSignal, right? So essentially, since you invoke the function, the runtime "knows" what is dependent to something and renders only the appropriate part... is this a correct assumption Jack?
Yes. Exactly.