I noticed that inside `ui-material` library `Typog...
# compose
d
I noticed that inside
ui-material
library
Typography
is a data class which then gets used like this:
Copy code
internal val TypographyAmbient = staticAmbientOf { Typography() }
I wonder why does it need to be explicitly constructed, why not have an
object Typography
and then
staticAmbientOf { Typography }
? Asking because I'm making my own Typography object (non-material theme) and maybe I'll run into trouble with this.
a
Think of ambients as a kind of composition-local, like a ThreadLocal but for a part of the composition tree
d
So having a singleton there would heart "sharing" (composing)?
a
Any part of the tree can do
Copy code
Providers(TypographyAmbient provides myTypographyInstance) {
  // Content
}
And everything inside the content block will see that value for that ambient
Having a singleton there will be kind of wasteful, if you have a singleton just use the singleton. Ambients let a value be provided for a subtree of the composition; it's a service locator mechanism
d
ah, I get that, but perhaps I wasn't clear enough. The
Typography
class has internal constructor and is final (being
data class
) so I can't really construct it differently than it's already constructed. Oops. As I wrote the above, I noticed the secondary public constructor 🤦‍♂️
Sorry. But at least I learned about
Providers(...)
from your comment above. By the way it feels really nice that I can just go sideways and not use MaterialTheme and build my own theme language, specified by designer. Nothing stands in a way, and I can also look at MaterialTheme as an example! Great!
🙌 3