-
Notifications
You must be signed in to change notification settings - Fork 489
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
Improve /release
page
#1996
Improve /release
page
#1996
Conversation
✅ Deploy Preview for tauri-docs-starlight ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
I prefer to have each release has its own dedicated route so it can have better links for example https://beta.tauri.app/releases/tauri/v2.0.0-beta.13/#enhancements this will lead to the the While the TOC looks good, we shouldn't rely on it at all, I'd prefer a custom list implementation (potentially with a filtering input box, e.g. type |
@amrbashir You can still do links like this: I kinda like that it's not separate pages, it's performant and easy to overview. We could make a similar implementation for this as we did for the features searching list, then we'd just have to put the input field at the top of the page |
Even if links are fixed, the generated files will only get bigger as time goes on which means more unnecessary traffic and slower load times for users. |
I think that we could implement pagination to fix that issue @amrbashir |
fine I guess, but is it really worth that much effort that just plain pages? |
I'm thinking about this whole situation and long term I personally think that each release having it own route would be the best, no broken links, no need to worry about pagination, less js (edit: less js considering we need to work around starlight design). Then of course we could have a page for quick reference with all releases for a pkg, possible with a search. The way I tried to do in PR (one route to rule them all) was to experiment and see it live, gather more ideas. But after seeing the problems arise: broken anchor, possible need to paginate, and mostly important no canonical links. Who knows what else may arise as those pages will always be changing on each release. All of those can be solved, but at what cost? Now I'm wondering if having a separated releases.tauri.app would be best. This would avoid having to regenerate all the pages in the docs, and because in the current live implementation (dedicated route) the build time doubled:
After /releases PR: Seeing how this will be a time sink (and doesn't help moving tauri to rc?) I'll leave as draft for a while, if anyone reading this wants to use and work on, go ahead This is still open for ideas and discussion, unless someone from the team says otherwise ofc. thanks for the feedback @amrbashir @simonhyll and @dreyfus92 |
I don't mind having a subdomain |
Also as side note, hopefully soon Astro will have content collections caching which will lead to faster builds. |
closing considering @simonhyll did a really good job at improving it recently, there's still some requested changes to do (I remember someone mentioned a summary table of versions or something) but this can go into another PR. |
Now it utilizes native Starlight TOC.
This is open for discussion about how it should look and function