Deep Linking Support

[DavidKmn]

Recently watched the navigation series from Point Free and was wondering how would deep linking be approached in the composable architecture? Had a look and did not find any examples, also did not see deep linking capabilities in the isowords app...

[mbrandonw]

Deep linking in TCA would happen in much the same way as it did in the last episode of the navigation series (this one). You first need to figure out how you are going to process the incoming deep link URL in order to figure out where the user needs to be routed (we used our parsing library to accomplish this, but you can use anything) and then you construct the app state to represent where you want to navigate to.

Although isowords doesn't need deep linking it does need to route push notifications, which is similar. We parse an incoming push notification payload and figure out where to navigate the user here:

https://github.com/pointfreeco/isowords/blob/b87f4c61c0523564adf17c031f9fa4b88a40d631/Sources/AppFeature/AppView.swift#L235-L262

In particular, if the push notification is the daily challenge report we navigate the user to the daily challenge screen here:

https://github.com/pointfreeco/isowords/blob/b87f4c61c0523564adf17c031f9fa4b88a40d631/Sources/AppFeature/AppView.swift#L257-L260

Hope that helps a little bit.

[johnpatrickmorgan]

Thanks @DavidKmn - assuming Home and Product are single-screen features then they wouldn't need their own coordinators. They would each exist in their own modules with no knowledge of each other. The action that triggers navigation from Home to Product would go unimplemented in the Home module. A third module would import both Home and Product and compose them within a Coordinator feature using TCARouter, which would respond to the trigger action by showing the Product screen. Similar to how the individual Home, NumbersList and NumberDetail features are independent of each other (and could be separated into their own modules) in this example:

https://github.com/johnpatrickmorgan/TCACoordinators/blob/b902f399295206d100a806313d1e79a4a3533e34/TCACoordinatorsExample/TCACoordinatorsExample/Screen.swift

If Home were a multi-screen feature with its own coordinator, it wouldn't work so easily.

Apologies if I've misinterpreted your issue!

[DavidKmn]

@johnpatrickmorgan I see what you mean, yeah a solution for sure. I actually went ahead with a custom architecture instead of TCA, was wondering where would you suggest the management of the routes happens. Say we take a basic MVVM architecture, we now go back to a MVVM-C architecture where the View sends actions to the VM and the VM then updates routes in the Coordinator?

[johnpatrickmorgan]

Hi @DavidKmn, TCACoordinators is built on top of FlowStacks, which can be used in non-TCA projects. There's an example in the README of how it can be used with ViewModels. The coordinator is itself a View with its own ViewModel that holds onto an array of Routes. Hope that helps!

[DavidKmn]

Thanks for this @johnpatrickmorgan, sorry for the late reply, somehow missed the Github notification. Had a look at the example, I was wondering why not keep the routes in the view model, any reason why there is a need for a separate view model for the coordinator?

[johnpatrickmorgan]

I was wondering why not keep the routes in the view model, any reason why there is a need for a separate view model for the coordinator?

Thanks @DavidKmn. Did you mean to ask 'why not keep the routes in the view'? If so, yes, you could certainly avoid having a view model for the coordinator and just have the coordinator view hold on to the routes itself. Though if you're using view models for individual screen views, I don't see why you wouldn't take the same approach for the coordinator view too.

In any case, both approaches should work well.