Closed faisalansari0367 closed 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 👍
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?
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.)
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 👍
Description
In the TodosOverviewBloc
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.