I have a question about modifiers: right now I see...
# compose
I have a question about modifiers: right now I see the only handled
type is a
, which, if I understand correctly, is read and applied in the
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?
At least LayoutModifier and some kind of DrawingModifier come to mind. I wonder what else could be modified using them
Input handling and semantic annotations have been discussed, it's all TBD at the moment though
LayoutParams are a big one that should be coming fairly soon
So some of the wrapper functions that you see in FlexRow and the like would be able to disappear
👍 1
And some functions that don’t have modifier param yet, like
, will get it, right? I just wrapped it in a
to have one in a
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?
yes re. other composables will get it and yes re. input handling
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.)
re: Semantic annotations covering accessibility: yep, among other things like testing, autofill...
👌 1
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
Do LayoutNodes typically emit DrawNodes?
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()
Even more so when interleaving modifiers of different types, since layout will always happen before drawing, no?
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.
👍 1
We're playing with a lot of ideas. 🙂
Or you could use functional composition and do smth like
Copy code
(::Padding wraps ::Row) {
::Padding wraps ::Button 
how do you pass parameters to Padding @themishkun?
or anything else for that matter
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
Well, using features Kotlin doesn't have is cheating 😛
it is not like it doesn’t have them. They are just not as familiar to ex-java coders.
looks kinda weird to people unfamiliar with partial application pattern