Get web view's URL at runtime

[joemasilotti]

If a Turbo request is redirected to a page with a Strada component this check would always fail. location is only set when BridgeDelegate is initialized. This change dynamically grabs the URL from the web view, falling back to the original location if nil.

Fixes #23 and should also address part of #19.

[svara]

This is a nice solution @joemasilotti!
I've left some feedback in #25.

[jayohms]

This is a fine solution 👍

I still believe this is not a core Strada issue, but a combination of redirect urls and Turbo Frames not proposing visits to the mobile Turbo adapters. A ViewController should not have its webview url change from underneath it — because that bypasses the path configuration, and the url maybe be configured a different ViewController or other path properties.

But, this added flexibility is fine and I don't anticipate any issues.

[joemasilotti]

I still believe this is not a core Strada issue, but a combination of redirect urls and Turbo Frames not proposing visits to the mobile Turbo adapters. A ViewController should not have its webview url change from underneath it — because that bypasses the path configuration, and the url maybe be configured a different ViewController or other path properties.

Perhaps a tangent but how do you see this working in an ideal world? If a page redirects should a new visit be proposed? What happens to the "old" screen in that scenario, especially if the new one should be a modal?

[jayohms]

Perhaps a tangent but how do you see this working in an ideal world? If a page redirects should a new visit be proposed?

Ideally yes — but it seems as though lots of apps are using redirects to load the root view controller, so this could make a pretty undesirable experience. I recommend not using a redirect to load the initial page for apps.

What happens to the "old" screen in that scenario, especially if the new one should be a modal?

It's an application bug if you use a redirect for your (non-modal) root view controller to a modal :)

[joemasilotti]

It's an application bug if you use a redirect for your (non-modal) root view controller to a modal :)

Good to know! I've had a bunch of folks asking me about this exact scenario. Usually related to loading /dashboard or similar and then needing to show authentication.

Do you have a recommendation for a workaround there? Assuming folks are not using native authentication.

[obromios]

I tried this PR on issue#28 and it appears to fix the problem.

[dginsburg]

Perhaps a tangent but how do you see this working in an ideal world? If a page redirects should a new visit be proposed?

Ideally yes — but it seems as though lots of apps are using redirects to load the root view controller, so this could make a pretty undesirable experience. I recommend not using a redirect to load the initial page for apps.

@jayohms, I'm here because we ran into the issue in this ticket when using Turbo Frames and Strada. I'd say the problem is broader than your example. It's not just redirects and it's not just a root view controller in the nav stack. Any page that uses redirects or uses Turbo Frames (unsure about morphing) to change the location without a new Visit can hit these issues in the Hotwire iOS native adapters.

Turbo iOS has a similar issue
https://github.com/hotwired/turbo-ios/blob/main/Source/Visitable/VisitableViewController.swift#L6-L11

In Turbo iOS you can work around it because visitableURL is an open var. But I think the default is harmful. The redirects and this way of using Turbo Frames aren't patterns that 37s tends to use, so it's understandable that it never came up as a problem. But they are common patterns in my experience and reasonable ways to use Rails/Hotwire.

The core of the problem is that the location of a page can change after the native controller is created with the original URL. Hotwire allows that so I think it's a first class use case that the native adapters should handle by default.