Would there be a way to add/override the wrappers ...

# compose-destinations

[Suhaib Kazi]

Would there be a way to add/override the wrappers in a feature module and imported in the main graph as an entire feature graph

So that we can add/override whatever wrapper we want on an individual screen level

[Suhaib Kazi]

Also is it possible to manually call the composable in the wrapper? maybe to pass some composable arguments

Or create a dependency in the composable and pass it to the actual composable?

Basically if i have a wrapper for profileScreen and in the wrapper i create the viewmodel to observe some things.

i want the same viewmodel instance to be passed to the profile screen composable too

I know we can use the same instance of the viewmodel in both the wrapper and screen composable using the dependency container. But is there any other way?

[Rafael Costa]

It’s a lot of questions 😅
https://composedestinations.rafaelcosta.xyz/v2/multi-module-setup#import-destinations

[Rafael Costa]

You can add wrappers as you import them to another module, yes

[Rafael Costa]

viewModel creation itself has a way to share instances. If you pass the same back stack entry or activity to it.
So you are able to share ViewModel instances that way.

[Suhaib Kazi]

Yes we can add wrappers for individual external destinations
But is it possible to do it when we have external nav graph? And we are importing that as a graph?

[Suhaib Kazi]

@ExternalNavGraph<FeatureXNavGraph>
With this annotation

[Suhaib Kazi]

Yeah we create viewmodels using the back stack entry and pass it through the dependency container

And what i wanted to know if it's possible to call the contentComposable in the wrapper with artifacts created in the wrapper

Apologies for the barrage of questions

[Rafael Costa]

Wrappers is a concept for destinations only. Graphs don’t have wrappers, so no. What would you want? To wrap all destinations of a given graph?

[Rafael Costa]

Your wrapped Composable probably has a way to get the same things as its wrapper, but no, there’s no direct way to manipulate the calling of the Composable to pass stuff like that

[Suhaib Kazi]

Got the second point

Regarding the first
Yes we can't wrap for graph that's correct

I was wondering if there's a possibility to import an external navgraph and override or add wrappers to the destinations of the external navgraph in the main app

[Rafael Costa]

I don’t really understand the question tbh. If you’re importing the graph as a whole, I don’t think you should need or care about individual screens inside that graph. The idea is to let that be the responsibility of the module that is creating the graph

[Suhaib Kazi]

That is correct.

In my usecase there are a couple of effects i want to consume at the app side, hence the wrapper to observe the viewmodel effects channel and to consume the effects

This is per screen

And yes ideally the module should handle all of it internally.

But we wanted the app side to excise more control

[Rafael Costa]

Wrappers is not the answer here then. And once again, the app in my opinion should not even know which screens are part of the graph it is importing. So you want to find another solution 🤔

[Suhaib Kazi]

Interesting perspective

But again shouldn't the app be able to navigate to any of the imported screen directly to be able to keep it reusable?

[Rafael Costa]

Usually, no. The module represents a feature and how that feature works. It’s actually the opposite, this way makes it more reusable since it does not care about particular aspects of the app that’s using it.
But this is like in a theoretical perspective, I can see cases where that’s not possible or feasible.

[Rafael Costa]

Ultimately, do it your way, but wrappers is not the answer. With official navigation, the equivalent to wrappers would also not be possible unless you import the destinations one by one.

[Rafael Costa]

which you can still do

[Suhaib Kazi]

Currently we are importing the destinations one by one and creating a graph at the apps end.
Which led to the other error mentioned in another thread.

Also to give more context, the external module is a library we created to hold similar features for multiple projects we have.

Small example:- Login screen feature with all the working with exposed interfaces for usecases and repos.

That is why i thought it would be great to have more control at the individual apps end.

[Suhaib Kazi]

Im guessing your following question would be why not just have them as composables in the library and create destinations using those composables.

That was our previous implementation. but since the viewmodels reside in the library we wanted to make use of the savedstatehandle methods generated by the destinations, hence decided to move the destinations declaration to the library

[Rafael Costa]

Makes sense. 👍

[Suhaib Kazi]

Will try some other solutions for my current usecase
Thanks for taking the time.

Let me know if i can be of any help