[see-dante]

I don't dig what they're doing, but I do kind of like the idea of a deconstructed getter/setter:

[ get, set ] = getterSetter(defaultValue)

as a wrapper around some stateful, immutable value (mutating the result of the get won't be tracked, that is)

[dceddia]

That's pretty much what useState does. (or maybe you were already saying you liked that -- sorry, if that's what you meant) The only difference being that the "getter" has already been "executed" in a way: useState returns a value and a setter. Changing the value won't get tracked, and a call to the setter will overwrite the old value and re-render.

[see-dante]

Yeah -- I'm saying it's dubious that there's magic here "doing the setState queue for you" -- notice the function call isn't bound and there's no passing of "this", so it's gotta' got some magic under the hood with some global context.

I do, however, like the concept for the react style of render -- being able to grab a getter/setter from that is awesome. They can remove the magic by simply doing:

const [getter, setter] = this.useState(...)

[acemarke]

It's nothing more than React already knowing exactly _which_ component it's working on rendering. See my other comment here: https://news.ycombinator.com/item?id=18306957