About your example of useState - yes, this is exactly how it works with primitive values, now let’s try it with an object, it will mutate immediately, because we get objects by reference and primitives by value in JS. React, as you mentioned, copies the objects in order to make state immutable, which is a little different.
I think what they meant was not javascript closures, the phrase “stale closure” is just a handy way of describing that we have the old references to our objects during a certain React render. In regular closures there is nothing to get stale - it doesn’t even make sense. But react renders by evaluating the render function every time, ergo recreating objects every time (if not using memoization). The object name is the same, but the reference is of course different (except when we useRef). This staleness is important, for example when setting new state derived from its current value in an event handler. Since event handlers run immediately, they are not synced with the render loop and there can be moments where the state value has already changed but the event handler has not and still has that old one. There are other places like useEffect where this staleness is important to understand. This is the basis of react in my mind. I don’t think any of this is wrong or misleading, besides the weird naming by react team.
I don't think both 'stale closure' or 'primitive or reference' gets to the point. Setting a primitive state variable to other value won't trigger the rerender, so idk it's very relevant to the topic. setState is kinda like queueRenderNextSnapshotWithThisUpdatedComponentDependencyValue, so explaining about mental model of React's reactivity system seems like a much better approach for me.
Absolutely love your videos! When I saw this pop up in my feed I thought the title was clickbait, then I saw it was from UI Engineering and I knew this was going to be good!
Thank God , I haven't read those without understanding. My explanation was correct. But one question about the internal copying of value. let state = some object. a=state. Now if we update a, state will also get updated. How react solve this?
nice video. it just reminds me of why i hate react so much. unfortunately, its how i make money. on the bright side, my need to use it professionally seems to be dwindling.
SOMEONE GIVE THIS MAN A RAISE
+1 💸 haha, would be great, thanks! 😆
About your example of useState - yes, this is exactly how it works with primitive values, now let’s try it with an object, it will mutate immediately, because we get objects by reference and primitives by value in JS. React, as you mentioned, copies the objects in order to make state immutable, which is a little different.
I deallocated my lunch just to watch this video. Outstanding!
🫶 Hope your stomach isn't unsubscribing from you now 😂
I like how creators of react don’t even know how their creation works. That makes sense
I think what they meant was not javascript closures, the phrase “stale closure” is just a handy way of describing that we have the old references to our objects during a certain React render. In regular closures there is nothing to get stale - it doesn’t even make sense. But react renders by evaluating the render function every time, ergo recreating objects every time (if not using memoization). The object name is the same, but the reference is of course different (except when we useRef). This staleness is important, for example when setting new state derived from its current value in an event handler. Since event handlers run immediately, they are not synced with the render loop and there can be moments where the state value has already changed but the event handler has not and still has that old one. There are other places like useEffect where this staleness is important to understand. This is the basis of react in my mind. I don’t think any of this is wrong or misleading, besides the weird naming by react team.
Great video! I learned a lot and I don't even develop in React.
AT LAST SOMEONE SAID IT!!!
Fantastic dude! Great work in explaning this!!
I don't think both 'stale closure' or 'primitive or reference' gets to the point.
Setting a primitive state variable to other value won't trigger the rerender, so idk it's very relevant to the topic.
setState is kinda like queueRenderNextSnapshotWithThisUpdatedComponentDependencyValue,
so explaining about mental model of React's reactivity system seems like a much better approach for me.
Absolutely love your videos! When I saw this pop up in my feed I thought the title was clickbait, then I saw it was from UI Engineering and I knew this was going to be good!
Damn, man. I'm honored, thanks much, really appreciate it 🙇
That was a really good video, well done.
YOU SIR, are AWESOME. I have been using React for YEARS!!!!!!!!!! I LEARNED SOMETHING NEW!!!!!!!!! You get the SUB BRO!!!!!!!
The fact that this channel is not bigger is a warcrime
Great Video,.
I never got the stale closure argument anyway. I agree 100%, the framing of the issue just makes it more complex for the newcomers
Exactly! Thanks 🙌
Thank God , I haven't read those without understanding. My explanation was correct. But one question about the internal copying of value. let state = some object. a=state. Now if we update a, state will also get updated. How react solve this?
nice video. it just reminds me of why i hate react so much. unfortunately, its how i make money. on the bright side, my need to use it professionally seems to be dwindling.
damn i think i was a vid with more views. good video though
React is just garbage 🤷
Totally