I think current design of Modifier.Node system com...

# compose

[Loney Chou]

I think current design of Modifier.Node system comes with a biggest problem: closed for further extension. Unlike Modifier system, where one can freely compose one or more Modifiers, almost all the underlying Modifier.Nodes emitted by these Modifiers are considered as "leaves" and can't be used to compose a custom Modifier.Node. This is especially true for Modifiers which take in lambdas like offset, onFocusChanged, pointerInput, where users need to write those logic over and over again.

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

You can compose modes via delegation (DelegatingNode), as long as the node types you want to delegate to are exposed. There are major improvements to the delegation system coming up too.

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

Cc @Leland Richardson [G]

[Loney Chou]

Like the following modifier I have in my project can't migrate to Modifier.Node without copy-paste:

fun Modifier.themePadding(
    size: ThemePaddingSize
): Modifier = composed {
    val themePadding = LocalThemePadding.current
    padding(themePadding[size])
}

enum class ThemePaddingSize { /* ... */ }

I would have to use padding like the following if I want to get rid of `composed`:

modifier = Modifier.padding(LocalThemePadding.current[/* ... */])

where I have to add Local... on each invocation.
I like the fact that DelegatingNode and CompositionLocalConsumerModifierNode is coming into view, but as you said, if the corresponding Modifier.Node type is not public, like padding, there's nothing you can't do 😥