Open timcreatedit opened 2 months ago
That's just how it is in React
Meaning you would not want to touch it? I feel like an optional parameter is a nice escape hatch, while keeping the default behaviour consistent with react
Seems like #347 was also looking for this. At least a keys
parameter could've covered their use-case. And just to be clear I'm not advocating for changing any current behaviour, it makes sense for useState(x)
to not recompute when x
changes, since React does it that way. But having the option to opt-in by saying useState(x, keys: [x])
could be powerful.
It could also help alleviate some of the confusion, since the keys
parameter and its default value would be visible, so people could see that x
is not part of the hooks keys by default.
I'd rather not have the core React hooks deviate too much from React. We can add new hooks if need be
I see the reasoning for requesting this feature, and I have also wished React had the same. But I do agree with not deviating much from React. Apart from breaking expectations, it can happen that we're not seeing weird edge-cases that caused React to be like that in the first place.
btw, @rrousselGit , unrelated, but I love this library. I can't think of any better state manager. I wonder why hooks are not a core part of Flutter itself. Thanks for doing this ❤️
Is your feature request related to a problem? Please describe. Multiple times now I've been surprised by the fact that
useState
doesn't allow for setting custom keys that trigger a reevaluation of the state. A simple use-case is rebuilding a widget whenever aPageController
page changes.This code works in principle, until
pageController
changes. This change will not get picked up byuseState
.Describe the solution you'd like Add optional keys to the
useState
hook.Describe alternatives you've considered For the given example, one might suggest
useListenable
, but that will rebuild way too often.Another option would be:
However, this is verbose, imperative, and not really readable (it might also add an extra rebuild?).
Additional Context: Riverpods
StateProvider
is a nice example for a bridge between declarative re-evaluation usingref
and imperative modification using.state