feat: Relative links#1204
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1204 +/- ##
==========================================
- Coverage 45.57% 45.56% -0.02%
==========================================
Files 484 484
Lines 34077 34081 +4
Branches 8532 8532
==========================================
- Hits 15531 15528 -3
- Misses 18495 18502 +7
Partials 51 51
Flags with carried forward coverage won't be shown. Click here to find out more.
|
91e3c14 to
e1a2fa7
Compare
| <Route exact path="/" component={AppInit} /> | ||
| <Route path="/notebook/:notebookPath+" component={AppInit} /> | ||
| <Redirect from="*" to="/" /> | ||
| <Route path="*" component={AppInit} /> |
There was a problem hiding this comment.
Was the redirect causing an issue with the relative paths? It was to not show random URL paths that don't mean anything like /ide/somethingIMadeUp
There was a problem hiding this comment.
Yea this doesn't work correctly with the './' at all, because it is just using the current URL path as the "basename".
I think instead, we should be getting the path from the import.meta.url (where are assets are). Not sure if the newer version of react-router-dom helps with this, but it has many breaking changes: https://reactrouter.com/en/main/upgrading/v5
For now I'll just fix up the base URL here.
Also it doesn't look like the /notebook/ redirect works anywhere right now.
There was a problem hiding this comment.
Also, thinking about this even more - the BASE_URL set to ./ would screw up any routing we'd have with paths, since the index.html would be incorrect. e.g if I go to /ide/notebook/foo.py, it'll serve up the index.html, but the path to the assets will be incorrect, e.g.:
<script type="module" crossorigin src="./assets/index-05abad89.js"></script>
... Which would try and load /ide/notebook/assets/index-05abad89.js, which is of course incorrect.
Hmmm.
There was a problem hiding this comment.
Opted for using BASE_URL=./, with the knowledge that deep-linking will fail unless the server/proxy is configured to rewrite the base tag on index.html. I think that's an acceptable compromise.
HashRouter sucks, it always writes a hash to the URL, and building relative URLs on the hash doesn't work right (e.g. you can't just do new URL('./mypath', document.baseURI) since that just gets rid of the full hash path).
|
We discussed having the server parameterize the head base url - can you post a snippet of that section of the index.html @mofojed. From a purity standpoint, it's a bit hacky as now we aren't being a "transparent proxy". There was also discussion around using query parameters instead of paths, and that could solve the issue. Or, potentially a service worker. |
|
There's a note in the Create React App docs about this: https://create-react-app.dev/docs/deployment/#serving-the-same-build-from-different-paths
We use Vite, but the same principles apply. We are serving up a static application, and client-side routing will not work correctly in this scenario. Either we don't do client-side routing (just using query params to specify paths), or we need server to rewrite the correct @devinrsmith The snippet that would need to be written in the index.html is similar to what we write in Enterprise (though it's written at Web UI Client build time, not dynamically by the server): |
|
Ok - I'm still interested in the query param route so the proxy / server can be completely transparent about it. If we need to test out the server/proxy re-writing |
|
We could still do client side routing with the HashRouter, the URLs are just a little bit ugly since they become HashRouter lets the bundle stay at a single URL. Everything after the hash is client-side only for displaying routes from the single bundle. |
|
@dsmmcken how about using HashRouter for client side routing? |
|
No. Client side routing is a feature of the app. |
|
What client routing that we currently use would hash router not support? We don't use the history API in enterprise, so even though there are different URLs, you can't navigate forward/back. So hash router would work identically aside from the URL containing a |
|
This cleans up some of the env vars and adds a |
- Merge in the latest main
39928e3 to
2189ddf
Compare
- It was ugly. If server wants deep-linking, they need to handle it - Add notebook routes to the vite proxy
- Use URL path resolution instead of `path.resolve` - When using base `./`, and then relative jsapi path `../jsapi`, path.resolve wasn't working because it was trying to navigate to a local directory. Instead use URL path resolution, so the path doesn't go up past the root accidentally
- We want the preview to run with the base URL of /ide/ so tests go to the correct route - Fix proxy URLs to be anchored at the start
- It was previously still showing a spinner
| const layoutStorage = new GrpcLayoutStorage( | ||
| storageService, | ||
| import.meta.env.VITE_LAYOUTS_URL ?? '' | ||
| import.meta.env.VITE_STORAGE_PATH_LAYOUTS ?? '' |
There was a problem hiding this comment.
Layout and notebooks path might not need to be env variables (and might not even need to be part of the constructor), but that's a discussion/change for another PR
There was a problem hiding this comment.
It was handy when we hadn't solidified the path yet. Would still need it somewhere global.
There was a problem hiding this comment.
It's only used here. So we have an env variable to define a constant value used in 1 place specific to the app. Potentially useful if we have cases where we need to change it or proxy it. But right now we do neither
Fine to leave for now, just seemed a roundabout way to define what is now a constant value used in 1 location
| # Any routes we define here | ||
| VITE_ROUTE_NOTEBOOKS=notebooks/ |
There was a problem hiding this comment.
Not a big fan of this being an env variable. Router we will almost certainly want static unless someone really wants to change the URL paths for some reason
There was a problem hiding this comment.
Still need to have it globally somewhere. Where would you suggest?
There was a problem hiding this comment.
I guess this is fine. Just feels odd to have notebooks/ and a /notebooks in here for slightly different uses
This is only used in the router and in ConsolePlugin, so I'm curious if there's a way to use it more cleanly in both. Not worth trying to figure out now though.
I think it's only used for linking from a markdown notebook right now. Might not need to have the URL if we know the file will just be relative to the GrpcFileService base
There was a problem hiding this comment.
Yea the reason I had two is because the GrpcFileService does not necessarily have the same path as our route. They are different things, after all.
Uh oh!
There was an error while loading. Please reload this page.