Reducing boilerplate for Side Effect operations

[tablet0ps]

I was reading through this section in the docs and I implemented it in my own app. I searched the internet and GitHub issues and discussions for a way to reduce boilerplate for the following:

1. Checking whether the snapshot is in loading state
2. Showing snackbar on success/failure in similar manner how we show it using ref.listen when listening to providers.

After finding no official recommendations for the second point, or an example in the docs showing how to display SnackBar on side effect completion, I decided to write a custom hook.

SideEffectController<T> useSideEffect<T>() {
  var future = useState<Future<T>?>(null);
  var snapshot = useFuture(future.value);

  return SideEffectController(
    future: future,
    snapshot: snapshot,
  );
}

class SideEffectController<T> {
  ValueNotifier<Future<T>?> future;
  final AsyncSnapshot<T> snapshot;
  FutureOr<dynamic> Function(T)? onChanged;

  SideEffectController({
    required this.future,
    required this.snapshot,
    this.onChanged,
  });

  set value(Future<T> fut) {
    future.value = fut;
    if (onChanged case var cb?) future.value?.then(cb);
  }

  bool isLoading() {
    return snapshot.connectionState == ConnectionState.waiting;
  }

  void listen(FutureOr<dynamic> Function(T)? cb) {
    onChanged = cb;
  }
}

I use it in the build method as follows:

class EditProfilePage extends HookConsumerWidget {
  const EditProfilePage({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    var profileProv = ref.watch(profileProvider);
    var sideEffect = useSideEffect();
    sideEffect.listen((snapshot) => switch (snapshot) {
          AsyncSnapshot(:var error?) => context.showSnackBar('Error!'),
          _ => context.showSnackBar('Success!'),
        });

    return Scaffold(
      body: Padding(
        padding: const EdgeInsets.all(30.0),
        child: switch (profileProv) {
          AsyncData(value: var user) => ProfileForm(
              user: user,
              onSubmit: (patch) => sideEffect.value = ref
                  .read(profileProvider.notifier)
                  .patch(UserPatchModel(update: patch)),
              isSubmitting: sideEffect.isLoading(),
            ),
          AsyncError() => const Text('Could not fetch profile'),
          _ => const CircularProgressIndicator(),
        },
      ),
    );
  }
}

This seems to work, but since I am new to riverpod, there has to be at least one issue with this code. I'd like to ask whether:

1. Is this a correct approach for showing loading state for side effects?
2. Are there more robust alternatives to this approach? It seems that the loading state vanishes when you navigate to some other page and the re-navigate the same page.

[snapsl]

The usual approach would be to use ref.listen(). Is there a reason to not use it here?

[tablet0ps]

The section in the docs which I'm referring to, demonstrates listening to side effects such as the status of addition of todos, not the actual state of the AsyncNotifierProvider which is the listing of todos.
As I'm calling

                ref
                  .read(profileProvider.notifier)
                  .patch(UserPatchModel(update: patch)),

which is a method of the class extending the AsyncNotifier, I have to use a useFuture hook or FutureBuilder to listen to the status of profile update operation.

[snapsl]

This is just an idea.

ref.listen(profileProvider, (prev, next) {
  if (next.hasError) context.showSnackBar('Error!');
  if (next.#hasChanged) context.showSnackBar('Success!'); // however this can be detected in your model
});

To detect loading state.

 isSubmitting: profileProvider.isLoading,

[tablet0ps]

Again, this will only show the Snackbar when the state of the profileProvider updates. For reference, I am using this method to update the profile state of the profileProvider, the only difference being that in the build method of ProfileProviderNotifier which contains a network request for fetching the list. There are two network requests being handled here. I want to listen and show a loading indicator for only the one in which the profile is being patched or updated.

[snapsl]

Does the update / patching change the state? If yes, the concept shown should be sufficient and would reduce boilerplate.😉
But, it's totally fine to use the side effect hook.

[tablet0ps]

Thanks for the suggestion! I can certainly wait for the notifier state itself for certain situations.

[rrousselGit]

That's alright. It's just that may people don't use hooks. But in itself there's no real issue I can see so far.

[tablet0ps]

Thanks! Now, that this got a seal of approval from Remi himself, I can use this in my apps without worrying about memory leaks or other issues. While searching for an easy way to handle this, I came across #1660 which, I think, should provide for more robust implementation. This is blocked by dart macros, so the hooks solution seems to be the least verbose solution currently.