Request for clarification: What problem does this watch_it solve?

[pimvanderheijden]

Hi!

I got very excited about get_it when I finally worked myself into so much trouble with globals and singletons that I decided to look for a more structured solution. I immediately understood intuitively what it was about and why it meant be added value for my code. With watch_it, however, I'm clueless.

Yes I'm looking for a simple state management solution, to remove clutter and organize my code. Yes I could use such a solution probably to optimise some code paths and some rendering. But, does watch_it do any of this? How so? How is watch_it different from the other tools out there?

Thanks for clarifying, maybe it will create some nice content for the readme 😉 Cheers 🙌

[escamoteur]

Hi Pim,

get_it alone won't update your UI if any of your singletons changes. So either you have to use ValueListenableBuilders or StreamBuilders. Watch_it makes that much easier because you just watch any Listenable, Stream, Future and it will rebuild the widget with the new data? Cheers Thomas Am 31. Mai 2024, 15:23 +0200 schrieb Pim van der Heijden @.***>:

Hi! I got very excited about get_it when I finally worked myself into so much trouble with globals and singletons that I decided to look for a more structured solution. I immediately understood intuitively what it was about and why it meant be added value for my code. With watch_it, however, I'm clueless. Yes I'm looking for a simple state management solution, to remove clutter and organize my code. Yes I could use such a solution probably to optimise some code paths and some rendering. But, does watch_it do any of this? How so? How is watch_it different from the other tools out there? Thanks for clarifying, maybe it will create some nice content for the readme 😉 Cheers 🙌 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[pimvanderheijden]

Sorry but natively this already requires very little code, right? What’s the problem and why does watch_it solve it?

[escamoteur]

How do do it natively normally? Am 31. Mai 2024, 16:08 +0200 schrieb Pim van der Heijden @.***>:

Sorry but natively this already requires very little code, right? What’s the problem and why does watch_it solve it?

On Fri, 31 May 2024 at 15:28, escamoteur @.***> wrote:

Hi Pim,

get_it alone won't update your UI if any of your singletons changes. So either you have to use ValueListenableBuilders or StreamBuilders. Watch_it makes that much easier because you just watch any Listenable, Stream, Future and it will rebuild the widget with the new data? Cheers Thomas Am 31. Mai 2024, 15:23 +0200 schrieb Pim van der Heijden @.***>:

Hi! I got very excited about get_it when I finally worked myself into so much trouble with globals and singletons that I decided to look for a more structured solution. I immediately understood intuitively what it was about and why it meant be added value for my code. With watch_it, however, I'm clueless. Yes I'm looking for a simple state management solution, to remove clutter and organize my code. Yes I could use such a solution probably to optimise some code paths and some rendering. But, does watch_it do any of this? How so? How is watch_it different from the other tools out there? Thanks for clarifying, maybe it will create some nice content for the readme 😉 Cheers 🙌 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/escamoteur/watch_it/issues/31#issuecomment-2142166771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFL2SSUE4CWHFZNGPI6VSITZFB3GNAVCNFSM6AAAAABIS2CEW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBSGE3DMNZXGE . You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

Ok

class AppState with ChangeNotifier {
    String foo = bar”
}

in main() you do

var appState = AppState();

runApp(
    ChangeNotifierProvider(
        create: (context) {
            return appState;
        },
        child: MyApp(),
    ),
)

in MyApp's build function you do

@override
Widget build(BuildContext context) {
    var appState = context.watch<AppState>();
    return Scaffold(
      body: Text(appState.foo)
    )
}

Now when the value of foo changes, the Text gets rerendered.

[escamoteur]

Ah, you are using Provider. Which isn't a part of the Flutter framework itself. watch_it allows you the same without provider. Am 2. Juni 2024, 14:10 +0200 schrieb Pim van der Heijden @.***>:

Ok class AppState with ChangeNotifier { String foo = bar” } in main() you do var appState = AppState();

runApp( ChangeNotifierProvider( create: (context) { return appState; }, child: MyApp(), ), ) in MyApp's build function you do @override Widget build(BuildContext context) { var appState = context.watch(); return Scaffold( body: Text(appState.foo) ) } Now when the value of foo changes, the Text gets rerendered. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

Ah yes, great that clarifies, thanks.

And why should I use watch_it instead of provider?

[escamoteur]

Ok, that's the interesting question 😁

1. If you are already using provider you do not really need get_it. However a lot of people use both because you don't need a context with get_it so the use it in the non UI code
2. If you already use get_it to store your business objects it makes sense to use a state management that connects directly onto get_it 3.you don't need to clutter your widget tree with providers
3. It's a matter of taste which api you prefer. I try to build apis that are easy to use and intuitive. Am 2. Juni 2024, 14:17 +0200 schrieb Pim van der Heijden @.***>:

   Ah yes, great that clarifies, thanks. And why should I use watch_it instead of provider? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

1. I do need get_it for getting my AppState instance and other helper class instances outside of Widget contexts.
2. Thanks, very clear.
3. I'm not sure what clutter in my Widgets you mean. With provider I do:

   var foo = context.watch<AppState>().foo;

Whereas with watch_it I would do this for every value I have.

final foo = watchPropertyValue((AppState a) => a.foo);

4. Depends on the answer to 3. I would say

[escamoteur]

With cluttering I mean that you have to add a provider widget somewhere in your widget tree You can use the simple 'watch' method to watch a whole object that implements Listenable/ChangeNotifier so you don't have to watch every property separately. Check out the different watch functions Am 3. Juni 2024, 10:21 +0100 schrieb Pim van der Heijden @.***>:

1. I do need get_it for getting my AppState instance and other helper class instances outside of Widget contexts.
2. Thanks, very clear.
3. I'm not sure what clutter in my Widgets you mean. With provider I do:

var foo = context.watch().foo; Whereas with watch_it I would do this for every value I have. final foo = watchPropertyValue((AppState a) => a.foo);

4. Depends on the answer to 3. I would say

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

So the clutter we're talking about effectively is just the ChangeNotifierProvider here?

var appState = AppState();

runApp(
    ChangeNotifierProvider(
        create: (context) {
            return appState;
        },
        child: MyApp(),
    ),
)

[pimvanderheijden]

Besides a different API, watch_it is not focussed on making an app more cpu efficient? I mean, if it would be more performant than provider than that would be a clear benefit to me.

[escamoteur]

If you have only one provider that's probably not a big deal. If you provide multiple objects it can get a bit crowded 😉 Am 4. Juni 2024, 12:09 +0100 schrieb Pim van der Heijden @.***>:

So the clutter we're talking about effectively is just the ChangeNotifierProvider here? var appState = AppState();

runApp( ChangeNotifierProvider( create: (context) { return appState; }, child: MyApp(), ), ) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

all right then

[escamoteur]

Nope, I don't think that there is any performance benefits on either side. Watch_it offers some additional functions like pushScope, callOnce or onDispose which let's you do things in stateless widgets that would normally not be possible. But in general it's mostly a matter of taste. Am 4. Juni 2024, 12:12 +0100 schrieb Pim van der Heijden @.***>:

Besides a different API, watch_it is not focussed on making an app more cpu efficient? I mean, if it would be more performant than provider than that would be a clear benefit to me. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[pimvanderheijden]

Oooh that's nice. Thanks for the insightful conversation!