Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…
> I look forward to him releasing his online React course
Any suggestions for a "second best" course that is available now?
Josh's content is always very very high quality. I look forward to him releasing his online React course [0] so that I can recommend it to others who are starting out. My personal biggest not-total-comprehension is around Hooks / effects. I've followed tutorials, used them in production, etc. I'm comfortable using them but I also consider them a bit of a black box, which I don't like (e.g. I'm not sure how they're im…
> I look forward to him releasing his online React course Any suggestions for a "second best" course that is available now?
> But it is tremendously wasteful to make a complete copy of a large data structure! You don't make a complete copy: you make a shallow copy of the spine, and then only descend along the fields you actually modify. The number of operations scales as O(branching factor * depth), not O(size).
> You don't make a complete copy: you make a shallow copy of the spine, and then only descend along the fields you actually modify. Sounds painful.
JS has built-in syntax to do just that. It's in fact much less painful than making a deep copy.
Why do you have to use current everywhere? You can do const { current: myStableValue } = useRef(computation); Not sure what you mean by one time constructor function, but you can pass the result of a function to initial value. const { current: myStableValue } = useRef((() => { //called once })());
This is incorrect. useRef takes an initialValue argument, but it does not treat functions as lazy initializers like useState does. If you pass a function to useRef, you’re just going to get that function as the initial value. If you want to lazily initialize a ref, you need to manually check if it has been initialized and run your expensive code if it hasn’t. Dan Abramov provides what appears to be a pattern official…
I always do `const [stableValue] = useState(() => ...)`. It’s clear, simple, and easy to promote to an interactive value.
I misunderstood what you were saying about it running on unmount when the dependency array is empty. Of course, it does run on unmount when the dependency array is empty, and it runs on unmount when there are dependencies in the dependency array. But upon re-reading what you said, I think your intent was that it's comparable to componentWillUnmount() in class-based React only when the dependency array is empty (becau…
Oh gotcha, no worries. I'm not sure if you meant to reply to me anyway, my comment was in regards to knodi123's original comment that linked to an article of mine and said it was wrong about when useEffect re-renders – but the comment was edited and that part is gone, so now mine looks entirely crazy haha.
I edited it because I realized I was wrong - I was confused by the difference between no 2nd argument, and [] for the 2nd argument. But again - as a full time professional web developer, who has being using React for a few years, I think that also goes towards my point. ;-)
Oh gotcha, no worries. I'm not sure if you meant to reply to me anyway, my comment was in regards to knodi123's original comment that linked to an article of mine and said it was wrong about when useEffect re-renders – but the comment was edited and that part is gone, so now mine looks entirely crazy haha.
I edited it because I realized I was wrong - I was confused by the difference between no 2nd argument, and [] for the 2nd argument. But again - as a full time professional web developer, who has being using React for a few years, I think that also goes towards my point. ;-)
Hahah, yeah, this whole set of threads just hammers home your point, really :D
My brain reads the title as "why not calling `render()` manually?". Probably unpopular opinion: manually call `render` is always better. Creating your own `ui = f(state)` is very trivial with DOM event, custom element, and a whatever 5kb pure view lib. With event delegation technique and a global store, I can build almost whatever ui with this pattern.
It's both. You should be able to control it, but can have a same default that does it for you automatically under certain conditions. Unfortunately React forces the latter only
Yes, practically force re-render comes with unnecessary mechanism to prevent it from happening, and there are unimaginable cases of state mutation that shouldn't force re-render. Example situation: changing state A, B and C, re-rendering, changing B again, not rendering. Auto-render + prevention mechanism is inferior means compared to just having `render` and just calling it whenever and wherever.