When should we use

staticAmbientOf

instead of

ambientOf

? what's the benefit of using

staticAmbientOf

that

RippleTheme

for example uses that instead of

ambientOf

?

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 Thank you So you used

staticAmbientOf

for

RippleTheme

as in most applications developers set that one time and won't change it later?

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.