Ignore React Navigation internal keys when comparing minimal actions #236
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
useWebViewNavigatehas logic to determine the minimum action to be dispatched to go from the current state to the new state when performing navigations.When doing a
replacevisit, we'd like to update the screens params by dispatching aSET_PARAMSinstead of a fullREPLACEaction if the two navigation states are similar enough (ie. same screen in same nesting).React Navigation uses some internal keys that are part of the two states which are not relevant for the library when determining the minimal action, so we ignore those. However, there are a few additional keys that have been added in eg. React Navigation v7 that we also need to ignore.
This PR adds the additional keys to the ignored parameter list in
areParamsSimilarForActionType.These properties don't represent meaningful differences in navigation intent and should be ignored when determining if two routes are similar enough to dispatch a
SET_PARAMSwhen performing areplacevisit.Test plan
Have a screen with a route such as
/subscribe/:action?.Let the first screen load
/subscribethat issue areplacevisit to/subscribe/checkout.Previously, this would result in a
REPLACEaction including an animation between the two screens.After this PR we correctly update the params of the screen, so that no replace animation is shown.