The Modifier system has been undergoing a rewrite since last year but I haven't found any documentat...

# compose

[Vinay Gaba]

The Modifier system has been undergoing a rewrite since last year but I haven't found any documentation that describes the steps needed to port the existing composed Modifiers to the new system. I'm wondering if there was a specific reason for holding off on more communication until now?

[shikasd]

yeah, someone has to write it...

[shikasd]

We are working on this, hopefully some of it will be released soonish (not committing to any time frame yet) 🙂

[Vinay Gaba]

The expected perf gains from this change were meaningful and we have a ton of composed Modifiers. This sounds like something that requires low effort but should have high ROI. Android Dev Rel superheroes, help your boy out 😂

[shikasd]

To be clear, it is not me who is writing it 🙂

[Vinay Gaba]

yeah I figured hence I was trying to summon someone from Dev Rel 😅

[Colton Idle]

we have a ton of composed Modifiers

just out of curiosity. what are those? 2 years of compose and i dont think ive used the composed modifier. lol 😅

[Vinay Gaba]

A lot of them are convenience wrappers for some internal tooling that requires access to some sort of a CompositionLocal . We could've probably passed the value into the function but wanted to simplify the usage.

[shikasd]

btw, you can check example of converted modifiers, e.g. PaddingElement or SizeElement. we also have samples for CompositionLocal.

[Vinay Gaba]

Yeah thankfully everything is open source so I know there are PRs tackling this. My concern was that there was (maybe?) a specific reason for not documenting it yet and I was assuming it meant the API was still going through iterations?

[shikasd]

nope, it is stable with 1.5

[Ben Trengrove [G]]

DevRel summoned, we are working on it. Check out the androidx samples in the mean time sorry

[Vinay Gaba]

oh you don't have to be sorry at all! It's all good, at least I have confirmation that things are stable so I can safely plan for this migration in the short term 🙏🏼

[Ben Trengrove [G]]

"A lot of them are convenience wrappers for some internal tooling that requires access to some sort of a CompositionLocal . We could've probably passed the value into the function but wanted to simplify the usage."

This is the exact question we are still debating over actually. The most correct/performant option is to use CompositionLocalConsumerModifierNode but feedback is that feels like overkill just to reference a theme value so we want to get the recommendation right

Sample of that: https://cs.android.com/androidx/platform/tools/dokka-devsite-plugin/+/master:testData/compose/samples/ui/samples/ModifierCompositionLocalSample.kt

[Albert Chang]

Also MaterialTheme doesn't expose any `CompositionLocal`s directly so I don't think it's even possible to read a theme value from modifier node now.

[Vinay Gaba]

The most correct/performant option is to use CompositionLocalConsumerModifierNode but feedback is that feels like overkill just to reference a theme value so we want to get the recommendation right

On seeing the example, it does look like it's fairly involved. I had seen Leland's talk last year so don't remember all the details but does it also cover this use case? Do you remember on the top of your head?

[shikasd]

CompositionLocal consumer was introduced way later, so I don't think it was covered

[shikasd]

I don't think it covers the use case of using composition locals for creating other modifiers as much atm though
E.g. doing something like this is pretty hard with Modifier.Node (without creating your own Modifier from scratch):

fun Modifier.themedBackground() = composed {
    Modifier.background(MyTheme.current.backgroundColor)
}