Why `composed {}` function for defining a custom modifier is not recommended anymore?

# compose

[marcinmoskala]

Why composed {} function for defining a custom modifier is not recommended anymore?

[MR3Y]

Long answer is in this talk:

https://youtu.be/BjGX2RftXsU?si=O8fqo-ujLgNtPMwJ▾

[gildor]

Keep in mind, many things is not possible to implement without it, or way harder, so it's often trade off between convinience and performance

[marcinmoskala]

@MR3Y Very useful, thanks

[marcinmoskala]

@gildor I guess, when you need something specific to the composition scope of the composable to which is it used, not of the composable in which modifier builder function is called, but do you have some practical examples?

[gildor]

You cannot use any composable functions in Node API, there are implementations for some important use cases, but many things like resolve resource (so modifier has some pre-defined defaults for colors for example), is not possible without composable modifier

[soufianehamama9]

@MR3Y thanks

[Zach Klippenstein (he/him) [MOD]]

You can get resources from a modifier node through the LocalContext.

[ephemient]

also for cases that aren't covered by ModifierNode, you can often write a `@Composable Modifier.`factory. it was discouraged in favor of composed {} before but not anymore