Optimizing UI rebuilds with 'ConsumerWidget'

[wujek-srujek]

I have a page whose small part (whether a Scaffold has a FAB or not) depends on provider state. For now, the code is this:

class Abc extends StatelessWidget {
  const Abc();

  @override
  Widget build(BuildContext context) {
    return Consumer(
      builder: (context, watch, child) {
        final state = watch(someProvider);

        return Scaffold(
          body: child,
          floatingActionButton: <depends on `state>,
        );
      },
      child: SafeArea(...),
    );
  }
}

I'm doing this so that the bulk of the UI doesn't get rebuilt unnecessarily, right now basically only the Scaffold and its FAB are rebuilt.

It seems a bit strange to have a StatelessWidget + Consumer as the root Widget in build, why not use ConsumerWidget directly?

It turns out ConsumerWidget doesn't support the child functionality. I can create a field final Widget child (or similar) and initialize it in the constructor, but it has downsides:

• In my case, it prevents the Abc constructor from being const (as part of the widget tree I try to cache isn't const).
• I don't have access to a BuildContext (which I use to read another provider in an event handler, i.e. it doesn't cause rebuilds of the whole widget tree).

I could address the second issue by either introducing a Builder or restructuring my code so that the whole body is a separate Widget class, but in this case it defeats the purpose as it would either result in an artificial additional widget (Builder) or some unnecessary boilerplate introducing a new Widget - in both cases my current solution is arguably more readable (the tree under SafeArea is small enough. (A separate widget would also make it possible for the Abc constructor to be const.)

Is it 'normal' to use StatelessWidget + Consumer at the root of the build method, the way I'm doing now, or am I missing something obvious, don't know about something?

[rrousselGit]

You're probably over thinking. But maybe you want the following?

Scaffold(
  body: SafeArea...
  floatingButton: Consumer(...)
)

[wujek-srujek]

This was actually my initial attempt, but I don't think this works because Consumer.builder returns Widget not Widget?, and if I don't want a Fab I would need to return null. Or use a hack like SizedBox.shrink or something like this instead, which I don't really like - if no Fab should be included, I would prefer it to be null.

What part am I overthinking, could you say more?

[rrousselGit]

What part am I overthinking, could you say more?

This sort of optimisation doesn't bring much unless very specific cases like animations with high refresh rate.

Consumer.builder returns Widget not Widget?,

In that case your current code is fine.

[wujek-srujek]

Yes, that's true, I might be overzealous with optimizations. The point is, I have read so much about optimizing UI, watched so many videos, read and heard so much about the importance of const for Widgets from various people, including you, that I started doing it this way naturally. In my specific case, though, I'm writing a timer app with high accuracy (i.e. parts of the screen will be refreshed at a pretty high frequency), and I think the difference between rebuilding the whole UI vs just a little part may make a huge difference. I know, it has to be measured, but in this case writing code that will definitely be well performing (only rebuilding what's really necessary) is not at all harder than writing code that may be bad - a low hanging fruit.

[wujek-srujek]

After an update to 1.0.0 I will need to restructure this code anyway as the BuildContext.read extension is gone and I will need the Consumer or something similar to be able to use read.

[esDotDev]

It does seem like an odd limitation to not allow Consumer.builder to return null. Especially as Flutter regularly accepts Widget?, like in the case of scaffold.fab.

This is certainly a valid use case and would prevent the entire scaffolds from rebuilding, which could be a significant cost savings.

With that said, returning a container or sizedbox doesn't seem like a big problem to me... Its a common approach when you want to render nothing.

[rrousselGit]

A StatelessWidget/StatefulWidget cannot return "null". Consumer is in the same situation. Same goes for StreamBuilder and many other widgets

[esDotDev]

I guess I was thinking that internally the Consumer is doing something like:

return builder.call(context, ref) ?? SizedBox.shrink();

So the builder can return null, to indicate 'render nothing' basically. Seems like it could be handy.

[rrousselGit]

That would break if you used Consumer in a place that uses a different contract than RenderBox for UI, like slivers/CustomScrollView

If SizedBox.shrink works for you, I'd suggest simply returning that on your own instead of returning null

[esDotDev]

Interesting, that never occurred to me with regards to Sliverlists. I don't have an particular need for this, more so just commenting that it would be some nice syntax sugar.