-
Notifications
You must be signed in to change notification settings - Fork 3k
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
perf(ui): virtualized schema table rows #6287
Conversation
…ing wide table definitions with many columns.
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.
this is a great idea! virtualizing this list and improving rendering performance of big tables is definitely something we want to do, thank you for looking into this!
I have some comments about a degradation in missing functionality as well as some unexpected / wonky UI behavior.
Let me know if you want any help as you're working on this because this would be a really great thing to get in!
components={{ | ||
body: { | ||
row: SchemaRow, | ||
}, | ||
}} |
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.
unfortunately removing this will also remove our functionality around showing foreign key entities on clicking them. So when you have a foreign key like this schema:
and you click on "Foreign Key" you get this:
Is there a way to use virtuallist while preserving this schema functionality to use SchemaRow
? After playing around with it a bit myself it doesn't seem very easy. So we'd have to change our implementation to still get the same functionality that SchemaRow
provides with foreign keys.
Another option is to look at other virtual list libraries that might still allow us to do this. Have you looked at react-window? not sure how easy it would be to use with ant designs table, though.
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.
Hey @chriscollins3456, first of all -- thank you for the thorough review! I'm currently in progress working on getting the foreign key information back to working with the chip toggle.
It looks like you had originally started some work to have rows expand based on search (filterSchemaRows.ts
), so I was going to build off of where that is used in the expandable
prop for the table itself with selectedFkFieldPath
info.
Originally I had tried to implement react-window with autosizer, but was running in to a wall due to how ant-design (really rc-table) expects to render the components
overrides vs how react-window prefers to wrap virtualized rows.
I'm making good progress on restoring the FK functionality though and expect to have it pushed tomorrow afternoon after resolving some dependency issues.
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.
amazing! I appreciate the explanation - all that makes total sense to me
row: SchemaRow, | ||
}, | ||
}} | ||
scroll={{ y: '100vh', x: '100%' }} |
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.
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 also seeing some buggy behavior when you try to grab the scrollbar and drag it and then try to scroll afterward (I'm assuming a bug with ant-design's scroll
prop here?)
here's a screen recording of what I'm talking about:
Screen.Recording.2022-10-26.at.5.45.31.PM.mov
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.
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.
Ah! Good catch(es). Should be pretty straight forward to fix these 🙂
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.
awesome! thanks so much!
@chriscollins3456 here's a summary of the latest changes pushed:
What's left? Currently I'm seeing two small errors that may require some help from you:
Appreciate the help and feedback |
Fixed the ingestion table error -- it turns out the newer version of ant-design adds a hover class to each table cell on mouseEnter and re-renders (causing the conditional graphql call to error out). Disabled pointer events (except on the functional buttons) to prevent this behavior. |
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.
this is looking real close! I tested it on a huge table and the performance improvements are very noticeable!
Unfortunately I noticed some bugs being introduced with the most recent changes and left those in the comments
}); | ||
} | ||
}, | ||
expandedRowRender: ForeignKeyRow, |
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.
unfortunately with this add and the showExpandColumn: false
add, it breaks our ability to view nested schemas. when you set showExpandedColumn: false
then we hide the arrow indicating to expand a column to show its nested columns. and then expandedRowRender
will then show a broken ForeignKeyComponent instead of the child rows.
When things are normal they should look like this:
not expanded:
expanded:
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.
Another thing I'm seeing with this ForeignKey component is that if the table is small and you expand the ForeignKey to see it all, the table doesn't expand with it and remains very small with a scroll. As an example:
A small table with a foreign key:
After clicking on ForeignKey to expand:
Maybe we can find a different way to display ForeignKeyRow
? Maybe along with the actual row renderer?
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.
Also when I close the ForeignKey view, I'm getting an error because we're requesting to getDataset
with an empty string as an urn. I believe this is coming from entityRegistry.renderProfile
in ForeignKeyRow
where we render a dataset profile component that makes this request.
So my guess is that when we close the foreign key component, we're removing the selectedFkFieldPath
but the ForeignKeyRow
is still mounted, but since selectedFkFieldPath
is null, we're passing in an empty string as the urn in renderProfile
as you can see here:
{entityRegistry.renderProfile(
EntityType.Dataset,
selectedFk?.constraint?.foreignDataset?.urn || '',
)}
margin-top: 40px; | ||
`; | ||
|
||
const ForeignKeyRow = () => { |
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.
love the rename!
@stanbaker I'm so sorry this is such a tough frontend situation with so many variables! However we really really appreciate you looking into this :) |
This reverts commit 780624f.
…e table rows" This reverts commit 9c46886.
This reverts commit 6c0f236.
… issues" This reverts commit 5eb0d48.
…p and add resize observer" This reverts commit a3ef0fd.
…n rendering wide table definitions with many columns." This reverts commit 94e52c5.
…rder to support custom row rendering
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.
this looks amazing Stan! tried it locally and all the edge cases we've discussed are looking good and I'm noticing a huge performance improvement on tables with many rows :) thanks so much for this!
@stanbaker it looks like unit tests are failing. I took a look into it and our tests around the schema tab are now failing because some things aren't getting rendered with this new virtualized table. After digging in more, the table renders the first row, but not others. I believe there's something wonky going on in the testing library with render size of the table itself, so the items out of the page scroll aren't getting rendered (exactly the point of this PR lol) I ended up making a few changes to the tests so that they continue testing the same stuff, but with the row that does indeed get rendered. Check out my diff from this PR to incorporate it yourself! #6420 Once that's in and CI is passing, this guy will be merged |
Resolves performance issues when rendering schema definitions for wide tables with many columns (100+)
Checklist