add Server-Driven Routes to path configurations?

[subelsky]

I discovered these useful turbo-rails route helpers in the Hotwire docs:

recede_or_redirect_to(url, **options) # Pops the visible screen off of the navigation stack. If a modal is presented on iOS, the modal is dismissed instead.
resume_or_redirect_to(url **options) # No action is taken.
refresh_or_redirect_to(url, **options) # Reloads the visible screen by performing a new web request and invalidating the cache.

which I found necessary to get forms and modals working properly with the template. @joemasilotti would you be open to a PR adding the routes? e.g.

        {
            "patterns": [
                "/recede_historical_location"
            ],
            "properties": {
                "presentation": "pop"
            }
        },
        {
            "patterns": [
                "/resume_historical_location"
            ],
            "properties": {
                "presentation": "none"
            }
        },
        {
            "patterns": [
                "/refresh_historical_location"
            ],
            "properties": {
                "presentation": "refresh"
            }
        }

[joemasilotti]

This is something we'd love to see included by default! Ideally, this would be built in to the codebase and not require any path configuration to work. So I'm not 100% sure of the implementation path, yet. But if you can get the ball rolling there's a good chance it will help us get it over the finish line.

[jpsphaxer]

Hey @joemasilotti - I would love to get some high-level feedback on the draft PR I opened when you get a chance.

[subelsky]

@jpsphaxer that's cooler than what I was thinking :-)

[jpsphaxer]

@jpsphaxer that's cooler than what I was thinking :-)

Thanks! Another approach I thought about was including those PathRules as default and merging them with whatever rules we get from a file/server. But I am open to suggestions!

[svara]

@jpsphaxer that's cooler than what I was thinking :-)

Thanks! Another approach I thought about was including those PathRules as default and merging them with whatever rules we get from a file/server. But I am open to suggestions!

@jpsphaxer This is what I had in mind too. The advantage of this approach is that we don't pollute the NavigationHierarchyController and introduce additional complexity.
Have a look at #76.

cc @jayohms @joemasilotti

[joemasilotti]

@svara that looks great, very clean! I'm in favor of this approach for the same reason you outlined. I think all the PR needs is a test or two to make sure the rules get added to the right spot and we don't accidentally remove rules.append(contentsOf:).

[svara]

@subelsky thanks for getting this started, and @jpsphaxer thank you for the draft PR and implementation suggestions 🙌
I'd like to provide some context and information on the next steps.

Historical location URLs are often redirected to from the server after a form submission in the "modal" context. The desired behaviour for the apps is to always dismiss the “modal” stack first and then handle the action (resume/refresh/recede) on the “default” stack.

Here's the behavior for each *_historical_location command:

resume_historical_location

1. Dismiss the modal view controller.
2. Arrive back at the view controller on the "default" stack.

refresh_historical_location

1. Dismiss the modal view controller.
2. Arrive back at the view controller on the "default" stack.
3. Refresh the view controller no the "default" stack by revisiting the location.

recede_historical_location

1. Dismiss the modal view controller.
2. Arrive back at the view controller on the "default" stack.
3. Pop the view controller on the "default" stack (unless it's already at the beginning of the backstack).
4. This will trigger a refresh on the appeared view controller if the snapshot cache has been cleared by a form submission.

I'll start working on this next week.

[leonvogt]

Hi @svara,
Thanks for giving some insights!
Until now I thought that the resume_historical_location doesn't pop the modal, since it has the presentation of none. At least, that's what the iOS app currently does. And that's how I interpreted the Routing explanation:

But I can see that popping the modal could be more beneficial and has more use-cases.

And you mentioned about the recede_historical_location:

Pop the view controller on the "default" stack (unless it's already at the beginning of the backstack).

That is what Android currently does. iOS only pops the modal. I thought that Android's behavior is the incorrect one, why I opened a issue on the Android repo. But maybe I'm wrong on that.