I noticed that inside `ui-material` library `Typography` is a data class which then gets used like t...

# compose

[dimsuz]

I noticed that inside ui-material library Typography is a data class which then gets used like this:

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.

[Adam Powell]

Think of ambients as a kind of composition-local, like a ThreadLocal but for a part of the composition tree

[dimsuz]

So having a singleton there would heart "sharing" (composing)?

[Adam Powell]

Any part of the tree can do

Providers(TypographyAmbient provides myTypographyInstance) {
  // Content
}

And everything inside the content block will see that value for that ambient

[Adam Powell]

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

[dimsuz]

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 🤦‍♂️

[dimsuz]

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!