* StalessWidget comes from Widget > DiagnosticableTree > Diagnosticable. It defines a user interface by returning a Widget in its build function. 1/
In StatefulWidget and StatelessWidget, both, the build function receives a BuildContext using which you can retrieve information from up the build chain in order to complete rendering your widgets. 2/
StatelessWidget is rebuilt only in 3 cases. 1) it's the first time it's being rendered to the screen. 2) The parent of this widget's configuration changed resulting in a repaint of the widget tree. 3) if it depends on an InheritedWidget who whose content changed! 3/
StatelessWidget usually contain constant constructors though they are not limited to that. They can have final fields whose values are not necessarily constants. StatelessWidget itself howsoever has a constant constructor. 4/
StatelessWidget's build function has to return a Widget which in turn can contain other widgets or even StatefulWidget instances so the parent of a StatefulWidget can in fact be a StatelessWidget. 5/
StatelessWidget in Flutter is usually the best place to have a render object whose rendering is only dependent on the parameters using which the widget itself is constructed. In other words, its contents won't change over time 6/
StatefulWidget is divided into 2 parts. A class extending StatefulWidget and a class State<T> where T is the class name of the stateful widget itself 7/
StatefulWidget together with its state construct a render object that Flutter then uses to construct what the user sees on the screen. A StatefulWidget's State object can mark the widget as needing to be rebuilt by calling the setState() function 8/
The setState() function is defined on State, not the StatefulWidget itself. Hence, StatefulWidget instances are usually constants with const constructors whereas their State objects are the ones that carry the state, as their names imply 9/
setState() function cannot return a Future<T>. That means if you have asynchronous work to perform inside State<T> of a StatefulWidget, you need to perform them before and then call setState() asynchronously and then call setState(). setState cannot be marked as async either. 10/
It is recommended that your perform the actual changes that are applied to your State<T> inside setState() and perform any asynchronous work that actually computes those changes, before calling setState() 11/
The State<T> object together with StatefulWidget form a render object that Flutter then uses in order to construct the user interface. The State<T> object always has access to its stateful widget using its "widget" property. end/
โข โข โข
Missing some Tweet in this thread? You can try to
force a refresh
Confused about #Provider in #Flutter? Thread to explain some of the most important concepts
๐งต๐๐ป
context.select() is used when you want to watch a specific aspect of a provider and rebuild your widget upon that value changing. It's only useful inside the build() function of your widgets and changes to the selected value will mark the widget as needing to be rebuilt
by using context.select(), you rebuild your widget only if the given aspect of your provider changes, this is specially useful if you have a large provider with many moving parts