AsyncNotifier: how to expose a loading progress message (as String) to the UI

[romaingyh]

Imagine you have an AsyncNotifier that calls a long running inside build like:

@riverpod
class MyNotifier extends _$MyNotifier {
  MyService get _service => ref.read(myServiceProvider);

  @override
  FutureOr<MyState> build() async {
    final params = await .....

    final data = await _service.doSomething(params, progressCallback: (message) {
      // handle progress change
    })

    final transformedData = await ....(data)

    return MyState(transformedData)
  }
}

The build can be long so the notifier can stay in AsyncLoading for some time.
Question is How would you expose loading progress message to UI?

Now we can pass a progress as num to AsyncLoading but it doesn't fit this use case as our progress is a string

Here are some options I've thought so far.

Hacky and ugly workaround: string to int

We define a constant list for messages:

const messagesList = {
  'Fetching X',
  'Preprocessing Y',
  'Doing some other thing',
  ....
}

In notifier's build we convert message to his index and divide it to scale in progress range:

...
    final data = await _service.doSomething(params, progressCallback: (message) {
      final messageIdx = messagesList.index(message);
      state = AsyncLoading(progress: messageIdx / 10.)
    })
...

And in UI:

...
    case AsyncLoading(:final progress?):
      final message = messagesList.valueAt((progress*10).round())

It works in theory but it has tons of bad practices and incovenients.

A second notifier for loading progress only

@riverpod
class LoadingMessageNotifier extends _$LoadingMessageNotifier {

  @override
  String? build() => '';

  void setMessage(String message) {
    state = message;
  }   
}

@riverpod
class MyNotifier extends _$MyNotifier {
  MyService get _service => ref.read(myServiceProvider);

  @override
  FutureOr<MyState> build() async {
    final params = await .....

    final data = await _service.doSomething(params, progressCallback: (message) {
      ref.read(loadingMessageProvider.notifier).setMessage(message);
    })

    final transformedData = await ....(data)

    return MyState(transformedData)
  }
}

In UI when state is AsyncLoading, we watch loadingMessageProvider to display progress message.
It works but introduces another provider.

AsyncNotifier -> Notifier with custom Sealed Class state

In this option we change from AsyncNotifier to Notifier and instead of AsyncValue<MyState> we create a sealed class for state:

sealed class MyState {}

class MyStateIdle extends MyState {}

class MyStateLoading extends MyState {
  final String message;
}

class MyStateError extends MyState {
  final Object error;
  final StackTrace? stack;
}

class MyStateLoaded extends MyState {
  ...
}

And the notifier becomes:

@riverpod
class MyNotifier extends _$MyNotifier {
  MyService get _service => ref.read(myServiceProvider);

  @override
  MyState build() {
    unawaited(_init());
    return .idle();
  }

  Future<void> _init() async {
    state = .loading('Initializing');
    try {
      final params = await .....

      final data = await _service.doSomething(params, progressCallback: (message) {
        state = .loading(message);
      })

      final transformedData = await ....(data)

      state = .data(transformedData)
    } catch (err, stack) {
      state = .error(err, stack)
    }
}

(this pseudo code uses dot-shorthands on factory constructors declared in MyState)

This should also works but It looks a bad practices to launch an asynchronous method inside a sync build, and it's like redoing a cheap and less powerful AsyncValue.

StreamNotifierwith custom state

Proposition from @lucavenir on riverpod discord

@riverpod
class MyStatesNotifer extends _$MyStatesNotifier {
  late userId;
  Stream<MyStates> build {
    userId = ref.watch(userIdProvider).requireValue;
    return _init();
  }

  Stream<MyStates> _init() async* {
    await Future<void>.delayed(1.second); // e.g.
    yield .task1;
    // etc.
    yield .done;
  }
  
  // other side effects, maybe, idk
}

In this solution the problem I see is the nested switch cases in UI because of the combo AsyncValue + custom state sealed class.

---

That's it, I'm open to all opinions and propositions to solve this problem :)

[lucavenir]

I propose not to vomit out AI schlop to give out help; if a user wants the schlop, it'd just ask gemini et. al. Instead, I think a user is here to ask actual humans. Thanks.

---

You've already shown my proposal above, but I want to address this:

In this solution the problem I see is the nested switch cases in UI because of the combo AsyncValue + custom state sealed class.

You probably fear this is "too much boilerplate", or "too much complicated", but imho it isn't. If my guess is right, you're probably underestimating the problem.

In a nutshell, you do need to keep track of which state you're in, and you need to keep track which was the last state that "went well", and if (and which) an error occurred in between. That's the true power of AsyncValue: you (possibly) get to keep three states at once.

For example (with - honestly - not that much code) you get to express with a single pattern-matchable variable: "yeah I'm loading, since I'm retrying to refresh this value because it errored, but hey I still have the first value which was OK".

Code speaks volumes:

@freezed
sealed class Step with _$Step{
  const factory Step.one() = StepOne;
  const factory Step.two() = StepTwo;
  const factory Step.three() = StepThree;
  const factory Step.final(int value) = StepFinal;
}

@riverpod
class SomethingNotifier extends _$SomethingNotifier {
  late Some dependency;
  Stream<Step> build {
    dependency = ref.watch(userIdProvider).requireValue;  // !
    return _init(dependency);
  }

  Stream<Step> _init(Some dependency) async* {
    final finalStep = await _service.doSomething(params, progressCallback: (step) {
      yield step;
    });
    yield finalStep;  // this contains .value
  }
  
  // other side effects, maybe, idk
}

[romaingyh]

Thanks for your time on this, I refactored my notifier and state class to use this pattern. It's a bit more verbose but it really handles all cases :)