swipe from message view back

[Aman-Maheshwari]

Proposed changes

Fix: issue handling go back on swipe on android

Issue(s)

fixes #4036

Video

SwipeBackMessageFixed.mp4

[chrisbobbe]

Thanks, @Aman-Maheshwari! A few comments below.

Also, thanks for fixing the code-style errors flagged by CI. Here are a few tips that should help make that process easier 🙂:

• You can run tools/test locally to run our full test suite locally, so you don't have to push the code to GitHub and wait for GitHub Actions (which is slower) to do so.
• If you use VSCode with our recommended setup, a lot of small formatting mistakes should be fixed automatically when you save a file. Alternatively, running tools/fmt will also fix those errors.
• Please squash the fix-up commits into the same commit that introduced the errors (this doc should help). That way, you don't need to make separate PRs for a single set of proposed changes, and we can maintain the invariant that we don't merge a commit with failing tests. 🙂 I see five commits: what looks like one main commit followed by four fix-up commits. Those five should be condensed to just one commit.

Then, please write a clear, coherent commit message for the commit, following our commit-message style.

[chrisbobbe]

How did you arrive at the number 20 for gestureResponseDistance.horizontal? 🙂 The doc says it defaults to 25. If we're not keeping the default, let's write down the reason in a code comment.

[chrisbobbe]

How did you arrive at the choice to configure the particular routes chat and search? 🙂 Did you find a reason not to apply the changes to all routes on AppNavigator, e.g., with defaultNavigationOptions?

I think this is a place where consistency would be helpful; a user might get confused if they find they can sometimes use the gesture and sometimes not, in similar situations. For that reason, I think using defaultNavigationOptions would be a good idea.

The doc I linked to in #4036 says that we should be careful to avoid situations where two things are set up to respond to the same gesture, with one of them being this new back-navigation handling. Did you find a situation like that? If so, it might be helpful to "opt out" of the back-nav gesture for that particular screen (if we can't easily just get rid of the pre-existing gesture handling) by, e.g., setting gestureEnabled: false on that screen—rather than "opting in" to the feature for just one or two screens.

[Aman-Maheshwari]

How did you arrive at the choice to configure the particular routes chat and search?

I considered the issue #4036 is being refer to giving user an alternative and a familiar way to navigate back from the message(chat) screen (swipping left to right).

I considered to apply the same thing on the search route to make goback action( by swipping left to right ) consistent for all the options( all message, starred, mention, search) in upperTabNavigator.

I think using defaultNavigationOptions would be a good idea.

Yes, I agree to this point.
Should I consider applying it as defaultNavigationOptions ?

The doc I linked to in #4036 says that we should be careful to avoid situations where two things are set up to respond to the same gesture, with one of them being this new back-navigation handling. Did you find a situation like that?

No, I could not find any situation like that. On Android no gestures are registered for the action swipe from left to right.

Also I have read in docs that states gestures are enabled by default in IOS and not on Android, so a platform specific code can be written to use gestures in defaultNavigationOptions.

Can this be considered as a point of consistency for users on different platforms(IOS and Android) ?.

[chrisbobbe]

Should I consider applying it as defaultNavigationOptions ?

Yes, let's try that.

Also I have read in docs that states gestures are enabled by default in IOS and not on Android, so a platform specific code can be written to use gestures in defaultNavigationOptions.

Yes, let's use Platform.select to apply the new settings to Android only. The new settings may coincide with the default settings on iOS, but navigation is one of the areas where iOS and Android have important differences in how they want navigation to be handled, so I think it makes sense for our code to treat the two platforms separately here.

[chrisbobbe]

#4398 (comment):

How did you arrive at the number 20 for gestureResponseDistance.horizontal? 🙂 The doc says it defaults to 25. If we're not keeping the default, let's write down the reason in a code comment.

Bump. 🙂 I suspect the default is probably fine; it's not much different—but perhaps there's a compelling reason not to use it?

[chrisbobbe]

Thanks for your response, above! I've just replied, at #4398 (comment).

One important piece of news for this area of the code is that we've just finished upgrading to React Navigation v5, in #4393. That means you should consult React Navigation's docs for version 5, instead of version 4. It also means that the current PR branch now has a rebase conflict; you might resolve it as part of rebasing atop the latest master; or, if that proves to be complicated, you could discard it and start over at the latest master.

[Aman-Maheshwari]

created a new PR for this issue #4432. closed this PR becaues of merge issue.