How to rely on data from another Stream? about bloc

[felangel]

Closing this for now since it sounds like the issue was resolved. Feel free to comment with additional questions/thoughts if that's not the case and happy to continue the conversation 👍

[ksyro98]

Hey!

First of all, I think it's worth taking a moment to think on whether filtering should be managed by your Blocs or by the Presentation layer. This is a good resource on that.

With that out of the way, you can probably store that variable in your state. I notice that you already store asksToDisplay in your state, so perhaps you could also store answeredAsks or something similar. You could also store only answeredAsks and a filter variable that can be used to dynamically determine which asks to display.

Does this help? Am I understanding the situation correctly?

[DanMossa]

@ksyro98 You are understanding correctly! I really really appreciate the response.

You make a good point about where the filtering should take place.

My understanding was that all logic for what the UI displays should be in the Bloc, which is why I was trying to do it there. Is that not the right move?
Should I not be having the value of asksToDisplay in my state and instead just have the BlocBuilder rebuild and the filtering is done inside the builder?

Storing answeredAsks in the state from the AnsweredAsksRepo stream would work, but then I have the value of answeredAsks in two different blocs, which is fine if they're both synced up, but there's no clear source of truth this way since I could change the value of answeredAsks in the CategoryBloc which wouldn't effect the answeredAsks in the repo.

Do my concerns make any sense?

[ksyro98]

Hey @DanMossa! Yes they make sense!

In my experience, there isn't a hard rule on whether all of the logic for the UI needs to be in a Bloc. It depends on the architecture you use.

What I see most often is that not all of the logic for the UI has to be in a Bloc. Specifically, UI logic can stay in the widgets, while business logic can be in the blocs. Which is more or less equivalent to saying "manage ephemeral state in widgets and app state in Blocs".

It's worth noting that logic which includes BuildContext (e.g. localization logic or navigation logic) should never be in the Blocs, because Blocs are framework independent (the framework being Flutter).

For your case both approaches are valid, which is why I didn't recommend anything in particular in my previous response. I would personally manage filtering in the widget classes, and hold all of the items in the Bloc, but this isn't a hard rule, it's more of a personal preference. (Or there might be a rule I'm not aware of.)

---

You are correct that if you also store the state in the Blocs you might end up without a single source of truth. Good point!

Since you're using a behavior stream could you maybe get the answeredAsks by getting the stream's last value?
Otherwise which is currently your single source of truth and can the CategoryAsksBloc access it?