Path prefixing

[arctic-hen7]

Is your feature request related to a problem? Please describe.
Having built the new Perseus website ready for GitHub Pages, I've realized that it's actually currently impossible to deploy because Perseus assumes everything is at the root of the site, when in fact it may be under something else (like /perseus/... for a Pages site).

Describe the solution you'd like
Perseus should support a new optional parameter to define_app! called prefix that allows it to support being hosted underneath an existing URL. This would then be a simple matter of prepending this prefix to every call to .perseus/ that the app shell makes. This particularly affects exported sites.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[lukechu10]

A problem with this fix is that the base url is hardcoded into the binary which makes it less flexible. Instead, consider using something like the following (from Sycamore's router):

https://github.com/sycamore-rs/sycamore/blob/99a3ff0fc4d6499276748277f87e1ddadd5b067f/packages/sycamore-router/src/router.rs#L124-L140

This extracts the base url from a html <base> element.

[arctic-hen7]

Yeah I agree, I was ruminating over the inconvenience of it yesterday. Yours however is a far better solution, so I think I'll use that! Thanks for the tip!

[arctic-hen7]

Unfortunately, that's actually not going to work because of the SSR issues. We inline some critical JS that calls the Wasm, which needs to know the base path, and we can't reliably parse that without parsing the entire HTML shell, which will incur a major performance issue. Also, there are issues as to running code that uses the base path in templates, because they might be rendered on the server or the client. It might well be feasible to use an environment variable though, because that would be far more flexible.

[arctic-hen7]

Okay, I've decided to go for a joint approach that's about as flexible as I think I can get it without major re-architecturing. You set a PERSEUS_BASE_PATH environment variable for the server-side stuff (which works perfectly) and then that gets sent to the client for use there. That latter part isn't implemented yet, but it should work well.

@lukechu10, when I use <base> on the client though, Sycamore seems to strip that away entirely, navigating to /about rather than /perseus/about (even with an explicit call navigate("/perseus/about")). Is that behavior intentional, and if so, why?

[lukechu10]

Is that behavior intentional, and if so, why?

No that is not intentional. Make sure you are using about rather than /about as the latter strips away the root, even with a base tag.

[arctic-hen7]

Hmm, I observed the same behavior with about I think, but I'll have another look.

[arctic-hen7]

Sometimes I do not understand the web. Setting the base href to http://localhost:8080/perseus doesn't work, but http://localhost:8080/perseus/ does. A trailing forward slash seems to fix the matter completely (even in a regular HTML file without Sycamore).

If you do not put a trailing slash to your base href attribute, foo will be treated as the last, volatile part of the path and will essentially be removed.

Documented here.

Given that, I'll use the environment variable on the server and then the <base> tag on the client-side!