When does it make sense to refactor to `Modifier.N...

# compose

[vide]

When does it make sense to refactor to Modifier.Node? I have a custom modifier that is currently using composed, it remembers a few values and reads some composition locals and applies some other compose-provided modifiers that are already implemented with Modifier.Node. Would it make any sense to migrate this modifier from composed to Modifier.Node, or would any performance benefits be negligible?

[Ben Trengrove [G]]

When that modifier is used in a path that is recomposed a lot (or possibly causing it to recompose a lot)

[vide]

Thanks! A follow-up question on how to actually do it, I'm not sure how I would convert this pattern to Modifier.Node without using composed? I think clickable still uses this pattern to remember MutableInteractionSources, for example. Is there some way this could be optimized even further? Remember the value in the composable using the modifier?

composed {
    val br = remember { BringIntoViewRequester() }
    this.bringIntoViewRequester(br) then MyCustomElement(arg1, arg2, br, ...)
}

[Ben Trengrove [G]]

Where do you use br?

[vide]

I give it to the .bringIntoViewRequester modifier as an argument

[vide]

And also in the MyCustomNode implementation

[Ben Trengrove [G]]

So somewhere in MyCustomNode you are calling br.bringIntoView?

[vide]

Yeah

[Ben Trengrove [G]]

I haven't encountered that yet but I will try and find out for you

[Albert Chang]

The basic idea is that you don't need remember at all because the Modifier.Node instance will never be recreated so the values you had to remember can just be the members of the class.
However, in this specific case, since the APIs behind Modifier.bringIntoViewRequester() are all private or internal, I don't think you can create a custom Modifier.Node with the functionality of Modifier.bringIntoViewRequester() yet.

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

Yea, in general to migrate to modifier.node your dependencies also have to have been migrated. Looks like we haven’t migrated BIVR yet

[vide]

Thanks for all the replies. I'll follow release notes closely to see when it will be available thank you color

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

If you file a feature request, it will be easier for both of us 😉

[vide]

Here we go: https://issuetracker.google.com/issues/299939840 blob smile happy

[Ben Trengrove [G]]

To answer your original question as well about converting that pattern, you would use a DelegatingNode(). There are lots of samples of it in https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]mpose/ui/samples/ModifierSamples.kt

It would end up looking something like (if we actually had a public implementation you could use)

class MyModifierNode: DelegatingNode() {
   val br = BringIntoViewRequester()
   val bringIntoViewNode = delegate(BringIntoViewModifierNode(br))

   // other custom behaviour here
}