Table component randomly fails to render provided items.

[SerhiiArbonics]

Provide a general summary of the issue here

I'm using Table component in my Remix js application. Table items are provided by the loader function. Table sorting, search, pagination is handled with the URL query parameters. When user interacting with the table sorting, pagination or search for some time, the table component randomly stop showing content and renders empty state fallback component instead. I checked the items array, it contains data, but when I use React dev tools and check TableBody component, it shows that collection is empty, while props have items.

Here is my code

      <Table onSortChange={handleSorting} sortDescriptor={getSortDescriptor()}>
        <TableHeader columns={columns}>
          {(column) => (
            <Column isRowHeader={column.isRowHeader}>{column.name}</Column>
          )}
        </TableHeader>
        <TableBody items={tableRows} renderEmptyState={() => "no results"}>
          {(item) => (
            <Row aria-label="Table Row" columns={customerTableColumns}>
              {(column) => (
                <Cell aria-label="Table Cell">{item[column.id]}</Cell>
              )}
            </Row>
          )}
        </TableBody>
      </Table>

🤔 Expected Behavior?

Table should render items if provided.

😯 Current Behavior

Sometimes table does not render items.

💁 Possible Solution

Unfortunately I don't have solution.

🔦 Context

Items are dynamic, provided by the Remix loader with the help of useLoaderData hook.

🖥️ Steps to Reproduce

Unable to reproduce it in sandbox. Might be SSR related.

Version

1.1.1

What browsers are you seeing the problem on?

Chrome

If other, please specify.

Remix js

What operating system are you using?

Mac OS

🧢 Your Company/Team

Arbonics

🕷 Tracking Issue

No response

[snowystinger]

Thanks for the issue!

If you can't reproduce in a codesandbox, you could try stackblitz, they have a bit more flexibility for things like SSR. Or you can create a public git repo with an example project in it.

Unfortunately, I don't have any ideas off the top of my head. We'll need a reproduction to investigate further.

[AndrewLeedham]

@SerhiiArbonics @snowystinger I am also seeing this quite consistently. Also, seeing it in other components like Breadcrumbs that use collections. I have managed to recreate it in this stackblitz repro: https://stackblitz.com/edit/github-eveodx-hxa463?file=app/routes/_index.tsx. However, it does not happen as often. Essentially if you click the 1-3 links enough the table content eventually disappears.

[SerhiiArbonics]

@AndrewLeedham Thank you for the StackBlitz example. It's unfortunate to hear that you've encountered similar issues with other aria components. I'll continue to monitor them and report any additional findings.

I suspect the issue might be related to hydration, as my table component functions correctly in Storybook, even with the same filtering and searching logic. Debugging this could be challenging since there are no error logs or other clues when the issue occurs.

Let's see if anyone else has suggestions for identifying the source of the problem.

[SerhiiArbonics]

@snowystinger @AndrewLeedham

FYI, I discovered that using an array index as the item ID, instead of a unique identifier like UUID4, prevents the issue. It seems that during sorting and searching, the IDs of the rows change, whereas the index remains constant. This can serve as a temporary workaround for now.

[AndrewLeedham]

@SerhiiArbonics I am seeing this when building the site statically as well. So it seems not to be related to hydration for me, there will still be hydration but the Remix SPA HTML is just a shell so not hydrating the table itself, that is a fresh render.

Thanks for the workaround, that does seem to work. Although, I am surprised because the ID will then be the same every time the pagination changes, because the length is always 1. So, would expect React to see them as the same thing and not re-render.

[SerhiiArbonics]

Unfortunately I do not have time to investigate the issue further. I will leave it for now, let's see if there are any negative consequences of using the workaround.

[AndrewLeedham]

I have a use-case where key's as indexes won't work (breadcrumbs because the first few are often the same and the last changes as you navigate).

I found a potential bundling issue, which might be related to this: In the built output isConnected is returning true for the document, whereas it should be returning this.isMounted, which relies on a useLayoutEffect.

Built output: https://unpkg.com/browse/react-aria-components@1.2.1/dist/Collection.mjs#:~:text=349-,get%20isConnected(),-%7B Source: https://github.com/adobe/react-spectrum/blob/b46d23b9919eaec8ab1f621b52beced82e88b6ca/packages/react-aria-components/src/Collection.tsx#L528

Has anyone managed to recreate this with the repro I provided? cc @snowystinger

[devongovett]

That was changed very recently so isn't in the published version yet. You could try installing the nightly version and see if it fixes your problem.

[AndrewLeedham]

That was changed very recently so isn't in the published version yet. You could try installing the nightly version and see if it fixes your problem.

Looks like that was a red herring. Tried the nightly, also manually added the tree-shaken code back on the last version. But still seeing the same symptoms.

[snowystinger]

Had a look at that stackblitz, I'm unable to reproduce it in there.

I did notice you're specifying both a key and an id, you should only need the id on items. Also the import path for useLoader seems wrong, I don't think you're meant to import from dist.

Otherwise, all I can think of so far is that you have, unintentionally, duplicate id's in your list of items somewhere. For instance, the screenshot in the description, all the items have uuid's, except the footer, which has an id. Should it also have a uuid or do the others all have ids? I also noticed that they are not placed as props on the items in the description example.

The other common issue we see which can have hard to predict results is duplicate or multiple copies of our packages installed into your node_modules. Typically seen as a node_modules directory inside a package already in your node_modules. You could check if you have any of those. Or you can read the lockfile or query through the package manager for installed versions. A good starting point is checking if you have multiple copies of @react-aria/utils.

Feel free to use this script to check for duplicate packages https://gist.github.com/jluyau/9024db3527788030312332075745469b as well, though we are aware now that it didn't catch a couple, so don't rely exclusively on it.