.watch(context) vs Watch differences

[PaulHalliday]

I've been using signals/lite_ref in my project, and part of my implementation relies on overriding a scoped dependency to provide demo data for a "preview" mode of a particular set of widgets.

I ran into an issue where I had to replace my Watch for .watch(context) as it did not work correctly otherwise:

jinyus/lite_ref#24

As I figured that Watch and .watch(context) were interchangeable (and especially considering the docs suggest using Watch over .watch(context)), are there any other/specific scenarios where this is expected?

[rodydavis]

The biggest difference is that Watch will rebuild for inherited widgets listened instead the callback (theme/media) and is an effect.

.watch calls the subscribe method for a specific signal.

That being said I am very interested and will see if we can get some tests added to make sure they are aligned as much as possible (inherited widgets will rebuild a lot more outside of my control).

[rodydavis]

Could you share a minimal example for reference?

[gmkado]

@rodydavis I just started playing around with this library and was wondering the same thing. I didn't fully understand this phrase:

Watch will rebuild for inherited widgets listened instead the callback (theme/media) and is an effect.

What does this mean? That if an inherited widget changes higher in the tree it will rebuild the Watch widget? I would like to understand the differences, using .watch(context) is very convenient when trying to migrate from a different state management (in my case riverpod), but if Watch is the "recommended" way it makes me wonder when to use one over the other.