Is it bad practice to make a `Modifier` function t...
# compose
e
Is it bad practice to make a
Modifier
function that is
@Composable
?
j
As opposed to
Modifier.composed
?
z
Generally I would try to avoid it because it usually indicates that you’re trying to do something in the wrong way. But I’m not sure we officially recommend against it
e
The use case is that I migrated
placeholder
to
Modifier.Node
but the material version of it wraps the call in
composed
so it could use material properties
Copy code
composed {
  Modifier.placeholder(
    visible = visible,
    color = if(color.isSpecified) color else PlaceholderDefaults.color(),
    shape = shape ?: MaterialTheme.shapes.small,
    highlight = highlight,
    placeholderFadeAnimationSpec = placeholderFadeAnimationSpec,
    contentFadeAnimationSpec = contentFadeAnimationSpec,
  )
}
It just felt weird to use
composed
after migrating away from it.
z
That might be a good reason. Also, consider filing a feature request to Material. If they just used composition locals directly, for example, you could access them from a modifier node.
👍 2
👍🏾 1
b
The catch with using a composable function to return a modifier, rather than Modifier.composed, is that composition locals are resolved where the modifier is created, not used. So for example if you have a modifier that uses a local called LocalColor and use it like this, it won't have the correct colour at the call site
Copy code
val modifier = Modifier.myComposableModifier()
CompositionLocalProvider(LocalColor provides Green) {
   Box(modifier) // not green
}
mind blown 1
e
Is there an official recommendation then? There's a commit in the api guidelines that says that
Modifier.composed
is now discouraged. Does that mean generally discouraged, but should be used in certain scenarios, or does it mean "don't use it"?
b
We are still working it out, especially for your case where you are just looking up theming values. You can keep using composed for now or use a composable function
thank you color 1