4 ms·
I'm with you on thought #2. Regarding your first thought, however: if you want control over when `useEffect` callbacks fire, identity isn't just an optimization
by purplerabbit 5y ago
I'm with you on thought #2. Regarding your first thought, however: if you want control over when `useEffect` callbacks fire, identity isn't just an optimization, it's a necessity. For example (used in another comment): if you're not using a smart intermediate layer like `react-query`, you can unintentionally trigger loading states and re-fetches if you're not closely watching dependency array identities
- codeflo 5y agoOh, that’s a good example. I’ll argue that you should try to use primitives (strings/numbers) as keys in those cases. But if you can’t, then you’re right that identity is critically important.
- acidbaseextract 5y agoI'm curious if you've used useDeepCompareEffect, the use-deep-compare-effect npm package? I've found that it is pretty reasonable foolproofing for many of these identity questions. I'm well aware of Dan Abramov's objections to the deep equality checking [1] but I still find it a bit easier for me and other devs to reason about when doing things like data fetching. [1] https://twitter.com/dan_abramov/status/1104414469629898754 https://twitter.com/dan_abramov/status/1104414469629898754
- purplerabbit 5y agoHadn't heard of that -- thanks for sharing! Crazy how many choices there are in the mix (use-deep-compare-effect, the `JSON.stringify` approach mentioned by Dan, `useMemo`, and `useMemoOne`). Feels like a "pick your poison" scenario, as each one has a significant issue. That being said, `useDeepCompareEffect` does seem the most "foolproof", and "foolproof" is probably more important than intuitive or performant in most cases.