Awesome Kevin....I would say this is the most underrated channels. Keep it up... love your updates on react and it's friends. Also love your sessions with different members of this community
Heya, found your talks during some downtime, and have been enjoying. I wanted to ask about the ref solution at 33:24 and I guess useEffect in general. From my experience, useEffect is really for syncing react with something external outside of react. Given a callback like onChange I'd just call it from the event handler that's updating calculatedValue versus waiting for useEffect to run when calculatedValue changed. This video is pretty old now too, so you may have changed the way you use useEffect. The useRef solution to ensure onChange is up-to-date without needing to include it as a dependency or memoize the incoming prop in the parent is interesting to me. Is this solution only intended for when you want useEffect to run under very specific circumstances? I could see someone finding this and doing something weird like wanting to do a fetch 'on mount' but only on mount so they ref all the potential props needed for that useEffect performing the fetch. I'm not saying you're wrong, but I'm trying to understand the value of what feels like bypassing the dependency list
I've changed how I do the useEffect useCallback thing mainly because React has changed. They fixed a bug where state setters would error when used after the component unmounts. In terms of useRef, it's powerful and needs to be done with care, but there are some situations where it's required.
This may be the best advertisement for frameworks with automatic dependency tracking like VueJS and SolidJS. How do you still love React when it forces you to jump through so many unintuitive hoops?
You are correct. I'm showing how insanely complex React Hooks are when used correctly. I use React professionally; that's why I still have to keep up with it right now. Before I started on React, I wanted to use AngularJS but had to use Knockout at work. For that situation, I later realized Knockout was superior in a lot of ways. I understand React at a deep level, and ESLint rules help a lot. React also works with Children-First design patterns. Solid has some issues in that department sadly. Haven't figured out a good fix. I wasn't enthusiastic about Vue from skimming the website in the past, but it might be worth looking into. I've honestly had zero exposure to it. Might be a good code conversation topic.
@@KevinGhadyani I have worked with Vue professionally for the past year and am now starting a job where I'll be working with React. Now that Vue's new composition API has stabilized, might be worth another look indeed! Vue's reactivity system is very comfortable and uncomplicated. I have thus far never been surprised or bitten by it. The TypeScript support is also quite good. One thing I suspect you won't like is that it's not really possible to pass components as props, Vue has a separate concept for that called slots. They are OK, but slots do not have good TypeScript support and they are not as flexible as passing children with React I think. I was about to ask you how you can know why certain rerenders happen, but I just found out that the React devtools tell you this! The only thing that was not clear from the video is 38:20, it is not clear to my why you would need to update a ref inside a useEffect, but it sounds like you don't know exactly either? In any case, brilliant video, I think I'm going to refer back to it a lot when I start working with React. Thank you! PS: Wow just tried it out, using function components without wrapping them in React.memo indeed renders them every time the parent is re-rendered, even if they don't take any props at all!
For the useEffect wrapper, I hate to say "do it on good faith that it will fix issues", but it's an execution timing issue. Hard to explain, but it's even more problematic with concurrent mode. Tweet Lenz Weber. He'll be able to point out more reasoning. Both Mark Erikson and Lenz Weber are the two who brought this to my attention.
2:48 It is wrong to compare the rendering to the DOM with rendering to the virtual dom, yes rendering to virtual dom is faster but it is also useless without eventually rendering to the DOM
@@KevinGhadyani I haven't even watched, just saw the poster saying my hooks are wrong without even seeing them, so I stopped by only to do the same. Cheers
Awesome Kevin....I would say this is the most underrated channels. Keep it up... love your updates on react and it's friends. Also love your sessions with different members of this community
my react-before-bed video, thanks mate, this is really mindful
I would have never thought of solving it with ref at 37:36. Got my mind blown right there. Awesome content!
That particular solution was given to me by Dan Abramov on Twitter before a different talk I did in 2019.
Heya, found your talks during some downtime, and have been enjoying. I wanted to ask about the ref solution at 33:24 and I guess useEffect in general. From my experience, useEffect is really for syncing react with something external outside of react. Given a callback like onChange I'd just call it from the event handler that's updating calculatedValue versus waiting for useEffect to run when calculatedValue changed. This video is pretty old now too, so you may have changed the way you use useEffect.
The useRef solution to ensure onChange is up-to-date without needing to include it as a dependency or memoize the incoming prop in the parent is interesting to me. Is this solution only intended for when you want useEffect to run under very specific circumstances? I could see someone finding this and doing something weird like wanting to do a fetch 'on mount' but only on mount so they ref all the potential props needed for that useEffect performing the fetch. I'm not saying you're wrong, but I'm trying to understand the value of what feels like bypassing the dependency list
I've changed how I do the useEffect useCallback thing mainly because React has changed. They fixed a bug where state setters would error when used after the component unmounts.
In terms of useRef, it's powerful and needs to be done with care, but there are some situations where it's required.
This may be the best advertisement for frameworks with automatic dependency tracking like VueJS and SolidJS. How do you still love React when it forces you to jump through so many unintuitive hoops?
You are correct. I'm showing how insanely complex React Hooks are when used correctly.
I use React professionally; that's why I still have to keep up with it right now.
Before I started on React, I wanted to use AngularJS but had to use Knockout at work. For that situation, I later realized Knockout was superior in a lot of ways.
I understand React at a deep level, and ESLint rules help a lot. React also works with Children-First design patterns. Solid has some issues in that department sadly. Haven't figured out a good fix.
I wasn't enthusiastic about Vue from skimming the website in the past, but it might be worth looking into. I've honestly had zero exposure to it. Might be a good code conversation topic.
@@KevinGhadyani I have worked with Vue professionally for the past year and am now starting a job where I'll be working with React. Now that Vue's new composition API has stabilized, might be worth another look indeed! Vue's reactivity system is very comfortable and uncomplicated. I have thus far never been surprised or bitten by it. The TypeScript support is also quite good. One thing I suspect you won't like is that it's not really possible to pass components as props, Vue has a separate concept for that called slots. They are OK, but slots do not have good TypeScript support and they are not as flexible as passing children with React I think.
I was about to ask you how you can know why certain rerenders happen, but I just found out that the React devtools tell you this! The only thing that was not clear from the video is 38:20, it is not clear to my why you would need to update a ref inside a useEffect, but it sounds like you don't know exactly either? In any case, brilliant video, I think I'm going to refer back to it a lot when I start working with React. Thank you!
PS: Wow just tried it out, using function components without wrapping them in React.memo indeed renders them every time the parent is re-rendered, even if they don't take any props at all!
For the useEffect wrapper, I hate to say "do it on good faith that it will fix issues", but it's an execution timing issue. Hard to explain, but it's even more problematic with concurrent mode.
Tweet Lenz Weber. He'll be able to point out more reasoning. Both Mark Erikson and Lenz Weber are the two who brought this to my attention.
2:48 It is wrong to compare the rendering to the DOM with rendering to the virtual dom, yes rendering to virtual dom is faster but it is also useless without eventually rendering to the DOM
I'm not understanding how this is related to the topic at 2:48. What am I missing?
great video!!
great video!
Woow thank you so much kevin😍😍
YOUR hooks are wrong.
Are you being facetious, or is there something I could improve?
@@KevinGhadyani I haven't even watched, just saw the poster saying my hooks are wrong without even seeing them, so I stopped by only to do the same. Cheers