A modern programming language that makes developers happier.

kotlinlang

do modifiers apply full recomposition of the composable they belong to? For instance, imagine a modifier with a border, with a mutableState as color ?

If the parameter to a modifier is a mutable state read, then when that state changes it causes the function in which it was read to restart. That means a new modifier will be created with the new value, and passed to the target composable, which should update appropriately. 

just imagining some complex composable, with a border as modifier with a state&lt;Color&gt;. I was asking if there was a better way to optimize for that particular change only

Ah, you mean create your own border modifier that takes a state instead of a raw value?

I mean, what is the right way to create a dynamic modifier (for instance, dynamic colored border stroke of some composable), besides just passing a State&lt;Color&gt;. Idk if thats the optimal approach, because the way i see it, only the stroke changes, but i don’t know if the internals of compose will trigger a full recomposition of everything inside the composable

Even if a parent function is recomposed, it's contents can still skip recomposition if their own inputs/constraints haven't changed, and that should extend to modifiers too.

And in general, you as the developer shouldn't have to worry about things like this; just assume Compose is going to do the right thing and update the UI efficiently

I've implemented custom dynamic modifiers like this by marking them as `@Composable`, and it works just fine. If the input to that function reads a `State`, updates to the state will be reflected just as expected

I can’t help it :stuck_out_tongue: I’m learning compose, so i normally want to know the best approach for some problem

In my mind, if a composable have a modifier that adds a colored border, just slaping state&lt;Color&gt; for the stroke modifier would trigger recomposition of everything. I don’t know if it is the right approach

The best approach for this is, as Casey said, just do the simple thing and not worry about it.

<@UD17D4K8W> There are some issues with making a modifier factory function composable. Better to use `Modifier.composed` – this doesn’t require the creator to call your function in a composable (which can be useful if you want to extract complicated modifier creation out to a state holder, for example), and also ensures that the composition context the modifier uses will be more accurate since it won’t actually be composed until the last minute before the modifier is actually applied to a node.