Two lists for the same resource share the same store for their state

[StefanFl]

What you were expecting:

I have 2 lists for the same resource. One list is accessible from the main menu and shows all datasets with a rows per page set to 25. The second list for the same resource is part of a tabform in an edit dialog of another resource and shows related datasets. Here we have rows per page of 10 and different search fields than in the first list.

Both lists should should be completely separated and the state of search fields, order and rows per page in the store should be stored for both instances separately.

What happened instead:

When I search for data in the second list or change the sort order there, an entry is written in the store with the state of search fields, order and pagination. After that I open the first list from the main menu. Here we see now 10 rows per page instead of 25 and data is filtered by criteria that we entered in the second list. Unfortunately we cannot change the filter because we have different search fields.

The state is stored with the key RaStore.resource_name.listParams and is used for both lists, even they are configured differently.

Environment

• React-admin version: 4.2.5

[antoinefricker]

Thanks for reporting!

Could you provide a sandbox reproducing the behaviour?

• a Stackblitz forked from simple example V4
• a link to a GitHub repo with the minimal codebase to reproduce the issue?

Many thanks for your help in this matter! 👍

[StefanFl]

I have amended the simple example in my fork https://github.com/StefanFl/react-admin-8038.

When you open a post from the list, you will see a list of posts in the first tab. Filter here for a date and return to the list of posts from the main menu. It is empty and you cannot change the filter. Only chance to get it working again is deleting the key RaStore.posts.listParams from local storage.

[fzaninotto]

This is a current limitation of List - there can be only one per resource. But we can imagine that we expose a <List storeKey> prop to specify a different store key than the one based on the resource. This would allow to have as many <List> per resource as you like.

I'll mark that as an enhancement request.

[StefanFl]

Thank you @fzaninotto, a storeKey would really help a lot. But now I found something more. In our tabs we have 2 lists for separate ressources. When I something in one list, like the sort order, the settings will be stored for both resources.

I have amended the simple example in my fork to show it. In the tabbed form we now have a list for posts and a list for comments. When I change the sort order in the list of comments, the same settings are stored in RaStore.comments.listParams and RaStore.posts.listParams. This is a bug in my opinion. When I change some thing in the list for one resource, the state should only be stored for that resource and not as well for another resource.

[fzaninotto]

StackBlitz for @StefanFl's example: https://stackblitz.com/github/StefanFl/react-admin-8038/tree/master/examples/simple

[fzaninotto]

You're not supposed to use a <List> as descendent of <Edit>. <List> is a page component, and there can be only one such component per page.

If you need a custom list inside another page, build it by hand using useList and ListContextProvider.

[StefanFl]

Ok, I will try to do that. Thank you

[StefanFl]

Great to see you are working on it

[crates]

We're facing a similar bug from the same issue as this. We have two components for each resource type: the full table version that we use when listing all details for a record, and a much shorter, simpler one for the administrative dashboard.

The bug is this: because these resources share the same localStorage key, when you use pagination features on the long-form view, it's polluting the way the shorter Lists work. Even though the shorter lists we're using have pagination={false} on them, and they specify perPage={5} for each one, they are reading the settings from the store instead of from the props passed to the components.

[slax57]

@crates PR #8073 should have you covered. It should be merged pretty soon.

Also note that if you do not want the list to save and read its state from the store, you have to use the disableSyncWithLocation prop.

[fzaninotto]

Fixed by #8073