How to deal with unwanted widget build?

FlutterDartFlutter LayoutFlutter WidgetUnbound

Flutter Problem Overview


For various reasons, sometimes the build method of my widgets is called again.

I know that it happens because a parent updated. But this causes undesired effects. A typical situation where it causes problems is when using FutureBuilder this way:

@override
Widget build(BuildContext context) {
  return FutureBuilder(
    future: httpCall(),
    builder: (context, snapshot) {
      // create some layout here
    },
  );
}

In this example, if the build method were to be called again, it would trigger another HTTP request. Which is undesired.

Considering this, how to deal with the unwanted build? Is there any way to prevent a build call?

Flutter Solutions


Solution 1 - Flutter

The build method is designed in such a way that it should be pure/without side effects. This is because many external factors can trigger a new widget build, such as:

  • Route pop/push
  • Screen resize, usually due to keyboard appearance or orientation change
  • The parent widget recreated its child
  • An InheritedWidget the widget depends on (Class.of(context) pattern) change

This means that the build method should not trigger an http call or modify any state.


How is this related to the question?

The problem you are facing is that your build method has side effects/is not pure, making extraneous build calls troublesome.

Instead of preventing build calls, you should make your build method pure, so that it can be called anytime without impact.

In the case of your example, you'd transform your widget into a StatefulWidget then extract that HTTP call to the initState of your State:

class Example extends StatefulWidget {
  @override
  _ExampleState createState() => _ExampleState();
}

class _ExampleState extends State<Example> {
  Future<int> future;

  @override
  void initState() {
    future = Future.value(42);
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return FutureBuilder(
      future: future,
      builder: (context, snapshot) {
        // create some layout here
      },
    );
  }
}

> I know this already. I came here because I really want to optimize rebuilds

It is also possible to make a widget capable of rebuilding without forcing its children to build too.

When the instance of a widget stays the same; Flutter purposefully won't rebuild children. It implies that you can cache parts of your widget tree to prevent unnecessary rebuilds.

The easiest way is to use dart const constructors:

@override
Widget build(BuildContext context) {
  return const DecoratedBox(
    decoration: BoxDecoration(),
    child: Text("Hello World"),
  );
}

Thanks to that const keyword, the instance of DecoratedBox will stay the same even if the build was called hundreds of times.

But you can achieve the same result manually:

@override
Widget build(BuildContext context) {
  final subtree = MyWidget(
    child: Text("Hello World")
  );

  return StreamBuilder<String>(
    stream: stream,
    initialData: "Foo",
    builder: (context, snapshot) {
      return Column(
        children: <Widget>[
          Text(snapshot.data),
          subtree,
        ],
      );
    },
  );
}

In this example when StreamBuilder is notified of new values, subtree won't rebuild even if the StreamBuilder/Column does. It happens because, thanks to the closure, the instance of MyWidget didn't change.

This pattern is used a lot in animations. Typical uses are AnimatedBuilder and all transitions such as AlignTransition.

You could also store subtree into a field of your class, although less recommended as it breaks the hot-reload feature.

Solution 2 - Flutter

You can prevent unwanted build calling, using these way

  1. Create child Statefull class for individual small part of UI

  2. Use Provider library, so using it you can stop unwanted build method calling

    In these below situation build method call

  • After calling initState

  • After calling didUpdateWidget

  • when setState() is called.

  • when keyboard is open

  • when screen orientation changed

  • If Parent widget is build then child widget also rebuild

Solution 3 - Flutter

Flutter also has ValueListenableBuilder<T> class . It allows you to rebuild only some of the widgets necessary for your purpose and skip the expensive widgets.

you can see the documents here ValueListenableBuilder flutter docs
or just the sample code below:

  return Scaffold(
  appBar: AppBar(
    title: Text(widget.title)
  ),
  body: Center(
    child: Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: <Widget>[
        Text('You have pushed the button this many times:'),
        ValueListenableBuilder(
          builder: (BuildContext context, int value, Widget child) {
            // This builder will only get called when the _counter
            // is updated.
            return Row(
              mainAxisAlignment: MainAxisAlignment.spaceEvenly,
              children: <Widget>[
                Text('$value'),
                child,
              ],
            );
          },
          valueListenable: _counter,
          // The child parameter is most helpful if the child is
          // expensive to build and does not depend on the value from
          // the notifier.
          child: goodJob,
        )
      ],
    ),
  ),
  floatingActionButton: FloatingActionButton(
    child: Icon(Icons.plus_one),
    onPressed: () => _counter.value += 1,
  ),
);

Solution 4 - Flutter

One of the easiest ways to avoid unwanted reBuilds that are caused usually by calling setState() in order to update only a specific Widget and not refreshing the whole page, is to cut that part of your code and wrap it as an independent Widget in another Stateful class.
For example in following code, Build method of parent page is called over and over by pressing the FAB button:

import 'package:flutter/material.dart';

void main() {
  runApp(TestApp());
}

class TestApp extends StatefulWidget {

  @override
  _TestAppState createState() => _TestAppState();
}

class _TestAppState extends State<TestApp> {

  int c = 0;

  @override
  Widget build(BuildContext context) {

    print('build is called');

    return MaterialApp(home: Scaffold(
      appBar: AppBar(
        title: Text('my test app'),
      ),
      body: Center(child:Text('this is a test page')),
      floatingActionButton: FloatingActionButton(
        onPressed: (){
          setState(() {
            c++;
          });
        },
        tooltip: 'Increment',
        child: Icon(Icons.wb_incandescent_outlined, color: (c % 2) == 0 ? Colors.white : Colors.black)
      )
    ));
  }
}

But if you separate the FloatingActionButton widget in another class with its own life cycle, setState() method does not cause the parent class Build method to re-run:

import 'package:flutter/material.dart';
import 'package:flutter_app_mohsen/widgets/my_widget.dart';

void main() {
  runApp(TestApp());
}

class TestApp extends StatefulWidget {

  @override
  _TestAppState createState() => _TestAppState();
}

class _TestAppState extends State<TestApp> {

  int c = 0;

  @override
  Widget build(BuildContext context) {

    print('build is called');

    return MaterialApp(home: Scaffold(
      appBar: AppBar(
        title: Text('my test app'),
      ),
      body: Center(child:Text('this is a test page')),
      floatingActionButton: MyWidget(number: c)
    ));
  }
}

and the MyWidget class:

import 'package:flutter/material.dart';

class MyWidget extends StatefulWidget {

  int number;
  MyWidget({this.number});

  @override
  _MyWidgetState createState() => _MyWidgetState();
}

class _MyWidgetState extends State<MyWidget> {

  @override
  Widget build(BuildContext context) {
    return FloatingActionButton(
        onPressed: (){
          setState(() {
            widget.number++;
          });
        },
        tooltip: 'Increment',
        child: Icon(Icons.wb_incandescent_outlined, color: (widget.number % 2) == 0 ? Colors.white : Colors.black)
    );
  }
}

Solution 5 - Flutter

I just want to share my experience of unwanted widget build mainly due to context but I found a way that is very effective for

  • Route pop/push

So you need to use Navigator.pushReplacement() so that the context of the previous page has no relation with the upcoming page

  1. Use Navigator.pushReplacement() for navigating from the first page to Second
  2. In second page again we need to use Navigator.pushReplacement() In appBar we add -
    leading: IconButton(
            icon: Icon(Icons.arrow_back),
            onPressed: () {
              Navigator.pushReplacement(
                context,
                RightToLeft(page: MyHomePage()),
              );
            },
          )
    

In this way we can optimize our app

Solution 6 - Flutter

You can do something like this:

  class Example extends StatefulWidget {
      @override
      _ExampleState createState() => _ExampleState();
    }
    
    class _ExampleState extends State<Example> {
      Future<int> future;
    
      @override
      void initState() {
        future = httpCall();
        super.initState();
      }
    
      @override
      Widget build(BuildContext context) {
        return FutureBuilder(
          future: future,
          builder: (context, snapshot) {
            // create some layout here
          },
        );
      }
    
    
     void refresh(){
      setState((){
       future = httpCall();
       });
    }

  }

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionR&#233;mi RousseletView Question on Stackoverflow
Solution 1 - FlutterRémi RousseletView Answer on Stackoverflow
Solution 2 - FlutterSanjayrajsinhView Answer on Stackoverflow
Solution 3 - FlutterTabaView Answer on Stackoverflow
Solution 4 - FlutterMohsen EmamiView Answer on Stackoverflow
Solution 5 - FlutterRohanView Answer on Stackoverflow
Solution 6 - FlutterCícero MouraView Answer on Stackoverflow