Hooks: Change UseState to be like react's use_state

[jkelleyrtp]

This PR modifies use_state to return (value, set_value) just like in React. This should make usestate easier to learn and easier to work with (direct matching, if/then/eq, etc).

More advanced usecases can use use_ref instead.

This is a very-much-breaking change - so the old UseState has been saved as "use_slot" with a deprecated tag, which we'll remove in the next release.

[t1m0t]

looks neat and sound to me

[WestXu]

My 2 cents. I doubt if this is a good decision.

The previous use_state returns only one variable, with .set() to set its value, which is simpler and more intuitive. The react way looks more like a hack to me. We don't have to mimic everything from react.

[jkelleyrtp]

My 2 cents. I doubt if this is a good decision.

The previous use_state returns only one variable, with .set() to set its value, which is simpler and more intuitive. The react way looks more like a hack to me. We don't have to mimic everything from react.

I feel like the most important question here is "messaging". Like, what should the signature of the hook say about how to use it?

The old "UseState" (the one-piece handle) is roughly the same with the new style as it was in the old style. It comes out as the second item in the tuple. We could even grab it out:

let name = use_state(&cx, || "bob").1;

match name.get() {
   "bob" => {},
   _ => {}
}

name.set("new_name");

There are a few challenges about these handles work in async, and the most reliable way of getting UseState working in async is to wrap it up behind a get/set interface.

Right now, the signature of use_state does not communicate that set_state has get/set/modify/make_mut etc. But, it does expose the value directly instead of keeping it locked behind a wrapper, which is much more intuitive than having .get or * all over your code to do simple thing.

[WestXu]

Oh right if that's the case. Thanks for the explaination.