You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the use_state hook, it would be more ergonomic if it only returned a struct rather than a tuple. It could be something like this:
#[derive(Clone)]pubstructStateHandle<T>{value:Rc<T>,}impl<T>StateHandle<T>{/// Update the state and trigger a rerender.pubfnset(value:T){}}impl<T>DerefforStateHandle<T>{typeTarget = T;fnderef(&self) -> &Self::Target{}}
This way, when cloning the state into a closure (for callbacks), we only need to clone one Rc instead of two which should improve performance and ergonomics.
Even though this is a major change, it would be better to change it now rather then when Hooks are officially released.
Questionnaire
I'm interested in fixing this myself but don't know where to start
I would like to fix and I have a solution
I don't have time to fix this right now, but maybe later
The text was updated successfully, but these errors were encountered:
Problem
This is a continuation of #1026 (comment)
For the
use_state
hook, it would be more ergonomic if it only returned a struct rather than a tuple. It could be something like this:It would be used like this:
This way, when cloning the state into a closure (for callbacks), we only need to clone one
Rc
instead of two which should improve performance and ergonomics.Even though this is a major change, it would be better to change it now rather then when Hooks are officially released.
Questionnaire
The text was updated successfully, but these errors were encountered: