link component with href should navigate to url as a new connection instead of launch browser and allow for target

[bcardarella]

I recall when we made this decision but I don't recall why.

But I now believe we should instead when something like <.link href={~p"/logout"}>Logout</.link> is used we need to actually navigate to a controller to update the cookie. Considering that LVN Core now also supports dead rendering we should just allow for that as well if for whatever reason someone decides to render SwiftUI from a controller. But the primary use case here is to permit session deletion and the expectation is they should then redirect.

This would be in conjunction with #1520 so you'd write the logout link like so:

<.link method="delete" href={~p"/logout"}>Logout</.link>

I do think we should still have a way to spawn a browser, so I believe we should extend the component to support the target attribute from the web. In this case we'd detect something like:

<.link target="_web" href="dockyard.com>DockYard</.link>

Supported values for target

• _self default - similar to web, this is the same app and is really just a noop as far as what the target does
• _web - this would do what the current link behavior does

[bcardarella]

We want to use _blank instead of _web

For the curious why _blank even exists: https://kyrylo.org/html/2024/10/25/why-does-target-blank-have-an-underscore-in-front.html

[fmmatheus]

Considering that LVN Core now also supports dead rendering we should just allow for that as well if for whatever reason someone decides to render SwiftUI from a controller. But the primary use case here is to permit session deletion and the expectation is they should then redirect.

In my experience using LVN, this would allow me to have 1 code to handle user auth and 2 views with basic the same behavior. That's a big win in terms of LVN adoption.

[bcardarella]

@fmmatheus one of our goals is to have "tabs" in that you can share a LV session/cookie jar between different LVs being used within SwiftUI/Jetpack. Then having a separate "windows" where they would be completely sandboxed instances with unique session/cookie jars.