Dependencies to composable and access to DestinationDependenciesContainer about compose-destinations HOT 7 CLOSED

I see. At the moment, I think CompositionLocal is the correct solution for you then.

// top level
val LocalNavigator = compositionLocalOf<Navigator> { error("No LocalNavigator was provided") }

// inside your Activities or every time you need to provide a different Navigator instance
CompositionLocalProvider(LocalNavigator provides myNavigator) {
    // ... Content goes here , for example your DestinationsNavHost call
    // This part of Composition will see the `myNavigator` instance
    // when accessing LocalNavigator.current
}

// then in your screens:
@Destination
@Composable
fun MyScreen(
    navigator: Navigator = LocalNavigator.current
) {
    navigator.navigate//...
}

This specific code was not tested, so take it with a grain of salt.

from compose-destinations.

Sounds, good! Thank you for the help and the nice library.

from compose-destinations.

@Rawa I brought back Dependencies container feature. It was helpful for multi-module too.
It was also improved.
So in case you prefer using that over CompositionLocals (which have the issue of creating implicit dependencies that all children Composables can also access), you can migrate to it :)

from compose-destinations.

Hi @Rawa !
Thanks for opening the issue 👍

So yeah this was a conscious decision. The reason is that container was a bit awkward to send specific things like lambdas and "Composable runtime stuff" (for example if you wanted to pass State<Something> it wouldn't work as expected ).
I thought about keeping both solutions where the container could be used for general components that you want to pass to a lot of composables and keep the manual calls in case there is a specific Screen that you need something else, BUT, I was afraid that would increase the complexity of the APIs and have at most some very niche actual use cases. Especially because both things intersect with CompositionLocal in some use cases.
So basically I figured between calling manually and CompositionLocal, all cases would be solved without increasing complexity unnecessarily.

That said, have you looked into CompositionLocal to pass stuff to your screens? If there are components that all or most of your screens need, maybe that could be a good solution for you.

In the end, I still don't have a final decision. If I see enough people wanting the DestinationDependenciesContainer back, I can totally bring it back easily.

Hope this helps at least explain my thought process, and please let me know if CompositionLocal or manually calling your composables is an ok solution for you.

from compose-destinations.

@raamcosta Thanks for the detailed reply, I understand your line of thinking, and also agree that is most cases is solved by other alternatives. In general I don't believe one should pass around State<Something>, but I see your point since it can snowball away into a DI framework.

In my case the component I want to provide to the composable is a activity navigator, similar to a destinations navigator but it helps me with logic navigate to another activity. Currently I could inject this into the view model to solve it or cast activity and then grab it, but it feels more like it is a implementation detail that the view should handle. Unfortunately I don't think a LocalComposition would help in this case, but feel free to correct me if you think I'm wrong.

from compose-destinations.

Closing this, let me know if there is anything I can help with.

from compose-destinations.

Thanks!

from compose-destinations.