feat(@clayui/core): adds asynchronous loading for Table items with nested row #5713
Conversation
There was a problem hiding this comment.
This is looking good @matuzalemsteles
Is the deploy preview currently not working? https://deploy-preview-5713--next-storybook-clayui.netlify.app/
| ref: React.Ref<HTMLTableSectionElement> | ||
| ) { | ||
| const {expandedKeys, nestedKey} = useTable(); | ||
|
|
||
| const [treeItems, setItems] = useControlledState({ |
There was a problem hiding this comment.
Looks like these should be consistent: [treeItems, setTreeItems]
| }} | ||
| > | ||
| {expandable && ( | ||
| {(expandable || onLoadMore) && !isLoading && ( |
There was a problem hiding this comment.
This seems to indicate that if this was not expandable but onLoadMore was passed as a prop that we would render the button used for expanding the row. What is the use case for this? I would think we would still only want to render the expand button if it was expandable.
There was a problem hiding this comment.
Yeah that's a big dilemma in this implementation and it's complicated, for example to say that an item is expandable we need the key for example children to be visible, so if it is not visible we make the assumption that it is not expandable in the default behavior when you have asynchronous loading the assumption we could make is if there is children but the array is empty we would consider it lazy loading but that is an assumption that we cannot guarantee is true for all use cases because the data structure in the DXP for example is different so it is difficult to make this assumption, so what we do here is always render the expandable when onLoadMore is defined but this is also not very interactive.
An idea I thought about this is we can add a property called lazy in the row to say that we should consider asynchronous loading so the developer can use any conditional he wants according to his data structure would be more flexible and we avoid assumptions.
<Table
nestedKey="items"
onLoadMore={async (item: any) => {
// load more
}}
>
<Head items={columns}>
{(column) => (
<Cell className="table-cell-minw-300" key={column.id}>
{column.name}
</Cell>
)}
</Head>
<Body defaultItems={items}>
{(row) => (
<Row lazy={row.items.lenght === 0}>
...
</Row>
)}
</Body>
</Table>Let me know what you think.
| @@ -242,6 +251,14 @@ export const Cell = React.forwardRef<HTMLTableCellElement, Props>( | |||
| </Layout.ContentCol> | |||
| )} | |||
|
|
|||
| {isLoading && ( | |||
| <Layout.ContentCol className="autofit-col-toggle"> | |||
There was a problem hiding this comment.
Is switching between a button and a div while loading going to cause the user to lose focus if they had been interacting via the keyboard?
There was a problem hiding this comment.
Well in this case no because when you expand via keyboard the focus is always on the Cell and not on the button, so it's safe to do that.
| /** | ||
| * When a tree is very large, loading items (nodes) asynchronously is preferred to | ||
| * decrease the initial payload and memory space. The callback is called every time | ||
| * the item is a leaf node of the tree. |
There was a problem hiding this comment.
So it's called when the item is "currently" a leaf, because the leaf might have children that need to be loaded? Is that right?
There was a problem hiding this comment.
Yes, this is the idea. We could implement paginated loading for non-leaf elements as well, as exists in TreeView, but I think it's best to wait for use cases to appear for this because it involves UI changes as well, such as where to add the button to load more, etc...
|
@ethib137 Did you check the example https://deploy-preview-5713--next-storybook-clayui.netlify.app/?path=/story/design-system-components-table--async-load ? I can test this behavior without any problems. |
|
Strange... this didn't work for me this past week, but now it's working. 🤔 |
Closes LPS-200428
This PR implements support for asynchronous loading of the node, the implementation is similar to what we have in TreeView but without support for paginated data, we can add it later when we have real use cases and we can explore the visual state of paginated data for table.