Combining Stream providers

[chris-rutkowski]

Hello,

I'm looking for the best practises when chaining + mapping stream providers. Code:

// first provider
@Riverpod(keepAlive: true)
Stream<List<Friend>> userFriendsList(UserFriendsListRef ref) {
  final user = ref.watch(authRepositoryProvider).currentUser;
  if (user != null) {
    return ref.watch(friendsRepositoryProvider).watchList(user.uid);
  } else {
    return Stream.value([]);
  }
}

// second provider (today)
@riverpod
Stream<Friend?> userFriend(UserFriendRef ref, UserId friendId) {
  return ref.watch(userFriendsListProvider).maybeMap(
        data: (data) => Stream.value(data.value.firstWhereOrNull((e) => e.uid == friendId)),
        orElse: () => Stream.value(null),
      );
}

// second provider (ideal)
@riverpod
Stream<Friend> userFriend(UserFriendRef ref, UserId friendId) {
  return ref.watch(userFriendsListProvider).maybeMap(
        data: (data) {
          final match = data.value.firstWhereOrNull((e) => e.uid == friendId);
          if (match == null) {
            // ??? pseudocode ???
            return Stream.notFoundError();
          }
          return Stream.value(match);
        }

        // ??? what about loading and error state ???
        orElse: () => Stream.value(null),
      );
}

The first provider userFriendsListProvider displays the list of friends very nicely, while responding to loading state and errors.

But I have a concerns about the second provider, userFriendProvider that I wish to develop following best architectural standards. I managed to develop the today version that works fine in most circumstances, but I believe the ideal is the one I'm looking for.

• I'd like to drop optionally - user, by design shouldn't end up on the friend detail screen that is not his friend in the first place - if that strange case happens I am happy with generic error rather then post process nullable success increasing complexity.
• orElse: () => Stream.value(null) I believe this doesn't forward nicely loading and error events from userFriendsListProvider, but just return null values, while at the same time I want to get rid of optionality here.

Please advise if I'm moving in the right direction.

Some additional insights:

• I know I could develop a function in my Firebase repository to watch a single document and use it in userFriendProvider but that's why I'm asking about best architecture. Why should I watch the low level layer (repo), instead of medium one - userFriendsListProvider. Currently that provider doesn't do much, but imagine there is some heavy-duty post processing - I'd like to have heavy-duty done once and later just return the single element if available.
• Maybe this is what I should do instead AsyncValue<Friend> userFriend(UserFriendRef ref, UserId friendId) {? But I'm a bit lost if I should ever declare my Stream providers as AsyncValue or is this type just a result of watching/reading a provider.