mobx 1.2.1

  • Readme
  • Changelog
  • Example
  • Installing
  • 99

Language: English | Português

mobx.dart en #

pub package Build Status Coverage Status

MobX for the Dart language.

Supercharge the state-management in your Dart apps with Transparent Functional Reactive Programming (TFRP)

Introduction #

MobX is a state-management library that makes it simple to connect the reactive data of your application with the UI. This wiring is completely automatic and feels very natural. As the application-developer, you focus purely on what reactive-data needs to be consumed in the UI (and elsewhere) without worrying about keeping the two in sync.

It's not really magic but it does have some smarts around what is being consumed (observables) and where (reactions), and automatically tracks it for you. When the observables change, all reactions are re-run. What's interesting is that these reactions can be anything from a simple console log, a network call to re-rendering the UI.

MobX has been a very effective library for the JavaScript apps and this port to the Dart language aims to bring the same levels of productivity.

Go deep #

For a deeper coverage of MobX, do check out MobX Quick Start Guide. Although the book uses the JavaScript version of MobX, nearly all of the concepts are applicable to Dart and Flutter.

Core Concepts #

MobX Triad

At the heart of MobX are three important concepts: Observables, Actions and Reactions.

Observables #

Observables represent the reactive-state of your application. They can be simple scalars to complex object trees. By defining the state of the application as a tree of observables, you can expose a reactive-state-tree that the UI (or other observers in the app) consume.

A simple reactive-counter is represented by the following observable:

import 'package:mobx/mobx.dart';

final counter = Observable(0);

More complex observables, such as classes, can be created as well.

class Counter {
  Counter() {
    increment = Action(_increment);

  final _value = Observable(0);
  int get value => _value.value;

  set value(int newValue) => _value.value = newValue;
  Action increment;

  void _increment() {

On first sight, this does look like some boilerplate code which can quickly go out of hand! This is why we added mobx_codegen to the mix that allows you to replace the above code with the following:

import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Counter = CounterBase with _$Counter;

abstract class CounterBase with Store {
  int value = 0;

  void increment() {

Note the use of annotations to mark the observable properties of the class. Yes, there is some header boilerplate here but its fixed for any class. As you build more complex classes this boilerplate will fade away and you will mostly focus on the code within the braces.

Note: Annotations are available via the mobx_codegen package.

Computed Observables #

What can be derived, should be derived. Automatically.

The state of your application consists of core-state and derived-state. The core-state is state inherent to the domain you are dealing with. For example, if you have a Contact entity, the firstName and lastName form the core-state of Contact. However, fullName is derived-state, obtained by combining firstName and lastName.

Such derived state, that depends on core-state or other derived-state is called a Computed Observable. It is automatically kept in sync when its underlying observables change.

State in MobX = Core-State + Derived-State

import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Contact = ContactBase with _$Contact;

abstract class ContactBase with Store {
  String firstName;

  String lastName;

  String get fullName => '$firstName, $lastName';


In the example above fullName is automatically kept in sync if either firstName and/or lastName changes.

Actions #

Actions are how you mutate the observables. Rather than mutating them directly, actions add a semantic meaning to the mutations. For example, instead of just doing value++, firing an increment() action carries more meaning. Besides, actions also batch up all the notifications and ensure the changes are notified only after they complete. Thus the observers are notified only upon the atomic completion of the action.

Note that actions can also be nested, in which case the notifications go out when the top-most action has completed.

final counter = Observable(0);

final increment = Action((){

When creating actions inside a class, you can take advantage of annotations!

import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Counter = CounterBase with _$Counter;

abstract class CounterBase with Store {
  int value = 0;

  void increment() {

Reactions #

Reactions complete the MobX triad of observables, actions and reactions. They are the observers of the reactive-system and get notified whenever an observable they track is changed. Reactions come in few flavors as listed below. All of them return a ReactionDisposer, a function that can be called to dispose the reaction.

One striking feature of reactions is that they automatically track all the observables without any explicit wiring. The act of reading an observable within a reaction is enough to track it!

The code you write with MobX appears to be literally ceremony-free!

ReactionDisposer autorun(Function(Reaction) fn)

Runs the reaction immediately and also on any change in the observables used inside fn.

import 'package:mobx/mobx.dart';

String greeting = Observable('Hello World');

final dispose = autorun((_){

greeting.value = 'Hello MobX';

// Done with the autorun()

// Prints:
// Hello World
// Hello MobX

ReactionDisposer reaction<T>(T Function(Reaction) fn, void Function(T) effect)

Monitors the observables used inside the fn() function and runs the effect() when the fn() function returns a different value. Only the observables inside fn() are tracked.

import 'package:mobx/mobx.dart';

String greeting = Observable('Hello World');

final dispose = reaction((_) => greeting.value, (msg) => print(msg));

greeting.value = 'Hello MobX'; // Cause a change

// Done with the reaction()

// Prints:
// Hello MobX

ReactionDisposer when(bool Function(Reaction) predicate, void Function() effect)

Monitors the observables used inside predicate() and runs the effect() when it returns true. After the effect() is run, when automatically disposes itself. So you can think of when as a one-time reaction. You can also dispose when() pre-maturely.

import 'package:mobx/mobx.dart';

String greeting = Observable('Hello World');

final dispose = when((_) => greeting.value == 'Hello MobX', () => print('Someone greeted MobX'));

greeting.value = 'Hello MobX'; // Causes a change, runs effect and disposes

// Prints:
// Someone greeted MobX

Future<void> asyncWhen(bool Function(Reaction) predicate)

Similar to when but returns a Future, which is fulfilled when the predicate() returns true. This is a convenient way of waiting for the predicate() to turn true.

final completed = Observable(false);

void waitForCompletion() async {
  await asyncWhen(() => _completed.value == true);



One of the most visual reactions in the app is the UI. The Observer widget (which is part of the flutter_mobx package), provides a granular observer of the observables used in its builder function. Whenever these observables change, Observer rebuilds and renders.

Below is the Counter example in its entirety.

import 'package:flutter/material.dart';
import 'package:flutter_mobx/flutter_mobx.dart';
import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Counter = CounterBase with _$Counter;

abstract class CounterBase with Store {
  int value = 0;

  void increment() {

class CounterExample extends StatefulWidget {
  const CounterExample({Key key}) : super(key: key);

  _CounterExampleState createState() => _CounterExampleState();

class _CounterExampleState extends State<CounterExample> {
  final _counter = Counter();

  Widget build(BuildContext context) => Scaffold(
        appBar: AppBar(
          title: const Text('Counter'),
        body: Center(
          child: Column(
            children: <Widget>[
              const Text(
                'You have pushed the button this many times:',
                  builder: (_) => Text(
                        style: const TextStyle(fontSize: 20),
        floatingActionButton: FloatingActionButton(
          onPressed: _counter.increment,
          tooltip: 'Increment',
          child: const Icon(Icons.add),

Contributing #

If you have read up till here, then 🎉🎉🎉. There are couple of ways in which you can contribute to the growing community of MobX.dart.

1.2.1 #

  • Improved observe() API for ObservableList. We now get better change events with accurate details about what has changed. Thanks to @darkstarx for the PR (#490)

1.2.0 #

  • Added the ability to spy on changes happening inside MobX. You can now setup a spy() to see all these changes. See this for an example.
  • Simplified the handling of tests and coverage. We are no longer dependent on the test_coverage package, which was causing issues on CI.
  • A custom EqualityComparer<T> can now be specified for Computed<T>. This can be passed in with the equals parameter in the constructor.
  • Several documentation updates from various contributors.

1.1.0 - 1.1.1 #

  • All exceptions caught inside MobX reactions are now reported as MobXCaughtException. Previously they were reported as-is and that caused issues in flutter_mobx, where the stack traces were not visible. The stack trace is now being captured as part of the exception, so flutter_mobx can show the complete trace. This helps a lot during debugging.
  • MobXException now extends from Error to capture the stack trace. This is done because Dart only captures stack traces automatically for Error instances.
  • Bringing test coverage back to 98% in 1.1.1

1.0.2 - 1.0.2+2 #

  • Added @StoreConfig annotation (@hawkbee1)
  • Fixed to link to pt-BR translation on github
  • Fixed anchor link inside

1.0.1 #

  • Fix for ObservableMap not adding null values (#417), thanks to @Vardiak

1.0.0 #

  • Ready for prime time!

0.4.0+3 - 0.4.0+4 #

  • Going back to original test_coverage package
  • Some cleanups in the tests

0.4.0+2 #

  • README updates
  • Switching to Github Actions for all builds and publishing

0.4.0 - 0.4.0+1 #

  • Removing the deprecated authors field from pubspec.yaml
  • Added extension methods to create an Observable{List,Set,Map,Future,Stream} from a regular List, Set, Map, Future, Stream. Thanks to the work done by Jacob Moura
  • translated to Portuguese, thanks to Jacob Moura

0.3.10 #

  • Removed Store.dispose
  • Fixed some analyzer errors related to unused_element

0.3.9+3 #

  • Documentation comments for many of the public methods and classes
  • Package updates

0.3.9 - 0.3.9+1 #

0.3.7 - 0.3.8+1 #

  • Fixes the type resolution bug that prevented using types from packages like dart:ui
  • Fixes the type resolution of other public Store classes referenced in the @store based generation

Thanks to @shyndman for the tremendous work on this release.

  • Added a version constant that matches the pubspec.yaml

0.3.6 #

  • Added new way to create Store classes using the @store annotation. This will exist as an alternative to the mixin based approach we already have.
  • Includes a new option for reaction for using a custom EqualityComparator<T, T>. This is useful when you want to avoid expensive reactions by plugging in a custom comparison function for the previous and next values of the predicate.

0.3.5 - 0.3.5+1 #

  • Fixed a bug where the ObservableFuture<T> would not show the correct status. This was happening because of the lazy evaluation strategy. We are now being eager in creating the status and monitoring the inner Future<T> immediately.
  • Upgraded test_coverage

0.3.3+1 - 0.3.4 #

  • Removed the @experimental annotations for Observable{Future,Stream} and reaction.
  • Removed the dependency on the meta package.
  • Some formatting changes
  • Reporting update or change only when the new value is different than the old value. This is mostly for observable collections like list, set, map.

0.3.3 #

  • Wrapping all collection setters in conditional action wrappers. This removes the need to wrap collection mutating methods in explicit actions.

0.3.0 - 0.3.2+3 #

  • API changes introduced to the enforceActions setting of ReactiveConfig. It is now called writePolicy and the enum EnforceActions has been renamed to ReactiveWritePolicy.
  • Also introducing a readPolicy setting on ReactiveConfig. It is an enumeration with two values:
  • Removing the "strict-mode" text in the exception message when the ReactiveWritePolicy is violated. This was a vestige from the mobx.js world.
  • Exposing a boolean isWithinBatch on ReactiveContext, which tells if the current code is running inside a batch. This is used to conditionally apply an action-wrapper for mobx_codegen-generated setters.
  • Introduced an action-wrapper called conditionallyRunInAction() that runs the given function in an action only when outside a batch.
  • Increasing test coverage
enum ReactiveReadPolicy { always, never }

0.2.1+2 #

  • Improving test coverage

0.2.1+1 #

  • README updates

0.2.1 #

0.2.0 #

  • A breaking change has been introduced to the use of the Store type. Previously it was meant to be used as an interface, which has now changed to a mixin. Instead of doing:
abstract class UserBase implements Store {}

You now do:

abstract class UserBase with Store {}

This allows us to add more convenience methods to the Store mixin without causing any breaking change in the future. With the current use of the interface, this was not possible and was limiting the purpose. Store was just a marker interface without any core functionality. With a mixin, it opens up some flexibility in adding more functionality later.

  • All the docs and example code have been updated to the use of the Store mixin.


Examples #

Annotations #

Annotations drastically simplify the usage of MobX by tastefully tucking away all the boilerplate in the generated files (*.g.dart).

These examples use annotations, which is supported by the mobx_codegen package. To run the code-generator, we are using the following command:

$> cd $PATH_TO_MOBX_DART/mobx/example
$> flutter packages pub run build_runner build

Counter (counter.dart) #

A really simple Counter. After all this is how you start off a Dart/Flutter project :-)

import 'package:mobx/mobx.dart';

part 'counter.g.dart';

class Counter = CounterBase with _$Counter;

abstract class CounterBase with Store {
  int value = 0;

  void increment() {

Notice the @observable value property and the @action increment()that mutates it.

Todos (todos.dart) #

This example showcases some of the core features of MobX such as Observable, Computed and Action. We have intentionally left out Reaction to keep it simple.

The Todos example is a classic way of showcasing a framework or a library. Here, you can see how MobX can simplify your code.

Todo #

A Todo entity is at the heart of the Todos example. A bit of boilerplate is needed to make the code-generator do the rest for you.

import 'package:mobx/mobx.dart';

part 'example.g.dart';

class Todo = TodoBase with _$Todo;

abstract class TodoBase with Store {

  String description = '';

  bool done = false;


The TodoList manages the list of Todo. Notice the use of annotations to make the code more readable. MobX follows the princple:

What can be derived, should be derived. Automatically.

This is achieved with a small core-state (the @observable properties) and the derived-state (the @computed properties).

enum VisibilityFilter { all, pending, completed }

class TodoList = TodoListBase with _$TodoList;

abstract class TodoListBase with Store {
  ObservableList<Todo> todos = ObservableList<Todo>();

  VisibilityFilter filter = VisibilityFilter.all;

  String currentDescription = '';

  ObservableList<Todo> get pendingTodos =>
      ObservableList.of(todos.where((todo) => todo.done != true));

  ObservableList<Todo> get completedTodos =>
      ObservableList.of(todos.where((todo) => todo.done == true));

  bool get hasCompletedTodos => completedTodos.isNotEmpty;

  bool get hasPendingTodos => pendingTodos.isNotEmpty;

  String get itemsDescription =>
      '${pendingTodos.length} pending, ${completedTodos.length} completed';

  ObservableList<Todo> get visibleTodos {
    switch (filter) {
      case VisibilityFilter.pending:
        return pendingTodos;
      case VisibilityFilter.completed:
        return completedTodos;
        return todos;

  // ...

Notice how you can have derived-state that depends on other derived-state. For example, itemsDescription depends on pendingTodos and completedTodos, which are also computed (aka derived) properties.


The operations that can be performed on the TodoList are marked with @action. These are simple functions, which can be invoked like normal dart functions! There is no extra ceremony to invoke an action.

class TodoList = TodoListBase with _$TodoList;

abstract class TodoListBase with Store {
  // ...

  void addTodo(String description) {
    final todo = Todo(description);
    currentDescription = '';

  void removeTodo(Todo todo) {
    todos.removeWhere((x) => x == todo);

  void changeDescription(String description) =>
      currentDescription = description;

  void changeFilter(VisibilityFilter filter) => this.filter = filter;

  void removeCompleted() {
    todos.removeWhere((todo) => todo.done);

  void markAllAsCompleted() {
    for (final todo in todos) {
      todo.done = true;

Use this package as a library

1. Depend on it

Add this to your package's pubspec.yaml file:

  mobx: ^1.2.1

2. Install it

You can install packages from the command line:

with pub:

$ pub get

with Flutter:

$ flutter pub get

Alternatively, your editor might support pub get or flutter pub get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:

import 'package:mobx/mobx.dart';
Describes how popular the package is relative to other packages. [more]
Code health derived from static analysis. [more]
Reflects how tidy and up-to-date the package is. [more]
Weighted score of the above. [more]
Learn more about scoring.

We analyzed this package on Jun 4, 2020, and provided a score, details, and suggestions below. Analysis was completed with status completed using:

  • Dart: 2.8.2
  • pana: 0.13.8-dev

Health suggestions

Format lib/src/api/observable_collections/observable_list.dart.

Run dartfmt to format lib/src/api/observable_collections/observable_list.dart.


Package Constraint Resolved Available
Direct dependencies
Dart SDK >=2.7.0 <3.0.0
meta ^1.1.6 1.1.8
Dev dependencies
collection ^1.0.0
coverage ^0.13.9
fake_async ^1.0.1
mockito ^4.1.1
test ^1.9.4