But on the other hand it becomes clear that decent performance with this approach requires all kinds of tricks and each react version adds more and more of these tricks with a steep learning curve. Shame since react started out with a very small, easy to understand API and that is what made it so popular.
I don't have the slightest doubts about me being in the minority here, but i've seen a large amount of projects which attempt to use multiple state hooks per component, and as a consequence the dependency arrays become brittle as the code is changed and sooner or later you're stuck with your page being in an endless rendering loop, because your logic isn't clever enough to actually untangle all of the state to decide when it needs to change anything:
useEffect(() => {
... // a whole bunch of code
}, [foo, bar]);
useEffect(() => {
... // a whole bunch of code
}, [bar, baz]);
useEffect(() => {
... // a whole bunch of code
}, [foo, bar, baz]);
You could easily comment that code out or change it. But with hooks, you need to untangle how all of the related calls to setState work and where every method for every state hook is called and why. I'm not sure that it was a good idea to decouple those.
They’re confusing. The magic is too high. They maintain state in an invisible way. The abstractions are hard to follow, especially when you roll your own.
The key issue for me is that they hide the rendering lifecycle from you. Everything’s implied. One of the complaints with classes was that you had to learn the arcane weirdness of the lifecycle. But a) it’s not that weird and b) it’s much easier to learn when the callbacks are named after the stage in the lifecycle. The hooks way makes all that invisible.
That said, I’m quite fond of the ‘[value, setter]’ return type from useState. It’s nice to use and nice to write. Just don’t ask me to explain how it works for multiple re renders.
I mean, something simple like:
let i = 0;
const inc = () => i+=1;
const [i, setI] = useState(0);
const inc = useCallback(() => setI(currentI => currentI + 1));
For all the hate angularJS got, at least with dirty checking your javascript was just plain javascript. I'm leaning more and more towards svelte, which offers this, but more performant than with dirty checking.
This might actually even have a bug and would need to be even longer to properly function :-D
I think you need to add [i] as a dependency, no?
But, I've had way more annoying problems using class-based syntax. Twice the code, four times the pain. And TS type inference doesn't work as nicely with classes.
Vue got it right in many ways. At least back in the 2.0 days, the last I've worked with it.
I fully expect that in a few years React will be widely seen as a J2EE-like poster child of over-engineering shark jumping for the functional paradigm. I already do.
I pretty much stopped paying attention to new versions after React 14.
KISS - keep it stupid simple.
I suspect that some Devs new to JS didn't like the various definitions of "this", and Hooks was supposed to help them out.
No, stale closures caused by hooks are more confusing than what "this" has ever been, especially since this-related problems are mitigated with fat arrows and class property assignment. No, as far as I understand, the driving force behind the hooks was the vision of the coming concurrent mode, for which class components posed some difficult problems somehow.
Now, there are obviously bad ways to use (no pun intended) any tool. Doing things right requires some planning, and learning some patterns. Many effects that also potentially relate to each other should be encapsulated into custom hooks, for example. And it's often a mistake to just make everything hook-dependant—think about how would a non-react bit of the page interact with this feature, or how can you unit-test without dealing with state and component lifecycles.
Learning how to do this in a way that is approachable, maintainable and that closely follows the domain model is not necessarily easy, but that is true for almost every aspect of software engineering, including how to organize functions or classes.
The same is true for things like Suspense. Again, if you have worked on a large application, you'll see that managing side-effects, data that comes (partially or fully) from a backend, and providing a clean and performant experience (no cascading, reasonable errors) is hard. Suspense answers to a real need. Whether you like the solution they propose or not, that there's throwing of Promises involved is, honestly, an implementation detail—and I'd say it works great.
And if these features are not for you, don't use them. And if React is not for you, don't use it. If you have to work on a codebase that is not well architected, full of tangled useEffects, you'd probably have a similarly bad experience if the application was class-component-based or built using a different framework.
Feels like we need a new language with lazy evaluation and a smart compiler that handles this for you for this paradigm to really shine.
That would be the "all kinds of tricks" the OP referred to. Not that going from one to the other is inherently a win, but that to match the capabilities and ergonomics that classes & objects come with out of the box for addressing state-related performance improvements & state-related features, with "functional" React, you have to resort to "all kinds of tricks", i.e. write your own version of some of the OO things you need to get the job done semi-cleanly (which is exactly what the React team did with Hooks).
The result, to put it in only slightly unfair terms, is that React has enabled their community to use a really bad and half-baked OO system with bizarre syntax & behavior, all so that no-one has to use the "class" keyword sometimes. They didn't do that for funzies, but because some of the things they wanted to do, including things related to performance, required OO-like features to be workable, but for whatever reason they didn't want to rely on built-in language features for that, nor tell their community that sometimes they would have to use those built-in language features. Instead they opted for... Hooks.
Now I'm not at all saying that class components are better. Hooks are mostly easier to work with. But there's no doubt that function components has me using too much brain power and lines of code on memoization. I like the new features the react team are working on, but I hope they'll eventually do something about the stable function reference problem as well.