IssueTracker

See: https://twitter.com/chrisbanes/status/1507392337399500801

Now that compose is maturing and best practices are being solidified it could really help newcomers to compose to have android lint rules for a lot of common cases.

It looks like the twitter team added lint rules for:

1. "We have one that detects that, for composables that emit Layouts, we should add a modifier, and link to @chrisbanes post about it https://chris.banes.dev/always-provide-a-modifier/ "
2. "We have a rule to make sure composables don't emit content at their top level. "
3. "We also added one that made sure that composables that emit content don't return a result as well. We make sure that all composables that emit content return Unit."
4. "We detect if viewModel() is acquired in a composable function body. If it is, we prompt for it to be injected into the composable as a parameter via a default value, to facilitate testing and reusability."
5. "Continuing with ViewModels, we detect if they are forwarded to other composables. We are pushing very hard to get stateful composables in line: if you acquire a ViewModel in a composable, you have to grab/hoist its state + allow sending events back via some lambda."
6. "We also detect if composables have commonly used known mutable types as parameters. We use an allowlist for common platform mutable types + Compose's MutableState (which was the #1 by far, that we saw in code reviews)"
7. "These snuck in a couple of times, and they were easy to miss: mutableStateOf / derivedStateOf, when used inside of a composable, should be remembered. So we added a rule for that"

It would be cool if the AS/compose team could incorporate some of these as I feel like they're applicable to every compose dev.