7 ms·

> The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps arra

> The function useEffect has so many caveats and such a terrible API. Really? What caveats? The only maybe oddity that I can think of is that if the deps array is omitted it always runs. What API would you prefer? Something more like signals?

cjcenizal 3y ago
This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
- consilient 3y ago
  That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
- paulddraper 3y ago
  tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
- Scarblac 3y ago
  In particular that it's OK to directly call setState inside functional components was a surprise to me (when I read that some months ago), it does make things simpler.
SinParadise 3y ago
Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way. I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it. You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.
- nwienert 3y ago
  But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc. Hooks imo are great, as they are pretty explicit and low level. Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.
  - SinParadise 3y ago
    I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.
    - nwienert 3y ago
      I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. [0] https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s
      - SinParadise 3y ago
        Thats a cool project. >But I don't think the "pretend it isn't" makes any sense Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it. >I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well. I'd probably like React better if it had a compile layer on top of its more functional parts? As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.
foota 3y ago
Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.
toastercat 3y ago
The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this." > What API would you prefer? Something more like signals? Yes. Or full tree redraws like Mithril.js did 8 years ago.
- paulddraper 3y ago
  React does full tree redraws (well, unless you use memo). useEffect is for side-effects.
  - toastercat 3y ago
    It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
  - Izkata 3y ago
    Class components have "shouldComponentUpdate()" that avoids this entirely.
- tshaddox 3y ago
  Or you installed the lint rule once 4 years ago and never had a problem again.
  - gyanreyer 3y ago
    Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.
danielvaughn 3y ago
This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc). useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.
- littlecranky67 3y ago
  Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that. Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.
  - SahAssar 3y ago
    > As long as the JavaScript VM and the DOM uses non-blocking async models The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).
    - littlecranky67 3y ago
      While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.
      - SahAssar 3y ago
        It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).
- 3y ago
Izkata 3y ago
It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-comparison-in-useeffect-hook-1elm https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...
- vlod 3y ago
  I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'? [0]: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/

cjcenizal 3y ago

This page[0] lists many situations in which useEffect shouldn’t be used. Some might seem counter-intuitive. [0] https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect

consilient 3y ago
That's not a bunch of separate caveats, it's a few principles illustrated with lots of examples. - Don't use effects for things that aren't genuinely effectful - Put finnicky state management stuff in reusable utils instead of re-implementing it from primitives over and over again. Neither is React-specific.
paulddraper 3y ago
tl;dr Don't use useEffect if there is an alternative. That's a bunch of examples where there are good alternatives.
Scarblac 3y ago
In particular that it's OK to directly call setState inside functional components was a surprise to me (when I read that some months ago), it does make things simpler.

SinParadise 3y ago

Not useEffect specifically, but wiring something very stateful like a map library into the React rendering paradigm while keeping the state management in React via useState etc. can be very difficult to do so in a performant way. I recalling using a lot of useRef to manually tune when to re-render, and in an ideal world I shouldn't be this granular about it. You can certainly use one of the many React map wrapper libraries to lessen the pain, the pain is still very real, just dealt with by someone else.

nwienert 3y ago
But what’s better? In the end you need control over stuff, it’s almost like people want frontend to be magically easy but unfortunately there’s just the reality that either you have high abstraction but less control, or low abstraction and more control (more code, more gotchas, etc) until you get a smart optimizing compiler ofc. Hooks imo are great, as they are pretty explicit and low level. Nowadays signals are the new kid on the block, though mobx and similar have existed since forever in react land, but they have their own crazy edge cases like reactive loops and implicit behavior.
- SinParadise 3y ago
  I like Svelte. It embraces the fact that UI is stateful and doesn't try to pretend it isn't.
  - nwienert 3y ago
    I do too, I made this [0] 3 years before Svelte existed. But I don't think the "pretend it isn't" makes any sense, I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. [0] https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s https://www.youtube.com/watch?v=HHTYHm6qLFY&t=11s
    - SinParadise 3y ago
      Thats a cool project. >But I don't think the "pretend it isn't" makes any sense Well, let me expand a bit more. React's pitch is that view is a function of state, and essentially designed around the idea of an immutable state which re-renders everything when changed. It then offered some APIs to allow fine-tuning of rendering via hooks which either ties with data changes or some rendering life-cycle. To me the API screams of stubborn refusal to let go of the "view as a function of state" mantra: When you encounter a scenario where it breaks the mantra, lets add another lever to handle it. This lever also has to be pulled by you the developer, and it is up to you to know when to do it. >I actually like React more than Svelte for many reasons, but magic compilers and templates are two big ones. I don't really have an issue with compilers. They are the accepted magic that bridges between language for people and language for machines. The ideal language might be something that is functional and immutable language that it is easy for us to read, but compiles to the optimized, imperative updates that machine can run well. I'd probably like React better if it had a compile layer on top of its more functional parts? As for templates, JSX is probably the one great thing that came out of React. It is no wonder that many other frameworks are embracing JSX, but none of them are really forking the idea of hooks.

foota 3y ago

Personally, I grew to prefer signals and rx and APIs for heavy things. I wish it were easier to hook up some custom class object to a component to use as state, but it always feels clunky.

toastercat 3y ago

The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this." > What API would you prefer? Something more like signals? Yes. Or full tree redraws like Mithril.js did 8 years ago.

paulddraper 3y ago
React does full tree redraws (well, unless you use memo). useEffect is for side-effects.
- toastercat 3y ago
  It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
- Izkata 3y ago
  Class components have "shouldComponentUpdate()" that avoids this entirely.
tshaddox 3y ago
Or you installed the lint rule once 4 years ago and never had a problem again.
- gyanreyer 3y ago
  Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.

danielvaughn 3y ago

This may be a personal thing, but I really like reading and writing code that feels like it's telling a story. That is, operating sequentially (this happens, then this happens, then this other thing, etc). useEffect breaks the sequential nature of your code and makes it feel like you're reading a script from a Quentin Tarantino movie.

littlecranky67 3y ago
Agreed, but non-sequential execution is the nature of event-driven, async non-blocking code. Event-driven as Web Applications (not Websites!) mostly deal with events (user input or network events). As long as the JavaScript VM and the DOM uses non-blocking async models no framework - being it Vue, Angular, React or whatnot - will ever change that. Sequential, blocking modells like i.e. batch ETL jobs are just not the domain of the browser.
- SahAssar 3y ago
  > As long as the JavaScript VM and the DOM uses non-blocking async models The DOM is almost entirely sync, all the operations on it are blocking operations (including things like replacing an entire document with innerHTML).
  - littlecranky67 3y ago
    While not strictly on "the DOM", a lot of modern APIs are within the browser's JS VM (Notification, Camera, Audio, QR scanning, etc.) and all of them are async to the core. My argument therefore stands.
    - SahAssar 3y ago
      It does not, since most of those APIs are not directly called from the framework. What react and most other JS frameworks do is DOM modification (which is clearly sync) and delegate events (which is usually done via callbacks or binding).
3y ago

Izkata 3y ago

It does a shallow compare, not a deep compare. Workarounds tend to involve additional hooks: https://dev.to/vsramalwan/ways-to-handle-deep-object-comparison-in-useeffect-hook-1elm https://dev.to/vsramalwan/ways-to-handle-deep-object-compari...

vlod 3y ago
I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'? [0]: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/