Expose keys in useState

[timcreatedit]

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 a PageController page changes.

Widget build(BuildContext context) {
    final page = useState(pageController.initialPage);
    return PageView(
       controller: pageController,
       onPageChanged: (value) => page.value = value,
      //  ...
    );
}

This code works in principle, until pageController changes. This change will not get picked up by useState.

Describe the solution you'd like
Add optional keys to the useState hook.

final page = useState(pageController.initialPage, keys: [pageController]);
// ...

Describe alternatives you've considered
For the given example, one might suggest useListenable, but that will rebuild way too often.

Another option would be:

useEffect(() {
  page.value = pageController.initialValue;
}, [pageController]);

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 using ref and imperative modification using .state

[rrousselGit]

That's just how it is in React

[timcreatedit]

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

[timcreatedit]

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.

[rrousselGit]

I'd rather not have the core React hooks deviate too much from React.
We can add new hooks if need be

[andrerpena]

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 ❤️