felangel / bloc

A predictable state management library that helps implement the BLoC design pattern
https://bloclibrary.dev
MIT License
11.53k stars 3.37k forks source link

perf: Example of not duplicating data with repository pattern in todos example #4167

Closed faisalansari0367 closed 1 month ago

faisalansari0367 commented 1 month ago

Description

In the TodosOverviewBloc

await emit.forEach<List<Todo>>(
  _todosRepository.getTodos(),
  onData: (todos) => state.copyWith(
    status: () => TodosOverviewStatus.success,
    todos: () => todos,
  ),
  onError: (_, __) => state.copyWith(
    status: () => TodosOverviewStatus.failure,
  ),
);

We are storing the data in the state in the above manner but we are storing the same data at the repository level in local_storage_todos_api

late final _todoStreamController = BehaviorSubject<List<Todo>>.seeded(const []);

To enhance this setup and promote a more realistic approach for real-world applications, consolidating data storage into a single location would be highly beneficial. This improvement could streamline processes for developers facing similar scenarios, offering clearer management and maintenance of data.

felangel commented 1 month ago

In this bloc the same model is used in both places but in more real-world, larger apps the data exposed by the repository would likely be quite different from the data exposed by a bloc and the bloc would handle transforming the repository data into the required state. You can see the StatsBloc for example also subscribes to the todos exposed by the repository and it converts that data into statistics that are later presented in the UI.

To enhance this setup and promote a more realistic approach for real-world applications, consolidating data storage into a single location would be highly beneficial.

There is still a single source of truth (in this case the repository) and one or more blocs may access data exposed by the repository and transform it as needed into state consumed by the presentation.

Hope that helps 👍

faisalansari0367 commented 1 month ago

In this bloc the same model is used in both places but in more real-world, larger apps the data exposed by the repository would likely be quite different from the data exposed by a bloc and the bloc would handle transforming the repository data into the required state. You can see the StatsBloc for example also subscribes to the todos exposed by the repository and it converts that data into statistics that are later presented in the UI.

To enhance this setup and promote a more realistic approach for real-world applications, consolidating data storage into a single location would be highly beneficial.

There is still a single source of truth (in this case the repository) and one or more blocs may access data exposed by the repository and transform it as needed into state consumed by the presentation.

Hope that helps 👍

Thanks for the response @felangel

I understood your point but in that case if I want to utilise the hydrated bloc to keep my data hydrated I would have to lose that functionality and implement a persistent storage on the repository level. Is there a way to handle that case?

felangel commented 1 month ago

In this bloc the same model is used in both places but in more real-world, larger apps the data exposed by the repository would likely be quite different from the data exposed by a bloc and the bloc would handle transforming the repository data into the required state. You can see the StatsBloc for example also subscribes to the todos exposed by the repository and it converts that data into statistics that are later presented in the UI.

To enhance this setup and promote a more realistic approach for real-world applications, consolidating data storage into a single location would be highly beneficial.

There is still a single source of truth (in this case the repository) and one or more blocs may access data exposed by the repository and transform it as needed into state consumed by the presentation. Hope that helps 👍

Thanks for the response @felangel

I understood your point but in that case if I want to utilise the hydrated bloc to keep my data hydrated I would have to lose that functionality and implement a persistent storage on the repository level. Is there a way to handle that case?

Hydrated Bloc is meant to cache your application state. If you want to cache repository data then I recommend adding a dedicated cache using your storage solution of choice (hive, sqflite, etc.)

felangel commented 1 month ago

Closing this for now since there doesn't appear to be any actionable next steps. Feel free to leave any follow ups and I'm happy to continue the discussion 👍