-
Notifications
You must be signed in to change notification settings - Fork 11
Add new Lustre's frontend #56
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
Conversation
|
Thanks @ghivert! This looks good at a first glance with the caveat that I have limited gleam experience. We are currently working on getting a release pipeline for this so we can test it in staging. We will let you know when that's ready. |
|
If you need additional modifications once your staging pipeline is added, feel free to ask, I'll do it as soon as I can! I'd love to finally push that new frontend live! |
|
If you want to keep the commit history of your project as well as be able to sync the project if you update your repo then you might want to consider using a git subtree. https://gist.github.com/SKempin/b7857a6ff6bddb05717cc17a44091202 Here's what it looks like as a diff: https://github.com/hexpm/hexdocs/compare/main...Gazler:hexdocs:hexdocs/search-subtree?expand=1 |
|
@ghivert can you please send a PR to https://github.com/hexpm/hexdocs-static instead? Or are you fine with us doing that? The home page is actually served by hexdocs-static but we can do the grunt work. :) Thank you! |
|
@josevalim I can for sure send you the PR on HexDocs static. If you prefer to do it on your side (for CI, pipeline, or whatever reason), I can give you the ownership, if the only concern would be my name/some commits in the commit history, I can live without this. 😁 My goal is to smooth your work as much as possible and help you deliver a cool HexDocs thing above all, so tell me what you do prefer, and I'll adapt to it. To be honest, I rather dislike subtrees, as they're always harder to manage from my point of view, and I see no real value-added to keep the old commit history, but maybe you see something I can't! Also, I think it would be much better to archive my repo, and put everything under Hex organisation ownership. It was my goal since the beginning in my mind. Especially since other than me could end up modifying it, so it would makes no sense to keep it on my account! |
|
@ghivert keeping the existing repo is perfect, given we will replace the existing one anyway! Can you please add me as admin to the existing repo? Then I can transfer it over :) |
|
@josevalim Added you as collaborator! I'm not sure I follow what you want here. 😅 Should I make a PR to |
|
Sorry, to be clear, we have two options:
Which one do you prefer? It is 100% up to you! |
|
Ha ha, no worry, I wasn't 100% sure so I preferred asking, but that was what I understand! I transferred you the ownership, as it's actually not possible to add an admin on a personal repository! I think it's simpler if you need to keep the site as-is right now. Tell me if you need some additional modification. 😄 |
|
It is here, thank you! https://github.com/hexpm/hexdocs-search |
What ?
After iterations in #49, that PR finally propose a merge of the new Lustre's Frontend directly in Hexdocs repository as a first step to migrate the old frontend.
Because I don't really know your build process, I decided to keep the frontend somewhat isolated, while providing a full CI action running tests and build, to illustrate how to run tests and how to build the application. Indeed, the application is somewhat separated from the backend: in development it runs directly on its own local dev server (
http://localhost:1234); when targeting production Lustre Dev Tools will generate 3 files: one HTML file, one JS bundle and one CSS file. They only need to be served from an HTTP server, alongside the assets (in theassetsfolder).Applications built in two parts usually choose among two solutions:
http://localhost:1234to the Hexdocs dev serverhttp://localhost:4002(ingleam.toml,tools.lustre.dev.proxy).The application is built as an SPA, and can act on every subpath. For example, if the application will be hosted on
https://hexdocs.pm, it can be served fromhttps://hexdocs.pm,https://hexdocs.pm/searchor evenhttps://hexdocs.pm/whatever. The application will read the location from the browser, and acts in the correct manner. Every unknown paths will fallback tonot_found. This opens the application to extension: adding new pages is only a matter of parsing the new locations, and implementing the pages directly in the Lustre application.As a first step, I cleaned the code and the useless files to only keep the sources, tests and essential config files (and I removed every noise from the old repository). I'm open to any modification you'd need to better integrate in the repository, I really wanted to open the merge discussion, feel free to ask for anything!