Photo by Deniz Demirci on Unsplashg

Flutter widgets - to be Stateless or not to be Stateless (Stateful): that is the question

How to decide the right state for your widget

When you write an App in Flutter, all the UI components are Widgets, there is nothing in the UI that is not a Widget. We compose several widgets to build the user interface, they are the unit of composition.

Widget is the unit of composition

To talk about a Widget we have to talk about its state, they are categorized in two types: Stateless and Stateful.

1. Stateless: a widget that never changes
2. Stateful: a widget that could be changed.

You can find a lot of documentation about how to write an stateless or an stateful widget, but here I will show you which type of state will be the rigth one for your next widget.

If your widget will never change, it is clear, you will define it as Stateless. For example, an Icon is Stateless, an image logo will be stateless, neither a button. But, then you will have more complex widgets, composite widgets, and will be more difficult the make a decision.

Define the architecture of the states

Before coding, you have to define some guidelines which will be part of the application architecture. I wrote other posts where I sent this clear message: the key, to write Flutter apps like a PRO, is to have a state management well defined. So, states must have architectural guidelines.

When we talk about state, is because we need some data to be available in some places. To define where to have the data we need to know who needs it.

Let’s see the picture below:

Picture from the official doc on Flutter.com

First rule: if my widget shares data with others, the state will be managed by the state management, so the widget will be Stateless.

Now, we have to work with those widgets which have data that nobody else needs. Here I will introduce a new variable, the complexity of the widget state.

Widgets that change their state

If the widget will not share data with others and will not use business rules, it will be a Stateful widget.

Otherwise, if the widget needs some kind of business logic, it will be a Stateless widget, and the state manager will be in charge of its states.

Showing a case of study

Photo by Leon Dewiwje on Unsplash

Let’s see an example. Supose we have:

1. a Form embbed in our view which is composed with inputs (text, dropdown,check,etc)
2. each input will be responsable of its value, it will check congruency like text size, text format (email, number), validations that not require any business rules.
3. the Form will create the object with all filled values and call the state management which resolves what to do with that and returns a new state. For example, a BLoC that receives the event with the new object and returns a new state.

As you can guess, the inputs widgets will be Stateful and our Form will be Stateless

Conclusion

1. If the widget will never changed, it will be Stateless
2. If the widget could change, but it doesn’t share data with others and will not use business logic, it will be Stateless
3. If the widget could change and uses business logic, it will be Stateful
4. Design your widget state definition, use it, respect it, share it

Thanks for reading, Clap if you like it!

Photo by Wil Stewart on Unsplash

Let me know your comments below.