feat: use storeKey in useRecordSelection

[mikhail-fedosenko]

Problem

It's not possible to create distinct List views that use separate record selection states.
Previous discussion was started in PR: #10951

Solution

Store selected IDs under in a Record<string, Identifier[]> structure in useRecordSelection. List component passes the storeKey to useRecordSelection. If storeKey is non-empty, then it's used as a key in the selection object. Delete controllers pass the flag to unselect deleted records from all storedKeys.

How To Test

Describe the steps required to test the changes

Additional Checks

• The PR targets master for a bugfix or a documentation fix, or next for a feature
• The PR includes unit tests (if not possible, describe why)
• The PR includes one or several stories (if not possible, describe why)
• The documentation is up to date

[mikhail-fedosenko]

This is just a draft to make sure the solution is applicable for the framework.
I've tried to keep backwards compatibility (selection state without namespace is stored under same key in localstorage). With major release we can migrate to new datatype in the store, so it will be a breaking change (for anyone reading and writing directly to the store, bypassing the useRecordSelection), but only one key will be used though.

Btw, is there any chance to get this feature in minor release?

[fzaninotto]

can you explain why you need to introduce the notion of namespace, which seems to overlap with the storeKey feature?

[mikhail-fedosenko]

It's maybe more like storeKey, i just named it like this...
I want to allow the user to select different sets of records on different views: for example, our system has members, members belong to teams. When a user goes to Team A he can select some members, when viewing the Team B, ideally, he should have another selection state.
Since the List view's storeKey doesn't affect selection state (it's stored "globally" per resource) I've introduced the storeKey/namespace for selection state.

Do you suggest to pass List's storeKey to useRecordSelection instead of adding separate & independent key for selection state?

[fzaninotto]

Do you suggest to pass List's storeKey to useRecordSelection instead of adding separate & independent key for selection state?

Exactly

[mikhail-fedosenko]

@fzaninotto ok, will do.
So, it will be a breaking change. Since new features are usually targeted to next, does it mean it will appear in next major release if I finally prepare the PR? :)

[fzaninotto]

Why will it be a breaking change? You only need to make the unselect() affect all storekeys by default.

[mikhail-fedosenko]

Any existing usage of List with non-empty storeKey will start using separate selection state.

[fzaninotto]

So you're right, it's a breaking change, but one that we're willing to accept given =i see no use case for two lists with different store keys that would require an identical selection.

You can continue on next and we'll consider your PR for a future minor release.

[mikhail-fedosenko]

Ok.

What about storing selection state in 2 separate keys (${resource}.selectedIds + ${resource}.selectedIds.namespaced) VS storing the selection state as new type in the existing key (${resource}.selectedIds)?
In current PR's state it stores "global" state under old key to keep backwards compatibility for those, who read the (local)storage directly, bypassing the useRecordSelection.
I would prefer simpler solution (store new type in the existing key), since I personally don't expect anyone (or at least the substantial number of people) to use direct access to selected IDs in the storage...

@fzaninotto , can you please have a look at the question above?