https://kotlinlang.org logo
Title
l

Loney Chou

04/01/2023, 10:22 AM
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.
z

Zach Klippenstein (he/him) [MOD]

04/04/2023, 6:27 PM
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.
Cc @Leland Richardson [G]
l

Loney Chou

04/05/2023, 2:38 AM
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 😥