feat: use request host for hot-reload instead of window.location.host

[amrbashir]

Checklist

• Updated CHANGELOG.md describing pertinent changes.
• Updated README.md with pertinent info (may not always apply).
• Updated site content with pertinent info (may not always apply).
• Squash down commits to one or two logical commits which clearly describe the work you've done. If you don't, then Dodd will 🤓.

This is a continuation of #494, when using tauri on mobile, we proxy the requests and the files are served using a custom protocol https://tauri.localhost so window.location.host will be tauri.localhost and the hot-reload socket won't connect. To fix this, trunk will hard-code the address inside the auto-reload script.

[thedodd]

Looks like this is going to need rebasing / updating. Also, while you are at it, do you mind elaborating a bit on what this solves and why this might be needed? Also, very importantly, I acknowledge that this may fix an issue for you, but will this break other users?

[amrbashir]

For tauri on mobile, due to some limitations, the webview can't access trunk server on the local network so instead we proxy the requests by connecting to trunk from the native part (Rust) of the APK and then serving the response to the webview using an internal custom protocol, so window.location is actually an internal URL which will be http://tauri.localhost but that is not an actual dev server and so connecting to it via websockets will fail.

With this change, we modify the HTML on the fly before serving it based on the incoming request URL, so if we have trunk configured to listen on 0.0.0.0 (means to listen on all local addresses), and a tauri app tries to connect to 192.168.1.13:8080, it will be served an HTML file that has hot-reload script that tries to connect to the socket on 192.168.1.13:8080/_trunk/ws

I don't think this will break for other users but in our fields you can never be so sure, however, for [email protected], we have been recommending users to use my fork (which has this change) for quite sometime now, used with leptos, yew and sycamore, and I haven't had any reports about regressions or bugs related to this but ofc take it with a grain of salt.

[amrbashir]

Is there anything I can do to push this and the related PR forward? It would be great for tauri users to have these features merged in this project so they wouldn't have to use my fork.

And I apologize if this sounds rude or impatient on my part, I appreciate your hard work and I am not trying to put more work on your plate.

[ctron]

I cherry-picked this into trunk-ng and will test it locally. If that looks good, it should be in the next release.

[ctron]

It's released as part of trunk-ng 0.17.10

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.

[amrbashir]

damn, forgot to comment to keep this PR open, I would still like to see this PR land if possible

[ranile]

damn, forgot to comment to keep this PR open, I would still like to see this PR land if possible

Referencing #625 here as well

[ctron]

This should come back to trunk with #623

[amrbashir]

closing as this has been superseded by #623