beta release

[wbazant]

Closes #1070

@ezwelty how do you feel about an enhancement to drop @ from the view syntax? I've confused myself with the test cases I used and gone in completely the wrong direction, wrote code to change how we store path segments, and then it didn't solve the issue. Easy to put it back in or remove but now that I look at the URL without @, I like it a bit more, and now is a great time to change URLs.

Closes #1068
I made the change to keep drawer state in params. Same commit because it also changes src/utils/appUrl.js a lot. It's definitely better - for example there's a skeleton loader shown when going from list to location - and we could maybe use params whenever there's a separate app view, like in the report modal.

On the other hand, it's harder to write transitions in this way. When keeping state in Redux, you can observe changes in state and make dispatches asynchronously, and have separate files for each individual tiny thing like e.g. a location marker on a map, but with url params, they start to clash with each other and make race conditions.

We have code for managing URLs to maintain view and params, so I added a new rule to it - a param with empty value is dropped - and whenever I navigate away from the context of panes I add ?pane=&tab= to reset the pane and tab.

Closes #1076
Closes #1078

[cloudflare-workers-and-pages]

Deploying falling-fruit-web with    Cloudflare Pages

Latest commit:	67522d8
Status:	✅  Deploy successful!
Preview URL:	https://3f57c8a6.falling-fruit-web.pages.dev
Branch Preview URL:	https://issue-1070.falling-fruit-web.pages.dev

View logs

[ezwelty]

@wbazant Thanks for going neck-deep to investigate!

#1070

• App doesn't crash 🥳
• Changing the language again does not trigger a refresh, leaving the map and places in the previous language. Occurs in both mobile app (no restart) and web (no toast).

#1068

• No (visible) URL redirect chain 🥳

• On desktop, it takes 4 clicks of browser back button to go back from location to /changes, /users/:id/activity, or /account/lists, and 2 clicks of back button if I try the same location a second time (?), while on mobile it is either 4 clicks if I access the list without visiting the map, and 1 click otherwise?

• On mobile, if I then click on "go to map" from the location page, then click browser back button, it goes back to the original list, not the full location. And conversely, I can't get back to the original list if I reopen the drawer and click the back arrow (since now the arrow means close the drawer).

• Saved locations page content is too narrow #1076

• Adding new list should seed it with the location #1078

Some additional thoughts on the URLs:

• Frankly, I was always skeptical of the @{lat},{lng},{zoom}z syntax because it seemed like trouble to do something so custom. Without the @, couldn't it lead to issues with ambiguous routing in the future? Is there a good reason not to treat these as standard URL params? ?y={lat}&x={lng}&z={zoom}? And I'm still in favor of dropping all the params into the browser bar (then no need for a share link button in the web version!).
• I notice that map {lat},{lng},{zoom}z and now also pane often end up passed along when navigating away from the map. Is this a bug or needed for a feature?
• If pane=standalone is what we use to link to locations, shouldn't that be the default? Then mobile pane can have three values low, half (or mid), full? Or would we rather link to the half drawer (the pane default) but can't because it has no back arrow? How about using standalone as full, and adding the standalone's back arrow to the half drawer in order to navigate back from it!? (the placemark button of standalone can be used to return to half drawer).