I'm kinda in love with ambients. But then again, p...
# compose-desktop
k
I'm kinda in love with ambients. But then again, powers to be are saying that those can be easily abused 🙂
I was thinking that if there's at least a dozen of those in core / material layers, then it's OK for another "design system" to be using those
I'd say that ambients are much more powerful compared to global variables as each one can be redefined, essentially, at any point in the hierarchy. Which is what I love about them.
j
Same with thread locals 😛
k
Sure, which is why a lot of "lower level" frameworks are using it. So maybe the argument is which "layer" needs them.
j
Yeah, there are a few valid use cases. That's why they exist. But they are like a chain saw attached to a gun tied to your foot. Which is why I'm not a fan of people talking about them in the slack channel or writing blog posts about them - it unintentionally harms our poor innocent young users who don't yet know any better.
👍 2
s
So what are ambients?
👍 3
t
lol
Problem is that than you never know what is really the value of the ambient. Or it is very hard to understand the program. But same counts for dagger and other framework mechanisms. But yea better try to avoid abuse them.
👆 1
Currently think of maybe using them for image loading. So i do have a image loading ambient which can be set. Do you think this would be abuse of the system. Or a good fit?
s
So what are ambients?
@spierce7 https://developer.android.com/reference/kotlin/androidx/compose/runtime/Ambient - I think it's more like Singleton for a component hierarchy.
c
If something is needed in a deeply nested component and it is accessible only from the caller of it far up, are there any other nice solutions? Passing them down would be the obvious solution, but then you have a bunch of composables with parameters that aren't strictly relevant to them Just curious about what else could be nice to use
g
It's not a singleton, more like scoped context
o
in a sense ambients/globals and such are ways to avoid explicit state data flow in the program, and such if can be thought as “duck typing” for data flows. So this is indeed a problematic pattern, but useful escape hatch, sometimes
👍 2