DEV Community

Discussion on: The React Hooks Announcement In Retrospect: 2 Years Later

Collapse
 
lizmo profile image
alisman

I still find hooks to be inherently unfriendly to the human mind. Classes are friendly and were the fruit of many years of programming evolution/wisdom, which hooks basically throws in the trash, all because of hatred of inheritance. Inheritance is only one feature of classes. They also serve as natural mental/organizational models. With hooks, figuring out what is going on based on reading code is much harder. If the goal is functional programming and code sharing, I've never understood why that could not be more simply accomplished within the class paradigm by using functions instead of methods and passing them what's necessary, even "this." func.apply(this, ...) isn't that hooks in a nutshell?

Collapse
 
lizmo profile image
alisman

With respect to state management, it seems quite clear that we need both global and local state. It would be nice if both were handled in the same way so that they could be used interchangeably depending on scenario. I view that as the biggest problem. Mobx solves it quite nicely. And by tracking change automatically at all nodes of a state tree, offers optimization that would be hard to exceed in any other fashion.

Collapse
 
ryansolid profile image
Ryan Carniato • Edited

I mean that is a bit of what of Vue 3 has with their Composition API. The reactivity is independent somewhat from the Component lifecycle.

You might like my library Solid. It's basically if you created a library purely from MobX (I needed to make some changes for performance reasons). No VDOM just reactivity. A simplistic view is everything is a series of nested autoruns. State management local and global is homogenous. It's all just a matter of scope.

That being said I like the function component part of React. So when I make the comparison to MobX it's based on the reactive data and not all the decorator/decorating stuff that people associate.