Are Flutter State widgets an illusion?
What if I say there’s only one widget type in Flutter. i.e. not Stateless and StatefulWidget but only StatefulWidget?
Keep digging how StatelessWidget and StatefulWidget works. Let’s check StatefulWidget code:
Not seeing anything specific hmm!!!! Strange. So when we check online courses and other stuff they always give us there are two widget types Stateful and Stateless, create State and call setState() to update the screen for Stateful widget and you can’t update Stateless widget.
let’s check the code for setState.
So it goes to element and calls markNeedsBuild which is from the Element class. which states that the widget has become dirty and needs to rebuild.
What is an Element?
An Element represents the use of a widget to configure a specific location in the tree. The element can change if the parent widget rebuilds and creates a new widget for this location. Element(mutable property) are created by createElement() method. The framework calls the mount method to add the newly created element to the tree at a given slot in a given parent.
For more info, see this documentation
Okay, so why I’m saying that there’s just one widget? Wait for a second what let’s check StatelessWidget code
We often write the build method in StatelessWidget as it’s abstract, but what is StatelessElement?
and this ComponentElement extends to Element. so everything is related.
Now that we are on the same page the Stateful and stateless widget use Elements to render and update based on dirty states.
All in All, it looks the same if we compare the Stateful and Stateless class so why there are two separate things? From my perspective, it’s there to reduce the developer problems with creating Elements every time the widget needs data and hides the true logic of this markNeedsBuild from the developer’s end.
But! But! wait so why it’s good to know this? We are not open-source contributors but we can if we understand the under-the-hood of how things work. This concept was utilised in the dart Provider package, which we almost all use for state management.
Here we have ChangeNotifierProvider which notifies when data changed rebuild the child widget.
And for ChangeNotifierProvider it extends with ListenableProvider class
check the constructor it sends startListening to the inheritedProvider which is Provider package class.
in that _startLitening method, we have value?.addListener(e.markNeedsNotifyDependents); value is a LinkedList which stores listeners that are listening to the changes of ChangeNotifier. in that markNeedsNotifyDependents method we have markNeedsBuild which will get called for the child that we are passing.
now that we know this…
Two different Widget types are there to reduce complexity. Demo code Link 👇
Hope you liked it.
Do you know you can press the clap👏 button 50 times? The higher you go, the more it motivates me to write more stuff!
Hello, I am Parth Dave. A noob developer and noob photographer. You can find me on Linkedin or stalk me on GitHub or maybe follow me on Twitter?
Have a nice fluttery day!
