-
Notifications
You must be signed in to change notification settings - Fork 329
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
base: develop
Are you sure you want to change the base?
Conversation
✨ GUI Checks ResultsSummary
See individual check results for more details. ℹ️ Chromatic Tests SkippedChromatic visual regression tests were skipped for this PR. To run the tests and deploy Storybook, add the Note: We skip tests by default to optimize CI costs. Only run them when your UI changes are ready for review. 👮 Lint GUI ResultsCheck Results
🎭 Playwright Test ResultsSummary
|
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
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?
intentional - this is fine with the current columns but what do we do if there are more columns? (4/5/6 columns) |
although it's possible that UX may be improved, i'm not completely sure that 100% width is the way to go |
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.
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, |
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.
Why this change? And do you know why did we have this?
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.
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.
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.
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
// @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 |
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.
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.
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.
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.
if (widths === prevWidths) { | ||
return | ||
} |
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.
As setWidths
always creates a new object, I think this if isn't necessary?
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.
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
"//": [ | ||
"To completely ignore deep dependencies, see .pnpmfile.cjs", | ||
"the following are overridden due to breaking changes in type definitions:", | ||
"@react-stately/*", | ||
"@react-aria/*", | ||
"@internationalized/*" | ||
], |
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.
Wait, so we are bumping versions but keeping the old type definitions? Why are we doing this?
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 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
@farmaazon can you elaborate on the changes in the |
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.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.