Ben Woodworth
11/10/2020, 2:29 AMgildor
11/10/2020, 2:31 AMromainguy
11/10/2020, 2:37 AMBen Woodworth
11/10/2020, 3:57 AMfun Modifier.then(Modifier)
and that gave me the answer. Each call on Modifier is wrapping the receiver with a CompinedModifier
And I'm definitely a fan of the change to the fluent interface from the old nesting-heavy approach, and from the Modifier.a() + Modifier.b()
approach. Makes sense now why something like this wouldn't work:
// Modifier.preferredWidth(100.dp).padding(10.dp)
modifier = Modifier {
preferredWidth(100.dp)
padding(10.dp)
}
gildor
11/10/2020, 4:02 AMMakes sense now why something like this wouldn’t workBecause it requies different API and order of modifiers matters, essentially to implement something like this you need:
Modifier { // this is some ModifierScope
add(preferredWidth(100.dp)) // add to list of modififers
} // Returns modififer, by converting List<Modifier> to a single nesting modifier
Javier
11/10/2020, 8:36 AMmodifier = Modifier {
preferredWidth(100.dp)
padding(10.dp)
}
gildor
11/10/2020, 11:50 AMJavier
11/10/2020, 1:39 PMinfix
and infix
would allow multiline.
modifier = Modifier
preferredWidth(100.dp)
padding(10.dp)
If we can create a Modifier
which block
only can use this infix
functions, we should get the the same behavior to the builder pattern, but I don't know what issue was in YouTrack, and if it lets us to solve our problem 100%.
But know we have two problems so I think it is infeasiblegildor
11/10/2020, 1:51 PMJavier
11/10/2020, 2:05 PMgildor
11/10/2020, 2:15 PMBen Woodworth
11/10/2020, 8:19 PMJavier
11/10/2020, 8:24 PMBen Woodworth
11/10/2020, 8:27 PM// Modifier.preferredWidth(100.dp).padding(10.dp)
modifier = Modifier {
preferredWidth(100.dp)
padding(10.dp)
}
then
call is what's used by the builder, not the return value), so this is equivalent, and might be misleading:
modifier = Modifier {
preferredWidth(100.dp).preferredHeight(40.dp)
padding(10.dp)
}
Javier
11/10/2020, 9:04 PM