7 ms·

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 starti

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 implemented). The other (even bigger) question for me is "why" -- what prompted the React team to change everything over to "effects". Anyone? [0] https://www.joyofreact.com/ https://www.joyofreact.com/

fabian2k 4y ago
You can reuse hooks between multiple components. You can't really do that with the lifecycle methods of class-based components.
- DanielHB 4y ago
  you can with mixins doesn't mean you should...
vanjajaja1 4y ago
Dan had a good summary of why hooks happened which I can't find now, the tldr was that there was a bunch of bugs introduced around referenced props/state being stale and unpredictable in components. Hooks was the natural evolution that removed all possibility of accidentally referencing stale data.
- joshribakoff 4y ago
  > Hooks was the natural evolution that removed all possibility of accidentally referencing stale data. It unfortunately does not, you can hve various foot guns with refs or omitting dependencies from the array argument; but to your point it makes it a lot easier to ensure you do it correctly by collocating logic related to each cross cutting concern instead of entangling the code in the lifecycle methods. More precisely it makes it easier to follow correct patterns, but as always that is subjective and hooks can be contentious :)
knodi123 4y ago
Hooks feel like a good system that stopped right before it became pretty. Like, an componentDidMount event is a now useEffect with no second argument? But a componentWillUnmount event is now a useEffect, with no second argument, that returns a callback? It's powerful, and it's not that hard to use, but it's cryptic and random. Why call it useEffect instead of some other more meaningful phrase? I mean, "componentDidMount" tells you exactly what it is. Does "useEffect"? Why should onload things be a function, but onunload should be a function returned by a function? Why does useRef give you a thing used for attaching handles to DOM elements so you can refer to them elsewhere, AND it gives you an object whose .current property can be used as a variable that persists without causing a render? It's like someone complained that there were two many functions in the API, and their names were too long, so they overcorrected in the opposite direction.
- ajkjk 4y ago
  I love hooks, but I think they made a few mistakes. The weirdness around useEffect having different behavior with no second argument vs [] is one of them. And they should have included a useUnloadEffect() by default, even though it's trivial to write, just for clarity. It's way too easy to miscount the number of ()s in useEffect(() => () => {}, []); They also should have included a few other basic hooks, like useStableValue() for just computing a constant once on first render. I hate the name `componentDidMount` though. useEffect seems much better to me.
  - kareemsabri 4y ago
    useRef is useStableValue
    - ajkjk 4y ago
      Not quite, having to use for current everywhere is just annoying, and it doesn't allow for a one-time constructor function.
      - kareemsabri 4y ago
ajkjk 4y ago
> e.g. I'm not sure how they're implemented It might help to have a simple mental model for them? Picture there is a global variable called _currentComponent: _currentComponent: { previousValue: React.Element hooks: HookValue[] currentHook: number firstRender: boolean } Each HookValue is whatever that hook wants. For useState something like: HookValue = { hookName: 'useState', value: [state, setState], } Before your component is run, the renderer sets `_currentComponent` to your component with its hooks set to their current values. If you run `useState(initial)` it looks like this: function useState(initialValue) { const component = _currentComponent let hookValue; if (firstRender) { hookValue = { hookName: 'useState', value: [initialValue, (newValue) => { hookValue[0] = newValue markForUpdate(component); // some React-provided function to mark this as needing an update } } component.hooks[component.currentHook++] = hookValue; return hookValue.value } else { hookValue = component.hooks[component.currentHook++] assert(hookValue.hookName == 'useState') return hookValue.value } Surely not perfect, but totally useable as a model of what's going on. To be honest I wish React showed pseudocode like this in the tutorials, it makes it a lot easier for me to understand.
- andyjohnson0 4y ago
  Thank you for posting this.
- acemarke 4y ago
  Yep! Also see Shawn Swyx Wang's talk "Getting Closure on React Hooks", where he goes through an equivalent example in more detail: https://www.swyx.io/hooks/ https://www.swyx.io/hooks/
HeyImAlex 4y ago
Hooks compose, whereas side effects and memoized values sprinkled through component constructors and lifecycle methods do not. For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. You try and make something like this re-usable and you’ll be leaking details of your implementation across the whole component via inclusion in these lifecycle methods, not to mention any data you’re shoving onto the component instance. But it’s still doable. Now, what if you wanted to use this re-usable behavior inside of another re-usable behavior? It gets complicated fast! Now your library needs to expose the lifecycle-updating methods of the underlying library, leaking details all the way down. Hooks are opaque from the perspective of lifecycle, while still having access to all the same… hooks.
- Griffinsauce 4y ago
  I wish the current detractors would look back at this. The options with life cycles are either huge life cycles with interspersed features OR super painful composition. I've been in big codebases with both and it was absolute hell. Hooks aren't perfect or pretty but the fact that they can encapsulate AND compose makes them a million times better. Those codebases are much easier to deal with now. Again, not perfect, but much better.
  - DanielHB 4y ago
    hooks were created to replace the functionality of mixins, not necessarily to replace lifecycles The react team could have easily added a useDidUpdate() and useWillMount(), but they didn't because the new abstractions cover the mixins use-cases also work better than lifecycles as well (but somewhat less intuitive at first glance)
somewhereoutth 4y ago
They are yet more evidence that any human engineered system will inevitably 'diverge' to become the most complicated thing that just about works - what we might call the complexity horizon. Driven by the power of our 'ingenuity', even the most elegant constructions will find themselves drifting towards this horizon. It takes super human effort to resist the effect, and super humans to keep systems from escaping us.
- johnfn 4y ago
  Really? Hooks seem quite simple to me conceptually - certainly significantly more simple than class components were. If anything, they seem to me to be a clear disproof of your hypothesis.
- eastbound 4y ago
  Human-built systems’ complexity evolves until the limit of our IQ. Hire 140-IQ people, the systems will just evolve 20% further.
8n4vidtmkvmk 4y ago
why? i personally like the "tear down" aspect effects. often times you have to clean up/unregister things when props change or component is unmounted. this leads to 5 random initializers in component class ctor and 5 random cleanups in onUnmount or whatever it was called. they're separated so its hard to correlate them. but even worse is that you cant encapsulate that by creating your own useX function. you could create HOCs but those were kind of clunky
solarkraft 4y ago
> I look forward to him releasing his online React course Any suggestions for a "second best" course that is available now?
- gregsadetsky 4y ago
  Scrimba is pretty great in my opinion -- https://scrimba.com/allcourses?topic=react https://scrimba.com/allcourses?topic=react (not affiliated, I just think their online learning environment is neat)

fabian2k 4y ago

You can reuse hooks between multiple components. You can't really do that with the lifecycle methods of class-based components.

DanielHB 4y ago
you can with mixins doesn't mean you should...

vanjajaja1 4y ago

Dan had a good summary of why hooks happened which I can't find now, the tldr was that there was a bunch of bugs introduced around referenced props/state being stale and unpredictable in components. Hooks was the natural evolution that removed all possibility of accidentally referencing stale data.

joshribakoff 4y ago
> Hooks was the natural evolution that removed all possibility of accidentally referencing stale data. It unfortunately does not, you can hve various foot guns with refs or omitting dependencies from the array argument; but to your point it makes it a lot easier to ensure you do it correctly by collocating logic related to each cross cutting concern instead of entangling the code in the lifecycle methods. More precisely it makes it easier to follow correct patterns, but as always that is subjective and hooks can be contentious :)

knodi123 4y ago

Hooks feel like a good system that stopped right before it became pretty. Like, an componentDidMount event is a now useEffect with no second argument? But a componentWillUnmount event is now a useEffect, with no second argument, that returns a callback? It's powerful, and it's not that hard to use, but it's cryptic and random. Why call it useEffect instead of some other more meaningful phrase? I mean, "componentDidMount" tells you exactly what it is. Does "useEffect"? Why should onload things be a function, but onunload should be a function returned by a function? Why does useRef give you a thing used for attaching handles to DOM elements so you can refer to them elsewhere, AND it gives you an object whose .current property can be used as a variable that persists without causing a render? It's like someone complained that there were two many functions in the API, and their names were too long, so they overcorrected in the opposite direction.

ajkjk 4y ago
I love hooks, but I think they made a few mistakes. The weirdness around useEffect having different behavior with no second argument vs [] is one of them. And they should have included a useUnloadEffect() by default, even though it's trivial to write, just for clarity. It's way too easy to miscount the number of ()s in useEffect(() => () => {}, []); They also should have included a few other basic hooks, like useStableValue() for just computing a constant once on first render. I hate the name `componentDidMount` though. useEffect seems much better to me.
- kareemsabri 4y ago
  useRef is useStableValue
  - ajkjk 4y ago
    Not quite, having to use for current everywhere is just annoying, and it doesn't allow for a one-time constructor function.
    - kareemsabri 4y ago

ajkjk 4y ago

> e.g. I'm not sure how they're implemented It might help to have a simple mental model for them? Picture there is a global variable called _currentComponent: _currentComponent: { previousValue: React.Element hooks: HookValue[] currentHook: number firstRender: boolean } Each HookValue is whatever that hook wants. For useState something like: HookValue = { hookName: 'useState', value: [state, setState], } Before your component is run, the renderer sets `_currentComponent` to your component with its hooks set to their current values. If you run `useState(initial)` it looks like this: function useState(initialValue) { const component = _currentComponent let hookValue; if (firstRender) { hookValue = { hookName: 'useState', value: [initialValue, (newValue) => { hookValue[0] = newValue markForUpdate(component); // some React-provided function to mark this as needing an update } } component.hooks[component.currentHook++] = hookValue; return hookValue.value } else { hookValue = component.hooks[component.currentHook++] assert(hookValue.hookName == 'useState') return hookValue.value } Surely not perfect, but totally useable as a model of what's going on. To be honest I wish React showed pseudocode like this in the tutorials, it makes it a lot easier for me to understand.

andyjohnson0 4y ago
Thank you for posting this.
acemarke 4y ago
Yep! Also see Shawn Swyx Wang's talk "Getting Closure on React Hooks", where he goes through an equivalent example in more detail: https://www.swyx.io/hooks/ https://www.swyx.io/hooks/

HeyImAlex 4y ago

Hooks compose, whereas side effects and memoized values sprinkled through component constructors and lifecycle methods do not. For example, the equivalent of useEffect required calls inside of componentWillMount, componentDidUpdate, and componentWillUnmount. You try and make something like this re-usable and you’ll be leaking details of your implementation across the whole component via inclusion in these lifecycle methods, not to mention any data you’re shoving onto the component instance. But it’s still doable. Now, what if you wanted to use this re-usable behavior inside of another re-usable behavior? It gets complicated fast! Now your library needs to expose the lifecycle-updating methods of the underlying library, leaking details all the way down. Hooks are opaque from the perspective of lifecycle, while still having access to all the same… hooks.

Griffinsauce 4y ago
I wish the current detractors would look back at this. The options with life cycles are either huge life cycles with interspersed features OR super painful composition. I've been in big codebases with both and it was absolute hell. Hooks aren't perfect or pretty but the fact that they can encapsulate AND compose makes them a million times better. Those codebases are much easier to deal with now. Again, not perfect, but much better.
- DanielHB 4y ago
  hooks were created to replace the functionality of mixins, not necessarily to replace lifecycles The react team could have easily added a useDidUpdate() and useWillMount(), but they didn't because the new abstractions cover the mixins use-cases also work better than lifecycles as well (but somewhat less intuitive at first glance)

somewhereoutth 4y ago

They are yet more evidence that any human engineered system will inevitably 'diverge' to become the most complicated thing that just about works - what we might call the complexity horizon. Driven by the power of our 'ingenuity', even the most elegant constructions will find themselves drifting towards this horizon. It takes super human effort to resist the effect, and super humans to keep systems from escaping us.

johnfn 4y ago
Really? Hooks seem quite simple to me conceptually - certainly significantly more simple than class components were. If anything, they seem to me to be a clear disproof of your hypothesis.
eastbound 4y ago
Human-built systems’ complexity evolves until the limit of our IQ. Hire 140-IQ people, the systems will just evolve 20% further.

8n4vidtmkvmk 4y ago

why? i personally like the "tear down" aspect effects. often times you have to clean up/unregister things when props change or component is unmounted. this leads to 5 random initializers in component class ctor and 5 random cleanups in onUnmount or whatever it was called. they're separated so its hard to correlate them. but even worse is that you cant encapsulate that by creating your own useX function. you could create HOCs but those were kind of clunky

solarkraft 4y ago

> I look forward to him releasing his online React course Any suggestions for a "second best" course that is available now?

gregsadetsky 4y ago
Scrimba is pretty great in my opinion -- https://scrimba.com/allcourses?topic=react https://scrimba.com/allcourses?topic=react (not affiliated, I just think their online learning environment is neat)