Is there some sort of provider consumer pattern in compose? If not, how are we going to deal with the similar prop drilling issue that faced the react community? Because it is still obvious that state hoisting is the best approach. But again state hoisting is the mother of prop drilling or in this case, parameter drilling

if you’re asking if there is an equivalent to React’s “context”, then yes - “Ambients”.

val ambientFoo = ambientOf<Foo> { DefaultFoo }

@Composable fun Root() {
  // provider
  Providers(ambientFoo provides myFoo) {
    App()
  }
}

@Compoable fun Leaf() {
  // consumer
  val foo = ambientFoo.current
}

Thanks, That's exactly what I was looking for.

Interesting about compose that is different from other react-like frameworks is that the components are just functions that don't even have to return anything. They don't have to be top-level; they can be methods of a class. And if they're in a class, you can use the constructor to declare their dependencies. You can then use Dagger to build the component graph. It's one of the things I explored in a toy project I started a few months ago (now outdated and abandoned because there's too many things to fix: https://github.com/monzee/over-engineered/blob/10277ef55e8683af14372076998ded7935ba3265/app/src/main/java/ph/codeia/overengineered/mvi/login/LoginForm.kt#L18)

Not only that, but

mutableStateOf

gives you a way to sideways-data-load into composables values that don’t change per specific sub-hierarchies of a composition, which is the problem that ambients are attempting to solve

@andylamax would be nice to hear your conclusions here. As the question seems to be asked from time to time, Thanks. https://stackoverflow.com/questions/64621371/how-to-hoist-multiple-states