In this article I continue explaining my ways of using bloc for state management in Flutter. Just as before, I will be writing based on my personal preferences and coding style.

🚨 This article will assume you have read the first article.

Providing blocs

In the previous article I explained that I’ve made a rule when it comes to consuming blocs. To recap, only destination widgets are allowed to consume blocs.

For providing blocs, I have a similar rule. Blocs are provided only in the following two locations:

Destination Widgets

While destination widgets can consume blocs, they are also allowed to provide other blocs. So why would we want to do this?

Let’s say we are creating a questionnaire app where users can answer different types of questions, like free-text, multiple-choice, rating, etc.

Next, imagine we have the following destination in our app: /questionnaire/<questionnaire-id>/<question-number>.

The first part tells us we’re doing a questionnaire, the second part tells us which one, and the last part tells us which question we’re at. So when we’re on page /questionnaire/12/4, it means we’re at question 4 of questionnaire 12.

This page shows us a question, so we’re on the QuestionPage. To back up this page, we need a bloc, which we would call QuestionBloc (or QuestionCubit if you use cubits), which holds QuestionState.

QuestionState will have the following familiar subtypes, like QuestionInitial, QuestionLoading, QuestionLoaded, and QuestionError. When the state is QuestionLoaded, it will hold the Question object, which in turn can also be one of few subtypes like, FreeTextQuestion, MultipleChoiceQuestion, RatingQuestion, etc.

The QuestionPage could look something like this:

Widget build(BuildContext context) {
  return BlocBuilder<QuestionBloc, QuestionState>(
    builder(context, state) => switch(state) {
      QuestionInitial() => _Loading(),
      QuestionLoading() => _loading(),
      QuestionLoaded(:final question) => _Loaded(question),
      QuestionError(:final error) => _Error(error),
    }
  );
}

The fact that our loaded object (Question) can be all these different kinds of subtypes, is what would make handling this in the QuestionPage and QuestionBloc complex and messy. There would be a lot of logic just for checking the current type of the question on many occasions, like when showing the actual question or answering a question.

Instead, what we can do, is simply delegate the responsibility to question-specific blocs. By creating a bloc for each type of question, we eliminate the need for type checks, because we only have to do that once at the point of delegation.

So now we basically turn the QuestionPage into a wrapper page, whose only responsibility is loading the question, and then delegate is to the correct question-specific bloc, like so:

Widget build(BuildContext context) {
  return BlocBuilder<QuestionBloc, QuestionState>(
    builder(context, state) => switch(state) {
      QuestionInitial() => _Loading(),
      QuestionLoading() => _loading(),
      QuestionLoaded(:final question) => switch(question){
        FreeTextQuestion() => BlocProvider<FreeTextQuestionBloc>(
          create: (context) => serviceLocator.create(),
          child: FreeTextQuestionPage(),
        ),
        MultipleChoiceQuestion() => BlocProvider<MultipleChoiceQuestionBloc>(
          create: (context) => serviceLocator.create(),
          child: MultipleChoiceQuestionPage(),
        ),
        RatingQuestion() => BlocProvider<RatingQuestionBloc>(
          create: (context) => serviceLocator.create(),
          child: RatingQuestionPage(),
        ),
        // etc...
      },
      QuestionError(:final error) => _Error(error),
    }
  );
}

And thus, we end up with multiple simple-to-deal-with blocs, instead of a behemoth class that grows with every new type of question.

Router

The other location where I provide blocs is in my router configuration.

For my apps I’m using the go_router package. I’m not going to explain here how go_router works, but I will show you how and why I started providing blocs in it’s configuration.

Take a look at this example router configuration for a todo app:

final todoRouter = GoRouter(
  routes: [
    // This is the root route which shows the list of Todo's
    GoRoute(
      path: '/',
      builder: (context, state) => BlocProvider<TodoListBloc>(
        create: (context) => serviceLocator.get(),
        child: TodoListPage(),
      ),
      routes: [
        // This is the first sub-route, which shows an empty detail page.
        // This will be shown when the user presses the + button.
        GoRoute(
          path: 'new',
          // Here we simply provide a new instance of the TodoDetailBloc.
          builder: (context, state) => BlocProvider<TodoDetailBloc>(
            create: (context) => serviceLocator.get(),
            child: TodoDetailPage(),
          ),
        ),
        // This is the second sub-route, which shows a selected todo.
        // This will be shown when the user presses an existing todo.
        GoRoute(
          path: ':id',
          // Here we also create a new instance of the TodoDetailBloc,
          // but we will also call the `load` function on it with the 'id'
          // that has been passed.
          builder: (context, state) => BlocProvider<TodoDetailBloc>(
            create: (context) => serviceLocator.get(state.)..load(
              id: state.pathParameters['id'],
            ),
            child: TodoDetailPage(),
          ),
        ),
      ],
    ),
  ],
);

As you can see, every route will first provide the bloc to be used, calling functions when necessary. When I provide the blocs like this, there is no need for me to add any parameters or logic to the widgets like the TodoListPage and TodoDetailPage. They now only need to consume whatever bloc is provided above them in the widget tree.

Just like with the example earlier with the destination widget, the router is responsible for delegating, thus providing the correct bloc and page.

Updating state

When managing state, you will often update and transition state objects. These mutations often come with a set of rules. Like when we’re in the initial state of the bloc, the only next possible state can be loading or when we’re in the loading state, the only possible follow-up states are either loaded or error.

We can use our knowledge of these possible mutations and create specific mutation functions. When I want to create these kind of functions, I will do so by creating extensions for every subtype.

Let’s take a look at an example for the initial state from a login page:

// LoginInitial means the user is filling in the form (username + password).
extension LoginInitialExt on LoginInitial {

  // The user has updated the username field
  LoginInitial applyUsername(String username) {
    return copyWith(username: username);
  }

  // The user has updated the password field
  LoginInitial applyPassword(String password) {
    return copyWith(password: password);
  }

  // The user has submitted the login form
  LoginLoading applySubmit() {
    return LoginLoading(
      username: username,
    );
  }
}

Here the functions clearly tell you what the LoginInitial state is capable off. It can update itself when form-fields are updated, or transition into LoginLoading when the form has been submitted.

The bloc or cubit can now call these functions instead of having to contain all the logic for all the different states and transitions, like this:

// Called every time the username field is updated
void updateUsername(String username) {
  final currentState = state;
  switch(currentState) {
    // When the currentState is LoginInitial, we can update the state.
    case LoginInitial():
      final newState = currentState.applyUsername(username);
      emit(newState);
    // Also, when login failed, we should be able to enter a new username.
    case LoginError():
      final newState = currentState.applyUsername(username);
      emit(newState);
    // Any other state should not call this, so we can ignore it.
    default:
  }
}

We have separated the concerns for updating the state into two parts:

1. The bloc/cubit is responsible for determining in which state which mutation can take place. It will then call the mutation function.
2. The extensions contain the implementation of the mutation functions which are responsible for the actual mutation of the state.

Creating blocs

You might have seen earlier in this article, that I’m using a service locator to instantiate blocs/cubits. I use a package for this called get_it, but you can also use an alternative like ioc_container, or write something yourself.

In the main.dart, I will setup get_it so that it can return a new instance of a bloc when requested:

// Make GetIt globally available
final serviceLocator = GetIt.instance;

void main() {
  // From repositories we only have a single instance which will be
  // shared across blocs.
  final todoRepo = TodoRepo();

  // Register factories for the blocs
  serviceLocator.registerFactory<TodoListBloc>(
    () => TodoListBloc(todoRepo: todoRepo),
  );
  serviceLocator.registerFactory<TodoDeetailBloc>(
    () => TodoDetailBloc(todoRepo: todoRepo),
  );
}

And now we can simply request a new instance by using:

serviceLocator.get<TodoDetailBloc>();

…in BlocProviders.

Syncing blocs

Sometimes your app has pages that need to share information. Like when you have an app with product which can be favorited. Both the ProductListViewPage as the FavoriteProductsPage should be updated whenever a product is (un)favorited.

The first thing I want to mention about this is, that blocs should NOT be connected to one-another, as per documentation:

Because blocs expose streams, it may be tempting to make a bloc which listens to another bloc. You should not do this.
- docs

Blocs and cubits should only be updated by the repositories they depend on, or events/functions triggered from the UI layer.

Coming back to the product app example, where both the ProductListViewPage as the FavoriteProductsPage rely on the favorited products. The ProductListViewPage should show a filled heart for product that already have been favorited and FavoriteProductsPage should just show all the favorited products.

This means both the ProductListViewCubit and the FavoriteProductsCubit will have a dependency on the (same) FavoritesRepository, which ideally would expose a stream of the currently favorited products.

Both cubits can subscribe to this stream and trigger (private) functions to update the state. An example:

class FavoriteProductsCubit extends Cubit<FavoriteProductsState> {
  FavoriteProductsCubit(this._favoritesRepo) : super(FavoriteProductsState.initial()) {
    // We can put the state in loading because we're starting to listen for
    // favorites right away.
    emit(FavoriteProductsState.loading());
    // Here we subscribe on the favorites stream from the FavoritesRepository
    // and pass in a private function to handle the updates.
    _favoritesRepoSubscription = _favoritesRepo.favorites.listen(_onFavoritesUpdated);
  }

  final FavoritesRepository _favoritesRepo;
  final StreamSubscription? _favoritesRepoSubscription;

  // The function that is called every time the list of favorites changes.
  void _onFavoritesUpdated(List<Favorite> favorites) {
    final currentState = state;
    switch(currenState) {
      case FavoriteProductsLoading():
        // This mutation will transition the state from FavoriteProductsLoading
        // to FavoriteProductsLoaded.
        // The actual mutating is delegated to mutation functions as explained
        // earlier.
        final newState = currentState.applyFavorites(favorites);
        emit(newState);

      // If the favorites are updated and we were already looking at the list
      // we still want to update the list when it changes.
      case FavoriteProductsLoaded():
        final newState = currentState.applyFavorites(favorites);
        emit(newState);
      default:
    }
  }

  // Favorite the given product. Only available when state is loaded.
  void favoriteProduct(Product product) {
    final currentState = state;
    switch(currenState) {
      case FavoriteProductsLoaded():
        // We call the repository to update the 'data'.
        _favoritesRepo.favorite(product);
        // We don't have to update the state here, because the update of the
        // repository will trigger the listener, which will cause the state
        // be updated.
        // This way we keep a nice unidirectional data-flow.
      default:
    }
  }
  
  // Unfavorite the given product. Only available when state is loaded.
  void unfavoriteProduct(Product product) {
    final currentState = state;
    switch(currenState) {
      case FavoriteProductsLoaded():    
        _favoritesRepo.unfavorite(product);
      default:
    }
  }

  void close() {
    // Always close the subscriptions!
    _favoritesRepoSubscription?.cancel();
    super.close();
  }
}

In this example for the FavoriteProductsCubit a few interesting things are happening. We rely on the FavoritesRepository for the latest favorites data. So, when an favoriteProduct/unfavoriteProduct function is called, we do not need to update the state in the function itself. This is because our action will cause the FavoritesRepository to be updated. This will update the stream that we are listening to, which in it’s turn will call the _onFavoritesUpdated listener function resulting in the new, up-to-date, state.

Because we’re putting the FavoritesRepository in charge of the data, it becomes a single source of truth and both cubits can stay in sync without having to rely on one-another!

Conclusion

In this article I’ve given some more advanced ways in how I use bloc in my applications. We’ve covered:

1. The way that I’m providing blocs in destination widgets and via go_router.
2. The way I’m updating state with the use of mutation functions, and how they result in a nice way to separate concerns.
3. How I create blocs with the help of get_it.
4. And how I keep my blocs in sync by relying on repositories to be the single source of truth.

Again, I hope that these articles are interesting or even helpful. If you do like this format, where I write about how I deal with real-life scenarios and use-cases, please leave some claps 👏 (the more the better 😉). If you have any questions, or suggestions, leave a comment below👇! Thank you! 🙏

🚨 This article will assume you have at least some basic knowledge of the flutter_bloc package. For learning on how to get started with flutter_bloc, please refer to the docs.

💡 In this article I will mostly speak of blocs, but these can easily be substituted by cubits.

Bloc feat. Freezed

Freezed is a package that goes very well with flutter_bloc. If you don’t know what freezed is, you are missing out!

️️️️💡 Freezed basically allows you to write super-charged (data) classes. All you have to do is define the properties for your class and freezed can generate things like toString, hashcode, operator == and copyWith methods for you.

The bloc documentation describes two ways of creating state objects. The first one is by using subclasses, where every subclass represents a state the state object can be in.

sealed class CounterState {}
final class CounterInitial extends CounterState {}
final class CounterLoading extends CounterState {}
final class CounterLoaded extends CounterState {
  required int count,
}
final class CounterError extends CounterState {}

The second is by using a single class where the different states are represented by the status field.

enum CounterStatus { initial, loading, loaded, error }
final class CounterState {
  const CounterState({this.status = CounterStatus.initial});
  final CounterStatus status;
  final int? count;
}

I prefer the first option. Using subclasses allows me to be mutual exclusive, so I never have to worry if a field of the state can or shouldn’t be accessed. In the single class example, the count field will always be accessible, while it probably only should be read when the state is loaded.

Unfortunately, creating that many subclasses by hand can be quite cumbersome. Specially when they get (and share) a lot of fields.

Lucky for us, there are freezed union types!

Union types

One of the best things of freezed is the support for union types. You can think of a union as a class that can have different representations, just like our state object.

I can create the same state object with freezed, like this:

@freezed
sealed class CounterState with _$CounterState {
  const factory CounterState.initial() = CounterInitial;
  const factory CounterState.loading() = CounterLoading;
  const factory CounterState.Loaded({
    required int count,
  }) = CounterLoaded;
  const factory CounterState.error() = CounterError;
}

It looks very similar to the original example, but under the hood, freezed will generate code that makes our lives so much easier.

Using our state object

Now that we have a nice state object to work with, let’s use it. We are going to implement an increment method for our CounterCubit:

void increment() {
  // We have to store the current state into a local variable in
  // order for Dart to be able to downcast it.
  final currentState = state;
  switch(currentState) {
    // We can only increment when the state is CounterLoaded
    case CounterLoaded(:final count):
      emit(currentState.copyWith(count: count + 1));
    // Anything else will just be ignored
    default:
  }
}

As you can see, we’re able to use the generated .copyWith method to easily turn the current state into the new state.

️️ ️ 💡 In this example I’m using the new Dart pattern matching functionality that came with Dart 3. Freezed is also able to generate .map/.when methods for us that can basically do the same. While I prefer the map/when syntax, I’m not using it since it’s been discouraged by the author.

Still, freezed just made our lives a bit… cooler 😎.

Custom listeners

If you ever had to fire off one-off actions based on state changes, like navigating, or showing a snackbar, you will most likely have used a BlocListener.

But when you have to listen to a bunch of different state changes, the code can become quite cluttered.

Let’s take a look at the following example:

Widget build(BuildContext context) {
  return MultiBlocListener(
    listeners: [
      // 1. When the user has successfully logged in, navigate to home
      BlocListener<LoginBloc, LoginState>(
        // Only trigger when state transitions into loginSuccess
        listenWhen: (previousState, state) => 
            previousState is! LoginSuccess && state is LoginSuccess,
        listener: (context, state) => context.go('/home/${state.user.id}'),
      ),
      // 2. Show a dialog when the user account needs to be verified
      BlocListener<LoginBloc, LoginState>(
        // Only trigger when state transitions into loginSuccessUnverified
        listenWhen: (previousState, state) => 
          previousState is! LoginSuccessUnverified && state is LoginSuccessUnverified,
        listener: (context, state) => context.showVerificationDialog(),
      ),
    ],
    child: BlocBuilder<LoginBloc, LoginState>(
      builder: (context, state) {
        // UI CODE HERE
      },
    ),
  );
}

As you can see, there is quite a bit of logic in our UI file and it’s making quite a mess. I also felt the need to add comments to make it more clear to what each listener does.

But, we can easily make this better bij creating our own listeners by extending BlocListener!

class LoginSuccessListener extends BlocListener<LoginBloc, LoginState> {
  LoginSuccessListener(
    void Function(BuildContext context, LoginState state) listener,
  {
      super.child, 
  }) : super(
    buildWhen: (previousState, state) => 
        previousState is! LoginSuccess && state is LoginSuccess,
    listener: listener,
  );
}

Doing this has several benefits:

1. The name of the listener tells you what it does.
2. The buildWhen logic is nicely tucked away.
3. The new listener is easily reusable.

If we do the same thing for the other listener, we can clean up our UI like so:

Widget build(BuildContext context) {
  return MultiBlocListener(
    listeners: [
      LoginSuccessListener(
          (context, state) => context.go('/home/${state.user.id}'),
      LoginSuccessUnverifiedListener(
          (context) => context.showVerificationDialog()),
    ],
    child: BlocBuilder<LoginBloc, LoginState>(
      builder: (context, state) {
        // UI CODE HERE
      },
    ),
  );
}

That’s a lot better now, isn’t it?

Consuming blocs

Even though blocs are a crucial part of my applications, I don’t want them to be mixed in with all the UI code. Therefor I have one very strict rule:

Only destination widgets should deal with blocs!

Widgets that are the root of a page, screen, dialog, bottomsheet, etc is what I call a destination widget. These are widgets that you use in your router, or your navigation methods, for example:

Navigator.push(context, MaterialPageRoute(builder: (context) => HomePage()));

Here HomePage can be considered a destination widget.

So, only destination widgets deal with blocs. They will orchestrate the content on the screen.

Most of the time I will split up a destination widget into several private widgets that can represent each state. If the file is getting too big for your taste, you could break the file up in their own (part) files.

Let’s take a look at a full example.

class TodoListPage extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    // We start with the listeners for this page.
    return MultiBlocListener(
      listeners: [
        TodoRemovedListener((context) => context.showTodoRemovedSnackbar()),
        TodoAddedListener((context) => context.showTodoAddedSnackbar()),
      ],
      // Then we add the builder.
      child: BlocBuilder<TodoListBloc, TodoListState>(
        builder: (context, state) => switch(state) {
          
          // Often initial and loading can use the same widget.
          TodoListInitial() => _Loading(),
          TodoListLoading() => _Loading(),

          // When the state is loaded, we want to show the todos.
          TodoListLoaded(:final todos) => _Loaded(todos),

          // When we are refreshing, it might be nice to keep showing the
          // current todos, but we also tell the widget to indicate refreshing.
          TodoListRefreshing(:final todos) => _Loaded(todos, isRefreshing: true),
          
          // If loading went wrong, we can show an error.
          TodoListError(:final error) => _Error(error),
        }
      ),
    ),
  }
}

class _Loading extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
     // Show loading screen
  }
}

class _Loaded extends StatelessWidget {
  _Loaded(this.todos, {this.isRefreshing = false});

  final List<Todo> todos;
  final bool isRefreshing;

  @override
  Widget build(BuildContext context) {
     // Show Todo List and optional a refreshing indicator
     // If the todos are empty, maybe even show an empty list message
  }
}

class _Error extends StatelessWidget {
  _Error(this.error);

  final Error error;

  @override
  Widget build(BuildContext context) {
     // Show error screen
  }
}

I think this looks pretty tight! 🔥

💡 The reason I limit the amount of widgets that may access blocs, is because this way, I know exactly where things can go wrong. It also allows for all the other, non-destination, widgets to be as ‘dumb’ as possible.

Conclusion

In this article I’ve shown you how I use bloc in my applications.

• First I talked about the freezed package, and how we can benefit from it in combination with bloc.
• Second, I showed you what I do to move BlocListener logic out of the UI by creating custom BlocListeners with more descriptive names.
• Lastly, I explained which widgets, that I call destination widgets, I allow to have access to blocs, and why.

I hope you found this article useful/interesting. If you like more of these please let me know by clapping 👏. If you have specific things you’d like to see, please leave a comment👇! Thanks! 🙏

Continue reading: Part II

In Flutter’s ThemeData you’ll find all the things you need to style you app based on the material design guidelines.
There are color schemes, text themes and even styling for material components like the Floating Action Button.

But what if you want to define your own styling, for your custom Widget for example?
If you, just like me, have tried to do this, you most likely found out that this is not that easy to do.

But I found a way to do this which I would like to share with you!

Solution goals

The solution that I wanted to use should have the following three properties:

A. One theme to rule them all.
The goal is to have just one ‘theme’ object so you won’t end up with themes that get out of sync.

B. Theme should be context based
I want to have the theme come from context so I can ‘scope’ the theme to certain parts of the app as I please. This also means that when the context changes, I can adapt to it.

C. Our solution should be backwards compatible with the old theme.
We don’t want the default behavior to break and mess with the material components Flutter provides.

Solutions used by the community

I’ve looked and asked around on the internet to see which solutions the community is using. Two solutions came up the most:

Using extension methods.

I think this is the one I saw the most. We could use extension methods to add properties to ThemeData. The nice part is, that we don’t have to change the way we access the Theme. We can still use the normal Theme.of(context).
But, the drawback is that these properties are NOT instance properties which means that it’s not as dynamic.
This violates goal B.

extension ExtendedThemeData on ThemeData {
  Color get myCustomColor => Colors.yellow;
}

Create another Theme-like object.

We could also just create our own separate object which would hold our custom properties. We could use an InheritedWidget (or a package like provider/riverpod) to access it from the context.
But now we have to keep track, and if needed, switch between multiple theme related objects, which violates goal A.

class CustomTheme {
  final Color myCustomColor;

  const CustomTheme({required this.myCustomColor});
}

Using extension methods was just not going to cut it. The only way this could become more dynamic would mean it should probably need some logic per property and I want the theme data to be as static as possible.

However, using a separate object does allow us to be dynamic. All I had to do was find a way to keep our custom theme in sync with the default theme.

My solution

So I liked the approach of creating a separate object, but hated the idea of having to manage multiple types of theme objects.
Luckily we can fix it, and all we have to do is create three simple classes…

MyThemeData

We start off by defining our own ThemeData class. You can name it whatever you like. It could be something generic, like AppThemeData, or something very app specific like WeatherAppThemeData. I recommend to end the name with ‘Data’. For this example I will call this class MyThemeData.

This class will hold all of your custom properties, like colors, spacings, or styling for complete widgets. One important thing is that it also includes a field to hold the default ThemeData. Notice that the themeData field is late and NOT final. This makes it easier to swap out later on to get the right behavior when accessing the default ThemeData.
Alternatively you could create a copyWith method (or use the copy_with_annotation package).

class MyThemeData {
  late ThemeData themeData; // important!
  final Color myCustomColor;
  final CustomWidgetData customWidget;

  MyThemeData({
    required this.themeData,
    required this.myCustomColor,
    required this.customWidget,
  });
}

class CustomWidgetData {
  final Color backgroundColor;
  final BoxShape shape;

  const CustomWidgetData({
    required this.backgroundColor,
    required this.shape,
});

That’s it, just add all the properties you need.

InheritedMyTheme

We need a way to provide our newMyThemeData objects. We are going to use an InheritedWidget for this.

Because I named my ThemeData object MyThemeData, I will name this widget InheritedMyTheme. Again, it’s just a very simple, but powerful, class.
All it has to do is provide the MyThemeData that we want the underlying branches of the widget tree to use.

class InheritedMyTheme extends InheritedWidget {
  final MyThemeData data;

  const InheritedMyTheme({
    required this.data,
    required Widget child,
    Key? key,
  }):super(key: key, child: child,);

  @override
  bool updateShouldNotify(covariant InheritedWidget oldWidget) =>     
      oldWidget != this;
}

MyTheme

Finally, we are going to create the widget that we need to actually use our custom theme in our app.

It will be a StatelessWidget that we can put anywhere in the widget tree where we want to use our new custom theme. We will support both light and dark mode based on the OS configuration.

Another very important task of this widget is providing a normal Theme widget so it remains compatible, and so both theme objects stay in sync.

We will also add a convenient method so we can simple access our theme with MyTheme.of(context). You’ll notice that we are getting the themeData as well.
This is needed to make sure that Theme.of(context) and MyTheme.of(context).themeData will return the same values.

class MyTheme extends StatelessWidget {
  final MyThemeData light;
  final MyThemeData dark;
  final Widget child;

  const MyTheme({
    required this.light,
    required this.dark,
    required this.child,
    Key? key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final brightness = MediaQuery.of(context).platformBrightness;
    final data = brightness == Brightness.light ? light : dark;
     
    return InheritedMyTheme(
      data: data,
      child: Theme(
        data: data.themeData,
        child: child,
      ),
    );
  }

  static MyThemeData of(BuildContext context){
    final theme = Theme.of(context);

    return context
        .dependOnInheritedWidgetOfExactType<InheritedMyTheme>()!
        .data..themeData = theme;
  }
}

This completes the solution. Let’s use it!

Usage

We’ve created multiple classes. Let’s see how we use them!

Create the themes

First we will create a light and a dark theme. To keep it simple I will just use ThemeData.light() and ThemeData.dark(). But since these are just the normal ThemeData objects you can configure them however you want.

final myLightTheme = MyThemeData(
  themeData: ThemeData.light(),
  myCustomColor: Colors.lightBlue,
  customWidget: CustomWidgetData(
    backgroundColor: Colors.lightGreen,
    shape: BoxShape.circle,
  ),
);

final myDarkTheme = MyThemeData(
  themeData: ThemeData.dark(),
  myCustomColor: Colors.blue,
  customWidget: CustomWidgetData(
    backgroundColor: Colors.green,
    shape: BoxShape.circle,
  ),
);

Using the themes

Usually you would provide your ‘main’ theme in the theme and darkTheme fields of theMaterialApp. But since our new theme is not a subtype of ThemeData, we can’t do that here.

We will use the builder field of MaterialApp which will allow us to put our MyTheme widget just above the Navigator, which is exactly what we want because then our theme gets used by all the pages we navigate to.

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);
  
  @override  
  Widget build(BuildContext context) {
    return MaterialApp(
      home: const Content(),
      builder: (context, child) => MyTheme(
        light: myLightTheme,
        dark: myDarkTheme,
        child: child ?? ErrorWidget('Child needed!'),       
      ),
    );
  }
}

That’s all! We can now access our theme anywhere in the app, simply by calling MyTheme.of(context).

Remember the CustomWidgetData form earlier?
Let’s see how our CustomWidget could use our theme!

class CustomWidget extends StatelessWidget {
  
  @override
  Widget build(BuildContext context) {
    final myTheme = MyTheme.of(context);

    return Container(
      decoration: BoxDecoration(
        color: myTheme.customWidget.backgroundColor,
        shape: myTheme.customWidget.shape,
      ),
      child: Text(
        'I use the default ThemeData',
        style: myTheme.themeData.textTheme.headline1,
      ),
    );
  }
}

And that’s a wrap! We’re done.

Example

You can checkout this basic example I made on dartpad.

Conclusion

We’ve created our own solution to extend the theming in Flutter.
For this we’ve created a custom ThemeData class, an InheritedWidget and a StatelessWidget that will help us pass around our custom theme through context to stay dynamic.

By wrapping and providing the existing ThemeData we are able to keep both new and old themes in sync, which makes switching themes easy and concise, but also makes it compatible with the existing Theme.

Extra

Even though the amount of code we’ve written isn’t that much, it might get a bit annoying to write it for every project. There are also a few things that could be improved upon, but would require even more boilerplate code.

Therefor I started working on a package that I plan to release soon that would hopefully make things a bit easier.
So stay tuned!

Update (8 February 2022)

I’ve create a package called ext_theme on pub.dev that implements my solution. It will generate all the necessary classes for you based on some simple configuration.
I haven’t spend much time yet cleaning it up, but it does work.
I’m already using it in my own project.

GitHub - SEGVeenstra/ext_theme: Extended themes for Flutter

Extending the Flutter Theme. was originally published in Pinch.nl on Medium, where people are continuing the conversation by highlighting and responding to this story.

How it al began

My professional software development career started back in februari 2016. I had just graduated and got hired by one of the companies where I’d done my internship. It’s a great company full of great people. I had a great time.

For the first couple of years I was absorbing the knowledge and skills of my superiors. Eventually I developed my own style and preferences towards software development.

Flutter

At the end of 2018, I discovered Flutter, a new Cross-Platform UI Framework from Google. I fell in love with it right away and I thought it would be the perfect replacement for the framework that we were currently using.

The following years I played around with Flutter and even organized workshops for my colleagues to show them the potential of this new amazing framework.

We even did a production project with great success. I was sure I’d proven Flutter. But I was wrong…

Mind made up

For me it was completely clear, we needed to use Flutter. It would be better for the company as most of the developers where fett up with the current framework we used.

Half way through 2020 it became clear we would not be adopting Flutter any time soon, I realized I might had to look elsewhere if I wanted to continue working with it. Playing around with it in my spare time just wouldn’t be enough if I wanted to become and expert.

The opportunity

Just a few months after I had decided to start looking around for a Flutter position, I was contacted by a recruiter.
He was looking for Flutter developers for a company which had recently adopted Flutter and wanted to start a Flutter team.

A tough decision

Full time working with Flutter?! That sounded amazing!
But the company was 189 kilometers away, so I would work remotely. Ever since COVID-19 we’d been working a lot from home, but I couldn’t really get used to it…

I did the interview anyway.
It went well, I heard a lot of things I liked that had gotten me all exited.
After giving it some thought I realized I just had to do this.
Even if I had to give up an amazing company… and had to work fully remote.

As of January 2021 I would be a full time Flutter developer.

Half a year later

A lot had happend the first half year at my new job. I learned a lot from my new colleagues. I really liked how much attention there was for quality.
The amount of experience I gained exceeded my expectations.
I had only been in the office two times. I had gotten used to working remotely.

But there also happend a few things that I wasn’t so happy with which made me reevaluate my position. This let to me keeping my eyes open.
I also started missing some of the aspects of my previous job.
My plan was to scale down my working hours for the company and pick up freelancing again to fill that void.

The next contestant

While I was still reevaluating I was contacted by another recruiter. Another company that adopted Flutter was looking for more Flutter developers.

After the second interview I was sold. It was everything I wished for, and more. I would not have to partially turn to freelancing, because the reason I would turn to freelancing, would be part of this new job.
This would also mean I would have more time to spend with my family.
I simply just couldn’t let this opportunity pass by.

So here we are

Within a span of only 7 months, I’ve left two perfectly ‘fine’ companies.

The first time was because of wanting different things. I would just not be happy I’ve I had to give up Flutter.

The second time was because the other position felt like a better fit for me.

Was it scary? Yes.
Would I’ve done it again, Heck yes!

I took a closer look into this concept of equality when I started working on the puzzle game that I’m building. It was not the first time I’ve had to compare objects, but this time it became more crucial. Now my game heavily relies on comparing objects and by doing it the 'right' way, it even made my code easier to read and understand.

Allow me to enlighten you.

Same vs Equal

So there is a difference between objects being the same, and objects being equal.

When we are talking about objects being the same, we refer to the same instance of an object. When you’re carpooling to work, you and your colleague are in the same car.

On the other hand, when you and your colleague both go with your own cars, they could be considered equal, depending on which properties you decide to compare. Like when the cars are the same make, year and color, we could consider them equal, right?

Comparing objects in Dart

The most obvious way to compare two objects is of course the == operator. This will in fact check for equality. To check if two objects are the same instance, we should use identical() .

identical can act a little unexpected when working with primitives like int or String . You hardly ever need to use identical but you should be aware.

Let’s checkout some examples:

As you probable noticed, both identical and equality checks result in the same output. So what is going on here?

Hashcode and ==

By default, each instance you create is unique. This explains the behavior in the example above.

When we want two instances to be considered equal, we must override == operator and hashcode on that class. When overriding, it’s important that the outcomes of both overrides are consistent.

When we want two objects to be considered equal the == operator should return true and hashcode on both objects should be returning the same int .

Let’s do this for our car example:

Now that we’ve implemented our own logic for == and hashcode , we decide which instances of Cars are equal. We do this by checking the three properties; color, make and year. We also calculate a new hashcode based on these properties.

As you can see in the example, car1 and car2 are instantiated with the same properties, so they are now considered equal.

car3 is completely different, and is therefor not equal to car1.

How we implement the == and hashcode logic is completely up to us. We could leave out certain properties if we’d like. The important thing is that both == and hashcode behave similar. If == says the objects are equal, then hashcode of both objects should also return the same value.

As you might think after seeing the example above; “damn, that’s a lot of work for something so simple”. And you are right. In the example above it takes up most of the class for a simple class that only holds a little bit of data.

Not only that, it is very error prone. The tiniest mistake can lead to unexpected behavior.

Luckily, there is a solution…

Equatable

To help you gain the advantages of object equality and prevent you from making application breaking mistakes, there is the equatable package.

Equatable will do the necessary overrides for you. All you have to do is tell it which properties to take into account by implementing the props getter.

Let’s update our example so it uses Equatable.

That’s it. This will now result in the same outcome as our tedious manual override.

If your class already extends another class, you can use the EquatableMixin instead.

Using object equality in your code

We can now use our new ‘equatable’ objects to write code that’s easier to read, understand and maintain.

Comparing objects

Let’s start with a simple example of comparing objects that don’t override == and hashcode or implement Equatable.

As you can see, we have to manually compare each and every property of which we decided to be of importance for our equality check. And this example only has three properties…

So let’s now do this for when Car extends Equatable.

Now doesn’t this look way better, and less error prone? I think so too!

Sets and Maps

Not only we can use it to compare objects, Dart uses it as well. Sets and Maps use equality comparison to define uniqueness. Set uses equality checks to prevent two equal objects to be entered and Map uses it for the keys.

Pro tip: If you want all the distinct objects in a List (of items that extend Equatable ) you can simply do: myList.toSet().

Unit tests

Last, but certainly not least, Equatable objects make it so much easier for us to write unit tests. Similar to what we’ve done in ‘Comparing objects’ above, we can simplify our expect.

Conclusion

Equatable makes it much easier for us to create comparable objects by allowing us to tell which fields to take into account.

Comparable objects can improve the readability and maintainability of our code by making comparing shorter and less error prone.

Comparing objects in Dart made easy with Equatable. was originally published in Pinch.nl on Medium, where people are continuing the conversation by highlighting and responding to this story.