question: UI interactivity and separation of concerns

[jnorkus]

I have a Home screen that contains a Scaffold with an AppBar and content. The content will change based on selected tab. I would like my AppBar to be dynamic and change its transparency, title and actions based on route and some other properties of deeper nested components within the routes, like a bottom sheet height.

I found myself looking at various implementation paths so I'd like to get some suggestions on what would be the correct BloC way. This is my current approach:

Route is stored in the HomeBloc, HomeView has listeners on the deeper Blocs, that update the HomeBloc with properties like "isAppBarVisible", "appBarTitle", "isAppBarTransparent". AppBar rebuilds based on this state.

My concern is that this looks like presentation logic and maybe it's not the best idea to store it in BloC. So I was thinking maybe this has nothing to do with BloC at all and should be kept within stateful widgets and controllers? Or is it ok to store UI specific properties like view height, transparency, visibility, etc. in BloC?

[felangel]

Hi @jnorkus 👋
Thanks for opening an issue!

Generally, presentation logic should be maintained in the widget tree but there's never a single hard/fast rule for these things so I'd recommend trying a couple of different options and weighing the pros/cons before making a decision. I'm happy to take a closer look at your current implementation (if it's publicly available on GitHub) or if you are able to share a minimal reproduction sample I can take a closer look and provide any suggestions. Hope that helps! 👍

[jnorkus]

Thanks a lot for taking the time to respond.

I decided to completely isolate the presentation logic and use the standard framework classes, like ChangeNotifier, StreamBuilder, etc. to reach my goals. One added benefit is that now the code can be refactored into reusable widgets as opposed to having the logic in the BLL and being app specific.