SwiftUI

MobX takes normal data (usually class properties) and makes it observable, via an annotation. That very much appears to be what the @State annotation in the Swift code is doing, though I don't know for sure.

setState is a totally special container for data; while it technically lives in a class member (this.state), it can only be modified via setState. It isn't observable, so much as setState just internally triggers a render directly.

useState is different because your state lives out somewhere in React's core framework, associated with your function only through a value and a callback. It doesn't live in your function's local scope itself, because it would get lost if it did. It's very weird and funky because the whole point of non-class components is for them to be pure functions which have no state. useState is this shortsighted workaround for that self-imposed limitation.

Redux, finally, is different because its new states are determined as a pure function of the current state and some change. It's the polar opposite of MobX's mutable-observables pattern. Neither is strictly better, but they're as different as can be.

> What's the difference between a class and a function with local state?

Practically nothing, especially since it is stored in objects and the code uses a lookup table to figure out which ones are part of your function's "this" (essentially), IIRC from reading the code. The similarity to how one implements objects/classes has been good for some laughs.

[EDIT] in "React Hooks" specifically, I mean.

Looking over the references and docs, this is pretty much the builder pattern to generate the view tree and data binding to update it.

It appears to be https://github.com/apple/swift/pull/25221, which doesn't yet have a public proposal.

I am still scratching my head why the 'some' keyword is needed/required for opaque types.

Eg. SquareButton and RoundButton are implementations of the Button (protocol).

You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to specify the word "some"

createPlayButton -> Button

instead of createPlayButton -> some Button

Am I missing something? It feels like the 'some' keyword is just there to help the compiler and not the users necessary

it seems like the equivalent of id in Objective-C. Basically just a surface re-arranging of names, but keeping the same concepts as in Objective-C

I feel Golang did better in this regards... (eg. not necessary distinguishing between protocols and super class-es, it is quacks like a duck, it is a duck)