Overriden shouldRelayout doesn't have access to BoxyDelegate

[WasserEsser]

I'm not sure if I'm being stupid, or if this is a bug or if the error message is wrong and this is not allowed (though it seems like it should?).

Consider this implementation of BoxyDelegate. The important part is the shouldRelayout function.

class TestBoxy extends BoxyDelegate {
  @override
  Size layout() {
    // do layout
  }

  @override
  bool shouldRelayout(covariant TestBoxy oldDelegate) {
    return children.length != oldDelegate.children.length;
  }
}

This will throw the following error on rebuild when the shouldRelayout function is trying to access either its own children or those of oldDelegate.

The EvenlySizedBoxy boxy delegate attempted to get the context outside of its normal lifecycle.
You should only access the BoxyDelegate from its overridden methods.

Am I doing something wrong, is the error message wrong or is this a bug? I am accessing the properties of either delegate in an overridden method.

[pingbird]

if the children are updated in any way the boxy will be laid out automatically, the error you are getting is from accessing the old delegate's children from outside of its lifecycle

[WasserEsser]

It sounds like I don't need to override the shouldRelayout function at all then.

But I don't understand how the error message is correct because all I'm doing is overriding the method (which, according to the error message should be the correct way). It's also already throwing an exception just accessing the boxy's current children, before trying to access the old delegate's children. It appears as though the shouldRelayout function (which I'm not calling myself) is being called outside of the boxy's lifecycle? Is that an error on my part? Because I don't see how I could influence this in any way. If not, it appears as though you just can't access any property of the boxy delegate or the old delegate in the shouldRelayout function, which makes the whole function pointless to override.

[pingbird]

Apologies if the docs are insufficient but the shouldRelayout and shouldRepaint methods are used in the same manner as CustomPainer.shouldRepaint, to compare custom properties that you have added to the constructor of the delegate:

class _TreeViewBoxy extends BoxyDelegate {
  _TreeViewBoxy({
    required this.root,
    required this.verticalSpacing,
    required this.horizontalSpacing,
  });

  ...

  @override
  bool shouldRelayout(_TreeViewBoxy oldDelegate) =>
      root != oldDelegate.root ||
          verticalSpacing != oldDelegate.verticalSpacing ||
          horizontalSpacing != oldDelegate.horizontalSpacing;
}

If your delegate has no parameters then there is no reason to implement the method.

If you want your boxy to relayout based on something other than it's own properties changing or constraints changing or a child updating, you'll probably need to use a notifier of some sort.

[WasserEsser]

Ah, I see, that makes sense. Thanks for clarifying!