5 ms·

Applying state changes in a controlled fashion is just about the last quality I'd ascribe to a non-trivial React codebase. By the time you've finished with all

Applying state changes in a controlled fashion is just about the last quality I'd ascribe to a non-trivial React codebase. By the time you've finished with all the ceremony of memoizing everything just right so you get acceptable performance you're left with a brittle codebase full of surprises. Making one innocuous change can break all your memoizations. Or you're just as likely to find something failing to update because it's been over memoized. Manually managing all the dependency arrays for all this is very poor DX. React deserves credit for bringing fresh thinking into the JS framework space but there's a tremendous amount of room for improvement.

ironmagma 4y ago
So don’t memoize unless you need to. Most of the time, you don’t. This is a fairly classic case of overeager optimization. The state changes shouldn’t* particularly depend on memoizations anyway though as memoize should be mostly for view stuff (which should* be idempotent) rather than model stuff. * = subjective and there are a few rare exceptions
- cageface 4y ago
  If you want acceptable performance in a reasonably complex react app you absolutely have to memoize. The fact you think this isn’t the case suggests to me you haven’t worked on a big react app.
  - ironmagma 4y ago
    There’s a significant difference between having to memoize and having to memoize tons of stuff. Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
  - moonchrome 4y ago
    > If you want acceptable performance in a reasonably complex react app you absolutely have to memoize I think what OP was suggesting is that you don't have to memoize at every level of the tree / where it doesn't make sense.

ironmagma 4y ago

So don’t memoize unless you need to. Most of the time, you don’t. This is a fairly classic case of overeager optimization. The state changes shouldn’t* particularly depend on memoizations anyway though as memoize should be mostly for view stuff (which should* be idempotent) rather than model stuff. * = subjective and there are a few rare exceptions

cageface 4y ago
If you want acceptable performance in a reasonably complex react app you absolutely have to memoize. The fact you think this isn’t the case suggests to me you haven’t worked on a big react app.
- ironmagma 4y ago
  There’s a significant difference between having to memoize and having to memoize tons of stuff. Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
- moonchrome 4y ago
  > If you want acceptable performance in a reasonably complex react app you absolutely have to memoize I think what OP was suggesting is that you don't have to memoize at every level of the tree / where it doesn't make sense.