Explore exposing InspectorInfo in the rendering/filtering API.
- Dominant language
- Kotlin
- Stars
- 899
- Forks
- 55
- PR merge metrics
- No merged PRs in 30d
Description
There is an effort ongoing right now to add `InspectorInfo` modifiers to all modifiers that describe their values in a human-readable way for some sort of debugger (presumably the LayoutInspector in Android Studio?). This is exactly the sort of information that could be useful for Radiography to render.
There's an example CL that adds this to a modifier [here](https://android-review.googlesource.com/c/platform/frameworks/support/+/1472686/3).
**Action items:**
- [ ] Figure out how this info is stored in the slot table and how to extract it.
- [ ] Is this information actually worth surfacing explicitly somehow in the Radiography API? (E.g. in `ComposeView` somehow.) Should it replace exposing modifiers entirely? Are more type-safe modifiers still a better API for reflectively selecting and rendering type-safe data?
Note that even if this does provide a better source of debug data going forward, it will only be available on newer versions of Compose for some time, so Radiography will need to support both for at least a few releases.
Contributor guide
Research direction
Start with the linked Android example CL and investigate how InspectorInfo is stored in the Compose slot table and whether Radiography can extract it. Then assess how the information could fit the rendering/filtering API or ComposeView, including support for older Compose versions. Done means documenting a decided API direction and compatibility approach.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- devtools, mobile-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100