Include default server route rules by default

[svara]

This PR builds on top of #74 and addresses #71.

Context

Turbo Native allows server-driven routing in Rails applications. Previously, developers had to explicitly define these routing rules in the path config. This PR adds default routing rules for server-driven navigation directly into the framework.

Changes

• recede, resume and refresh historical location rules (historical location rules) have been added as PathRules.
• historical location rules are now loaded by default whether or not the source of the path config is provided.
• the NavigationHierarchyController has been adapted to handle the historical location rules.

Historical Location Behaviour

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.

[jpsphaxer]

I like this approach @svara - thanks for sharing this!

[svara]

The delays are far from ideal, but they are necessary to ensure the view lifecycle methods execute properly and the tests pass. I’ll explore architectural improvements in the future.

[joemasilotti]

I'm surprised these are needed even with the TestableNavigationController presenting everything without animation. Does pushing, popping, or dismissing require the delay?

[svara]

Without the delay the recede historical location test fails. Even though the presentations are not animated, I doubt the view lifecycle methods are all called synchronously. I'll investigate.

[jayohms]

Great work on this @svara. Just a couple questions to start.

[jayohms]

It's possible that someone includes these historical location paths in their files, attempting to override the default behavior. Are there other properties that we should explicitly provide here? I'm thinking we should at least provide "context": "default" for each of these rules to make it clear these don't operate in the modal context.

[svara]

Good point! They could, but since the default rules are added last, they will always override those in the path config. I'll add "context": "default" and also a test.

[jayohms]

Is visitable already being used in the library? If so, how/where is it being used? Android doesn't have a corresponding property, so I'm curious if there's anything to align here.

[svara]

Good catch! It isn't. We use it internally in the email app. I'll remove it.

[joemasilotti]

The guard with the != nil feels like a lot of inverse logic. What if we used an if statement here instead?

if visit.isHistoricalLocation, navigationController.presentedViewController != nil {
    navigationController.dismiss(animated: visit.animated)
}

[svara]

I personally don't have issues with this and use guard extensively for early returns. If you feel strongly about this we can switch to if.

[joemasilotti]

I don't feel strongly, no. It just took me a few reads to understand when dismiss(animated:) would be called.