Problem
There is a category of frontend issues related to "back-button" behavior. See this comment for many examples, or search "back button" in App/issues. Some of these are legit one-off bugs but many of these issues go like this:
- User enters into a flow that has an RHP with multiple steps (ex: adding a new company card)
- User hits device back button or browser back button
Expected: user goes back to previous step
Actual: user is (often) navigated entirely out of the flow and back to whatever page they were on before entering into that flow
Why does this happen?
Because our "step" logic for navigation often doesn't change the url, and when you hit the device's back button it pops to whatever was previously on the navigation stack, resulting in the user going much farther back in the flow than they intended to. In this GH we decided that the "ideal" behavior would be for the device back button to go back a step when a RHP has multiple steps in a flow, but the fix for making this ideal behavior happen is not easy since it requires re-doing how we implemented large parts of our navigation code. See SWM dev's explanation here.
Next steps:
We came to the conclusion in this issue that the back buttons in the app behave inconsistently and in a way that we don't think is ideal, and we discussed here about how to fix this. We need an internal engineer to pick this up and lead a group of contributors to tackle this problem. Would need a P/S, small design doc and implementation with C+ (similar to the Onyx.connect project). Most of the confusion comes from screens not using separate routes/ URLs (in multi-step forms, some reused components like currency picker etc). We should plan how to fix this, update the navigation philosophy if it was unclear somewhere and tackle the refactoring with the community.
Issue Owner
Current Issue Owner: @VickyStash 
Design Doc
Problem
There is a category of frontend issues related to "back-button" behavior. See this comment for many examples, or search "back button" in App/issues. Some of these are legit one-off bugs but many of these issues go like this:
Expected: user goes back to previous step
Actual: user is (often) navigated entirely out of the flow and back to whatever page they were on before entering into that flow
Why does this happen?
Because our "step" logic for navigation often doesn't change the url, and when you hit the device's back button it pops to whatever was previously on the navigation stack, resulting in the user going much farther back in the flow than they intended to. In this GH we decided that the "ideal" behavior would be for the device back button to go back a step when a RHP has multiple steps in a flow, but the fix for making this ideal behavior happen is not easy since it requires re-doing how we implemented large parts of our navigation code. See SWM dev's explanation here.
Next steps:
We came to the conclusion in this issue that the back buttons in the app behave inconsistently and in a way that we don't think is ideal, and we discussed here about how to fix this. We need an internal engineer to pick this up and lead a group of contributors to tackle this problem. Would need a P/S, small design doc and implementation with C+ (similar to the Onyx.connect project). Most of the confusion comes from screens not using separate routes/ URLs (in multi-step forms, some reused components like currency picker etc). We should plan how to fix this, update the navigation philosophy if it was unclear somewhere and tackle the refactoring with the community.
Issue Owner
Current Issue Owner: @VickyStash