Events (UI -> Presenter)

First type of communication is when UI has to run some method on Presenter. We're calling these events just like Bloc and some other state management solutions would.

In presenter they are simple methods. For example:

RaisedButton(
  child: Text('Save'),
  onPressed: () {
    presenter.onSavePressed();
  }
)

Take a note on a naming. The events don't command on presenter, but say onSomethingHappened and presenter will decide what to do. Wrong naming would be presenter.saveProfile().

View state (UI <- Presenter)

Second type is when presenter is managing view state. The UI should observe that state and rebuild. Usually this is done by our presenters extending ChangeNotifier or StateNotifier:

    Consumer<MeetupScreenPresenter>(
      builder: (context, presenter, _) {
        return _MeetupList(list: presenter.state);
      },
    ),

With riverpod you can use hooks to flatten this: https://riverpod.dev/docs/concepts/reading/#useprovider-hooks_riverpod-only

Actions (UI <- Presenter)

The view state describes how the view tree should be built. Sometimes presenter needs to communicate other things that don't fall under the view tree of that widget. Most often these are:

• Navigation (open some screen, close current screen)
• Dialogs (show dialog, bottom sheet, hide dialog)
• Snackbars, Toasts, etc.

For these cases we use Actions. For more information check the Actions chapter.