When should we use `staticAmbientOf` instead of `ambientOf` ? what's the benefit of using `staticAm...

# compose

[Kazemihabib1996]

When should we use staticAmbientOf instead of ambientOf ? what's the benefit of using staticAmbientOf that RippleTheme for example uses that instead of ambientOf?

[Adam Powell]

staticAmbientOf has lower overhead but if it ever changes in place, we will invalidate and recompose the entire subhierarchy below the Providers where it changed, since we don't track precise location of reads for static ambients.

[Adam Powell]

In effect, "dynamic" ambients are just a static ambient that holds a State<T> that holds the "real" value of the ambient

[Adam Powell]

so in the case of dynamic ambients, that State<T> instance from the Providers in the composition stays constant and never changes, only the observable value changes when you provide a new value for the ambient key.

[Kazemihabib1996]

@Adam Powell
Thank you
So you used staticAmbientOf for RippleTheme as in most applications developers set that one time and won't change it later?

[Chuck Jazdzewski [G]]

That is correct. Use staticAmbientOf for ambients that are unlikely to ever change or if they do change they likely invalidate the entire tree anyway. Here, change is defined as changing the value provided at the point it is provided. If a static ambient is re-provided, it is not counted as being changed and will not invalidate the tree below it, the tree below just sees a different value than the tree above.