Zach Klippenstein (he/him) [MOD]
08/06/2020, 9:23 PMLayoutNode
and walking the node tree, but many Composables just wrap other Composables and don’t have their own `LayoutNode`s, modifiers are often contributed from multiple composables for a single node, etc, so that’s not ideal either.
I’ve seen some work being done for Android Studio tooling around extracting some data about stuff like this by inspecting the slot table directly. Would it be reasonable to request a public API for exposing that parsing in debug builds?Vinay Gaba
08/06/2020, 9:47 PMZach Klippenstein (he/him) [MOD]
08/07/2020, 1:41 AMasTree()
extension method on SlotTable
, and this seems to return more than enough information for this kind of use case.Vinay Gaba
08/07/2020, 4:27 AMAndrew Neal
08/07/2020, 4:29 AMjim
08/07/2020, 7:47 AMZach Klippenstein (he/him) [MOD]
08/07/2020, 4:43 PMjim
08/07/2020, 4:50 PMZach Klippenstein (he/him) [MOD]
08/07/2020, 7:07 PMremember
in the output from SlotTable.asTree()
, besides just matching the group name, which seems pretty brittle (any function could call itself “remember”). Maybe this is an XY question – the reason this could be helpful is that it could serve as a simple heuristic for data that might represent state that the developer cares about and would want to see in a dump of the current composition. Still playing around with other ways to guess this stuff and try to prevent a slightly-less-overwhelming view of the composition, so hoping I’ll find another way to do this.