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
l
Leland Richardson [G]
06/30/2020, 1:17 AM
if you’re asking if there is an equivalent to React’s “context”, then yes - “Ambients”.
Copy code
val ambientFoo = ambientOf<Foo> { DefaultFoo }
@Composable fun Root() {
// provider
Providers(ambientFoo provides myFoo) {
App()
}
}
@Compoable fun Leaf() {
// consumer
val foo = ambientFoo.current
}
Leland Richardson [G]
06/30/2020, 1:18 AM
that said, I think that “prop drilling” is often (but not always) an indication of poorly separated concerns and API design and ambients are often not the right choice to “get rid of” these problems
➕ 4
a
andylamax
06/30/2020, 1:46 AM
Thanks, That's exactly what I was looking for.
m
mon
06/30/2020, 3:02 AM
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)
l
Leland Richardson [G]
06/30/2020, 3:44 AM
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