Hi, I'm learning compose and was wondering if I ca...

# compose

[Tobias Gronbach]

Hi, I'm learning compose and was wondering if I can reuse a Modifier. I created a file 'Modifiers.kt' that contain modifiers I want to reuse, f.e.

val dialogModifier = Modifier
    .padding(10.dp)
    .background(MaterialTheme.colors.surface)
    .width(400.dp)

But then build is failing with: @Composable invocations can only happen from the context of a @Composable function . What am I doing wrong?

[Alexander Maryanovsky]

MaterialTheme.colors can only be dereferenced inside a @Composable function.

[Alexander Maryanovsky]

Its value is not a constant like 10.dp, it’s composition-dependent. So you can’t just use it.

[Alexander Maryanovsky]

But you can do

@Composable
fun dialogModifier() = ...

[Tobias Gronbach]

Thank you for your help and explanation. I appreciate that! It's compiling when I refactor it as function as you proposed, but in this specific case padding gets just ignored, while background and width is applied correct.

[Tobias Gronbach]

After further investigation I realized that it's actually working when I change the order and put padding after width. If there's an explanation to that behaviour I'm glad to hear but anyway thanks so far, my issue is solved!

[Alexander Maryanovsky]

The order of the modifiers matters

[Alexander Maryanovsky]

if you put padding then width then the padding is “outside” the width”, and vice versa.

[Andrew Neal]

https://developer.android.com/jetpack/compose/modifiers#order-modifier-matters

[Alexander Maryanovsky]

Like if you put .border(Color.Red).border(Color.Blue) you will have a blue border inside a red border.

[Tobias Gronbach]

Ah, that makes sense and is actually a nice behavior! 👌 Thanks again guys! 😀

[mattinger]

FYI: Your other option for using composable content to build modifiers is the composed function. There's subtle differences in using this as opposed to just marking a function with @Composable.

If you mark your function with @Composable as @Alexander Maryanovsky suggested, any composable references will be evaluated at the time of the function invocation. If you use the composed function, it happens a bit later in the recomposition. The official description:

Declare a just-in-time composition of a Modifier that will be composed for each element it modifies. composed may be used to implement stateful modifiers that have instance-specific state for each modified element, allowing the same Modifier instance to be safely reused for multiple elements while maintaining element-specific state.

https://developer.android.com/reference/kotlin/androidx/compose/ui/Modifier#(androidx.compose.ui.Modifier).com[…](kotlin.Function1,kotlin.Function1)

[Adam Powell]

Yes, Modifiers are designed to be reusable. Modifier.composed is the way to create a modifier factory that will be invoked at each usage site to preserve this reusability by giving you a place to create and remember point of use instance-specific information.

[Alexander Maryanovsky]

Can you guys elaborate on that? I'm not sure I understand what it does.

[Alexander Maryanovsky]

Ah, I think I understand. It lets the modifier become part of the composition, including having its own state.

[Adam Powell]

right. In essence every @Composable function (including lambdas) is a factory for instances of that content in a composition. They can be reused in multiple places and keep instance-specific state. Modifier.composed {} gives that same capability to modifiers and lets you assemble them into a chain with other modifiers like you would expect