Prevent navigating twice when clicking a button quickly

[nihgwu]

When we double-click(or multi-click) a link quickly, it will navigate to the same screen twice, so when we want to goBack, we need click the back button twice to go back to parent screen, that's insane.

I use ExperimentalNavigation before, and if I double-click a link quickly, the app crashes because we are pushing a route with the same key, which is not allowed by ExperimentalNavigation, you can try the UIExplorer to reproduce, so I make a check for it:

1. newKey == latestKey, ignore this action
2. routes.contains(newKey), jumpTo(newKey)

Now in react-navigation it won't crash because every time we dispatch a new action, we get a different key

So my propose:

1. don't generate key if provided in action when dispatching and check for existing
2. generate key according to route params, but I'm afraid that will be buggy because the screen relies on more params expect routeParams

Any thoughts on this?

[nihgwu]

export function routerReducer(state, action) {
  if (action.type.startsWith('Navigation/')) {
    const { type, routeName } = action
    const lastRoute = state.routes[state.routes.length - 1]
    if (type == lastRoute.type && routeName == lastRoute.routeName) return state
  }
  return AppNavigator.router.getStateForAction(action, state)
}

workaround for my case, I know we can custom nearly everything, but IMO this issue should be fixed in core

[satya164]

Another option is to just debounce the function you're dispatching from.

cc @ericvicenti

[nihgwu]

but debounce would make transition a bit laggy and we should let user to dispatch them own keys
dispatch(NavigationActions.navigate({routeName: 'Detail', key: 'user-123'}))

[grabbou]

Now in react-navigation it won't crash because every time we dispatch a new action, we get a different key

To me it's a feature. Imagine a screen, like userProfile that is generic and accepts user details to display as a JSON. It can be in the stack as many times as I want.

[nihgwu]

@grabbou But I don't think we should override the provided key, at least show a warn about overriding or key generation strategy

[satya164]

@nihgwu : but debounce would make transition a bit laggy

Maybe I'm missing something, but why would it?

cc @ericvicenti What do you think about this? This is has been a common issue I have faced in all of the apps I have worked on so far.

Mostly I used NavigationExperimental or ExNavigation. In case of former I did changes in reducer to not push same routes with same params twice

ExNavigation had a debouncing mechanism to prevent navigating twice in quick succession. cc @skevy

[nihgwu]

@satya164 my mistake, a debounce would be fine, but we should stop overriding custom keys

[arnsa]

@satya164 @nihgwu care to explain how can I implement this with a TabNavigator? Because state.routes[state.routes.length - 1] is always going to be last tab bar item for me.