-
-
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
[DataGrid] Move column resizing to XGrid only #257
Conversation
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 need to update the documentation. I think that we should also add a custom prop type for when a developer tries to enable the feature on the DataGrid (see the example with pageSize
).
I'm working on the DataGrid vs XGrid feature table comparison in #255, I'm going to account for it. |
Not sure what you mean |
Probably change this section to talk about how to enable column resizing (XGrid) and how to disable it for one column. https://deploy-preview-257--material-ui-x.netlify.app/components/data-grid/columns/#column-sizing
|
I see! So you prefer to assign them to type true and add proptypes than removing the prop of the options, right? Any particular reason you check pagesize in disableMultipleColumnSorting? |
It's a mistake from my end, a wrong copy and pastes, we need to fix it :) |
I'm not sure to understand your question. I think that developers should be able to swap DataGrid with XGrid with as little effort as possible. |
I fixed it! No worries! |
yes but as these properties are overwritten, and are not required. I originally remove them from the DataGrid props. |
@dtassone What about somebody using XGrid with |
Ahhh good point! |
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.
A fix of the CI and an update of the documentation and we should be good to go.
'& *::-webkit-scrollbar-track': { | ||
borderRadius: 10, | ||
}, | ||
'& *::-webkit-scrollbar': { | ||
width: 8, | ||
height: 8, | ||
}, | ||
'& *::-webkit-scrollbar-thumb': { | ||
borderRadius: 10, | ||
backgroundColor: borderColor, | ||
}, |
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.
Wrong pull request? Isn't this one for #260? Could we keep the pull requests isolated :)?
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.
Also, what about we only mess around if the theme is dark? Disturbing the UX as little as necessary. Especially, I don't think that we should change the size of the scrollbar.
docs/src/pages/components/data-grid/columns/ColumnWidthGrid.tsx
Outdated
Show resolved
Hide resolved
Regarding the docs, what do you think about adding a new header? We have one to disable column resizing per column but not to enable/disable it entirely. |
let render; | ||
let defaultProps; | ||
beforeEach(() => { | ||
render = createClientRender(); |
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.
createClientRender() is already wrapping
a beforeEach, it should stay at the top level.
).to.throw( | ||
[ | ||
`Material-UI: \` column.resizable = true \` is not a valid prop.`, | ||
'Column resizing is not available in the MIT version', |
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 believe to.throw
accepts a partial match. I think only matching with the first sentence will be enough to make sure the error isn't coming from somewhere else, and at the same time, make the test easier to write and less likely to fail the next time we fix a typo or slightly improve the error message.
|
||
const hasResizableColumns = columns.some((c) => c.resizable); | ||
if (hasResizableColumns) { | ||
throw new Error( |
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.
What about using a custom prop type? This would allow the code to be removed in production (no bundle size implication). This would also be less disruptive to the DX. This would also give a better component error trace
Probably due to all the paths in tsconfig, as the npm pkgs are missing |
So it's a regression from the current state of master? After this change, we do no longer make sure TypeScript passes on the Storybook? Which can then lead to wrong examples? |
well I added the |
Oh right, my bad. So it's one step forward :) /~https://github.com/storybookjs/storybook/blob/6c0e00522d1ecbeae6f261fc5eb421238480f3fe/lib/core/src/server/config/defaults.js#L2 |
Fix #245