Flutter performance of StatefulWidget and StatelessWidget

Question

I use a lot StatelessWidgets when I have to create "templates" of widgets that are used multiple times inside my app because the docs say so:

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.

Here is an example:

class StepInputButton extends StatelessWidget {

  final int pos;
  final String value;

  const StepInputButton({
    this.pos,
    this.value
  });

  @override
  Widget build(BuildContext context) {
    return Row(
      // Text, Icon and a tiny button
    );
  }

}

The above is good because I can use const StepInputButton(val, "val"), in the code with CONST which improves performances.

---

PROBLEM

I am using the famous Provider widget to manage the state and the page of my apps usually look like this:

class SuccessPage extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    var prov = Provider.of<Type>(context);    
    return Scaffold(...); 
  }

}

That's a page of my app with Scaffold that has a Drawer, a float action button and an appTitle. Here I use a StatelessWidget because I do not use setState() since provider does all the work for me. But still in the official flutter doc they say:

For compositions that can change dynamically, e.g. due to having an internal clock-driven state, or depending on some system state, consider using StatefulWidget.

So do I have to change class SuccessPage extends StatelessWidget to class SuccessPage extends StatefulWidget? Do I get advantages?

Note: if you want to put the question in another way: should I use StatefulWidgets to create "app pages" whose state is going to change and StatelessWidgets for "reusable widgets" whose state doesn't change?

Answer 1

StatefulWidget is necessary for when the widget itself is maintaining its own state. In the example you gave, the Provider package is handling the state for you, assuming you're using the correct provider type higher up the widget tree (for example, ChangeNotifierProvider). There also doesn't seem to be anything in this code that would benefit from having access to the widget's lifecycle, so you wouldn't need access to methods like initState or dispose.

As such, there's nothing for the widget itself to manage, so converting your class to be stateful is unnecessary.

One thing I might suggest, though, is to use a Consumer instead of calling Provider.of directly. A Consumer handles the call for you and removes any ambiguity on whether your widget will get updated when the Provider detects a state change.