Anyone have an idea of how much overhead there is ...

# compose

[mattinger]

Anyone have an idea of how much overhead there is adding semantic properties? I’m working on testing, and there’s definitely some stuff i’d like to verify. For instance, we have a “Fill” and “Stroke” button (ie. Button and OutlinedButton) that can have a “Tone” that affects the color of the button. The normal semantic tree would only put a “Role” of “Button”. I was thinking of adding a ButtonType and Tone semantic property. Just looking for an idea of the overhead. There’s also a loading indicator, so i was thinking of a Loading property as well.

[Alexandre Elias [G]]

the cost is to allocate a single-digit number of objects at recomposition time and to keep them around in memory. when no accessibility service is active, I think the cost should be somewhat more expensive than an object you store in a remember block, but not by much

[Alexandre Elias [G]]

so I think this is a reasonable thing to do to help your unit testing and your layout inspector view

[Alexandre Elias [G]]

we designed semantics to be extensible in order to allow things like this

[mattinger]

Thanks @Alexandre Elias [G] I’ve been adding properties for some core characteristics of things based on our design system. For example, we have a “Tone” which affects color, “Size” which shrinks the font size and padding, etc…. I’ve been adding those things so that while testing i can make assertions that the elements have been created with the right properties. Not necessarily checking the exact colors, but checking that the right Tone was set.

[miqbaldc]

i can make assertions that the elements have been created with the right properties.

did you able to make this happen on jetpack compose testing? @mattinger

[mattinger]

@miqbaldc Yes. it’s actually pretty easy.

[mattinger]

It’s the same as any other semantic property assertion:

[mattinger]

.assert(SemanticsMatcher.expectValue(SemanticsProperties.Role, Role.Button))

[mattinger]

just use the custom semantic property you created and the expected value (a lot of times, this will be an enum)

[miqbaldc]

Ahhh, thank you~ That’s make sense to use Role

[miqbaldc]

This is unfortunate for the color properties, e.g:

There’s no such SemanticProperty like following:

enum ColorRole { // StyleRole?
   ....Yellow, Orange, DarkJungle, DeepBlue
}

and modify your snippet to:

composeRule.setContent {
   Button()
}

....
.assert(SemanticsMatcher.expectValue(SemanticsProperties.Role, Role.Yellow))