feat: ability to observe state directly via context.watch

[btrautmann]

Description

Oftentimes I am bitten by the fact that doing the following is not supported:

final state = context.select((MyState s) => s.canContinue);

Instead, I need to do:

final state = context.select((MyCubit c) => c.state.canContinue);

The former is a bit more ergonomic than the latter, and is something you can see done via StateNotifier (as mentioned in the README, sorry...no closer anchors).

Desired Solution

I haven't looked at bloc's code, so this might be dumb, but I would suspect that another Provider<T> could be shimmed in such that BOTH (the cubit and its state) are provided and the consumer can select which they want to observe.

Alternatives Considered

Me just dealing with it 💁‍♂️

Additional Context

You can see the original discussion RE: this issue in Discord.

[felangel]

Hey @btrautmann 👋
Thanks for opening an issue!

I agree that the ergonomics of context.select (as well as the other extension methods) could be greatly improved. The reason for the current API is that it just leverages the pkg:provider implementation to provide a unified API. I believe the StateNotifier example you're referencing uses pkg:riverpod but I'll take a closer look.

I think the best option is to introduce new extensions to avoid conflicting with pkg:provider and we'd just need to come up with some new names for context.read, context.select, and context.watch. Will think about it some more and any other ideas are welcome 👍

[saschaernst]

In order to create extensions to watch/select a state directly, you would have to type both the Bloc/Cubit and the state, which would defy the purpose of making the expression less verbose.