Zach Klippenstein (he/him) [MOD]08/06/2020, 9:23 PM
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 Gaba08/06/2020, 9:47 PM
Zach Klippenstein (he/him) [MOD]08/07/2020, 1:41 AM
extension method on
, and this seems to return more than enough information for this kind of use case.
Vinay Gaba08/07/2020, 4:27 AM
Andrew Neal08/07/2020, 4:29 AM
jim08/07/2020, 7:47 AM
Zach Klippenstein (he/him) [MOD]08/07/2020, 4:43 PM
jim08/07/2020, 4:50 PM
Zach Klippenstein (he/him) [MOD]08/07/2020, 7:07 PM
in the output from
, 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.