Riverpod how many providers to register

Question

I am in the process of converting my providers to riverpod.

Currently a Provider looks like this:

class ExampleProvider extends ChangeNotifier {
    Future<void> loadData() {
       ...
       notifyListener();
    }

    Future<void> filterItem() {
       ...
       notifyListener();
    }

    Future<void> getCustomer(int id) {
       ...
       notifyListener();

    }
    //And so on
}

So you could say this Provider does different types of actions.

When using Riverpod is it bad practice to create a big State Class e.g Like so:

class ExampleState {
  final Customer details;
  final String error;
  final bool isLoading;
  final List<Customer> customersList;
  final List<Customer> filteredCustomers;
  ....
  copyWith....
}

And then doing also one riverpod provider like so:

final exampleProvider =
    StateNotifierProvider<ExampleNotifier, ExampleState>((ref) {
  return ExampleNotifier();
});

or would I split everything up and having an

exampleFilterProvider / exampleCustomerProvider / exampleLoadDataProvider

Of course this would improve readability but does it also improve the performance?

tl;dr Does it improve performance to have a custom Riverpod provider for each function in our app even tho the functions belong to the same feature?

Best Regards

Answer 1

It will be logical to have several providers if they are responsible for different functionality - then we use Provider, StateProvider, FutureProvider or StreamProvider. With the help of these providers, you can easily control your rebuilds in a pinpoint manner.

Widget build(BuildContext context, WidgetRef ref) {
  String name = ref.watch(userNameProvider);
  return Text(name);
}

If you have many different fields but they provide common functionality - then use Notifier, AsyncNotifier, StreamNotifier (or legacy providers - ChangeNotifierProvider and StateNotifierProvider) with ExampleState model. If at least one field changes in the model, then all listeners will be notified that you agree, it’s not so cool anymore. However, you can use select to filter changes in a complex object:

Widget build(BuildContext context, WidgetRef ref) {
  String name = ref.watch(userProvider.select((user) => user.name));
  return Text(name);
}

But this can be overkill if your model is complex enough.