Lint for AnimatedBuilder/ValueListenableBuilder's child property

[dnfield]

BAD:

return AnimatedBuilder(
  animation: someAnimation,
  builder: _builder,
  // no child
);

Widget _builder(BuildContext context, Widget? child) {
  return SizedBox(
    height: someAnimation.value * someOtherValue,
    child: SomeOtherWidget(), // child does not need the value of the animation
  );
}

GOOD:

return AnimatedBuilder(
  animation: someAnimation,
  builder: _builder,
  child: SomeOtherWidget(),
);

Widget _builder(BuildContext context, Widget? child) {
  return SizedBox(
    height: someAnimation.value * someOtherValue,
    child: child,
  );
}

Similar for ValueListenableBuilder, but that one might be easier because the actual value we're interested in is part of the method signature (so no need to correlate someAnimation as in the AnimatedBuilder).

/cc @Hixie

[Hixie]

Yeah the AnimatedBuilder case is particularly tricky because you have no way to know what the incoming Listenable is actually telling you. It could be "the time has changed" and somewhere else you use DateTime.now(). Or "the network updated the data model" and the rest of your tree is based on reading the data model.

The ValueListenableBuilder one is great though, that one should be much easier to do.

[pq]

Does an annotation on child seem like the right approach here?

const ValueListenableBuilder({
  ...
  @notNull
  this.child,
});

See also: flutter/flutter#91616

[Hixie]

It's common to not have a child.

[dnfield]

This one is a bit different. It's saying you should use child if there's some widget subtree in the builder function that isn't using the value, e.g.

// a ValueWidgetbuilder
Widget buildWidget(BuildContext context, double value, Widget child) {
  return SizedBox(
    height: value, 
    child: ColoredBox(color: Colors.red),
  );
}

The idea is the analyzer could possibly detect that value is not used in the ColoredBox or below, and tell the user that the ColoredBox should be passed as the child argument to the ValueListenableBuilder that's using buildWidget.

[pq]

Ah, OK. Thanks! This is useful.

Can you think of a way that we could generalize this or communicate this contract via an annotation (or pragma)?

Respecting @Hixie's #58543, I'd like to strive for a solution that is more durable than one that encodes class names and URIs...

[dnfield]

Perhaps something on ValueWidgetBuilder like this:

@widgetTreeBelowLastUsage(variableName: 'value', shouldUse: 'child')
typedef ValueWidgetBuilder<T> = Widget Function(BuildContext context, T value, Widget? child);

[dnfield]

(I'm not fond of that name but you get the idea hopefully)