Bug with listing since 5.13.0: storeKeys are not resolved

[deep-choice]

In my app, I use a <List> to list some resources.

What you were expecting:
In my previous version, 5.12.2, this worked without problems.

What happened instead:
Since upgrading to 5.13.0, it does not work anymore (code unchanged), due to the error "selectedIds.includes is not a function". However, the actual problem seems more deep because tracing the error, I found that selectedIds is not string[] | undefined, as it should be, but instead {storeKeys: string[]}. This is obviously not intended and probably indicates a bug in resolving objects from storage.

Steps to reproduce:
Related code:
Unfortunately, I have not been able to create a minimal example to replicate the issue despite some effort; it seems to happen only under specific circumstances. I try to describe them below as best as possible.

Other information:
Assume the bug happens in an element that is loaded at page A with url /pages/a.

• Strangely, it does not occur when I directly load that url (/pages/a) - then the list loads as expected!
• It only occurs when I first am at another page B (say /pages/b) and then navigate to /pages/a from there.
• It does not happen for all lists, just for certain ones. From what I can see, it does not depend on which children the list renders and also not on its filters or other params; in my case, just on the resource prop instead. (Note that the problem is not in the dataProvider though.)
• My best guess is that the error occurs if page B already triest to list the problematic resource X and then page A tries again.
• In my concrete case, page B contains a <Datagrid> with resource Y. It lists without problems. However, for each row of Y, I list the associated X`s. That also works on B! But then, when navigating to A which just lists all X unconditionally, it breaks down.
• In the JS stack trace (see below), note the recursion.

Environment

• React-admin version: 5.13.0
• Last version that did not exhibit the issue (if applicable): 5.12.2
• React version: 19.2.0
• Browser: Firefox
• Stack trace (in case of a JS error):
  TypeError: selectedIds.includes is not a function
  areAllDataSelected SelectAllButton.tsx:77
  SelectAllButton SelectAllButton.tsx:77
  React
  react_stack_bottom_frame
  renderWithHooks
  updateFunctionComponent
  beginWork
  runWithFiberInDEV
  performUnitOfWork
  workLoopSync
  renderRootSync
  performWorkOnRoot
  performSyncWorkOnRoot
  flushSyncWorkAcrossRoots_impl
  processRootScheduleInMicrotask
  scheduleImmediateRootScheduleTask
  scheduleImmediateRootScheduleTask
  ensureRootIsScheduled
  scheduleUpdateOnFiber
  forceStoreRerender
  subscribeToStore
  batchCalls notifyManager.ts:73
  notifyFn notifyManager.ts:21
  flush notifyManager.ts:44
  flush notifyManager.ts:43
  batchNotifyFn notifyManager.ts:24
  flush notifyManager.ts:42
  setTimeout handler*systemSetTimeoutZero timeoutManager.ts:134
  flush notifyManager.ts:41
  batch notifyManager.ts:60
  #dispatch query.ts:677
  setData query.ts:234
  fetch query.ts:558
  #executeFetch queryObserver.ts:343
  onSubscribe queryObserver.ts:101
  subscribe subscribable.ts:11
  useBaseQuery useBaseQuery.ts:100
  React
  subscribeToStore
  react_stack_bottom_frame
  runWithFiberInDEV
  commitHookEffectListMount
  commitHookPassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber
  recursivelyTraversePassiveMountEffects
  commitPassiveMountOnFiber

[djhi]

Hi, thanks for the report. I didn't manage to reproduce your issue.

In my concrete case, page B contains a with resource Y. It lists without problems. However, for each row of Y, I list the associated X`s. That also works on B! But then, when navigating to A which just lists all X unconditionally, it breaks down.

Can you explain what you mean by for each row of Y, I list the associated X's? Are you using a <ReferenceField> or another reference related components?

I modified the simple example to use <Datagrid> in both the posts and tags pages. The posts list page lists the posts tags with a <ReferenceArrayField>.

[deep-choice]

Hi, yes unfortunately I also did not manage to reproduce it with simple examples.
In my real case, I use both a <ReferenceManyCount> and a <ReferenceManyField> (with a <Datagrid> as child component) in the list of Y to count and list the X's related to the respective Y.

However, it is not that simple also: When I remove both components from page B and then navigate to page A, then it seems to work at first glance - the list of X's loads without error. But when I then navigate to another page C and then back to A, suddenly the error is there again...

So I do not think it is related to the concrete design of B, the important thing is probably just the X's have already been loaded and then, the next time, are tried to be fetched from the storage instead of reloading them.

[djhi]

I replicated your usage with posts and comments but was still unable to reproduce the issue. Navigating back and forth to comments from any page, with or without selection, filters or any other parameters seems to work fine.

Do you provide custom store keys to any component? Can you share the code of page A?

[deep-choice]

No, I do not use custom store keys.

I was able to reduce the code of page A to its very basics, and still the problem occurs:

import {
  Datagrid,
  List,
  SimpleList,
  TextField,
} from 'react-admin';

export const PageA = () => {
  return ( // works when using SimpleList instead of Datagrid
    <List resource="posts">
      <Datagrid>
         <TextField source="id" />
      </Datagrid>
    </List>
  );
};

However, I found that when I use <SimpleList> instead of <Datagrid>, it works... So maybe the problem is there?

[fzaninotto]

so can you please link to a reproduction based on https://stackblitz.com/github/marmelab/react-admin/tree/master/examples/simple ?

[deep-choice]

I have tried again to do this, but unfortunately did not succeed: With the simple example, everything worked.

I have also tried to go the other way round and simplified my real case as far as possible (which is not easy though because it is quite nested), and the error there remained even for quite simple setups.

However, I found out that I can bypass the problem by specifying storeKey={false}, which is sufficient for my case, as I do not actually need to store filters and sorting, at least not at the moment.

Still, you probably want to solve the problem anyway. I assume it has been introduced by PR10953, but as we see, it is hard to replicate unfortunately.

[slax57]

@deep-choice I may have found a reproduction scenario, but I'll need you to confirm a few things to ensure this is really the same issue.

I have found that setting and unsetting a storeKey on a <List> can lead to react-admin reading and writing at two locations in the Store, one being nested into the other:

• ${resource}.selectedIds.storeKeys when a storeKey is set
• ${resource}.selectedIds when a storeKey is not set

This is not an issue with the default Store provider -- the localStorageStore -- as it is a simple key-value store, using the unmodified key string as key (i.e. it will write both to, say, 'posts.selectedIds.storeKeys' and 'posts.selectedIds' with no issue).

However other Store providers, like the memoryStore, use a single object to store the values, which means using nested keys can overwrite data from the parent key.

I have been able to obtain the same error with the following reproduction steps:

1. Use an Admin with the memoryStore as Store provider
2. In the List view of a resource, set a storeKey to "test"
3. Select some records
4. Then, remove the storeKey from the List
5. Select some records
6. You should get the selectedIds.includes is not a function error

@deep-choice Can you confirm the following:

• You are not using the default Store provider
• You set a storeKey at some point during the development phase

[deep-choice]

Thanks for your effort. Unfortunately, neither is true for my case:

• I do use the default Store provider
• I did not set storeKey anywhere so far. (Now I have changed that to storeKey={false} for every List, after which it works.)

However, what caught my attention is that you said that localStorageStore were the default Store provider; maybe here is the problem:

• I do not use Admin but AdminContext and AdminUI separately, and in my ra-core/src/core/CoreAdminContext.tsx file (version 5.13.2), there is on line 28:
  const defaultStore = memoryStore();

Update: In fact, when I do const myStore = localStorageStore(); and then set store={myStore} in AdminContext, it works.

[djhi]

Yes, ra-core uses the memoryStore by default, but react-admin set it to localStorageStore. That might mean that the issue lies in the memoryStore implementation.

[ghost91-]

We also just ran into this (or at least a very similar) problem in our tests. We use the AdminContext, which uses a memoryStore by default. We then get weird errors like this:

Error handled by React Router default ErrorBoundary: [TypeError: selectedIds.includes is not a function]

We traced the error down to selectedIds from useList being returned as something like

{
  "storeKeys": [
    "undefined.123.foo.selectedIds",
  ],
}

Notice how this is an object instead of an array.

useRecordSelection uses 2 stores:

• ${storeKey || resource}.selectedIds
• ${resource}.selectedIds.storeKeys

The memoryStore implementation uses lodash's get and set to manage the store (which is just a simple object). My guess is that the lodash dot path notation breaks things here in some way, since the store keys are partially identical.

Using the localStorageStore instead fixes the problem for us.

[slax57]

We definitely need to fix the memoryStore implementation. Marking as bug.