most/all core components will accept modifiers as ...

# compose

[Leland Richardson [G]]

most/all core components will accept modifiers as far as I understand it, but not all have been refactored to do so yet

[Fudge]

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?

[Leland Richardson [G]]

umm so i don’t think “need” is the word I’d use here….

Your custom component can have whatever parameters it wants:

@Composable fun MyButton(padding: Int, ...) {
  Button(modifier = padding(padding.dp), ... )
}

is just as valid as

@Composable fun MyButton(modifier: Modifier, ...) {
  Button(modifier = modifier, ...)
}

[gildor]

Still, standalone Padding component may be useful as building block for own custom component

[voddan]

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

[Fudge]

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.

[themishkun]

Yeah, these modifiers are a step back to where we started - it is like the views all having padding and background.

[themishkun]

Indentation is not so creepy nor ugly, especially if you modify your guidelines to use 2 spaces

[George Mount]

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:

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.

[George Mount]

MyButton(padding(16.dp))

is equivalent to:

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.

[George Mount]

The unfortunate part is that all items have to take a Modifier parameter now.

[George Mount]

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.

[Fudge]

What did we gain in passing padding as an argument instead of wrapping with a Padding component?

[gildor]

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

[themishkun]

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?

[gildor]

That is my point, I don’t want to create dozen functions that used only once just to reuse padding

[gildor]

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