But that took the simplicity away. Everyone that knows modern JavaScript knows classes. Now they have to learn this alien concept called "hooks".
Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable logic in components. Then decompose your mega-components into simpler components. This removes all remaining need for reusable logic. If you still have reusable logic inside your component -- this is very rare -- allow some duplication of code, this is better than creating monstrous code that nobody understands.
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.
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!
Exactly. 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.
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.
Now regarding reusability: I have been doing UI code for many many years and I have rarely felt that logic inside UI components need to be reusable. First move all business logic out of UI components into model-layer objects. This eliminates most of the need for reusable logic in components. Then decompose your mega-components into simpler components. This removes all remaining need for reusable logic. If you still have reusable logic inside your component -- this is very rare -- allow some duplication of code, this is better than creating monstrous code that nobody understands.