A modern programming language that makes developers happier.

kotlinlang

in the roadmap for “Recomposition Tooling” is there any insight into what tooling will be provided? My team and I are talking about how we can roll out compose to a larger group of devs accross our company. Right now seems to not be so much guardrails around recomposition and lint checks warning / (potentially errorring) when functions are not skippable. So we’re debating whether to invest time in some tools to provide the necessary guard rails., or there is plans in the next year to release something

In the near term (Q2/Q3) we will be including recomposition counts in the Layout Inspector. There is also the Compose metrics library that was released recently.

Beyond that, we’re actively working on releasing more tooling for debugging recomposition that hopefully we can release by the end of the year in Canary, but no promises.

What kind of tooling would you be curious in seeing / building?

thank you <@UJJ1A3G1G>. What would be interesting:
1. Lint checks around non `@Stable` / `@Immutable` parameters to a composable (especially with `List` types)
2. Debug overlays on composables that are misbehaving (rendering a lot in a short period of time).
3. Lint checks around unused dependencies in a `remember` or other capture state. (or any dependencies missing like React hooks provides)
4. Probably could go in detekt, but warnings / errors for deeply nested composables (without splitting them into smaller pieces)
5. Provisional render cycle detection and escape hatches. 
6. What composables are heavier on performance (take a lot of CPU on render, re-render) 
In a good architecture, I can imagine we can account for a few of these things, but having them also part of the framework would prevent some issues.