-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[docs] Automatically generate API docs #1529
Conversation
bbd65da
to
762789f
Compare
Nice 👍 A couple of points.
For the events page, I would add a warning or disclaimer to say something like React.useEffect(() => {
// Please note that you have to return the subscription in useEffect for it to be disposed correclty when the component unmount
return apiRef.current.subscribeEvent('columnResize', (params) => {...}, []
} |
I would leave the GridApi page with all the methods it has. This interface is what users will get when they call Your idea of splitting the API into sections is nice, since we have a lot of methods. But I would rather not create a page for them but generate a JSON that, with a custom component, we can embed it into the markdown docs. On each feature page (sorting, filtering, pagination, selection) we could have a section like "Controlling this feature programmatically" with the methods available (https://material-ui.com/components/data-grid/sorting/#apiref).
An "Advanced Use" page is good, but I would prefer to do it in another PR. For now, we could move the catalog of events to https://deploy-preview-1529--material-ui-x.netlify.app/api/data-grid/. What do you think? |
For the apiPage I was talking about sections not separate pages.
I think we can leave the events page as it is for now. Then open a new PR to add some more context or start the advanced page. Issue on https://deploy-preview-1529--material-ui-x.netlify.app/api/x-grid/ => broken links around the doc Also not sure about the menu. Is it possible to show the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look like we are a long way done. 👍 for the hybrid approach taken, half automation looks great
## Catalog of events | ||
|
||
{{"demo": "pages/components/data-grid/events/CatalogOfEvents.js", "bg": "inline", "hideToolbar": true}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would need to explain the upper-case import conversion logic.
) => () => void; | ||
``` | ||
|
||
{{"demo": "pages/components/data-grid/events/SubscribeToEvents.js", "bg": "inline", "defaultCodeOpen": false}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was the plan to use GRID_COLUMN_RESIZE
in the demos or columnResize
? I can't remember.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had this discussion in #1299 (comment). The plan was to use columnResize
in demos and markdown. GRID_COLUMN_RESIZE
could be documented, but users wouldn't be encouraged to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, cc @mui-org/x to make sure we all agree on the approach. I personally don't really mind.
The advantage of GRID_COLUMN_RESIZE
is IMHO to be easier to search, but since apiRef.current.subscribe
is easy to grep in a codebase, I don't see it really important.
import path from 'path'; | ||
import kebabCase from 'lodash/kebabCase'; | ||
import * as prettier from 'prettier'; | ||
import { renderInline as renderMarkdownInline } from '../../node_modules/@material-ui/monorepo/docs/src/modules/utils/parseMarkdown'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could work
import { renderInline as renderMarkdownInline } from '../../node_modules/@material-ui/monorepo/docs/src/modules/utils/parseMarkdown'; | |
import { renderInline as renderMarkdownInline } from '@material-ui/monorepo/docs/src/modules/utils/parseMarkdown'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The renderInline
is only available in the next branch, but the monorepo used by the docs points to the master branch. That's why I'm importing it from the node_modules
of the root directory.
Also, before we publish these pages live, it would be awesome to review in detail what we document, adding |
@dtassone What was missing is the descriptions of events and methods, but that is already fixed and merged (#1572 and #1767). I think we can push forward and #1529 (comment) can be done in another PR. |
/* eslint-disable */ | ||
import * as babel from '@babel/core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure we will add this one back in the future for DataGrid, XGrid, GridToolbarExport, TreeView, etc. We are not here yet.
This PR covers the automatic generation of the API pages using
typedoc
.Preview:
https://deploy-preview-1529--material-ui-x.netlify.app/api/data-grid/
Closes #446
To be merged after #1572
Summary of changes
Added a page to group the exports into categories. This is what users looking for the DataGrid component will see now.
Added a page describing how to subscribe to events. This page also contains a table automatically populated with all the events. I had to do some workarounds to get the same styling from the component API page here. The worst part I think is using the
MarkdownElement
(a component from the docs) inside a demo, but users can't fork the demo so maybe we can live with that. We could separate the events into groups if necessary.Generated API pages for the GridApi, GridColDef, GridCellParams and GridRowParams. Which other APIs should we have documentation?
TODO:
generateType
(https://github.com/TypeStrong/typedoc-default-themes/blob/master/src/default/partials/type.hbs)