3 ms·
The problem I have with hooks is that I see cool examples like the window size watcher, but when it comes to my own code I have: 1. Some stuff that happens whe
by com2kid 7y ago
The problem I have with hooks is that I see cool examples like the window size watcher, but when it comes to my own code I have:
1. Some stuff that happens when the component gets mounted
2. So local state that gets maintained (shown error text, whatever, red x, whatever)
3. Some stuff that happens when the component is unmounted.
React classes fit 99% of my use cases. Yes HOCs to get navigation and stuff working is a pita. But honestly I'd have preferred a way to get the cool hook stuff added to class components instead of adding all the class component stuff to function components!
- efdee 7y agoBut these three things are super easy with hooks, maybe even easier so than with class components.
- thatswrong0 7y agoExactly. I'll often use a shared useOnMount and useOnUnmount for additional clarity for those in our codebase unfamiliar with how useEffect works.. there's nothing preventing you from writing custom hooks to replicate the effect of lifecycle methods for the transition period. For the simplest cases, class components might be clearer with its clearly labeled lifecycle methods. But most of the time, if I have multiple different things happening on mount, hooks are definitely simpler as you can divide / encapsulate based on feature functionality rather than lifecycle. This is my favorite example for showing how this effects code structure: https://twitter.com/threepointone/status/1056594421079261185 https://twitter.com/threepointone/status/1056594421079261185 If you then extract those bits into custom hooks in order to name that piece of functionality (e.g. in that example, useTitle() and useWindowResize()), the clarity improves dramatically.