You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Another solution to this problem, which would be much more useful for devs, would be the ability to start the scan at some point further down in the tree, similar to passing a non-root View to scan(). However that presents a few (solvable) issues:
Composables don't have any implicit identity, so we'd probably need to do something like for filtering and use test tags or layout IDs to identify the root.
The visitor infra doesn't currently support filtering nodes above, only below, so that would have to be implemented. This could also make it possible to visit Groups directly instead of using the intermediate LayoutInfo type - I'm not sure we should, since that type lets us decouple a bit from compose APIs that might change a lot, but we'd have the option.
Having thought about this more, that API makes much more sense than this one. I'll take a stab at implementing it, but would like to not block this PR on it since this API is marked as unstable anyway.
Another solution to this problem, which would be much more useful for devs, would be the ability to start the scan at some point further down in the tree, similar to passing a non-root View to scan(). However that presents a few (solvable) issues:
Having thought about this more, that API makes much more sense than this one. I'll take a stab at implementing it, but would like to not block this PR on it since this API is marked as unstable anyway.
Originally posted by @zach-klippenstein in #33 (comment)
The text was updated successfully, but these errors were encountered: