Ambients - why sometimes ambients are "registered"...

# compose

[Jan Skrasek]

Ambients - why sometimes ambients are "registered" with the value directly and sometimes you pass a remembered state of the value? What's is the logic/meaning behind this? I thought that there is already a logic in ambient how to compare new provided value to the previous.

[Adam Powell]

do you have an example?

[Jan Skrasek]

ConfigurationAmbient - it is a remembered state vs. ContextAmbient - context is passed directly.

[Adam Powell]

ah. `ConfigurationAmbient`'s wireup to get changed values is a bit different in the implementation details and could probably be simplified a bit. It's remembering an observable state holder so that the Providers call recomposes when it changes via the callback.

[Adam Powell]

There is indeed logic in ambient to compare the provided values, the implementation there is to wire up the observation for when the host view's configuration changes.

[Adam Powell]

Context doesn't change for a view after construction so it doesn't come up there.

[Jan Skrasek]

So when the provided value for ambient is not remembered state, recomposition ambient value can be caused done only by new Providers() call?

[Adam Powell]

A new Providers call is the only way an ambient value can change

[Adam Powell]

For Configuration, recomposition based on reading the MutableState holder is causing a new Providers call

[Jan Skrasek]

For Configuration, recomposition based on reading the MutableState holder is causing a new Providers call

Aha moment, obvious now! Thanks a lot.