From changelog: > Added DrawModifier, a modifi...

# compose

[dimsuz]

From changelog:

Added DrawModifier, a modifier type that is allowed to draw on the surface of the modified layout.

I have a fear that this modifier-stuff has a potential to make API quite messy where you can do everything in modifier and they'll be misused. Like some widget will decide that it wants to draw its content with DrawModifier and I can't theme it. Or it will decide to size itself through modifier constraints in some clever way and won't let me size it in the usual way. etc etc

Tell me I'm wrong! :)

[Ryan Mentley]

The short answer is that components could always draw or measure themselves in weird ways with or without modifiers - modifiers aren't making this any worse. They could even not expose a modifier parameter and decline to be configurable at all.

That said, the parent ultimately controls the constraints passed to the child, so contractually the child is required to size itself within those constraints (caveat: I don't think this is currently enforced, but you shouldn't count on it not being enforced in the future).

And in terms of theming - you can only theme the parts of a widget that the widget exposes for theming to begin with - modifiers don't change the status quo here either.

If anything, modifiers make it easier, not harder, for components to allow themselves to be configured, because with one parameter, they accept the full range of capabilities of modifiers.

[dimsuz]

Thank you for the detailed answer! My examples were out of head, the main thing I'm concerned with is that modifiers will create some kind of orthogonal configuration parameter space and this would complicate the API. I guess this stems from the fact that I've seen in dev03 that I could limit a width of Container either with Container(width=10) - function argument or with a Modifier.

Someone here told me this is a draft and only one of them will stay, but still, what prevents me as a library author of going the same route?

Although I guess if API would prefer modifiers everywhere this will suggest its users to do likewise.

But still I hope that modifiers end up having clear set of constraints on what you should do with them (and when creating new ones) and what you shouldn't. If they'll be too permissive and generic, this can byte us API-wise.

[Ryan Mentley]

I think we're killing off Container in favor of Box and encouraging exactly this sort of "there's one way to do it" thing - see, for example, the replacement of HeightSpacer and WidthSpacer with a Spacer that accepts a modifier

[Ryan Mentley]

(but that's not a discussion I've been directly involved in so don't take my word as gospel here)

[matvei]

Ryan is right. DrawModifier might be an effecient way to draw something: it just adds drawing to your already-existent layout nodes.

But we will have some higher-level APIs that will eliminate your need to put draw modifiers everywhere and just use Box(modifier = LayoutSize(100.dp, 100.dp), backgroundColor = Color.Red) { /* your content */ } and we do all the draw modifiers work for you 😉