I have a question about modifiers: right now I see the only handled `Modifier` type is a `LayoutModi...

# compose

[wasyl]

I have a question about modifiers: right now I see the only handled Modifier type is a LayoutModifier, which, if I understand correctly, is read and applied in the LayoutNode in appropriate place.

I know there’s been a discussion about the scope of modifiers, but in the end there’ll be just some number of modifier types handled by the core library in appropriate places, right?

Could you share what other possible types of modifiers were you thinking about in general, not necessarily ones that are likely to be part of Compose?

[wasyl]

At least LayoutModifier and some kind of DrawingModifier come to mind. I wonder what else could be modified using them

[Adam Powell]

Input handling and semantic annotations have been discussed, it's all TBD at the moment though

[Adam Powell]

LayoutParams are a big one that should be coming fairly soon

[Adam Powell]

So some of the wrapper functions that you see in FlexRow and the like would be able to disappear

[wasyl]

And some functions that don’t have modifier param yet, like TextField, will get it, right? I just wrapped it in a Container to have one in a Row

[wasyl]

Semantic annotations seems like pretty good use case, this would cover accessibility, right? And by input handling you mean like reacting to input devices (like physical keyboard), focusability?

[Adam Powell]

yes re. other composables will get it and yes re. input handling

[wasyl]

Thank you 🙂 I was on the fence about the modifiers initially, but they seem like a great addition. Now I’m in the camp that would like to do drawing there too (background, borders etc.)

[Ryan Mentley]

re: Semantic annotations covering accessibility: yep, among other things like testing, autofill...

[Adam Powell]

They kinda grow on you. 🙂 The issue you've noted around it being a parameter boilerplate for composable functions that emit a layout node is one we're thinking on but even that has its up sides

[wasyl]

Do LayoutNodes typically emit DrawNodes?

[wasyl]

I’m having a hard time wrapping my head around potential DrawModifier and how would it work when applying e.g. modifier = Padding(..) wraps BackgroundColor()

[wasyl]

Even more so when interleaving modifiers of different types, since layout will always happen before drawing, no?

[Adam Powell]

it would potentially work quite a bit differently. There's an inconsistency between how draw nodes and pointer input nodes get sized today and what direction that data flows in that modifiers could help resolve. Part of the reason why draw nodes size to their parent is so that you can create composables that do provide a border or decoration, and that would have a different expression. That means that something like Draw { might be able to become something like Canvas { that could emit a layout node with attached drawing modifiers.

[Adam Powell]

We're playing with a lot of ideas. 🙂

[themishkun]

Or you could use functional composition and do smth like

(::Padding wraps ::Row) {
::Padding wraps ::Button 
}

[Fudge]

how do you pass parameters to Padding @themishkun?

[Fudge]

or anything else for that matter

[themishkun]

If there was a pleasant way to do partial application in kotlin, we could use it to pass less parameters than needed to produce a function with these params backed-in

[Fudge]

Well, using features Kotlin doesn't have is cheating 😛

[themishkun]

it is not like it doesn’t have them. They are just not as familiar to ex-java coders.
::Padding.partial(16) looks kinda weird to people unfamiliar with partial application pattern