vuetifyjs
docs: API description column & comprehensive TOC
Description
This is an initial step in redesigning our documentation site, focusing on improving the API pages by reintroducing the description column and a more comprehensive TOC.
Markup:
N/A
@MajesticPotatoe I was thinking of having a follow up PR to utilize v-data-table for mobile support. I know in Vuetify 2 data-table becomes a card which doesn't seem to happen on v3 yet.
Perhaps I should have a next-docs branch to merge to. I'm anticipating making multiple follow up PRs.
@MajesticPotatoe irt the table content. I was thinking of implementing different views for API content. For example: https://mui.com/material-ui/api/button/ has table and list view mode. Putting it back to tables is a first step to that.
The thing is should api descriptions be that long? Once we do the auditing I think descriptions should be concise and should point to an example in components page as needed.
I'm open to keeping the description as it's own row. But maybe improving the ui with a space in between items https://v15.vuetifyjs.com/en/components/menus/.
Not sure a next-docs is really necessary. Could just make this branch/PR the comprehensive "api overhaul" and then just PR's that are meant to merge into this one.
Correct, descriptions should be concise and to the point. Lengthy ones might want to be cleaned up and then the more in depth explanation moved to a relevant doc page/example and then linked in the description.
Different view might be cool, can hook it up as a user setting.
Mobile support should be rather easy, hook up display composable to ApiTable, and then just add alternative row styling on breakpoint. TOC should be easy fix by removing any non-alpha characters except hyphens (there might be a utility function used somewhere that does that)
"redesign" more like return to monke
There's a reason this was changed, it's pretty awful on narrow windows or with long types.
Can we make it configurable and potentially offer some different options? I don't know if this rewrite is the answer, but I do know the current way of viewing the API feels cumbersome to me.
