Inherited Widget to Signal

[rodydavis]

I have noticed in when using the Watch widget that if any inherited elements are used from the context it can cause unnecessary rerenders.

For some models like Theme and Media it would be nice to pull it out of the tree and map to a global or local signal. This of course would break any overrides but this widget could be used where you want to break out a model.

Consider the following:

final app = App();
...
final screen = Screen();
...
final widget = Watch((context) {
  final theme = Theme.of(context);
  return Text('Hello', style: theme.textTheme.bodyLarge);
});

This would rebuild the child forever if called even once. But really we want to rebuild when bodyLarge changes the value.

I wrote the following mapper:

class InheritedElementToSignal<T> extends StatefulWidget {
  const InheritedElementToSignal({
    super.key,
    required this.builder,
    required this.target,
    required this.child,
  });

  final Widget child;
  final Signal<T> target;
  final T Function(BuildContext) builder;

  @override
  State<InheritedElementToSignal<T>> createState() =>
      _InheritedElementToSignalState<T>();
}

class _InheritedElementToSignalState<T>
    extends State<InheritedElementToSignal<T>> {
  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    widget.target.value = widget.builder(context); // update with new value
  }

  @override
  Widget build(BuildContext context) {
    widget.builder(context); // subscribes to changes
    return widget.child;
  }
}

That can be used to pull the model out of the tree:

final theme = signal(ThemeData());

class App ... {
  ...
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      ...
      builder: (context, child) {
         return InheritedElementToSignal<ThemeData>(
            target: theme,
            builder: (context) => Theme.of(context),
            child: child!,
         );
      },
      home: ...
    );
  }
}
...
class Child ... {
  final bodyLarge = computed(() => theme.textTheme.bodyLarge);
  
  @override
  Widget build(BuildContext context) {
      return Text('Hello', style: bodyLarge);
  }
}

Now the Child will only rebuild when the selector changes and does not react to anything else. This also means there is one subscriber to the Theme class too.

Feedback

Really not sure what to call this new widget that would be included in signals_flutter.

Also maybe a MultiAdapter could be done to map to multiple signals on models from the context?

Related Flutter Issues

• Add a variant to context.dependOnInheritedWidget that removes the unused dependencies when the dependent no-longer depends on it flutter/flutter#106549
• Missing removeDependency on the InheritedElement flutter/flutter#128432
• Widget got rebuilt due to outdated dependencies flutter/flutter#12992

[Solido]

The single approach solve the Theme problem and it will probably be of great use when devs rely on their own InheritedWidget but I rather prefer your adapter approach. It may gather in one place all default Flutter requirements. I'm also interested to see if there a place for animation in this wrapper of if it required another specific piece of code.

At the end as a dev I would like to easily subscribe to explicit Flutter signals.
Theme is one, Ticker is too, Locales, LifeCycle events too.

We may have to introduce common ancestors widgets SignalApp or whatever parents to wraps that
avoiding explicit redefinition each time.

[rodydavis]

Exactly, and I am trying to avoid having a root to wrap with and not sure if it will be needed.

There is a AppLifeCycle signal (not yet published) that does subscribe once and can be used.

For animation that will be interesting since we will need to provide vsync and connect to the animation controllers. That is something I want to dive into though.

[Solido]

We can combine a specific widget SignalApp and SignalContainer

SignalApp(
  child ...
)


final theme = flutterSignalsContainer(ThemeData)
final lifecycle = flutterSignalsContainer(AppLifecycleListener)
etc

[rodydavis]

Oh that is really nice idea! That would require the widget to place in the tree, but I think would be a nice addition. Plus would take care of all the Flutter inherited models.

One issue I was facing is that some of the Flutter models (like ThemeData) are compound models under the hood and not an inherited model itself.

[Solido]

Bro imagine us working full time on this... we can get the work done :D

[drantunes]

I think it's not such a bad idea to include a Root widget to track signal mutations and enable more efficient updates. A package that does this and uses distributed states is "asp" or "rx_notifier".

What really frustrates me is the need to use builders for this granular reactivity. As more builders and widgets are added, the signals approach will look more like traditional approaches like MobX and others. This will make its adoption difficult, with questions like "what's the difference between a value notifier or mobX)"? That's why I believe that solid_dart didn't grow, as it already used builders from the beginning.

[rodydavis]

Yep agreed. That's why I also made the .watch(context) extension since it does not need builder and will rerun the nearest build method

[rodydavis]

Now that I have had time to think about it more, I don't think we need a widget at all. In fact just a single builder could do the work.

final theme = signal(ThemeData());

class App ... {
  ...
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      ...
      builder: (context, child) {
         theme.value = Theme.of(context);
         return child;
      },
      home: ...
    );
  }
}
...
class Child ... {
  final bodyLarge = computed(() => theme.textTheme.bodyLarge);
  
  @override
  Widget build(BuildContext context) {
      return Text('Hello', style: bodyLarge);
  }
}

So instead I think documentation would be the better solution here.

Also since signal skip updates if the value is the same this would also be a noop on objects that haven't changed and override ==.

[rodydavis]

The other nice thing about this approach is it can be done anywhere with Watch or Builder.

And if you needed to do something with the theme, media query or other info outside the widget tree with signals then it would be possible.

You could even return a computed signal that mutates the object, and insert it back in the tree with an override like Theme, Media

[Solido]

Why was InheritedElementToSignal required for?
Sure it's better if we don't have to introduce new classes and can tailor on needs.

[rodydavis]

My thought was to provide a mapper and a builder that didn't update the child.

[rodydavis]

Looking at the API docs, this is actually what I was needing regardless:
https://api.flutter.dev/flutter/material/MaterialApp/builder.html

[drantunes]

This API is very interesting. I generally use it for authentication reactivity, mainly because it sits above the navigation.

[rydmike]

Related to the mentioned observed ThemeData extra re-renders issue, might be the fact that ThemeData has broken value equality as soon any MaterialStateProperty in it, or any of its sub-themes, is defined. So its value equality may be returned as not equal, even when it is equal.

For more info, see flutter/flutter#89127 (comment)

[rodydavis]

That is why I am introducing a SignalsEquality override too.

But even if the theme data signal updates many times the computed signal targeting specific properties would be way less frequent