https://kotlinlang.org logo
#compose
Title
# compose
l

Leland Richardson [G]

10/14/2019, 8:15 PM
most/all core components will accept modifiers as far as I understand it, but not all have been refactored to do so yet
4
f

Fudge

10/14/2019, 11:30 PM
Wait, ALL core components explicitly accept a modifier argument? And if I want to make it so a custom component can have padding and other modifiers I need to make it accept a modifier too?
l

Leland Richardson [G]

10/15/2019, 12:04 AM
umm so i don’t think “need” is the word I’d use here…. Your custom component can have whatever parameters it wants:
Copy code
@Composable fun MyButton(padding: Int, ...) {
  Button(modifier = padding(padding.dp), ... )
}
is just as valid as
Copy code
@Composable fun MyButton(modifier: Modifier, ...) {
  Button(modifier = modifier, ...)
}
g

gildor

10/15/2019, 12:30 AM
Still, standalone Padding component may be useful as building block for own custom component
3
👆 1
v

voddan

10/15/2019, 8:51 AM
Your custom component can have whatever parameters it wants
If my goal as a component library writer is for my custom components to feel "native", than I'll have to follow whatever conventions core components follow. E.i I'll have to propagate the
padding
parameter just to be acceptable
f

Fudge

10/15/2019, 11:46 AM
Has it been decided that in the end this design is not optimal? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1559657848034400?thread_ts=1559597743.089600
We're trying to direct people into writing components that accept
@Composable() () -> Unit
function references if they need to display arbitrary content, and in many cases the caller can add padding around their content they put there if they want it. Some designs might call for padding emitted by the container before calling the provided function, some might not.
t

themishkun

10/15/2019, 12:13 PM
Yeah, these modifiers are a step back to where we started - it is like the views all having padding and background.
2
🚫 2
Indentation is not so creepy nor ugly, especially if you modify your guidelines to use 2 spaces
g

George Mount

10/15/2019, 9:32 PM
Layout modifiers have a property that we like quite a bit -- layouts don't have to know about their implementations at all. For example, a
Row
layout doesn't have to know anything about
padding
to use it. It is just something that is applied to it. It acts quite a bit like:
Copy code
Padding {
  MyButton(...)
}
In that
MyButton
doesn't know anything about a
padding
modifier. A developer can add custom modifiers to any component. The modifier developer doesn't have to worry about what happens when multiple children are placed within because a layout modifier only applies to a single layout.
1
Copy code
MyButton(padding(16.dp))
is equivalent to:
Copy code
Padding(16.dp) { MyButton() }
in that
MyButton
doesn't have to know about padding. That is different from Android Views. In Android Views, if you add
layout_padding="16dp"
, your layout must understand how to handle the padding attribute.
The unfortunate part is that all items have to take a
Modifier
parameter now.
👆 2
I guess
layout_padding
was a bad example because
android:padding
is on the View itself, but insert your custom layout attribute in there instead.
f

Fudge

10/16/2019, 12:07 AM
What did we gain in passing padding as an argument instead of wrapping with a
Padding
component?
g

gildor

10/16/2019, 12:57 AM
Tho I see problems with this approach, it makes modifier style contract implicit, similar to what we have now with Android styles. But when I think about some of our complicated layouts with dozens and dozens elements, where essentially every view has internal and/or external padding, it terrifies my, how much nesting and noise it would introduce with compose, where 1/2 or 2/3 of code would be padding blocks and custom component wouldn't help in this case, same as styles Modifiers solve 2 problems for me: 1. Very easy to reuse because we have an object of modifier, that can be passed to any other component. Do the same with Padding component requires a lot of boilerplate 2. Solves nesting for components that used a lot, almost on every view/component: padding, background
t

themishkun

10/16/2019, 6:14 AM
Views are just funtions now, so you could easily extract/inline them, so maybe better not to create monolithic view in the xml style with "dozens and dozens of elements", but use the composability of the new framework and cut your layouts in small reusable pieces?
g

gildor

10/16/2019, 6:15 AM
That is my point, I don’t want to create dozen functions that used only once just to reuse padding
but use the composability
If you split 1 big layout to 10 small layouts you do not decrease amount of required paddings. You will still have 1 view with 1 or 2 padding/margin wrappers
3 Views