-
Notifications
You must be signed in to change notification settings - Fork 1k
DataTable: changing size of cells does not work in every situation #7294
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
base: master
Are you sure you want to change the base?
DataTable: changing size of cells does not work in every situation #7294
Conversation
70b13c6
to
128509d
Compare
This PR replaces #7283 since I rebased to master. Jest test fail although I updated snapshots successfully in this branch (which is based on master). I don't have any idea what is the reason for those errors reported. Can you give me a hint? |
It looks like you have snapshot changes committed to this branch that are unrelated to the DataTable change |
c9aa4cc
to
9c43ca3
Compare
What I did:
That's it. I don't know why all these snapshots change and whether they should or not. However, my next attempt:
Again the tests fail in the Github-pipeline but succeed locally. Actually, I don't know what I can do else. Since the same tests succeed locally I guess the problem is not up to my commit (246f476). Can you do the same procedure and check whether the snapshots your computer builds also works on Github? |
2cc2740
to
b794ca9
Compare
Finally, I made it:
I'm looking forward to your response! 👀 |
As the UI Tests show there are still problems to be solved. I will check that... |
@jcfilben: I could fix the unintended UI test changes. There is only one change left, caused by the intended adaption to bring the new behavior into a DataTable story. |
7518622
to
417920b
Compare
@jcfilben: Again I rebased my changes because |
The Grid and Grid with show 77 stories sometimes don't load the image quickly enough for the snapshot so don't worry about those ones changing. However, I don't think the infinite scroll snapshot should change |
However, I don't think the infinite scroll snapshot should change
OK. I reverted the changes for that story. Now it is proved that there is actually no change.
a736f90
to
51d65d3
Compare
rebased +1 |
Signed-off-by: Stephan Pelikan <stephan.pelikan@phactum.at>
Signed-off-by: Stephan Pelikan <stephan.pelikan@phactum.at>
51d65d3
to
d35561d
Compare
rebased +1 @jcfilben: would you mind to review the last changes and maybe consider to merge them? 👍 |
Hey @stephanpelikan it might take me a little longer to get to this PR, DataTable styling is an area we've had some odd issues come up in the past so I need to set aside a bit of time to look through the snapshots, storybook, and test on different browsers. |
@jcfilben I just wanted to ask whether there is already a time horizon for the PR? |
Hey @stephanpelikan the grommet team will take a look at this Thursday this week |
Hey @stephanpelikan we took at this PR today a look and one thing that we noticed was without the This is the div without the This is the div with the In the PR that added |
@jcfilben OK, I'll check this in the christmas vacation to make it work as before 👍 . As far as I remember |
Sounds good! We just took the https://storybook.grommet.io/?path=/story/visualizations-datatable-onselect--on-select-data-table story and made the name in the first row long enough to wrap to see the issue. I think plain="noPad" was originally internal only but somewhere along the way it did get added to the documentation https://v2.grommet.io/table#plain |
What does this PR do?
In DataTable the height is calculated in code what does not work on resizing any column's content (see #7177) if there is another plain-column. Additionally, there are performance issues with resizing columns as I experienced and create an issue for (see #7284). This PR is a pure CSS solution for the problem which solves both issues.
Where should the reviewer start?
See section "Actual Behavior" of #7177.
What testing has been done on this PR?
We manually tested both situations: On initializing the table and on changing cells content. We use this as a fork already in production for two costumers who expiriences #7177 or #7284.
How should this be manually tested?
In "Steps to reproduce" of #7177 a sandbox is provided. To test correct sizing on table initialization one can set the default-value to true at https://codesandbox.io/p/sandbox/datatable-collapse-issue-2jq6d9?file=%2Findex.js%3A255%2C1-256%2C1. Additionally, one can remove the line
https://codesandbox.io/p/sandbox/datatable-collapse-issue-2jq6d9?file=%2Findex.js%3A310%2C1-311%2C1 to also test for non-plain columns.
The performance issue mentioned in #7284 I'm not able to reproduce. Actually, I figured out the root cause using the browsers profiler. Using grommet patched by this PR solved the problem.
Do Jest tests follow these best practices?
screen
is used for querying.asFragment()
is used for snapshot testing.Any background context you want to provide?
The author of the initial implementation didn't see that there is a pure CSS solution (see comment in https://github.com/grommet/grommet/blob/master/src/js/components/TableCell/TableCell.js#L129). Meanwhile there were changes in the same section 10c46fd which should be tested. I updated the Sandbox to Grommet's current version and the intermediate change does not effect the behavior of this PR.
What are the relevant issues?
Screenshots (if appropriate)
No
Do the grommet docs need to be updated?
No
Should this PR be mentioned in the release notes?
As you wish
Is this change backwards compatible or is it a breaking change?
Was backward compatible before 10c46fd. If the underlying issue of this change #6086 is still solved with the PR in place, then it is confirmed that it still is backward compatible.