Stateless Widget

The Chronicles of Flutter state management

So for a couple of months, I have had this urge to explore the various state management techniques that are available for us in the flutter “ecosystem”, deep diving into what they are, how they are different and the different scenarios in which you can consider using any of them and then try to explain in the simplest of terms. When I got started with flutter I needed something that could help me get started with state management, but most at times, I always more often end up with a tutorial on how to implement it and not necessarily what it is, and when I can consider using it, so i will be taking a deep dive and exploration into it for myself and hoping that it serves as a proper guide for anyone who comes across these chronicles.

Definitely I will not go over all the state management methods that exist, I definitely don’t have the time nor the discipline to sit down and study all of those or do I? What I will be doing is taking most of the popular ones and delving into them.

We are going to start from somewhere and it will be a series that will last us a couple of weeks. We will start with what a widget is and explore through other complex concepts and techniques.

• Widgets(stateless widgets)
• Stateful widgets
• Redux
• InheritedWidget & InheritedModel
• Providers:

— Providers with change notifiers

— Providers with state notifiers

• BLoC / Rx
• GetIt
• MobX
• Riverpod with statenotifiers

Stateless widgets

Let’s start our state management journey in a rather ironic place: talk about the stateless widget. This will help us understand better what state is and allow it to mold our understanding of state and state management.

State: state defines the condition of a system or entity at a specific time (or under specific conditions).

Yeah that’s obvious, you may say but is it?

In life, you may ask a very trivial question as, what’s the state of water at room temperature? It’s liquid, that’s right, but does that mean that water is stateful? Yes sure, due to some external conditions, water is able to change its form or state.

What about a clock, when it is switched on, it starts to tick, indicating time at different time intervals. This is a no-brainer that a clock in that aspect is stateful, it reacts to external input and continues to represent different values at different intervals of time (self sustained). But what about a clock without a battery that needs you to continually come to turn its hands to change the current configuration of the clock? It automatically makes that particular clock stateless, why? Because the clock left on its own will take and maintain the configurations placed on it except a new configuration is inputted.

Therefore in simple terms, a stateless widget is a widget that once built, its internal configurations and external presentation does not change except forced to be rebuilt with new configurations and representations from an external control (or creating a totally new object).

Stateless widgets are basically immutable, and can not induce a self rebuild or redraw itself.

Stateless widget are useful when the part of the user interface you are describing does not depend on anything other than the configuration information in the object itself and the BuildContext in which the widget is inflated. Source Flutter.dev

Lets take the example of a text widget as such,

Text(“Hello There”)

Once that is built, it will present the “Hello There” text on the device, if for instance you needed it to display something a little different than that something like “Hey There”, you will need to create a new text Object to do this.

Text(“Hey There”)

This makes sense and is necessary, as flutter as a matter of fact created a set of stateless widgets like Text, Icons, Colors, containers etc to be the building blocks or foundations of a flutter app such that even a stateful widget with changing representations is just a couple of stateless widgets that are built interchangeably based on the state of the parent stateful widget (we will see more of this in the stateful widget section).

For instance if you wanted to create a checkbox widget, it will have two stateless widgets one for blank and one for checked that are shown interchangeably when an external action like a click changes the internal state of the parent widget to determine which one should be displayed.

That said, lets take a look at the structure of a typical custom stateless widget

Here we see a typical class definition which extends from the StatelessWidget class provided from the material.dart package. This StatelessWidget super class provides methods like the build method that needs to be overridden to define the particular stateless widget being implemented. The build method here is like the render method in react that displays whatever widget it returns (widget composability) in our case a Container widget. The build method takes in a parameter of type BuildContext which is unique for every widget built and is necessary as it helps to locate the widget in the widget tree. If we notice, the BlueSquare widget requires a parameter that specifies its size.

const BlueSquare(size: 50)

And that is creating the object of the BlueSquare stateless widget bringing us to a wrap on the stateless widget and this part of our series. If you are wondering why the const keyword is in front of the constructor then checkout my previous article on that.

See you on the next one, where we will be exploring and diving deep into the stateful widget, I hope this article is informative and helps you in your flutter journey.