6 ms·
Or maybe you shouldn’t be thinking in terms of a “component lifecycle”.
by robertoandred 4y ago
Or maybe you shouldn’t be thinking in terms of a “component lifecycle”.
- lloydatkinson 4y agoExactly - OP is perpetuating bad explanations. https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27s%20the%20crux%20of%20the%20issue%3A%20useEffect%20is,the%20dogId%20changes%2C%20fetch%20the%20new%20dog%27s%20information.%22 https://epicreact.dev/myths-about-useeffect/#:~:text=Here%27...
- Rapzid 4y agoThat's bullshit; useEffect is a lifecycle hook. From the documentation for the useEffect SETUP parameter: > setup: The function with your Effect’s logic. Your setup function may also optionally return a cleanup function. When your component is first added to the DOM, React will run your setup function. After every re-render with changed dependencies, React will first run the cleanup function (if you provided it) with the old values, and then run your setup function with the new values. After your component is removed from the DOM, React will run your cleanup function one last time.
- dgb23 4y agoIt absolutely is. But the article and the comments above mention that it’s more useful to have the mental model of synchronizing side effects with state. It’s good advice, because it addresses a major stumbling block people struggle with. After that the code and the way useEffect is used becomes simpler.
- Rapzid 4y agoFrom the linked article in this thread: > Here's the crux of the issue: useEffect is not a lifecycle hook. That doesn't leave much room for ambiguity; seems like a definitive statement. Many don't see any nuance here and then go around blasting people for saying useEffect is a lifecycle hook because they read on some blog the exact opposite. But anyway, what is a lifecycle hook if not a way to synchronize two systems... ( ͡° ͜ʖ ͡°)
- ZephyrBlu 4y agoThe amount of groupthink from React influencers is a big reason why I don’t interact with the community. Posts like this are almost always insufferable.
- robertoandred 4y agoIt’s not groupthink, it’s how the library was designed. What’s wrong with understanding the tools you’re using?
- ZephyrBlu 4y agoLifecycle methods are a valid use case for hooks, yet that use case is constantly bashed (E.g. in this post). There is a very specific way of doing React that influencers and sometimes the React core team push very, very strongly. Sometimes it's justified, but usually I find that it's personal preference being pushed as fact.
- the_gipsy 4y agoHow do you handle route changes and data fetching, then? Back to Redux?
- MrPatan 4y agoNever left
- notpachet 4y agoSame boat. It's tiring watching other React devs tie themselves in knots over component lifecycle (either via hooks or class lifecycle methods) when the actual solution is to use neither.
- yamtaddle 4y agoIt's downright pleasant, with typescript. All the "waaaah boilerplate" stuff goes away. It's very simple (not even hard to reimplement, in a pinch). Truly does work well with non-React codebases, so if you build your business logic or at least your client-code around it, it's portable. I stopped being a React fan with hooks, but remain a fan of Redux.
- robertoandred 4y agoThose are results from a change in state, nothing to do with whether a component has appeared.
- the_gipsy 4y agoYou either have some world state, like redux, or you have react components with hooks. With hooks, those have everything to do with the component's lifecycle. Hooks are included with react, world state management is not.
- robertoandred 4y agoWhat? You still use hooks with Redux. And you could consider React's Context API as world state management if you really wanted to. And these still aren't intrinsically tied to a component lifecycle.