Skip to content
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

DataTable: changing size of cells does not work in every situation #7283

Closed

Conversation

stephanpelikan
Copy link
Contributor

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. This PR is a pure CSS solution for the problem.

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 fork already in production.

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=/index.js:255,1-256,1. Additionally, one can remove the line
https://codesandbox.io/p/sandbox/datatable-collapse-issue-2jq6d9?file=/index.js:310,1-311,1 to also test for non-plain columns.

Do Jest tests follow these best practices?

  • screen is used for querying.
  • The correct query is used. (Refer to this list of queries)
  • 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?

#7177

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.

@stephanpelikan
Copy link
Contributor Author

This PR replaces #7229 since I rebased the commit on tag v2.39.0. Hopefully, you consider to merge this PR soon, since it is open for months and we have to use a custom built grommet instead of the official one.

Hint: Some checks fail which is not due to my changes, as far as I can see. Additionally, some button styles are not updated in the jest snapshots, therefore I could not update the the snapshots for my changes. On updating tests based on master or tags/v2.39.0 one gets these errors:

  ● Button › hoverIndicator as object with color

    "Value mismatch for property 'background-color'"

    Expected
      "background-color: rgba(125, 76, 219, 1)"
    Received:
      "background-color: rgba(125,76,219,1)"

      382 |     expect(
      383 |       screen.getByRole('button', { name: 'hoverIndicator' }),
    > 384 |     ).toHaveStyleRule('background-color', 'rgba(125, 76, 219, 1)', {
          |       ^
      385 |       modifier: ':hover',
      386 |     });
      387 |     expect(container.firstChild).toMatchSnapshot();

      at Object.<anonymous> (src/js/components/Button/__tests__/Button-test.tsx:384:7)

Would you mind to to update test snapshots on master, so I can rebase and update snapshots due to my commit?

@jcfilben
Copy link
Collaborator

jcfilben commented Aug 5, 2024

Hint: Some checks fail which is not due to my changes, as far as I can see. Additionally, some button styles are not updated in the jest snapshots, therefore I could not update the the snapshots for my changes. On updating tests based on master or tags/v2.39.0 one gets these errors:

Can you try running the tests with node v20?

@stephanpelikan
Copy link
Contributor Author

Can you try running the tests with node v20?

I use v21.7.3. Do I need to downgrade?

@jcfilben
Copy link
Collaborator

jcfilben commented Aug 7, 2024

I use v21.7.3. Do I need to downgrade?

In my environment I've been running into issues the past few days with the snapshots depending what version of node I am using. Still looking into this and trying to get a consistent reproduction of this issue. When the tests run upstream on circleci they are passing there. To get you unblocked on the tests you could try a different version of nod, or just run and update the snapshots that are failing upstream on your PR

@stephanpelikan
Copy link
Contributor Author

Unfortunately, I'm not able to make it 😢 .

Due to my change more than 100 snapshots change. A lot of whitespace changes in the snapshot files and a lot of webkit-styles are inserted next to others.

I reverted Button's snapshots but that causes 66 other tests to fail. The only way to make it is to accept all those changes (actually not caused by my change) and remove the whitespace from toHaveStyleRule to match the color delivered. I pushed this into a different branch showing the changes done automatically (41f3ae7) and those two I've done manually (41f3ae7#diff-9be3da7b83cd74d0c9cc807e22c90b81f6e0c6f3358c89f60a82760880bdecd0).

If you wish I could cherry-pick that commit, but I guess you don't want to since a lot of diffs are not caused by my change.

@jcfilben
Copy link
Collaborator

jcfilben commented Aug 8, 2024

Some of these snapshot changes may be coming from the latest styled-components update. I put up a PR for that #7290. You could also ensure that your yarn.lock matches exactly with the one on the master branch and then running a fresh yarn install to get the exact dependency versions that are on the master branch

@stephanpelikan
Copy link
Contributor Author

OK, there is something about those "^...." dependencies. It seems when I did npm install in the past it fetched versions which caused those whitespace changes. I remove node_modules and did a clean npm install and now the whitespace changes are gone.

I've created another PR including the update snapshots: #7294

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants