为什么有状态的小部件在 flutter 中定义为两个类？

Question

I'm new to flutter/dart, so while I try to make an app I also try to understand why things are a certain way. In the flutter docs there is example code of a stateful widget as shown:

class YellowBird extends StatefulWidget {
  const YellowBird({ Key key }) : super(key: key);

  @override
  _YellowBirdState createState() => new _YellowBirdState();
}

class _YellowBirdState extends State<YellowBird> {
  @override
  Widget build(BuildContext context) {
    return new Container(color: const Color(0xFFFFE306));
  }
}

Questions:

1. Why are they defined with two classes as opposed to one? I'm guessing the State class can be used somewhere else so it was better to be split up.

2. From what I understand the createState() function returns an object of type State , so having _YellowBirdState extends State makes sense, but why is YellowBird passed into the generic class of State ? My guess it has something to do with Yellowbird extending the StatefulWidget class but not quite sure.

Answer 1

There are multiple reasons :

• Widgets are immutable. Since StatefulWidget extends Widget it therefore must be immutable too. Splitting the declaration into two classes allows both StatefulWidget to be immutable and State to be mutable.

• Widgets are instantiated using the syntax new MyWidget() . If we merged both classes into one, new MyWidget() would reset all the properties of the state every time its parent update.

As for the explanation of class _MyStatefulState extends State<MyStateful>

That is because the State class can access to it's Stateful part using the this.widget field. The generic is here to make that field of type MyStateful instead of just StatefulWidget . As you may want to access MyStateful properties.

Answer 2

1. One of the main design decisions of Flutter is that it is cheap to re-create Widgets, so build() can be called to rebuild a branch of the widget tree when something changes. This works fine for stateless widgets which are given their immutable values through the constructor. But stateful widgets need to preserve their state across builds. In your example, the framework can create multiple YellowBird s, but it only ever creates one YellowBirdState . Each newly created YellowBird gets transparently hooked up to the existing YellowBirdState by the framework.

2. A subclass of State needs to know its Widget type so that the compiler knows what type the variable widget is. In YellowBirdState you can refer to the Widget with widget . If YellowBird had a member variable final String foo , the compiler knows that widget.foo is the String called foo in YellowBird .

Answer 3

class YellowBird extends StatefulWidget

StatefulWidget is an immutable class (Immutable class means that once an object is created, we cannot change its values).

1. The class must be declared as final (So that child classes can't be created).
2. Data members in the class must be declared as final. (So that we can't change the value of it after object creation).
3. A parameterized constructor.
4. Getter method for all the variables in it. No setters (To not have the option to change the value of the instance variable).

---

class _YellowBirdState extends State<YellowBird>

State class which type is generic is a mutable class that can be instantiated with different values after creating its object.

Same as this StatefulWidget class which is immutable is calling a function of createState() which define the class State of the widget after its called in a flutter so we can change the values of the widget again and again by this approach but we cannot change the type of Stateful or Stateless.

Answer 4

The Flutter documentation explains this.

Having separate state and widget objects lets other widgets treat both stateless and stateful widgets in exactly the same way, without being concerned about losing state. Instead of needing to hold on to a child to preserve its state, the parent can create a new instance of the child at any time without losing the child's persistent state. The framework does all the work of finding and reusing existing state objects when appropriate.

Basically, its so that a Stateful Widget can be re-instantiated (whenever its build() , eg from a state change) without losing its state.

This is also enforced by Widgets being immutable, so the mutable state data must be stored elsewhere: the State object.