storeKey prop is not passed to useRecordSelection hook inside useListController about react-admin HOT 5 CLOSED

Good catch! Would you mind opening a PR to fix it?

from react-admin.

Actually, we already had a few similar issues about this and the answer is not so simple: see #8536 and #7401

from react-admin.

@djhi

Hi there, thx for the quick reply! I've thought for a while about the issue at hand and read through the linked related issues and wanted to add my two cents to it.

First of all let me restate the issue to know if I undertood it well enough:

When implementing row selection in lists, resource-bound global selection state was chosen for, among others, one main goal: keep selection accross navigations (mainly list view <-> edit view back and forth user experience) and be able to delete records from other views (mainly the edit view) and being able to deselect (if selected) that record so when the user goes back to the list all is consistent.

Since then, a custom storeKey prop has been added to the list controller to allow different lists using the same resource to be, for example, filtered independently from one another.

This independence cannot be applied to the selection state because it would break the stated main goal, since when deleting a record from its edit view there could be arbitrary keys in the store that would have to be updated, which is not possible or very hard to manage.

Now with the problem stated, I think that the custom storeKey funcionality is not 100% complete, let me explain:

I would argue that the meaning of storeKey={false} is "For this list, I don't want any store interaction", not for list params and also not for selected rows, no interaction at all. For this reason, and only if storeKey is false, the list should keep the selected rows in local state, and use the resource-derived storeKey otherwise. That would mean that if I navigate away and come back, the list won't have any selected rows, but I chose that consciously.

By using "the resource-derived storeKey otherwise", we avoid breaking react-admin's desired interactions with the store for selection related stuff. For normally managed lists, current behaviour is kept in all cases. For storeKey={false} lists, any navigation away from the page will loose (unselect) its selection state, so deletions from another page don't have to worry about ghost selected rows for that list.

I've made a quick PR so we have some code to look at, and also to show that the changes seem to be limited to a couple files.

from react-admin.

@nbalaguer that seems like a sensible approach, thanks for taking the time to explain it.

from react-admin.

Fixed by #9742

from react-admin.