In this particular case (`@Composable` needed only for accessing resources), when migrating away fro...

# compose

[Mark]

In this particular case (@Composable needed only for accessing resources), when migrating away from composed { } , do we use the new Modifier.Node way or is a @Composable and @ReadOnlyComposable more appropriate:

fun Modifier.middleCardPadding(): Modifier = composed {
    val horizontalPadding = dimensionResource(id = R.dimen.card_view_horizontal_margin)
    padding(start = horizontalPadding, end = horizontalPadding, top = 0.dp, bottom = 0.dp)
}

[saket]

I'd suggest migrating to Modifier.Node. Migrating to a composable Modifier should be your fallback if the new node architecture does not support your usecase, such as delegating to other modifiers.

[Mark]

I’ve only taken a brief look, but it seems like a lot of code to do the above which is currently 2 lines?

[saket]

correct, so you'll have to decide whether the migration is worth investing the effort. in your case, it'll be a lot easier to hoist your context/resources as a parameter

fun Modifier.middleCardPadding(context: Context = LocalContext.current): Modifier {
  val horizontalPadding = context.resources.getDimension*(…)
  return this.padding(…)
}

[Mark]

I guess the problem with that is I’m introducing an explicit dependency on Context to the extension function. How much of an issue is it do something like:

@Composable
@ReadOnlyComposable
fun Modifier.middleCardPadding(): Modifier {
    val horizontalPadding = dimensionResource(id = R.dimen.card_view_horizontal_margin)
    return this.padding(start = horizontalPadding, end = horizontalPadding, top = 0.dp, bottom = 0.dp)
}

[saket]

> explicit dependency on Context to the extension function
hmm why is this a problem? wouldn't your usages remain unaffected?

about making your modifier composable, I'm sorry I don't know enough about modifiers to answer whether it's performant enough

[Mark]

Mostly thinking about KMP. I'm trying to make my code as platform neutral as possible.

[saket]

ah gotcha, I forgot about multiplatform 🙂

[electrolobzik]

@Mark R class is anyway not accessible in the common module. Why should you think about KMM then?

[electrolobzik]

Or do you want to use expect/actual for this extension?

[Mark]

I’m just thinking in terms of ease of migration further down the line. I’m currently holding off something like Moko Resources in the hope that a more official solution will come in the meantime.

[Alexander Maryanovsky]

I think multiplatform resources are planned for the next release. You can already use them in dev builds.

[Mark]

Interesting thanks! Is there a decent stepping stone in the meantime? For example, maybe it’s worth migrating to Moko Resources now if the migrating from Moko Resources to the official option is trivial.

[Alexander Maryanovsky]

I don’t know enough about either to say anything.

[p-schneider]

Moko resources hasn't been fully compatible with kotlin 1.9.x / compose 1.5.x for a long time now. They're doing a big refactor right now.
https://github.com/icerockdev/moko-resources/pull/575
So unless you'd like to test their current WIP/Dev State from that PR I wouldn't suggest going for that.

[electrolobzik]

In my case moko works fine for both iOS and Android, using last stable version. Indeed it was a bit tricky to setup it with kotlin 1.9.2, but it works fine.