Flow of change notification

Question

I have already understood how the process of changing the state of a widget where it is 'updated' to show its new value. However, the documentation speaks of the flow, that is, the path that is traveled:

In Flutter, change Notifications flow "up" the widget Hierarchy by way of callbacks, while Current state flows "down" to the stateless widgets that do Presentation. The common Parent that Redirects this flow is the State. The following Slightly more Complex example shows how this Works in Practice:

I would like to understand how exactly this 'up' flow works when it refers to notifying change, while the current state flows 'down' to the widget who made the presentation.

*Example referring to the English phrase:

class CounterDisplay extends StatelessWidget {
  CounterDisplay({this.count});

  final int count;

  @override
  Widget build(BuildContext context) {
    return Text('Count: $count');
  }
}

class CounterIncrementor extends StatelessWidget {
  CounterIncrementor({this.onPressed});

  final VoidCallback onPressed;

  @override
  Widget build(BuildContext context) {
    return RaisedButton(
      onPressed: onPressed,
      child: Text('Increment'),
    );
  }
}

class Counter extends StatefulWidget {
  @override
  _CounterState createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _counter = 0;

  void _increment() {
    setState(() {
      ++_counter;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Row(children: <Widget>[
      CounterIncrementor(onPressed: _increment),
      CounterDisplay(count: _counter),
    ]);
  }
}

Answer 1

Well, as visually it is always better to understand, let’s see how would look in a simplified way this code Widgets tree you passed example:

Note that the Counter is the widget that is keeping the variable state _counter, as well as being responsible for the implementation of the _increment() updating the _counter.

Another point is that the reference for this method _increment is passed to the Widgets children of that tree, until the RaisedButton, where it will be used as the implementation of your onPressed.

When the button is clicked then, your onPressed runs, only the implementation is there in our parent widget, so this occurs:

The 'flow up' process mentioned happens, this process is also called callback, for the widget below the tree 'flame again' a Widget above the hierarchy.

When that function _increment is then executed, it updates the value of the _counter and executes the setState, as we well know, this is a special method in Flutter that warns the SDK that it needs to update the status of Widgets by happening:

When updating the setState occurs the process of 'flows down', after all, all the Widgets below in this hierarchy will have their build re-dispatched to fit the new state, then Text that shows the _counter below the tree will show the new value.

In practice Flutter is smart enough to know if the state of the Widget has been changed for its re-export, this involves using Widgets const as explained here for example.

It is worth remembering that:

• All this question of state management in Flutter always yields a good and long discussion, in general it is not very recommended to manage state only with the use of the setState, because of this issue of updating the whole tree.
• It is worth always knowing the management of states with Bloc or Provider, the most accepted at the moment.