Is it possible to open BuildlessAutoDisposeAsyncNotifier/BuildlessAsyncNotifier for public consumption outside of 'riverpod_generator'?

[abigotado]

In continuation of the discussed in #1953

Hello!

I have made a mixin on AutoDisposeAsyncNotifier to reuse code in my AsyncNotifiers with list pagination logics.

/// Mixin for pagination screens.
mixin PaginationMixin<T>
    on AutoDisposeAsyncNotifier<PaginationState<T>> {
  /// Fetch list and manage states.
  Future<PaginationState<T>> fetchList({
    final bool isRefresh = false,
    final bool isSocketUpdate = false,
    final String? search,
    final EvaluationStatus? filter,
  }) async {
    if (isSocketUpdate || isRefresh || !(state.value?.isEnd ?? false)) {
      PaginationState<T> pagination = state.value != null
          ? state.value!.copyWith(
              page: isRefresh ? null : state.value!.page,
              items: isRefresh ? null : state.value!.items,
              search: search ?? state.value!.search,
              filter: filter ?? state.value!.filter,
            )
          : PaginationState<T>();

      if (!isSocketUpdate) state = AsyncLoading<PaginationState<T>>();

      debugPrint('isSocketUpdate $isSocketUpdate');

      final int nextPage = (pagination.page ?? 0) + 1;
      state = await AsyncValue.guard(() async {
        final List<T>? list = await getList(
          isSocketUpdate ? 1 : nextPage,
          length: isSocketUpdate ? (state.value?.page ?? 1) * 20 : null,
          isRefresh: isRefresh,
          search: state.value?.search ?? '',
          filter: state.value?.filter ?? EvaluationStatus.all,
        );
        if (list != null) {
          pagination = pagination.copyWith(
            isEnd: list.length < 20,
            items: <T>[
              if (!isSocketUpdate) ...pagination.items ?? <T>[],
              ...list,
            ],
            page: isSocketUpdate ? pagination.page : nextPage,
            search: search ?? pagination.search,
            filter: filter ?? pagination.filter,
          );
        }
        return pagination;
      });
    }
    return state.value ?? PaginationState<T>();
  }

  /// Load list from repository.
  Future<List<T>?> getList(
    final int page, {
    required final EvaluationStatus filter,
    final int? length,
    final bool isRefresh = false,
    final String? search,
  });
}

It works well, when I am using AsyncNotifier with no additional arguments. But if there are arguments (similar to family), generator creates BuildlessAutoDisposeAsyncNotifier, not general AutoDisposeAsyncNotifier. So the mixin has class mismatch.

This one works well:

/// The controller of EventsScreen states.
@riverpod
class EventsController extends _$EventsController
    with PaginationMixin<EventModel> {
  @override
  FutureOr<PaginationState<EventModel>> build() {
    return fetchList();
  }

  @override
  Future<List<EventModel>?> getList(
    final int page, {
    required final EvaluationStatus filter,
    final int? length,
    final bool isRefresh = false,
    final String? search,
  }) {
    return ref.read(eventsRepositoryProvider).fetchList(
          page,
          length: length,
          isRefresh: isRefresh,
          search: search,
          filter: filter,
        );
  }
}

And this one won't work because of id argument:

/// The controller of [ParticipantsScreen] states.
@riverpod
class ParticipantsController extends _$ParticipantsController
    with PaginationMixin<AccessModel> {
  @override
  FutureOr<PaginationState<AccessModel>> build(final int id) {
    return fetchList();
  }

  @override
  Future<List<AccessModel>?> getList(
    final int page, {
    required final EvaluationStatus filter,
    final int? length,
    final bool isRefresh = false,
    final String? search,
  }) {
    // debugPrint('event controller id: $id');
    return ref.read(participantsRepositoryProvider(id)).fetchList(
          page,
          isRefresh: isRefresh,
          search: search,
          filter: filter,
          length: length,
        );
  }
}

The problem would be solved, if there's a possibility to make mixin on BuildlessAutoDisposeAsyncNotifier (which is only for internal use now), rather than AutoDisposeAsyncNotifier.

So, is it possible to open BuildlessAutoDisposeAsyncNotifier for public consumption outside of 'riverpod_generator'? Or maybe here can be another solution?

[rrousselGit]

That's not reasonable. It isn't meant to be used

You don't need the on clause on mixins for them to work. You can instead do:

mixin PaginationMixin<T> {
  State<AsyncValue<T>> get state;
  set state(State<AsyncValue<T> value);
  Ref<AsyncValue<T>> get ref;
}

If you end up needing this often, you can make an interface

abstract class AsyncNotifierInterface<T> {
  State<AsyncValue<T>> get state;
  set state(State<AsyncValue<T> value);
  Ref<AsyncValue<T>> get ref;
}

mixin MyMixin<T> implements AsyncNotifierInterface<T> {

}

[rrousselGit]

I'll maybe expose it in the future, but I'm a bit skeptical about it for now.

It's not something that was designed to be exposed. I'd need to carefully review it before exposing it.
Considering there's a decent workaround, it's not too important to me.

[abigotado]

@rrousselGit Well, I've just thought that it could be possible to expose both Buildless and general Notifiers, if one had already been exposed, but I understand your skepsis about it. Anyway your workaround functions excellent, thank you!

And I just want to specify two more things:

1. Concerning the the Ref in a workaround

If I try to use it like that:

mixin PaginationMixin<T> {
  Ref<PaginationState<T>> get ref;

There is and error, if I try to use the mixin: 'BuildlessAutoDisposeAsyncNotifier.ref' ('AutoDisposeAsyncNotifierProviderRef<PaginationState<AccessModel>> Function()') isn't a valid concrete implementation of 'PaginationMixin.ref' ('Ref<PaginationState<AccessModel>> Function()')

It is solved, if I create mixin this way:

mixin PaginationMixin<T> {
  AutoDisposeAsyncNotifierProviderRef<PaginationState<T>> get ref;

So it is necessary to specify type of ref, isn't it?

2. Concerning passing a provider to a class as an argument:

/// Screen with scrollable widget.
class ScrollableScreen<T> extends HookConsumerWidget {
  /// Creates a [ScrollableScreen].
  const ScrollableScreen({
    required this.provider,
    super.key,
  });

  /// Provider of a controller with [PaginationMixin] for the [ScrollableScreen].
  final AutoDisposeAsyncNotifierProvider<dynamic, PaginationState<T>> provider;

Is it a proper way? If I change dynamic in generic with AutoDisposeAsyncNotifier<PaginationState<T>> it will work only with AutoDisposeAsyncNotifier, but won't work with BuildlessAutoDisposeAsyncNotifier.

[rrousselGit]

So it is necessary to specify type of ref, isn't it?

Depends on what your mixin needs.

Generally AutoDisposeRef<T> vs Ref<T> is enough

[rrousselGit]

Concerning passing a provider to a class as an argument:

Providers shouldn't be passed as parameter at all. So I would argue that's asking the wrong question.

[TimWhiting]

I think Remi's method, and also the ProviderListenable + callback method should be mentioned somewhere in the docs as the recommended solution for creating components that can be reusable with multiple different providers for your app. In general I think it is good to know about ProviderListenable and the fact that it is the interface that you should be using when creating reusable abstractions on top of Riverpod. I definitely learned pretty quickly that it was not great to pass providers around because then a component would work with one type of provider and not another, for example I couldn't switch a StateProvider to a StateNotifierProvider in one case.

[rrousselGit]

I'll add this to the list.

[raminsafaei]

I've recently started using Notifier/AsyncNotifier and after reading some issues and your responses, I kinda get why you've done this, but I think the new approach is too restrictive. StateNotfier is very flexible, it's easy to abstract, compose and partially scope.
Notifier on the other hand is kinda hard to work with if you want to write reusable code or abstract stuff.

Let's say I have a base class for posts feed screen notifier. I might have the same logic on five different screens with slightly different methods. For example all of these posts screens can filter posts, using mixins we can write a PostsFilterMotifier and write a widget which uses this as a scoped provider without passing multiple arguments down the widget tree. With StateNotifier we could write this, for example:

mixin PostsFilter {
  bool get includeRead;
}

mixin PostsFilterNotifier<S extends PostsFilter> on StateNotifier<S> {
  void changeFilters();
}

class PostsState with PostsFilter {
  PostsState(this.posts, this.includeRead);

  // assume its a full fledged class
  final List<String> posts;
  @override
  final bool includeRead;

  static PostsState initial = PostsState([], true);
}

class PostsNotifier extends StateNotifier<PostsState> with PostsFilterNotifier {
  PostsNotifier(super.state);

  Future<void> loadPosts() async {}

  @override
  void changeFilters() {}
}

// there might be several variant of this, each using some of mixins like filters
// some posts notifiers might not be filterable for example but be refreshable etc.
final mainPostsProvider =
    StateNotifierProvider((ref) => PostsNotifier(PostsState.initial));

// you can easily override this with mainPostsProvider or anyother notifier mixing postsfilternotifier
// this will give access to only filters state and changefilters function
final filtersProvider = StateNotifierProvider<PostsFilterNotifier, PostsFilter>(
  (ref) => throw UnimplementedError(),
);

Using the new Notifier class, however, there's no unified class to depend on. It's not as easy to write shared logic and use providerscopes. Provider's lifecycle is directly tied to notifier implementation.
I can be wrong (and probably am) and also StateNotifier is still there and usable, but it would be nice to be able to write notifiers regardless of the lifecycle.

[abigotado]

@raminsafaei As it was mentioned previously by Remi you can use mixins but a little bit differently

Something like that:

mixin PostsFilter {
  bool get includeRead;
}

mixin PostsFilterMixin<S extends PostsFilter> {
  /// State from the class that uses the [PostsFilterMixin].
  State<AsyncValue<T>> get state;
  set state(State<AsyncValue<T> value);

  /// Provider reference from the class that uses the [PostsFilterMixin].
 Ref<AsyncValue<S>> get ref;

  void changeFilters();
}

class PostsState with PostsFilter {
  PostsState(this.posts, this.includeRead);

  final List<String> posts;
  @override
  final bool includeRead;

  static PostsState initial = PostsState([], true);
}

@riverpod
class PostsNotifier extends _$PostsNotifier with PostsFilterMixin<PostsState> {
  @override
  FutureOr<PostsState> build() {
    return loadPosts();
  }

  @override
  void changeFilters() {}
}

I have implemented this way of creating mixins for notifiers in my projects after Remi's post. And everything works well.

[raminsafaei]

@abigotado thanks for response and code sample. I've read Remi's response before and have implemented a very similar thing.
My main problem was polymorphism and overriding notifiers. As I've mentioned before, using StateNotifiers It's easy to use provider scopes and give parts of a widget tree access to only parts of a bigger notifier. We could have a modal to change posts filters without giving it the whole notifier with dozens of methods and state, you could simply give it PostsFilterNotifier with PostsFilter as its state (as a StateNotifier), and it would just work. With this mixins and state etc. it's technically possible to achieve similar thing, but it's not a Notifier.
Of course in this example it's not that big of a deal, but you can imagine how handy it can be in more complex situations.
Also, I believe it's discouraged to read state outside of read/watch of notifier's state (it's protected). Can it lead to unintended rebuilds? (if I use PostsFilterMixin as you've written above)

[Dean-Spotec]

to encapsulate paging loading widget，riverpod_paging_utils uses the mixin solution. riverpod_infinite_scroll use the StateNotifier solution