Hey all, looking for some best practices/opinions/...

# compose

[Tash]

Hey all, looking for some best practices/opinions/insights:

We’ve built a Compose component library and created Android View wrappers for easier interop. For example, TextButton : AbstractComposeView internally calls @Composable fun TextButton. We use a custom setIsEnabled() instead of the traditional View#setEnabled that updates the Compose state which makes Espresso testing a bit tricky.

We’re considering overriding View#setEnabled and calling super.setEnabled() in addition to updating the Compose state, to sync Compose and view layers, but are concerned about conflicts with rendering since View#setEnabled does cause layout invalidation.
1. Is it advisable/ok to override View#setEnabled for Views that extend AbstractComposeView ?
2. Any other suggestions for syncing Compose and view layers while keeping Espresso testing straightforward?
Thanks!

[Zach Klippenstein (he/him) [MOD]]

If you change compose state from that method, that will also invalidate any parts of the compose view that read that state. All of those updates, both the compose and view ones, will happen on the next frame. So I’m not sure what is getting out of sync

[Tash]

That makes sense.. But is it "bad" performance wise to invalidate the View in both View and Compose land?

Are there other (better) ways of making it easier to Espresso test and assert enabled states on such Views?

[Tash]

I'd imagine this would extend to other general interop scenarios such as inflating a ComposeView in an xml hierarchy and trying to assert View based matchers on that...Do we set equivalent View properties for those cases as well, just to make it easier to Espresso test, or is there another way?

[Zach Klippenstein (he/him) [MOD]]

are you toggling the enabled flag on every frame, continuously?

[Zach Klippenstein (he/him) [MOD]]

if you’re not (and i hope you’re not), then it’s not even worth asking really

[Zach Klippenstein (he/him) [MOD]]

as for testing, it’s up to you really, however you want to write your tests

[Tash]

Haha that's a good point 👍

[Tash]

For anyone curious reading the thread: came across this that favors using UIAutomator for interop UI tests (when migrating to Compose).
https://joebirch.co/android/compose-interoperability-in-espresso-tests/

Maybe this might be a way to go for some. I can’t imagine things scaling if you have to “sync up” View/Compose states for every interop case when writing Espresso tests.