Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path prefixing #48

Closed
arctic-hen7 opened this issue Oct 4, 2021 · 7 comments
Closed

Path prefixing #48

arctic-hen7 opened this issue Oct 4, 2021 · 7 comments
Assignees
Labels
A-templates Area: templates C-enhancement Category: enhancement D-easy Difficulty: easy P-high Priority: high S-in-development Status: in development

Comments

@arctic-hen7
Copy link
Member

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.

@arctic-hen7 arctic-hen7 added C-enhancement Category: enhancement A-templates Area: templates D-easy Difficulty: easy P-high Priority: high S-in-development Status: in development labels Oct 4, 2021
@arctic-hen7 arctic-hen7 self-assigned this Oct 4, 2021
@lukechu10
Copy link
Contributor

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member Author

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

@arctic-hen7
Copy link
Member Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-templates Area: templates C-enhancement Category: enhancement D-easy Difficulty: easy P-high Priority: high S-in-development Status: in development
Projects
None yet
Development

No branches or pull requests

2 participants