Exactly.
I did a somewhat longer writeup a while back.
https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
The pull request is still open :-)
Narrowmindedly worrying about syntactical differences is contributing nothing to the conversation. The point is relinquishing control of state to the framework (be it via props, hooks or @State), and drawing the UI as a pure representation of whatever the framework tells you. Hence ui = f(state). This gets you a metric ton of advantages, which is why every modern framework is doing it.
Classes, by themselves, are inadequate as containers for state unless that state must only exist in memory and never be observed, synchronized or serialized. You can attempt to patch that with decorators, ORMs or whatever, but now you're doing the same thing as React is doing with functions.
Why do you think it would?
Did you misread my post as "ha ha, Apple does it differently and therefore react is wrong"?
If so, you certainly misread it a lot, and you have the wrong person. I have tons of posts about Apple getting things wrong.
Anyway, did you miss the following part?
I also think that despite all the flaws, react.js and react.native are currently eating native development's lunch.
Clearly I made the point in my post that this approach has a lot of mindspace, despite the obvious flaws, so not sure how you pointing out that this approach has a lot of mindspace invalidates my post.
> Hence ui = f(state).
Every UI is always some mapping of the state. Otherwise it isn't really a UI, is it? What would it be, in your opinion, if it didn't map the state?
> pure representation
What does "pure representation" mean to you? I covered in the post that it sure as hell isn't a pure function of the state. And cannot be.
Did you miss the part where David Abramov conceded that point?
To elaborate a bit, React components aren’t always “pure” in strict FP sense of the word. They’re also not always functions (although we’re adding a stateful function API as a preferred alternative to classes soon). Support for local state and side effects is absolutely a core feature of React components and not something we avoid for “purity”.
> This [ui=f(state)] gets you a metric ton of advantages,
Well, yes. Like being a working UI, for example, which is why MVC is also structured this way.
But can you elaborate the specific advantages you believe the react approach gives us over, say, MVC?
The post elaborates that it would be really nice if UI were a pure function of the state. But it just isn't. And trying to pretend that it is might seemingly buy you some of those advantages, but at a huge cost.
