Experiment with react-router instead of the current snap scrolling experience

[Transfusion]

Mobile browsers already use edge swiping for navigating forward and backward (!)

Background routes should have no problem being unmounted because all the information, besides scroll positions, perhaps, is in the DataContextProvider.

It would avoid all of the issues associated with Chrome mobile jumping back to the left of the StickyOutputBarWrapper.

[Transfusion]

It would also be much easier to implement hash / browser routing or providing a URL that directly pre-fills certain input boxes with certain data.

[Transfusion]

https://react-swipeable-views.com/demos/demos/ is being considered - a basic implementation can be found in the https://github.com/Transfusion/cjk-radical-search/tree/ids_etl_ui_react_swipeable_views branch.

https://github.com/oliviertassinari/react-swipeable-views/blob/241a723b13ab950234585acd2e950add153897cc/packages/react-swipeable-views/src/SwipeableViews.js#L787-L795

There appears to be quite a large performance penalty because react-swipeable-views attaches mouse and touch listeners on the div and calculates a transformation matrix on the fly - blocking time when swiping from the search screen to the component picker screen in excess of 1 second on a Snapdragon 425 phone.

Profile-20210304T160203.json.txt

It is aesthetically pleasing otherwise and does not seem to suffer from any scroll-snapping issues even though the performance is likely unacceptable.

[Transfusion]

Simulating the swipe animation has an undesirable bug

simplescreenrecorder-2021-03-04_18.56.46.mp4