Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
faisalansari0367 opened this issue May 10, 2024 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@faisalansari0367
Copy link

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
Copy link
Owner

felangel commented May 10, 2024

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 👍

@felangel felangel added question Further information is requested waiting for response Waiting for follow up labels May 10, 2024
@felangel felangel self-assigned this May 10, 2024
@faisalansari0367
Copy link
Author

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
Copy link
Owner

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
Copy link
Owner

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 👍

@felangel felangel removed the waiting for response Waiting for follow up label May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants