UI Guides don't work inside closures in build methods

[shinayser]

Just updated to latest version (35.2.3) and UI guides don't work when inside a build method, like the StreamBuilder:

See the ui lines working fine on the top of the images (BlocProvider) but stop working inside the LazyStreamBuilder.

[jacob314]

Thanks for trying out this feature!
To clarify the issue is the Flutter Outline view does not currently show outlines for content within closures. Regular build methods should all work fine.
We will support this case as soon as the Dart Analysis Server supports it. Let us know if you see any cases that look odd. We are in particular interested in any cases where the data we display is inconsistent with what you see in the Flutter Outline View. If it is inconsistent it means we have a bug, otherwise it means there is an opportunity for the outline view to include outline trees for additional data.

@scheglov when do you think the analysis server will support outlines within closures? It would be really nice to support build trees inside closures for the builder case and the ListView case among others.

[devoncarew]

@scheglov, is this something you think you can get to in the near term?

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/103900

[shinayser]

You guys are fast! When will we be able to see that in production?

[jacob314]

The UI guides for this example look nice but I worry they are misleading as some nodes that are not children show up as children.
For example, the header in that example definitely isn't a child of the OrientationBuilder. It is referenced more deeply in the widget tree.
What do you think of adding an intermediate builder: (BuildContext context ...) node
to the flutter outline with a node type so I can detect it? That way we can still show UI guides for widget trees within build methods and potentially indicate that the closure is the source of the children of the OrientationBuilder but avoid making claims that all widgets referenced within a closure are children of the parent widget?

@InMatrix any thoughts about what guides make sense for this case from a UX perspective?

[scheglov]

Well, we never can be 100% sure that this is a parent-child association. Even in case of named parameters like child: - it is just a convention. The widget that accepts this arguments can do just anything with it. What Flutter Outline shows is just a syntactic structure, not the semantic one. It is a reasonable guess that if you give a Widget in a constructor argument, it will be shown as a child. And similarly, if something is returned from a builder, it is a reasonable guess that it will be shown inside the enclosing constructed widget.

That said, I'm not against of inserting an intermediate node here, and as @bwilkerson mentioned in the review also for UI-as-code structures.

[InMatrix]

I agree header should not be identified as a child. If adding an intermediate node is not sufficient, I wonder if we can correct the UI guides using data from the inspector once the user runs the code.