Is it a bad idea to introduce tooling to fail CI builds if the compiler metrics shows an unstable cl...

# compose

[eygraber]

Is it a bad idea to introduce tooling to fail CI builds if the compiler metrics shows an unstable class being used as an input to a composable function?

[Ben Trengrove [G]]

You could do a warning, failing seems a bit strong to me. Unstable != Bad

[eygraber]

In my use case unstable might be worse than it typically is. I collectAsState on a Flow at the top level of my features, and fan out the state to the specific composables that need it.

That state is always marked as Immutable but if one of its values (or grandchild values, etc...) is unstable it can cause a whole subtree to not get skipped when it should have.

[Ben Trengrove [G]]

Fair enough but just a warning is probably fine. There will be cases where trying to force everything to be skippable/stable will just add huge amounts of complexity to code for no real gain in performance and if you are failing a build for it, I don't think it makes sense

[eygraber]

I'm hoping I can build an exclusion feature for that.

[Ben Trengrove [G]]

A better solution would be writing performance benchmarks and failing a build when you regress performance. Admittedly that's probably a bit more effort to set up though

[eygraber]

First I need unit tests 😬

[Stylianos Gakis]

A better solution would be writing performance benchmarks and failing a build when you regress performance. Admittedly that’s probably a bit more effort to set up though

A precedent for something like this can be set by introducing this setup in NowInAndroid. Do you think there’d be room for something like that there?

[Ben Trengrove [G]]

It is actively being investigated right now

[Stylianos Gakis]

Awesome! Is this discussion taking place in a public setting? Is there an Issue inside NiA I can for example follow, or is it too early for that?

[Ben Trengrove [G]]

I don't think there is a public issue currently, I'm not 100% across it though