I might get thrown off the island for this question, but.. in a pure client app, how do you fetch data and then load it into state without set state in the use effect hook?
I remember you explaining this to me at react conf, I totally get this. This is client side suspense which technically is not released. Is the old pattern going to be deprecated? Or just not recommended? Should we stop teaching it all together?
I understand the code here: that cache is outside the scope of the component, that @ricky.fm uses the new use hook. But I’m struggling to see the correlation with his first statement. Maybe this could make for a great topic in a good old blog post? It might help clarify things for others too
Ugh, I had an old coworker that insisted we memoify all of our Redux action creators. It got to the point where now I actively question every useMemo I see.
There was a point in time many years ago where someone made the decision to memoize all components in our huge code base, with it calculating hashes on all (even deeply nested object) props. You can imagine how well that went.
What are the general alternative strategies here? Is the assumption that most setState calls in useEffect callbacks are for fetching async data and that we should instead be using server components to do so? I see this sentiment shared and more and more so I’m mostly curious.
setState in an event or promise callback is fine, it’s setState in the effect body that is the absolute worst, especially in layout effects (which forces a sync render)
Just my theory - it’s hard to do some use cases (like reacting to multiple events/state) outside of effects, and using an effect is so easy. Probably the right trade off in those cases, but then it builds a habit to doing that pattern everywhere.
Yes, it's easy and powerful. More often than not, people don't understand or care about the order of things happening and that's great if perf is not the main concern.
I was guilty of this. I think it was mostly because I was thinking “when this value changes I want this other state to change.” useEffect accomplishes this consistently. It wasn’t until I started writing tests that I realized that things weren’t working how I expected.
Some of the rules seem a bit overly strict to me.
Should we really disallow all use of class components for instance? Does it still allow error boundaries? Do the react docs now recommend not using classes at all?
Feels a bit like taking blanket statements and turning them into rules, which I suspect will turn a lot of people off.
The no direct setState rules makes a lot of sense though, its a bad pattern for sure.
I think the plan was always to eventually get rid of class components from react - or at least, not bundle them with the `react` package and maybe in a future major get them with a separate package if you need to
errorBoundaries should also have a hook equivalent, but they don't yet. It's better to just disable this rule in-line if you write it once. Zero lint violations isn't the goal (never was) - it's about not adding new anti-patterns with new code, then fix the existing ones over time.
Hopefully the rule can get updated with an exception for error boundaries then.
It’s important for linters to allow common patterns, since developers who aren’t familiar with it are going to end up looking for a different solution rather than responsibly turn it off.
It’s definitely something to keep in your back pocket, but like most things it can be abused. I’ve worked in a codebase that overused this technique, and debugging updates was not fun.
Comments
- render
- commit
- effect
with setState in useEffect:
- render
- commit
- effect
- render
- commit
- effect
it’s a render waterfall
I suspect the app im working on is a big offender 😅
In general, having more advanced docs would be helpful
I’m still pretty new to react though (coming from Angular & Vue) so maybe it will click in a few more weeks 🤞
The whole eslint-react series of rules is great, as it builds the rules based on recommendations from the new react docs 🎉
Should we really disallow all use of class components for instance? Does it still allow error boundaries? Do the react docs now recommend not using classes at all?
The no direct setState rules makes a lot of sense though, its a bad pattern for sure.
I think the plan was always to eventually get rid of class components from react - or at least, not bundle them with the `react` package and maybe in a future major get them with a separate package if you need to
It’s important for linters to allow common patterns, since developers who aren’t familiar with it are going to end up looking for a different solution rather than responsibly turn it off.
https://react.dev/learn/preserving-and-resetting-state#option-2-resetting-state-with-a-key