Riverpod

Note: this is WIP, and now seems to be wrong.

Mocking notifiers is a rabbit hole that never ends.

Arch

Notifiers

Intro

Notifiers are great, but confusing. In order to avoid problems, make sure to follow some best practices.

What they are

First of all though, what exactly are notifiers? In practice, they are stateful services, that provide a second state.

What does that mean? It means you have state, separate from your provided state. It's confusing, here is an example:

@riverpod
class MyController extends _$MyController {
  // this is state
  late SomeService _service;

  // and this is your provided state
  String build() => "some label";

  // this method uses the notifier state, to update the provided state
  void update() => state = _service.getNewLabel();
}

Testing

Unfortunately there is not a perfect solution right now, only an ok one. You have to include test code in production 🤮. Sorry.

@riverpod
class MyController extends _$MyController { ... }

class MyController extends _$MyController
    with Mock
    implements MyController {}

Is there really no alternative?

I've worked with notifiers for a while, and the alternatives are to:

• wrap services and use those
• mock the dependencies of the notifier

So yes, there are alternatives, but they suck long-term. I've tried both, and after a while, they both become more complicated and ugly. It's a trade-off, but IMO it's worth putting the mock definition into production code.

.

.

.