react-native-router-flux: Race condition when quickly navigating between scenes

Version

react-native-router-flux v3.35.0
react-native v0.34.1

Expected behavior

** From someSceneA ** Actions.someSceneB(dataObj); -> yields the expected view with dataObj ** Android back button is pressed to return to someSceneA ** (quickly do:) Actions.someSceneB(otherDataObj); -> instantiates someSceneB with otherDataObj

Actual behavior

* From someSceneA* Actions.someSceneB(dataObj); -> yields the expected view with dataObj ** Android back button is pressed to return to someSceneA ** (quickly do:) Actions.someSceneB(otherDataObj); -> re-renders someSceneB with dataObj

Current fix

It seems like what’s happening above is a race condition, where if you try to navigate too quickly to a component that you’ve already been to, but with a new data object, it will not re-render that component with the new data. If you wait for a second for the animations to complete, the issue goes away.

In order to prevent the race condition described above, I’m doing:

    const onPress = () => {
      InteractionManager.runAfterInteractions(() => {
        Actions.someSceneB({ data });
      });
    };

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 9
Comments: 15

Links to this issue

View not re-rendered when clicking back too fast on Button

Commits related to this issue

V4 announcement, v3 is obsolete now; closes #1,#2,#3,#4,#5,#6,#7,#8,#9,#10,#11,#12,#13,#14,#15,#16,#17,#18,#19,#20,#21,#22,#23,#24,#25,#26,#27,#28,#29,#30,#31,#32,#33,#34,#35,#36,#37,#38,#39,#40,#41,#... — committed to aksonov/react-native-router-flux by aksonov 7 years ago
V4 docs; closes #1,closes #2,closes #3,closes #4,closes #5,closes #6,closes #7,closes #8,closes #9,closes #10,closes #11,closes #12,closes #13,closes #14,closes #15,closes #16,closes #17,closes #18,cl... — committed to aksonov/react-native-router-flux by aksonov 7 years ago

Most upvoted comments

I got this problem too. Tapping “back” button and then quickly tapping to another menu item rendered scene with previous props.

I did as @erikandersson suggested in a related issue:

<Router duration={150} ...>

It solved the problem! And it actually works for any value I tested between 50ms and 400ms, for some reason…

vladimir-e on May 31, 2017

Almost same problem here. scenario:

Actions.page1(); -> opens page 1
Back with android back button or with Action.pop();
Then opens Actions.page2() quickly -> i will see page1 for almost half second, then page 2 appears.

my guess is its happen when Action.pop() didnt finish yet.

yeknava on Oct 18, 2016

IMO - as long as this library is using the forked version of RN ExerpimentalNavigation, that was forked almost a year ago, it’s not a great decision to continue using this library. I don’t fault the authors at all, it’s really hard to maintain a library w/RN constantly changing its API.

I’m now using react-navigation, which has good community support and the API behaves pretty similarly to this one. Hopefully it’ll be the last router based refactor I do for a while.

I’m closing this since it’s unlikely to be fixed and there’s a few workarounds. IMO the best workaround is moving to react-navigation.

dannycochran on May 15, 2017

This is driving me nuts.

loug38 on Dec 20, 2016

Looking through the source code, I believe the issues stems from the react-native NavigationExperimental component. There is a method handleNavigation that react-native-router-flux relies on. That method calls setState(), for navigation purposes. I believe the issue that is occurring is the result of the state change not being finished.

If handleNavigation could return the 2nd argument of setState() which is a callback when it’s finished, we could use that to sync operations and avoid the race condition. Actions.pop() already returns the result of handleNavigation.

The problem obviously is that changing NavigationExperimental is not possible from this project, and I don’t have the context for why handleNavigation was designed the way it is. So this issue may be fairly challenging to solve.

I will use @dannycochran 's solution for now.

meddy on Dec 6, 2016