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

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?

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, ...)
}

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

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

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.

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

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.

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

Padding

component?

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

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?

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