What’s the best API practice for having a composable with a default size but still allow it to be ov...

# compose

[julioromano]

What’s the best API practice for having a composable with a default size but still allow it to be overridden via modifiers?

[julioromano]

I was thinking something like:

@Composable
fun SomethingNice(
  modifier: Modifier = Modifier,
) {
  Box(
    modifier = modifier.size(24.dp),
  ) {
    // Something more...
  }
}

It is working.

But I was afraid the “default” 24dp modifier would be called after the one passed in via parameter therefore always overriding it. Turns out this is not true. But can’t understand why.

[Zoltan Demant]

Have you seen this? I havent used it myself in practice, but Ive seen it used in the material library to seemingly do what youre looking for 🙂

Modifier.defaultMinSize()

[Adam Powell]

Layout sizing modifiers alter the measurement constraints of their element more or less as (pseudocode) min = max = myRequestedSize.coerceIn(parentSuppliedMin, parentSuppliedMax)

[Adam Powell]

If the incoming constraint range doesn't include the requested size then it will try to get as close as it can

[Adam Powell]

But only the requiredSize modifiers override parent constraints

[julioromano]

Not sure I’m following. What I meant was:

If I draw this:
SomethingNice() It gets drawn at 24dp as expected.

And if I draw this:
SomethingNice(modifier = Modifier.size(64.dp)) It gets drawn at 64dp. But it is strange to me as in the code it will happen something like:

@Composable
fun SomethingNice() {
  Box(
    modifier = Modifier.size(64.dp).size(24.dp),
  ) {
    // Something more...
  }
}

Shouldn’t the second call to .size(24.dp) override the first call to .size(64.dp) ?

[Adam Powell]

24.coerceIn(64, 64) = 64

[Adam Powell]

24 is out of range of the constraints given by size(64.dp) so it's coerced into the constraints of the upstream parent

[julioromano]

But it works even the other way around (e.g. if I pass in Modifier.size(12.dp) )

In this case we’d have:
24.coerceIn(12, 12) = ?

[julioromano]

But nevertheless SomethingNice it is displayed with 12dp size

[julioromano]

Wait a sec… so by “the upstream parent” you mean “the upstream modifier” OR the “enclosing (i.e. outer) composable”?

[julioromano]

Gosh I’m confused. So there’s no way to create a composable that would size itself to a default value while at the same time offering the (opt-in) possibility of sizing it to any other value?

[julioromano]

In the end swapping modifier = modifier.size(24.dp) with modifier = Modifier.size(24.dp).then(modifier)
Solve any issues with sizing I had 🤷

[Scott Kruse]

Maybe I’m not understanding the question, but can’t you can solve this with default argument for modifier?

[julioromano]

Nope, because a user may wish to add any modifier other than the size one while still keeping the default size

[Adam Powell]

You should never need to invert the modifier order that way, you can still change the size externally with the component expressing its own default using the standard ordering.

[Adam Powell]

"upstream parent" means the modifier that comes before it if there is one, or the parent layout composable if there are no more modifiers before it

[Adam Powell]

the layout process is one where each parent (and modifier) tells the next link in the chain, "you must be between min and max size; how big are you?" Modifier.size narrows those min and max constraints to be as close to the requested value as possible, within the constraints of how it was measured by its immediate parent (whether that parent is another layout modifier or a layout composable)

[Adam Powell]

so if I write:

@Composable fun DefaultSizeBox(
  modifier: Modifier = Modifier,
  content: @Composable BoxScope.() -> Unit
) = Box(modifier.size(24.dp), content = content)

and then call it like this:

DefaultSizeBox(Modifier.size(64.dp)) {
  Text("Hello, world")
}

then the final modifier for the Box created by DefaultSizeBox is Modifier.size(64.dp).size(24.dp).
Measurement then proceeds; let's say the parent of the DefaultSizeBox measures it with the constraints (min = 0, max = 500) (simplified to only one dimension here for the sake of this discussion; both width and height each have a min and max)

[Adam Powell]

That measurement operation reaches the first .size(64.dp). 64 is between 0 and 500, so now the measurement proceeds, but with (min = 64, max = 64)

[Adam Powell]

next, measurement reaches .size(24.dp). 24 is not between 64 and 64; in order to be within that range the constraints are "changed" to (min = 64, max = 64). The final box is measured with those constraints, and reports that it is size 64. The "outer" modifier passed to the DefaultSizeBox call thereby overrode the requested default defined in `DefaultSizeBox`'s implementation.

[julioromano]

Thanks for the thorough explanation Adam, it took a while but I eventually digested all of this 🙂

[Rafiul Islam]

Hey , I goy this far.
next, measurement reaches .size(24.dp). 24 is not between 64 and 64; in order to be within that range the constraints are "changed" to (min = 64, max = 64)

But what happened in this case? 24.coerceIn(12, 12) = ?

[julioromano]

= 12

[julioromano]

https://github.com/JetBrains/kotlin/blob/34e57a45f2d4283be572137b4b497414b8833ee7/libraries/stdlib/common/src/generated/_Ranges.kt#L1189

[Rafiul Islam]

Ops. I know what coerceIn function does actually It was a stupid question As I see you mentioned you were getting 12. Anyway thanks