Skip to content

Resizable columns for Assets Table #13327

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

Open
wants to merge 22 commits into
base: develop
Choose a base branch
from

Conversation

somebody1234
Copy link
Contributor

Pull Request Description

Important Notes

None

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.
  • If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
    or the Snowflake database integration, a run of the Extra Tests has been scheduled.
    • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

@somebody1234 somebody1234 added the CI: No changelog needed Do not require a changelog entry for this PR. label Jun 19, 2025
@somebody1234 somebody1234 added the x-new-feature Type: new feature request label Jun 19, 2025
@somebody1234 somebody1234 changed the title Wip/sb/resizable table Resizable columns for Assets Table Jun 19, 2025
Copy link

github-actions bot commented Jun 19, 2025

✨ GUI Checks Results

Summary

  • 🧹 Prettier: ✅ Passed
  • 🧰 GUI Checks: ❌ Failed
  • 📚 Storybook: ✅ Deployed

⚠️ Action Required: Please review the failed checks and fix them before merging.

See individual check results for more details.

ℹ️ Chromatic Tests Skipped

Chromatic visual regression tests were skipped for this PR.

To run the tests and deploy Storybook, add the CI: Run Chromatic label to this PR.

Note: We skip tests by default to optimize CI costs. Only run them when your UI changes are ready for review.

👮 Lint GUI Results

Check Results

  • 🧠 Typecheck: ✅ Passed
  • 🧹 Lint: ✅ Passed
  • 🧪 Unit Tests: ✅ Passed

🎭 Playwright Test Results

Summary

  • ⏳ Duration: 11m 20s
  • ✅ Passed: 354 tests
  • 🔴 Failed: 12 tests
  • ⚠️ Flaky: 1 tests

📥 Download Detailed Report

⚠️ Action Required: Please review the failed tests and fix them before merging.

@PabloBuchu
Copy link
Contributor

  1. I mini scroll bars on every table header
Zrzut ekranu 1404-03-29 o 15 07 02
  1. Most right column has weird fixed width. This creates empty space between the table and right side
Zrzut ekranu 1404-03-29 o 15 07 07
  1. I can resize left column to full width moving modified_at and labels offscreen. Then the horizonatal scroll bar appers. Ideally we want min width for each column and not allow users to move table offscreen
Zrzut ekranu 1404-03-29 o 15 07 25

@somebody1234
Copy link
Contributor Author

mini scroll bars on every table header

those are the column resizers (as you may have figured out already), but i would appreciate suggestions on how to make them look less like scrollbars

most right column has weird fixed width. This creates empty space between the table and right side

tried to fix it but it breaks resizing (causing the handle to jump when resizing starts). one question: must it take up all available space?

can make table wider than screen

intentional - this is fine with the current columns but what do we do if there are more columns? (4/5/6 columns)
see example screenshot:

image

@somebody1234
Copy link
Contributor Author

although it's possible that UX may be improved, i'm not completely sure that 100% width is the way to go

Copy link
Contributor

@farmaazon farmaazon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in package.jsons are not the cleanest, and I'm not sure if they will work good with bazel.

@@ -4,7 +4,6 @@
"lib": ["DOM", "es2023"],
"allowJs": true,
"checkJs": true,
"skipLibCheck": false,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change? And do you know why did we have this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you know why did we have this?

no tbh

Why this change

was trying to fix errors due to the updates. can try reverting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, i dont think this should be an issue, it's been there since the start but there shouldn't be any reason to explicitly override it

Comment on lines 4 to 8
// @ts-expect-error All conflicting exports are types
export type * from '@react-types/shared'
// @ts-expect-error All conflicting exports are types
export * from 'react-aria'
// @ts-expect-error The conflicting exports are props types ONLY
// @ts-expect-error All conflicting exports are props types
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So why conflicting types are ok here? Are we sure they're same types?

Instead of TS exceptions, I'd prefer just listing exports manually.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure they're same types?

yes, they are packages from the same monorepo. we can export types manually but there are a lot of re-exports. i can specifically export just the exports we need though.

Comment on lines 1266 to 1268
if (widths === prevWidths) {
return
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As setWidths always creates a new object, I think this if isn't necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

technically yes, but this is to protect against any possible future expansion of the store - if other keys are changed, widths stays the same

package.json Outdated
Comment on lines 50 to 56
"//": [
"To completely ignore deep dependencies, see .pnpmfile.cjs",
"the following are overridden due to breaking changes in type definitions:",
"@react-stately/*",
"@react-aria/*",
"@internationalized/*"
],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, so we are bumping versions but keeping the old type definitions? Why are we doing this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are not, we are bumping versions but to the version right before upstream broke all type definitions at the end of last month - the new versions are from right before that commit

@somebody1234
Copy link
Contributor Author

@farmaazon can you elaborate on the changes in the package.jsons?

@somebody1234 somebody1234 requested a review from farmaazon June 23, 2025 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: No changelog needed Do not require a changelog entry for this PR. g-dashboard x-new-feature Type: new feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants