OOP is a great fit for UI frameworks.
OOP is a bad fit for many other things.
They guy who hammers nails all day thinks screwdrivers are worthless.
They guy who hammers nails all day thinks screwdrivers are worthless.
Lenses solve the nested mutation problem for immutable structures but then go past what you can do with getters and setters. For example, you can compose bigger lenses out of smaller ones.
Most of the even more OO frameworks around the same time, like Taligent, failed.
Of course it did win over procedural frameworks like classic MacOS, but some of those are still popular in games or embedded systems.
The biggest UI framework of the past decade is decisively anti-OOP in its philosophy
Switch it to a state with the methods and you got your object. Polymorphism here is not a requirement. It is a feature to be used when needed. Some time in the 80s I was doing exactly the same - operating on state with functions. Same shit different color.
Programmers just love going on crusades. I find it a waste of time and intolerance breeding ground. Instead of heating the air use whatever the fuck suits one. Just do not stalk other people who happen to have different preferences.
Agreed hooks are… something else.
I think it looks functional because it's only easy to reason about if you write functional code.
I suppose it tries to solve some of the same problems as OO, like related state and private transitions. But it feels like React itself is the God Object.
This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/
Lots of use of context managers in Python are for accomplishing this. Smalltalk error handlers are like this (different than try/catch). Or Scheme's with-output-to-file... I got the sense that variables that start and end with stars in Common Lisp are used for this, but I was never clear if it was convention or an actual language feature.
I think I'd like it in React too if they just hadn't tried to be so clever.
You could achieve the same effects by passing down callbacks.
I thought the reason why this is good for Errors, Themes and Loading (Suspense), is because they're so common, that you can always expect someone up in the hierarchy to consider it, and therefore sacrifice some type safety for less verbosity.
The article mentions that "usually the fact that a function can perform an effect would be encoded into its type signature", which is why I don't understand the need in this example.