Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[DataGridPro] Add
unstable_setRowHeight
method toapiRef
#3751[DataGridPro] Add
unstable_setRowHeight
method toapiRef
#3751Changes from 4 commits
58be1fe
038e611
0297e8e
2832094
9702d25
d95381d
9672b27
b4260cc
ba3b81a
bb2c54d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Wouldn't this API be public? I was left with the impression that the reason we are adding it is so that devs can target specific rows manually. If that is the case then it shouldn't have the
unstable_
prefix.If it is for internal use only I would argue that we don't need it (or at least we don't need it at this point in time).
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.
Same feeling
This API only goal is to be used by the user, so making it private kind of kill this usecase.
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.
It will be used when we add the the resize handle. Since we don't know if
setRowHeight
will work for that purpose and it won't require heavy changes I would keep private. But it should be public once we know it's stable.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.
Exactly what @m4theushw said.
One more thing I was thinking of is that we might change its signature to
setRowsHeight
to support resizing multiple rows at once. This wayhydrateRowsMeta()
will get called once per resize, not once per row per resize.But maybe I should implement it like that in the first place?
What do you think?
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.
Is there a use case for resizing multiple rows at once? Maybe only through a button. If there's one,
unstable_setRowsHeight
could call theunstable_setRowHeight
but have an argument to onlyhydrateRowsMeta
after the last row. I remember we had something similar for postponing the call toapplyFiters
.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 have no idea, but you can do that in Google spreadsheet for example.
I'm just trying to avoid future breaking changes (if we want to ditch
unstable_
prefix now)Yes, that's the reason I'm proposing the array signature.
Also, I think it's more elegant than
setRowHeight(hydrateRowsMeta)
, because we don't need to explain what ishydrateRowsMeta
and when to use it.AFAIK those two signatures are equal, so it doesn't matter
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 a bit confused. It seems like we are adding an API method to hypothetically cover a case that may or may not exist. I was left with the impression that this new API method will be used eventually to support row resizing (similar to column resizing) but I don't know if this is even a feature we want to add eventually.
I would be in favor of starting with a very narrow scope -> resize a target row - and make that public.
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 have two features that could leverage
setRowHeight
: #3801 and #417. This PR could be the first step to #417. Any spreadsheet app allows to automatically adjust the row height to the content height by double clicking the row. Instead of a full dynamic height feature, we could allow the same thing in the DataGrid. Users have been encouraged to use this demo but you can only see the full content on hover. Despite having a use forsetRowHeight
or not, for any new feature released we release a declarative API (props) and a imperative API (methods), for #3218 we miss the last.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 not about always adding an imperative API to every feature. I think it should be on a case-by-case basis, otherwise, we will end up with too much public API, like it was before.
Either way - I'm not saying we shouldn't add that API method but rather just remove the
unstable_
prefix and keep it as it is - update only 1 row.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.
On today's meeting we came to a conclusion that we are not sure about stability of this API and we'll keep
unstable_
for nowThere 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.
When asserting on the row size it's a good practice to hardcode the initial row height so if the default value is changed the test doesn't break.
https://github.com/mui-org/material-ui-x/blob/07cda31650f4ddd6d39e02578b6fee9637159e5e/packages/grid/x-data-grid/src/tests/layout.DataGrid.test.tsx#L730-L736
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.
Right, I've seen that in other tests
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.
Hmm, actually it's already done - see
TestCase
componentThere 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 suggestion: you could make an assertion by passing a mocked
getRowHeight
callback and check if it's not called after changing the height.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.
Thanks, I've added
getRowHeight
check to the test.