riverpod architecture/design pattern advice

[varunbhalerao56]

Hello, I have an app made with riverpod as the main state management. But I need some advice regarding some architectures/design patterns that I can use to make my code cleaner and easier to maintain in the future.

Overall I feel riverpod is already quite easy to maintain but is there any specific design pattern that would be advisable to use? So here are my questions

• Is there a pattern that is recommended to use with riverpod?
• If not, what would you consider as best practices while working with riverpod?
• I am using riverpod for production and it is quite good so far, but are there going to be massive updates going forward?
• How do I test the code in Figure 2?

Packages I am using with riverpod

• freezed
• json_serializable

Figure 1: This is my current folder structure.

cart 
  - controller
      - cart_controller.dart
  - model 
      - cart_model.dart 
      - cart_model.freezed.dart 
      - cart_model.g.dart    
  - view
      - cart_view.dart 
  - widgets 
      - checkout_button.dart 
      - .... 

Figure 2: Since I am using firebase and riverpod together this is how my state notifier provider looks like.

final cartController = StateNotifierProvider.family<MemberCartList, AsyncValue<List<BuyForm>>, String>((ref, memberId) {
  return MemberCartList(ref.read, memberId);
});

class MemberCartList extends StateNotifier<AsyncValue<List<BuyForm>>> {
  final String memberId;
  MemberCartList(this.read, this.memberId) : super(const AsyncLoading()) {
    _getCart();
  }

  final Reader read;

  Future<void> _getCart() async {
    try {
      final List<BuyForm> buyForms = await CartApi(memberId, read(firebaseFirestoreProvider)).getCartForms();
      state = AsyncData(buyForms);
    } catch (e, st) {
      throw AsyncError<Exception>(e, stackTrace: st);
    }
  }

  Future<void> addToCart({required BuyForm buyForm}) async {
    try {
      await CartApi(memberId, read(firebaseFirestoreProvider)).setCartForm(buyForm);
      final List<BuyForm> buyForms = await CartApi(memberId, read(firebaseFirestoreProvider)).getCartForms();
      state = AsyncData(buyForms);
    } catch (e, st) {
      throw AsyncError<Exception>(e, stackTrace: st);
    }
  }

  Future<void> deleteFromCart({required BuyForm buyForm}) async {
    try {
      await CartApi(memberId, read(firebaseFirestoreProvider)).deleteCartForm(buyForm);
      final List<BuyForm> buyForms = await CartApi(memberId, read(firebaseFirestoreProvider)).getCartForms();
      state = AsyncData(buyForms);
    } catch (e, st) {
      throw AsyncError<Exception>(e, stackTrace: st);
    }
  }

I think this is okay overall but not really following any specifically named design pattern. Like provider and bloc have design patterns are quite good and well known, but not really sure about riverpod. But I do want to continue using riverpod because its very good in most things I need from my app.

Thanks for making this amazing package ❤️

[rrousselGit]

  throw AsyncError<Exception>(e, stackTrace: st);

This is a bit weird. I don't see the purpose of this code. Maybe you wanted to do state = AsyncError(...)?

Other than that, your code looks alright.
Riverpod is a pattern on its own. You're not using "Riverpod + ". Riverpod is the pattern, since it's fairly strict in what you can and can't do

As for testing your code, I'd suggest looking at the testing cookbook or some of Riverpod's tests.

[rrousselGit]

Also:

I am using riverpod for production and it is quite good so far, but are there going to be massive updates going forward?

So far, there's no plan for a big update.

[varunbhalerao56]

@rrousselGit Thanks for answering!

Riverpod is a pattern on its own. You're not using "Riverpod + ". Riverpod is the pattern

Is there a need to base it around some form of architecture right? That is followed in the development industry like MVC (i think my one is close to MVC in some ways), MVVP, etc.

I was looking at your reply here How do you structure your projects with Riverpod?

In the discussion, you mention some of the ways that you split up your code, So I am assuming there is some kind of architecture to it right? (Apologies if I got it wrong)

[rrousselGit]

In the discussion, you mention some of the ways that you split up your code, So I am assuming there is some kind of architecture to it right? (Apologies if I got it wrong)

I'd differentiate folder architecture from app state architecture

You're free to architecture your folders however you like in Riverpod (I prefer per entity as you've seen).
On the other hand, as an app state architecture, Riverpod is kind of standing on its own.

I don't like associating Riverpod with standards like MVC/MVVP. Riverpod is a big of an odd one. I don't think they truly fit.

I feel Riverpod has a different kind of architecture: reactive caching with uni-directional dataflow and ideally immutable data.
Although if I had to pick one, MVC works alright with Riverpod.