-
-
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
[RFC] Clean x-data-grid
and x-data-grid-pro
exports
#2227
Comments
TypeDoc only generates documentation for what is exported. By not exporting a particular interface we might lose its docs. We have to have this in mind.
These we can definitely stop exporting them ASAP.
Same as above. +1 for not exporting.
I'm not sure if the docs will still be generated correctly. We relay in the @event annotation to know if it's an event. To group events a string enum has to be used to keep the string value. Basically, the constant (e.g.
Could you elaborate your idea? We're using constants but there're some classes still hardcoded. We can even leverage more the |
We should be able to add a TypeDoc entry point directly on the event file I think.
I agree that it must still generate the doc correctly and that if it can't them the enum is not viable.
I'm not sure we should touch to the class part since it must be refactored in #1950 |
As a side note, rebasing #1212 allows having a great overview of the expected modules, see https://deploy-preview-1212--material-ui-x.netlify.app/ for |
I was using Webstorm autocomplete, but a raw TypeDoc implementation is a lot easier to follow indeed. |
Element currently exported (I did not list the types for now)
|
For the components, we can stop exporting without doubt the icons and inner components used in the virtualization.
|
x-data-grid
and x-data-grid-pro
modules exports
x-data-grid
and x-data-grid-pro
modules exportsx-data-grid
and x-data-grid-pro
exports
I will do the component cleanup just after the virtualization PR merge to avoid further conflicts. |
I am stopping the effort for v5, I will resume it when we will start working on v6 alpha. |
Closing this one, see #3287 for the v6 cleaning |
Relates to #924
Relates to #18
Proposals
We currently export from the module root almost every variable / type ever exported from any file inside the grid codebase.
We should be able to keep some variables / types private
And even if we have an
export *
cascade, we almost always import from the leafs to avoid circular imports.Here are a few things we should stop exporting without reason:
the features hooks (
DataGrid
exportsuseGridColumnReorder
even if it does not use it). We may export them when we'll have a hook-only API but currently they can never be properly used outside of the Grid.the internal utilities, (
isMultipleKey
,isEscapeKey
,isDesc
, ...)the internal data transformation functions (
mergeGridColTypes
, ...)We are exporting dozens of variables (
GRID_RESIZE
,GRID_KEYDOWN
,GRID_COLUMN_HEADER_FOCUS
) when we could only export a single enumGridEvent
.This would be more explicit and would also allow to strongly type
publishEvent
first argument (and later on type the second argument).Probably related to #1950
Motivations
Limit the breaking changes. If we export everything, renaming an internal variable or type is theoretically a breaking change. In a PR currently in work, I stop exporting
DEFAULT_GRID_SLOTS_COMPONENTS
because I moved it inside the single file that is using it, it's breaking because the variable is exported even if never used by anyone.Make the import clearer. Having hundreds of imports is a bit overwhelming.
Never export something related to XGrid in the DataGrid package
Make it easier to reduce bundle size of DataGrid by knowing what is in it
The text was updated successfully, but these errors were encountered: