[Design Question] Single state with different values?

[matanshukry]

My use case is a some local configuration fields or settings, that can change through the app lifetime. e.g. theme, to show/hide some texts, and "small stuff" like that.

I thought about creating a single non-abstract state, with a field of properties, and an event to change the properties. due to the docs, and the way the classes are designed (e.g. initialState), it sounds a bit counter-intuitive to me.

Is that the correct way to design such a thing? Is there a better way?

[felangel]

Hi @matanshukry 👋 Thanks for opening an issue and great question.

In general, I would not recommend having a single bloc with multiple responsibilities. Instead, I would recommend having a ThemeBloc, NetworkConnectionBloc, etc...where each bloc has specific states that are all related to a single functionality/feature.

Hope that makes sense! 👍

[matanshukry]

@felangel thanks for taking the time to answer! It make sense in some things, but in this case I'm talking about properties that doesn't have any more states or functionality other than the value it self. Think about properties such as (taking from WhatsApp as an example): Status - a text that the user set, and will be sent to the server. Last Seen - "Everyone"/"My Contacts"/"Nobody. Again, only sending it to the server.

and even ThemeBloc you mentioned - what would be the states of that? Considering the use of flutter Theme, it would probably have a ThemeState, with only 1 state. Possibly 2, if you want to load it from properties or a file.

Let's consider this settings class data:

class AppSettings {
  final ThemeType theme; // None, White, Red, Yellow, etc. Only around 10 values
  final String status;
  final VibrateMode vibrate; // Off, Default, Short, Long

  ... ctor ...
}

What states would you give this one?

[felangel]

@matanshukry no problem!

For Status and Last Seen I'm not sure I understand the scope of the feature. If it's literally a piece of data that you show on a screen, then I think it would make sense to wrap those into a ProfileBloc. The status could then just be part of the ProfileBlocState.

Regarding a ThemeBloc, your states could just be different ThemeData objects. You can check out the Weather App Tutorial for an example.

In general, I recommend thinking of a bloc as a finite state machine. I try to think of my features/functionality in this way before determining what bloc(s) to create.

Hope that helps 👍

[matanshukry]

I think there was a bit of confusion about what I meant. However, I never noticed the Weather app example - it is exactly the design I was wondering about.

Specifically, the fact that there is only a single state in there (ThemeState) and even a single event. I can see it is fine though and looks good.

Thanks!

[felangel]

Awesome and sorry for any misunderstanding!