useLinkProps not generating correct link in browser

[khagesh]

Current behavior

I am not sure if I am doing something wrong or there is some bug in useLinkProps. I posted a stack overflow question as well. Please feel free to close this and answer stack overflow question here React Navigation: useLinkProps not generating correct link in browser.

Basically if I have a stack navigator inside a drawer navigator, then useLinkProps does not generate correct link for command+click behaviour or for copy link.

I am using react-navigation v6 and expo 49. But in the snack I provided, I am using expo 50 and latest packages. Bundler for web is webpack. But in snack link, it is metro.

I need help with react navigation. It is around how links are generated. I have created a linking config which has a config like

[screenNames.itemDetail]: {
  path: "item-detail/:itemId",
  exact: true,
}

I am using useLinkProps to generate href links on web. Here is that code snippet

const { onPress: onLinkPress, ...linkProps } = useLinkProps({
  to: {
    screen: screenNames.itemDetail,
    params: {
      itemId: item.id,
      origin: "search",
    },
  },
});

If I am on same browser tab and click on the link that gets generated. I go to correct link which is /item-detail/40?origin=search. However, if I use ⌘+click or right click to open in new tab, the link that I get is /item-detail?itemId=40&origin=search. Notice that itemId is a param now.

How do I make sure that link that is generated is always item-detail/40?

Another thing that I noticed is that if I don't nest Stack Navigator inside Drawer navigator, then I get the correct link no matter if I open in new tab or same tab. But this is not realistic for me because we need that Drawer navigator.

I don't want to create the exact link string myself. I know I can always serialize params for query string myself and give react navigation the exact path. By doing this, I loose strict type checking for params and screen names.

Expected behavior

I should always see generated url as /item-detail/41?origin=search

Reproduction

https://snack.expo.dev/@khageshfoodapp/hello-react-navigation-|-react-navigation

Platform

• Android
• iOS
• Web
• Windows
• MacOS

Packages

• @react-navigation/bottom-tabs
• @react-navigation/drawer
• @react-navigation/material-top-tabs
• @react-navigation/stack
• @react-navigation/native-stack
• react-native-tab-view

Environment

• I've removed the packages that I don't use

package	version
@react-navigation/native	6.0.10
@react-navigation/bottom-tabs	6.3.1
@react-navigation/drawer	6.4.1
@react-navigation/material-top-tabs	6.2.1
@react-navigation/stack	6.2.1
@react-navigation/native-stack	6.0.10
react-native-safe-area-context	4.8.2
react-native-screens	3.29.0
react-native-gesture-handler	2.14.0
react-native-reanimated	3.6.2
react-native-tab-view	3.0.0
react-native-pager-view	6.2.3
react-native	0.73.1
expo	50.0.0
node	v18
npm or yarn	yarn

[github-actions]

The versions mentioned in the issue for the following packages differ from the latest versions on npm:

• @react-navigation/native (found: 6.0.10, latest: 6.1.10)
• @react-navigation/bottom-tabs (found: 6.3.1, latest: 6.5.12)
• @react-navigation/drawer (found: 6.4.1, latest: 6.6.7)
• @react-navigation/material-top-tabs (found: 6.2.1, latest: 6.6.6)
• @react-navigation/stack (found: 6.2.1, latest: 6.3.21)
• react-native-tab-view (found: 3.0.0, latest: 3.5.2)

Can you verify that the issue still exists after upgrading to the latest versions of these packages?

[khagesh]

Yes, it is still happening. I updated snack to use latest versions and it is still the same.

[khagesh]

I realized that I needed to pass exact same structure to useLinkProps as we have in our navigator. So, if I do below then everything is fine.

useLinkProps({
  to: {
    screen: "main-drawer",
    params: {
      screen: screenNames.itemDetail,
      params: {
        itemId: item.id,
        origin: "search",
      },
    },
});

[github-actions]

Hey! This issue is closed and isn't watched by the core team. You are welcome to discuss the issue with others in this thread, but if you think this issue is still valid and needs to be tracked, please open a new issue with a repro.