Recently we took a deep dive into the new skeleton template included in the Flutter SDK. As noted in the article, one of the big missing pieces in the template is a scalable state management solution with dependency injection and data-binding.

Given that, we thought it would be informative to convert it to use a couple of popular state management libraries, specifically riverpod and GetItMixin.

Converting to riverpod

For some background, the skeleton template uses a ChangeNotifier based SettingsController and it passes that controller down through the tree to various widgets. To simulate that with riverpod, we’ll create 2 providers inside of main.dart. We also need to add a ProviderScope to the top of the tree:

void main() async {
  runApp(
    const ProviderScope(child: MyApp()),
  );
}

final settingsProvider = ChangeNotifierProvider((ref) => SettingsController(ref));
final settingsServiceProvider = Provider((ref) => SettingsService());

In the original template, SettingsController requires a SettingsService dependency be passed in via the constructor. With riverpod, the expected way to do something like this, is to pass a ref into the controller, and have the controller lookup it’s dependency using the ref.read method.

This looks something like:

class SettingsController with ChangeNotifier {
  SettingsController(this.ref);
  final Ref ref;
  SettingsService get _settingsService => ref.read(settingsServiceProvider);
 ...
}

The benefits of having SettingsManager look up the settings object rather than instantiating it itself, is that it becomes very easy for us to mock the SettingsService later if we want. This is typically known as the inversion of control principle.

View Binding

With the changes to the controller, we’re now ready to update the views. In the skeleton app there are two pages that access this SettingsController.themeData, they are MyApp and SettingsView.

MyApp.dart
In the original template, an AnimatedBuilder is used to rebuild the entire app anytime settings controller calls notifyListeners. With riverpod we can remove the AnimatedBuilder, and extend ConsumerWidget instead. ConsumerWidget has a 2nd parameter in it’s build method which is a ref we can use to watch one of our providers:

class MyApp extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final themeMode = ref.watch(settingsProvider.select((s) => s.themeMode));
    ...

Notice that the provider.select method here which allows us to bind only to the themeMode value instead of the entire ChangeNotifier.

SettingsView.dart
Like the MainApp, this view binds to themeMode. It also modifies it by calling updateThemeMode. To accomplish this, we switch to a ConsumerWidget, and use the watch and read methods respectively:

class SettingsView extends ConsumerWidget {
 ...
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final themeMode = ref.watch(settingsProvider.select((s) => s.themeMode));
    return Scaffold(
      body: Padding(
        child: DropdownButton<ThemeMode>(
          value: themeMode,
          onChanged: ref.read(settingsProvider).updateThemeMode,
          ...

Finishing Up

The final step to converting the template, is to load the settings before showing the app. The original template did this in main.dart, before calling runApp. Like this:

void main() async {
  final settingsController = SettingsController(SettingsService());
  await settingsController.loadSettings();
  runApp(MyApp(settingsController: settingsController));
}

This is a bit tricky to do with riverpod, as it requires you be inside of a Widget to obtain a ref. To do this, we converted MyApp to be a StatefulWidget, then used initState and a _hasSettingsLoaded flag to load the settings, before we show the actual app:

class _MyAppState extends ConsumerState<MyApp> {
  bool _hasSettingsLoaded = false;

  @override
  void initState() {
    ref.read(settingsProvider).loadSettings().then((_) {
      setState(() => _hasSettingsLoaded = true);
    });
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    if (_hasSettingsLoaded == false) return Container();
    final themeMode = ref.watch(settings.select((s) => s.themeMode));
    return MaterialApp(...);
   }
}

That’s it! The app is identical to before, but the property drilling is gone, and you can easily mock the settings service, or the controller if you need.

If you’d like, check out the full example on github.com.

Converting to GetItMixin

Another great DI + binding setup is GetIt and GetItMixin. If you’re not familiar with these packages, check out our post here for a quick dive into how they work.

Converting to GetIt is even easier than using riverpod. To get started, we need to register our singletons, which we’ll do in main.dart. Additionally, because GetIt has no requirement for a WidgetRef we can restore the original logic of loading settings inside of main, and we can revert MyApp to be stateless:

void main() async {
  registerSingletons();
  await settings.loadSettings();
  runApp(MyApp());
}

void registerSingletons() {
  GetIt.I.registerLazySingleton(() => SettingsController());
  GetIt.I.registerLazySingleton(() => SettingsService());
}
// Add some shortcuts methods so views can easily fetch controller
SettingsController get settings => GetIt.I.get<SettingsController>();

You may notice that our SettingsController no longer takes anything in it’s constructor. This is because GetIt does not require a ref when looking things up. Thus, SettingsController can be simplified to:

class SettingsController with ChangeNotifier {
  SettingsService get _settingsService => GetIt.I.get<SettingsService>();
  ...
}

Similar to the previous example with riverpod this service is easily swapped out for a different implementation later, making it very simple to mock.

Another way we could handle this, is to pass the service in via constructor as before, but use GetIt to look it up:

GetIt.I.registerLazySingleton(() => SettingsController(GetIt.I.get<SettingsService>()));

In some ways this is preferable, as it more clearly shows the dependencies that SettingsController has. But it’s a little harder to read and slightly more convoluted. In the name of simplicity we will keep it similar to the riverpod approach, and go with the previous example, where the controller request the service itself.

View Binding

The final thing we need to do, is update the ui views to bind to the themeMode. Again the two views we need to change are MyApp.dart and SettingsView.dart

MyApp.dart
We can bind to the themeMode value using a GetItMixin and the watchOnly method:

class MyApp extends StatelessWidget with GetItMixin {
  @override
  Widget build(BuildContext context) {
    final themeMode = watchOnly((SettingsController s) => s.themeMode);
    ...

In the above, watchOnly() allows us to bind only to the single property, and not to the entire ChangeNotifier. This is similar to provider.select().

SettingsView.dart

class SettingsView extends StatelessWidget with GetItMixin {
  @override
  Widget build(BuildContext context) {
    final themeMode = watchOnly((SettingsController s) => s.themeMode);
    return Scaffold(
      body: Padding(
        padding: const EdgeInsets.all(16),
        child: DropdownButton<ThemeMode>(
          value: themeMode,
          onChanged: settings.updateThemeMode,
          ...

Again we use GetItMixin and the watchOnly method to bind to data. To change the value we can just use the settings shortcut we defined earlier, and use the updateThemeMode method.

We’re done! Again the app is identical in functionality, but the services and managers are now easily mocked, and there is no more need for property drilling. Check out the full example on github.com.

As always, please let us know if you have any questions or comments below!

Need help building something cool in Flutter? We’d love to chat.