Cutomize built in store keys

[MohammedFaragallah]

Is your feature request related to a problem? Please describe.
I'm working on a multi-tenant application where the same resources are used under different basenames for multiple tenants. This causes conflicts with built-in store keys like useUnselect(), useUnselectAll(), useRecordSelection(), and useExpanded(), as they aren't customizable and lead to unexpected behavior when managing selections and expansions.

Describe the solution you'd like
I would like the ability to customize the built-in store keys for selection and expansion states. Specifically, the ability to set unique store keys per resource instance, perhaps through a storeKey context, for better isolation across tenants. It would also be helpful to expose other store keys like theme and locale for safer reuse in multi-tenant setups.

I'd be more that happy to work on this if you agree.

Describe alternatives you've considered
I haven't found an alternative yet.
i found this case documented here storekey but i still think we can have a better solution like a context please let me know what you think

Additional context
None.

[slax57]

Thank you for your suggestion.

I'm not sure this is the right solution for this use case.
You see, the <List storeKey> was initially introduced to make it possible to render multiple instances of the same List in the same Admin, or even on the same page.

But multi-tenancy is a very different use-case. You are mentioning the ability to also support storeKey for things like the theme or the locale, so it seems to me that all preference settings should not be shared across tenants in your case.

For this, the easiest solution would probably be to implement your own StoreProvider, which would prefix all store keys with the tenant id.
This way, each tenant settings are isolated, and you don't need to customize any storeKey prop in the code.

Can you give it a try and confirm it allows to solve your use-case?
Thanks

[MohammedFaragallah]

Thank you for your response.

I’m using react-admin in a React Native environment, so some of the built-in hooks from RA rely on web-only code. To address this, I’ve created custom hooks to control these values. However, I need to keep an eye on changes to the store keys that RA uses, which is why I suggested exporting them for better control.

Apologies for the confusion regarding the multi-tenant setup. In my case, most tenants share store values, as one user can have access to multiple tenancies. Therefore, I can't use completely separate stores. Everything works well except for the mentioned hooks, which rely on the resource name instead of the storeKey provided to the list. Unfortunately, I don't have a way to customize it from the outside and rewriting them means rewriting the whole List.

[fzaninotto]

My take on building multi-tenant single page apps with react-admin: you should put the multi-tenant logic on the server side. I've explained my rationale here: https://marmelab.com/blog/2022/12/14/multitenant-spa.html

[slax57]

@MohammedFaragallah Thanks for the clarifications.

Digging a bit deeper into the topic, I find that this is not the first time this issue is being discussed: #9740.

The TLDR is that the answer is not so simple, and using the storeKey for the selection state in useListController would probably require a breaking change.

Hence I'll label this issue as enhancement, but will also tag it for v6, as it requires a breaking change.

In the meantime, I see no better solution than to either provide you own StoreProvider, or (probably simpler) to implement your own useListController, as the documentation suggests.