3 ms·

The big time/cognitive savings is in not having to manually keep track of what should be in the dependency array, which is what you have to do with useMemo. I

The big time/cognitive savings is in not having to manually keep track of what should be in the dependency array, which is what you have to do with useMemo. I don't explain why the trade off is worth it because I'm not convinced the trade off is worth it. I'm explaining because devs using React will need to know, I'm not trying to convince that it's the right choice.

jhardy54 2y ago
How does this compare with ubiquitous lint rules that require hook dependency arrays to be exhaustive?
- naught0 2y ago
  Personally, I semi-regularly encounter instances where this rule must be ignored else I achieve an infinite re-render loop. Other times, it can be ignored, like when you use a stable value in the body of the memo or effect, like state setters from `useState`. In practice this leads to ignoring the rule, disabling the rule with a comment (and potentially forgetting to add vital dependencies when the function is updated), or adding a bunch of unnecessary noise to the dep array.
  - jhardy54 2y ago
    Can you give an example? In my experience these cases are often trivial to fix, and React provides some solid documentation on how to solve these: https://react.dev/learn/removing-effect-dependencies https://react.dev/learn/removing-effect-dependencies There absolutely might be cases that can’t be solved, so I’m hoping to break out of my bubble and learn what they are!
    - beedrillzzzzz 2y ago
      Fairly common: triggering a side-effect that uses some state value, only when a different piece of state changes. useEffect(() => { doSomething(someState) }, [otherState])
      - jhardy54 2y ago
        Sorry, there might be a misunderstanding —- I’m looking for an example of when the dependency array needs to be [], is that what you posted?
        beedrillzzzzz 2y ago
        Yeah maybe I didn’t follow exactly, I meant this as a common example of when the hook dependencies rules must be ignored.
        naught0 2y ago
        The example supplied is what I was trying to get at. An empty dependency array means that the effect runs only once on mount. Same with memos and callbacks -- the value should remain stable. Here's a real world example of how I populate some state based on url query params: https://github.com/Naught0/combinator/blob/master/frontend/src/App.tsx#L36-L53 https://github.com/Naught0/combinator/blob/master/frontend/s... I may end up using a more robust routing solution to keep in sync with query params if I ever want to spend the effort, but this is a naive solution that works alright. A more simplified, generic example could be: const [foo, setFoo] = useState(); useEffect(() => { setFoo("bar"); }, []); // The eslint rule wants setFoo here despite the value being stable
- Tarean 2y ago
  To me the big winning is that you don't have to memoize transitively. Occasionally someone asks me for help to optimize some react code, and then the dependency array contains some object/callback that has a dependency which has a dependency which wasn't memoized.

jhardy54 2y ago

How does this compare with ubiquitous lint rules that require hook dependency arrays to be exhaustive?

naught0 2y ago
Personally, I semi-regularly encounter instances where this rule must be ignored else I achieve an infinite re-render loop. Other times, it can be ignored, like when you use a stable value in the body of the memo or effect, like state setters from `useState`. In practice this leads to ignoring the rule, disabling the rule with a comment (and potentially forgetting to add vital dependencies when the function is updated), or adding a bunch of unnecessary noise to the dep array.
- jhardy54 2y ago
  Can you give an example? In my experience these cases are often trivial to fix, and React provides some solid documentation on how to solve these: https://react.dev/learn/removing-effect-dependencies https://react.dev/learn/removing-effect-dependencies There absolutely might be cases that can’t be solved, so I’m hoping to break out of my bubble and learn what they are!
  - beedrillzzzzz 2y ago
    Fairly common: triggering a side-effect that uses some state value, only when a different piece of state changes. useEffect(() => { doSomething(someState) }, [otherState])
    - jhardy54 2y ago
      Sorry, there might be a misunderstanding —- I’m looking for an example of when the dependency array needs to be [], is that what you posted?
      - beedrillzzzzz 2y ago
        Yeah maybe I didn’t follow exactly, I meant this as a common example of when the hook dependencies rules must be ignored.
      - naught0 2y ago
        The example supplied is what I was trying to get at. An empty dependency array means that the effect runs only once on mount. Same with memos and callbacks -- the value should remain stable. Here's a real world example of how I populate some state based on url query params: https://github.com/Naught0/combinator/blob/master/frontend/src/App.tsx#L36-L53 https://github.com/Naught0/combinator/blob/master/frontend/s... I may end up using a more robust routing solution to keep in sync with query params if I ever want to spend the effort, but this is a naive solution that works alright. A more simplified, generic example could be: const [foo, setFoo] = useState(); useEffect(() => { setFoo("bar"); }, []); // The eslint rule wants setFoo here despite the value being stable
Tarean 2y ago
To me the big winning is that you don't have to memoize transitively. Occasionally someone asks me for help to optimize some react code, and then the dependency array contains some object/callback that has a dependency which has a dependency which wasn't memoized.