Article on context drilling

[manuel-plavsic]

I am excited to share context drilling, a state-management pattern I have developed the past couple months. It is thought for large-scale codebases and it is compatible with this library.
I also wrote a companion article called State management patterns and their potential drawbacks.

Would love to get your insights. Questions are also welcome!

If you like this pattern, maybe we could mention it somewhere in the docs.

[nank1ro]

I read the article, thanks for mentioning solidart as a state management solution 💙
At first glance I understand that dependencies are not made explicit clearly. I'll give you a simple example, feel free to make changes if I misunderstand how it works.

Context drilling

class UserCtx {
 final user = createSignal<User?>(null);
 final isPremium = createSignal<bool>(false);
}

class ChildCtx {
 final UserCtx userCtx;
 final anotherState = createSignal();
}

// Assuming we have a bloc at the height of `ChildCtx` that only needs to know if the user is premium.
class SomeBloc {
 SomeBloc(this.childCtx);

 final ChildCtx childCtx;
  
  void someFn() {
    if (childCtx.userCtx.isPremium()) {
      // do something
    }
  }
}

SomeBloc can also access the user state even though it does not need it.

What I propose with solidart is simply:

class UserBloc {
  final user = createSignal<User?>(null);
  final isPremium = createSignal<bool>(false);
}

class ParentWidget extends StatelessWidget {
  const ParentWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Solid(
      providers: [
        SolidProvider(create: () => UserBloc()),
      ],
      child: const ChildWidget(),
    );
  }
}

class SomeBloc {
  SomeBloc({required this.isPremium});

  final Signal<bool> isPremium;
}

class ChildWidget extends StatelessWidget {
  const ChildWidget({super.key});

  @override
  Widget build(BuildContext context) {
    return Solid(
      providers: [
        SolidProvider(
          create: () => SomeBloc(
            isPremium: context.get<UserBloc>().isPremium,
          ),
        ),
      ],
      child: const Placeholder(),
    );
  }
}

As you can see the dependency has been made explicit correctly and SomeBloc can't access any other state.

[manuel-plavsic]

Hey, sorry if I reply only now. I just ported a side project from Riverpod to Solidart and wanted to test your library well before answering.

With context drilling, dependencies are not injected. That is right. The context objects are supposed to be passed down explicitly. This way, type safety is guaranteed. The fact that user can be accessed even though it is not needed is not really an issue. You can just ignore it. It is useful if descendants need it. However, if the subtree below some specific node does not need it at all, you can create a context object without user; that would be better.

When the Solid widget is preferable

There are cases where context drilling is not ideal. For example, it is much more convenient to use the Solid widget in combination with a map of id/signal pairs when dealing with design language and theme mode. E.g.:

class _ProvidersWrappingAppRouter extends StatelessWidget {
  const _ProvidersWrappingAppRouter();

  @override
  Widget build(BuildContext context) => Solid(
        signals: const {SignalIds.designLanguage: createDesignLanguageSignal},
        child: Solid(
          signals: const {SignalIds.themeMode: createThemeModeSignal},
          child: Builder(
            builder: (context) {
            // ...

and

Signal<ThemeMode> createThemeModeSignal() {
  const key = 'theme_mode'; // shared preferences key
  final themeModeSignal = createSignal<ThemeMode>(
    () {
      final themeModeString = sharedPreferences.getString(key);
      if (themeModeString == null) {
        logger.v('No $key key found in shared preferences');
        sharedPreferences.setString(key, ThemeMode.system.name);
        return ThemeMode.system;
      } else {
        logger
          ..v('$key key found in shared preferences with value: $themeModeString')
          ..v('Valid ThemeMode strings: ${ThemeMode.values.map((ui) => ui.name)}');
        if (ThemeMode.values.map((ui) => ui.name).contains(themeModeString)) {
          // The value inside shared preferences is valid.
          final loadedUi =
              ThemeMode.values.singleWhere((ui) => ui.name == themeModeString);
          return loadedUi;
        } else {
          // The value inside shared preferences is not valid.
          const resetThemeMode = ThemeMode.system;
          sharedPreferences.setString(key, resetThemeMode.name);
          return resetThemeMode;
        }
      }
    }(),
  );
  createEffect((dispose) {
    final themeMode = themeModeSignal();
    sharedPreferences.setString(key, themeMode.name);
  });
  return themeModeSignal;
}

createDesignLanguageSignal can be defined analogously.

Now, wherever you need the value of the ThemeMode signal, you can use a Solid widget, which I find convenient and the type-safety issue does not matter in this case, since the signal is defined on top of the widget tree.

When context drilling is preferable

You might find yourself creating some signals of that are not on top of the widget tree. E.g., calling context.get<Signal<SomeType>>(SignalIds.someType) might throw an exception. In these cases you may want to use a type-safe alternative to Solid, thus either classical prop drilling (for one or a few arguments) or context drilling if several props need to be passed down.

(NB: of course, the Solid widget also could have been used in these cases)

One of the advantages of context drilling is that if you change something in one of the context object, the IDE is gonna detect automatically if something broke or not. On the contrary, if you change one signal inserted in a Solid widget, you won't know if something is broken until you run into it, during runtime.

[nank1ro]

Would love to see a sample project using context drilling to understand pratically how it works.

I know that getting Solid signals throws at runtime, but I think this is acceptable and the ReadSignal feature is more important.
You may write an extension like:

extension GetSignalExt on BuildContext {
  Signal<T> getSignal<T>(Object id) {
    return get<Signal<T>>(id);
  }

  ReadSignal<T> getReadSignal<T>(Object id) {
    return get<ReadSignal<T>>(id);
  }
}

And simply use context.getSignal<SomeType>(SignalIds.someId).

I know this isn't really type-safe, in fact in my projects I tend to use SolidProviders more often.
I personally use Solid signals only for UI specific state, like themeMode or isScrollEnabled and stuff very specific to the UI. I like to think of the signals provided through the Solid widget as enhanced ValueNotifiers that live in the widget tree. Descendants can access or change the state (if isn't a ReadSignal).

Instead I use SolidProviders for business logic and place all the signals inside. If I change something that breaks, I can see it immediately from the LSP.

Context drilling seems to me to be an additional layer on top of the providers.
In any case, we are talking about design patterns here.
Design patterns depend on the use cases one has, how big the team is, and many other details.
There is no right and wrong answers here.

[nank1ro]

Your Ctx classes seems just Providers to me. I think we're talking about the same things. It's where you place your business logic too?

I don't know exactly what you meant with " the ReadSignal feature is more important"

Initially with the context.get<Type>(someId) extension I just returned a Signal<Type>.
Then I added the ReadSignal and I had to return T.

[manuel-plavsic]

I bet the solidart_lint feature will be very hard to implement. However, if you manage to do it, maybe you can also try making it possible to press CTRL+click (or some other key combination) and have the IDE bring you to the Solid widget where the provider/signal is defined? This would be very helpful in case of multiple providers of the same type.

[nank1ro]

This is a great suggestion, however I can add lints or assists but not something like Go to Definition, this is something not feasible as of now with custom_lint.

[manuel-plavsic]

Should one of us open an custom_lint issue already now, or do you want to see if you can implement the solidart_lint feature first?

[nank1ro]

I don't have any idea if this could be implemented in custom_lint, we may wait to check if I can implement the other lint first