Deep Linking: Allow many paths to be configured for a single screen

[bowen9284]

In our app, it's not uncommon to have a screen support both a new and edit state. For example, we have a Products Screen which can be deep linked to with the following paths /products/${productId} and /products/new.

Because our screen (Products) within the linking configuration object accepts an object and not an array, we can only assign a single path to a screen. I've seen the workarounds in #9328, but they feel a bit hacky and it's not scaleable in our large application.

I wanted to get your opinion on the following API where we pass an array to our screen instead of an object. I plan on trying to implement this approach this week.

Thanks!

const linking = {
  prefixes: ["https://example.com/", "myapp://"],
  config: {
    screens: {
      Products: [
        {
          path: "products/:id",
          parse: {
            id: (id) => `${id}`,
          },
          stringify: {
            id: (id) => `${id}`,
          },
        },
        {
          path: "products/new",
        },
      ],
      ScreenB: "pathB",
    },
  },
};

[satya164]

Which path will be displayed in the browser URL bar when you navigate to this screen if there are 2 different paths defined for the same screen?

The example above is already possible with a single path: products/:id. To support new all you need to do is to check route.params.id === 'new' inside the screen.

For more complex cases the proper approach is to have 2 screens instead of one. If you have a component with logic for 2 states, then reuse that component in both screens.

[satya164]

The simplest solution is to just add a comment if you want to be able to know all the types from the pattern.

All the examples add complexity during processing the URL as well as increase verbosity of user code when simpler alternative exist.

If that's not enough then instead of having a single WebView screen you can have multiple screens for each type as well. A single component doesn't mean it has to be a single screen as well. The same component can be used for multiple screens.

[bowen9284]

All the examples add complexity during processing the URL as well as increase verbosity of user code when simpler alternative exist.

I mostly agree with this and my API could be improved 😄 But I feel like the existing config object is too rigid and dictates how you should organize your screens. In my opinion, the ideal state would provide more flexibility and not force us to create new screens in order to satisfy deep linking.

I'm sure you've seen this issue, but there is a desire for something like that.

If that's not enough then instead of having a single WebView screen you can have multiple screens for each type as well. A single component doesn't mean it has to be a single screen as well. The same component can be used for multiple screens.

Absolutely. This is one of the approaches we are considering.

---

I think we're okay with these workarounds, but it it would be great to add more flexibility in future releases. Thanks again for sharing your insights @satya164 !

[satya164]

I think we're okay with these workarounds

These are not workarounds. If there are logically 2 different URLs, then it also makes sense to have 2 screens. It's more confusing to do navigate('Products', { id: 123 }) and navigate('Products') instead of navigate('CreateProduct') and navigate('EditProduct').

If the argument against using products:/id for both is that it's not obvious that it's an edit screen or create screen, then why shouldn't the same argument apply to the name of the screen itself?

I feel like the existing config object is too rigid and dictates how you should organize your screens

It only dictates how you should organize your screens if your mental model of a page with a URL is not the same as a screen.

A rigid config is necessary to keep the logic manageable. The config is used to both create and parse the links, the more complex it is, the bigger scope for bugs and mismatches between how creating and parsing links work.

Increasing the complexity is fine when the alternative requires the user to handle the complexity themselves anyway, but it's best to avoid complexity when there are simpler alternatives.

At least in the above cases the complexity only arises because you want the path pattern to contain info (such as type of screen) that the screen name itself doesn't have.

I'm sure you've seen #9328, but there is a desire for something like that.

That's a very different case where there are 2 different URL formats to mean the same thing. SEO concerns with such an approach aside, I'm not sure those examples show the use case accurately. Using me and user interchangeably is pretty strange. I'd assume it'd be something like /:userId and /me - where me usually denotes the current user ID - which would usually be handled by the server itself and doesn't need extra logic on the client.

We'll eventually support aliases that allow you to map additional patterns to the same screen, but it will only influence the parsing, and not when creating a URL for a route. Similar to how redirections would work on the server.

[bowen9284]

These are not workarounds.

That's fair and I agree that with a 1:1 path to screen relationship, this works great. I think there are valid reasons where a web or mobile would re-use a screen for a create/edit type of functionality. For example, maybe you have 20 screens that share create/edit functionality because you want to avoid having a total of 40 screens. Sounds like aliases could help with that though.

That's a very different case

Maybe I missed something about SEO, but the attached issue looks to be about the same but I proposed an idea of what the API could look like.

[satya164]

Search engines will rank pages based on URL. When the same page has 2 different URLs (which the linked issue shows: /user and /me are equivalent), then it'll rank lower. None of the comments in the linked issue use /me as a user ID, but in the same way /user is used, i.e. not /me and /:userId, but /me and /user.

maybe you have 20 screens that share create/edit functionality because you want to avoid having a total of 40 screens

20 screens seems excessive for create/edit for most apps. Either way, I don't see what's wrong with having more screens. More screens don't mean more duplication. In the end, you still have the same number of components that handle this functionality. Screens are just a way to tell the navigator about different destinations, like URLs. It's better to keep the same mental model for both. A web framework like NextJS would also require a similar approach, though it needs a lot more boilerplate as you'd need to import and export the same component in multiple files.