Is there a performance difference here? Should I a...

# compose

[vide]

Is there a performance difference here? Should I always prefer the latter?

fun Modifier.foo() = composed { this.then(FooElement(remember { Foo() })) }
Composable(Modifier.foo())

fun Modifier.foo(foo: Foo) = this.then(FooElement(foo))
Composable(Modifier.foo(remember { Foo() }))

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

composed is generally bad for performance, yes. The new modifier node APIs are better to use (and also for other reasons)

[vide]

That's what I thought, thanks for confirming. The API surface here is a bit clunky for the user, as they need to remember a value that the modifier only uses internally. Has there been any thought about how to do this in a cleaner way? (In this case foo is a BringIntoViewRequester --I cannot delegate to the node implementation because it's private)

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

Does the caller of the modifier factory need to be able to call bringIntoView? If so, there’s no way to get around them creating it, since they need access to it. If not, just have your modifier node implement BringIntoViewRequesterNode

[vide]

Nope, the parent doesn't need access to it. The issue here again is that BringIntoViewRequesterNode is currently internal, I'll try to push for that being publicised too

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

Oh right. It needs a bit of refactoring but I’m pretty sure we can fix that