Isn't `Modifier` the new `LayoutParams` in a way?

# compose

[louiscad]

Isn't Modifier the new LayoutParams in a way?

[Vinay Gaba]

I think Modifiers do a lot more than just that.

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

Kinda, yea. It's not an exact 1:1 relationship, but it is one of their use cases.

[Adam Powell]

Kind of a fusion of LayoutParams and the assortment of general-purpose properties that accumulated on the View class over the years, but with (ideally) less of a fragile base class problem

[louiscad]

@Adam Powell You mean more… composable?

[romainguy]

It’s so much more 😛

[romainguy]

To me modifiers are closer to the concept of components in Entity-Component Systems

[Adam Powell]

@louiscad yes, the strong ordering property is a big part of what creates that composability and why I think it's worth the tradeoff of explaining why we don't have a fixed ordering of position-independent margin/padding 🙂

[louiscad]

It’s so much more 😛

So much or too much? Regardless, I'm wondering about the discoverability of these abilities (at least, the built-in ones).

(I'm waiting for the next dev version that will work on Kotlin 1.4-rc to start playing with compose dev serioulsy, I'll probably see myself, event though it may change in subsequent releases)

[Vinay Gaba]

The mental model I’ve been using is that they are “component decorators”. Any time I want to add more UI functionality(gestures, appearance, etc) to a composable, I either look for an existing Modifier or try to think about how a custom modifier might be useful. And I rarely ever need custom modifiers for now 😛

[romainguy]

I don’t think discoverability is any worse than with regular composable functions. It might actually be better thanks to the code completion context provided by chaining modifiers

[romainguy]

How we present them in the docs is a different problem though