I also had the idea of using `ambientOf` in this w...

# compose

[Daniele B]

I also had the idea of using ambientOf in this way, which is basically the same way you would use @EnvironmentObject in SwiftUI:
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1592352556316500

@Composable
fun foo(appState: StateFlow<ChannelState>) {
  val currState by appState.collectAsState()
  Providers(CurrAppState provides currState) {
    // Content that should see currState
  }
}

as a kind of “dependency injection”, which “saves” an object in the environment, so that it’s possible to call it down the tree without having it passed all the time as a parameter.
But I didn’t understand the explanation of @Adam Powell and @Zach Klippenstein (he/him) [MOD] why ambientOf should not be used in this use case, and what is the way to use it instead.

[Adam Powell]

Mechanically it works, but the implicit dependency it creates will make things more cumbersome to use, reuse, test, and reason about. Semantically speaking you probably want to split out individual sub-pieces of state that each composable consumes via parameters as you descend down the tree rather than having the whole app state everywhere, which makes this pattern of ambient usage less useful.

[Daniele B]

So, I guess JetpackCompose is not promoting the same concept of @EnvironmentObject on SwiftUI

[Daniele B]

@Adam Powell so if ambientOf is not to be used to have an environment object like in @EnvironmentObject , what is it for and how should it be used?

[Adam Powell]

It can certainly be used that way mechanically, it's more of a question of design and best practice. It should be used when those kinds of implicit dependencies are situationally appropriate, which I realize is a circular and unsatisfying answer. 🙂 Theming constructs are one example where the tradeoffs tend to be worth the potential for confusion, along with other information like density scaling

[Adam Powell]

Much of the advice given for react's context feature applies here: https://reactjs.org/docs/context.html#before-you-use-context

[Adam Powell]

if you would feel strange using a ThreadLocal to get information into a regular function call as opposed to via parameter passing, you should similarly feel strange about using ambients to provide information to composable function calls

[Adam Powell]

sometimes it's an appropriate and elegant solution to a problem; other times it's hiding things that should probably remain visible and explicit

[Sean McQuillan [G]]

Agreed with Adam. Personally my current rule for ambient vs. parameter goes something like this:

"Ambients should be reserved for select foundational app-wide or ecosystem-wide architectural pieces, everything else is parameters"

[Daniele B]

@Adam Powell thanks! I get the point now