4 ms·
I've found that people that learned class-based React first and then switched to modern function-based React often have more trouble with useEffect than people
by culi 4y ago
I've found that people that learned class-based React first and then switched to modern function-based React often have more trouble with useEffect than people who learned functional components directly
I think a big part of the problem is we need to stop selling useEffect as a replacement for the lifecycle methods of class based components. It also probably would've been a lot less confusing if we called it something like useSideEffect
I think any react linting setup resolves most of the confusion but there's a lot of people that start off and don't even know how to set up lint rules for react. They should be a default in any react app imo
- luisgvv 4y agoI can second this... I inherited a huge pile of crap without a react lint ruleset and as soon as I put it in place there were ton of errors. The part I don't like about useEffect is that developers tend to overuse it and when they get stuck in infinite render loops you can see the whole mess it can lead to and how hard it can be to untangle monkey patched logic.
- orangepanda 4y ago> I've found that people that learned class-based React first and then switched to modern function-based React often have more trouble with useEffect than people who learned functional components directly I’d say its the opposite; people who used lifecycle methods know that useEffect and friends eliminates an entire class of bugs. People who started with hooks dont understand the problems it solved, and only see the quirks
- chrisbaker98 4y agoI'm far more experienced with React function components than with class components, so I'm curious, what are some of the problems with class components and how did hooks solve them?
- spion 4y agoThis was not the only design possible. The main problem with lifecycle methods was that you couldn't have multiple of them. There is absolutely nothing about the design of React that necessitated hooks to fix that issue. You could have this API this.addListener('mount', () => { // do things on mount // return cleanup to be called on unmount return () => cleanup() }) called from the constructur of a component. With this you could setup multiple listeners and make sure they're all cleaned up. But no, the syntax wasn't "clean" (you'd pass `this` as an argument to the "custom hooks" equivalent"), so instead we got this error-prone order-dependent design that doesn't allow conditional execution and runs on every render.