What is the purpose of `Turbo::Native::Navigation`?

[hotwired]

What is the purpose of `Turbo::Native::Navigation`?

[zachwaugh]

Turbo::Native::Navigation are specific urls with some semantic meaning that the apps can handle in a way that makes the most sense for that particular app/platform. For example, there may be cases on the web where it makes sense to redirect to a particular url. In the same case in the mobile apps, we might want slightly different behavior. A common case is things that mobile apps present a form in a modal (like composing a new email). When that email is sent, we want to recede to the previous screen by dismissing the modal and not follow the redirected url that the web does.

Which part handles the native specific response?
What happens to a client if one gets that kind of response?

There is nothing built-in to the libraries to handle it. This just sends different redirect urls depending on the user agent and the response comes in as a normal visit proposal like any other url. It's up to the client app to decide how to handle those urls.

Should a port to another language of turbo-rails include Turbo::Native::Navigation?

I think it would make sense to include for parity, but probably not necessary since we haven't documented it well and it's not likely anyone is relying on it. It's also completely optional. I'll add a to-do for myself to better document how this is intended to work.

[tonysm]

Ayush shared this article on the topic a couple days ago: https://dev.to/ayushn21/directing-turbo-native-apps-from-the-server-187c

[pfeiffer]

Hey @zachwaugh, sorry for resurrecting this old issue.

While I understand that the implementation of how to handle these special semantic URLs differ from app to app, could you share some light into the behavior that you are currently using for the resume, recede and refresh action?

We are working on an open-source React Native wrapper around turbo-ios and turbo-android. The React Native wrapper provides a stacked navigation and it would be great to support these semantic URLs out-of-the-box.

If you provide some details in this issue, I'm happy to wrap that up in a PR that fixes the FIXME: .. comment in the file mentioned :-)