Bloc: Two BlocProviderTrees?

Created on 11 Jun 2019  路  3Comments  路  Source: felangel/bloc

I was wondering if it's proper or possible to provide two BlocProviderTree's. For example, an application I am working on launches two different screens for two different users. Each screen has it's own hosted BottomNavigationBar that is different than the other. At the moment, the main.dart listens for the authenticationBloc to authenticate the user, and determine the user type to bring them to either page that hosts their own BottomNavigationBar with their own unique layouts. The main.dart hosts a BlocProviderTree that provides many blocs. However, we are running into problems with blocs persisting information once the user has logged out. For example, when signing out from the application and signing back in with a new user, the profile page is still loaded from the previous user signed in. Forgive me if this is answered somewhere else but what is a general rule of thumb with what goes in the tree and what doesn't.

question

Most helpful comment

Hi @carmenkerim12 馃憢
Thanks for opening an issue!

Just as @craiglabenz pointed out, you should only scope blocs to the parts of the application that need them in order to eliminate the issue you described. In addition, BlocProvideTree is just syntactic sugar for nested BlocProviders so it doesn't provide any special functionality and just makes the code a bit easier to read when you're providing more than one bloc to a subtree.

I would strongly recommend that before providing a bloc you ask yourself which widgets need access to that bloc or its state. Then find the closest common ancestor to all of the widgets and initialize/provide the bloc there instead of making all of your blocs globally accessible.

Hope that helps and great question! 馃憤

All 3 comments

Is your authenticated user data stored in the bloc or in a lower-level repository? Generally, you'll want to store data in lower level classes that the BLoC merely coordinates.

Do you have any code samples?

Hi @carmenkerim12 馃憢
Thanks for opening an issue!

Just as @craiglabenz pointed out, you should only scope blocs to the parts of the application that need them in order to eliminate the issue you described. In addition, BlocProvideTree is just syntactic sugar for nested BlocProviders so it doesn't provide any special functionality and just makes the code a bit easier to read when you're providing more than one bloc to a subtree.

I would strongly recommend that before providing a bloc you ask yourself which widgets need access to that bloc or its state. Then find the closest common ancestor to all of the widgets and initialize/provide the bloc there instead of making all of your blocs globally accessible.

Hope that helps and great question! 馃憤

Okay, that makes a lot of sense! Thank you guys for taking the time to answer and help me out. This pointed me in the right direction! Thank you again!

Was this page helpful?
0 / 5 - 0 ratings