4 ms·
You're only calling it not simple because you're not familiar with it. I personally think hooks are simpler despite being different. Everyone knows "classes" bu
by thatswrong0 6y ago
You're only calling it not simple because you're not familiar with it. I personally think hooks are simpler despite being different. Everyone knows "classes" but React's usage of them is not typical and there _are_ non-standard behaviors about using them that you have to learn when learning React (because the classes necessarily exist within the React runtime). Either way you're dealing with React.
And on a day-to-day basis for me, there are still plenty of uses for reusable logic inside of components even after extracting business logic / creating small focused components, especially as it pertains to presentation. A simple example that I use somewhat frequently is a window-size watcher.. a pretty simple hook that watches the window-size, re-renders when it changes (on a debounce), and it provides the current width x height of the window, allowing the component to use those values to calculate some view parameters. With hooks, it's as simple as plopping `const { windowHeight, windowWidth } = useWindowSize()`. Without hooks it generally requires wrapping a component with another.
I've been using hooks basically since they came out and IMO they're way more in tune with React's programming model than class-based components. Even if you create custom hooks for most components, the paradigm still encourages developers to encapsulate related pieces of component logic into their own hook-functions rather than spreading that logic across multiple lifecycle methods. I haven't come across a single situation where I would have preferred a class based component.
- com2kid 6y agoThe 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 6y agoBut these three things are super easy with hooks, maybe even easier so than with class components.
- thatswrong0 6y 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.