4 ms·

I think that particular choice was an unusually big mistake. Most of them are not so big. But I can't fathom why they made "empty array" cause no rerenders but

by ajkjk 4y ago

I think that particular choice was an unusually big mistake. Most of them are not so big. But I can't fathom why they made "empty array" cause no rerenders but "no array" cause all the rerenders.

culi 4y ago
There's a few, rare, use-cases where you'd actually want this behavior. But I agree it's too easy to accidentally do this thing that should be an extreme edge case.
- sli 4y ago
  I've run into those cases a couple times before and my immediate thought was that it seems unwise for this one function to be used in both cases. There really ought to be something specifically intended for effects with no dependencies even if all it does is make the difference explicit. I'm not a fan of things that contain features that manifest like subtle traps because determining programmer intent is undecidable. That lesson was learned from PHP <=5.
imbnwa 4y ago
At the very least make them separate functions
- ajkjk 4y ago
  Yeah, that's what I'm saying. There's no reason they had to be the same thing.
eyelidlessness 4y ago
This is why whenever I can (i.e. it’s not a breaking API change or it’s agreed on), I turn these implicit rules into explicit options named and documented as such in the code. Yeah it’s a little more to type, but it solves the “this isn’t obvious for good reasons” problem much better than a pair of defaults that you probably don’t even know how to look up.
systoll 4y ago
useEffect is treating undefined as meaning undefined. It makes perfect sense from inside of useEffect. If there are no dependencies ([]), the dependencies can never change, so React can always reuse the old effect. If the dependencies aren’t defined, there’s no way to tell if the old effect is OK, so React must always rebuild it. ** But `useEffect(()=>{})` doesn’t explicitly show that React will get `dependencies = undefined`, and in this case that’s unusually important. You could have ESlint force you to change that to `useEffect(()=>{}, undefined)`, I suppose…
- bottlepalm 4y ago
  Yes we know how it works. What we’re saying is that it is a cryptic design. Just like the function returned from useEffect is used for unmounting the component. Not intuitive at all.
- darepublic 4y ago
  there is an eslint rule exhaustive-deps which really helps with this
  - systoll 4y ago
    For useMemo and useCallback, Typescript and exhaustive-hooks will both tell you to add a dependency array, because without it those hooks do nothing. For useEffect, exhaustive-hooks & Typescript say nothing, because a non-memoised Effect is a reasonable thing to write. It’s just not a great thing to write accidentally.
purple_ferret 4y ago
I'm pretty sure because it's basically an easy hack to recreate the behavior of componentDidMount.

by ajkjk 4y ago

I think that particular choice was an unusually big mistake. Most of them are not so big. But I can't fathom why they made "empty array" cause no rerenders but "no array" cause all the rerenders.

culi 4y ago

There's a few, rare, use-cases where you'd actually want this behavior. But I agree it's too easy to accidentally do this thing that should be an extreme edge case.

sli 4y ago
I've run into those cases a couple times before and my immediate thought was that it seems unwise for this one function to be used in both cases. There really ought to be something specifically intended for effects with no dependencies even if all it does is make the difference explicit. I'm not a fan of things that contain features that manifest like subtle traps because determining programmer intent is undecidable. That lesson was learned from PHP <=5.

imbnwa 4y ago

At the very least make them separate functions

ajkjk 4y ago
Yeah, that's what I'm saying. There's no reason they had to be the same thing.

eyelidlessness 4y ago

This is why whenever I can (i.e. it’s not a breaking API change or it’s agreed on), I turn these implicit rules into explicit options named and documented as such in the code. Yeah it’s a little more to type, but it solves the “this isn’t obvious for good reasons” problem much better than a pair of defaults that you probably don’t even know how to look up.

systoll 4y ago

useEffect is treating undefined as meaning undefined. It makes perfect sense from inside of useEffect. If there are no dependencies ([]), the dependencies can never change, so React can always reuse the old effect. If the dependencies aren’t defined, there’s no way to tell if the old effect is OK, so React must always rebuild it. ** But `useEffect(()=>{})` doesn’t explicitly show that React will get `dependencies = undefined`, and in this case that’s unusually important. You could have ESlint force you to change that to `useEffect(()=>{}, undefined)`, I suppose…

bottlepalm 4y ago
Yes we know how it works. What we’re saying is that it is a cryptic design. Just like the function returned from useEffect is used for unmounting the component. Not intuitive at all.
darepublic 4y ago
there is an eslint rule exhaustive-deps which really helps with this
- systoll 4y ago
  For useMemo and useCallback, Typescript and exhaustive-hooks will both tell you to add a dependency array, because without it those hooks do nothing. For useEffect, exhaustive-hooks & Typescript say nothing, because a non-memoised Effect is a reasonable thing to write. It’s just not a great thing to write accidentally.

purple_ferret 4y ago

I'm pretty sure because it's basically an easy hack to recreate the behavior of componentDidMount.