atlassian / react-sweet-state

Shared state management solution for React

Home Page:https://atlassian.github.io/react-sweet-state/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Persistent global scoped stores

tompuric opened this issue · comments

commented

Hi,

When attempting to work with multiple scoped stores, I was hoping to maintain persistence between them when applying both isGlobal and scope. Instead what happens is that the stores are cleaned up when unmounted, contrary to what the docs suggest: https://atlassian.github.io/react-sweet-state/#/advanced/container?id=scoped-data-cleanup

Here is an codesandbox illustrating the issue.
https://codesandbox.io/s/react-sweet-state-selector-promise-react-example-forked-i41ded
(Add to the store, then switch between pages, you'll notice the store being reset and not persisting data)

When we unmount a global scoped store, it destroys the store and recreates it once remounted.
The expected behaviour is that a global store remains and the persisted data is reaccessed.

This would be ideal in SPA's when switching between single resources (usually on separate pages, /api/resource/1)

Let me know if this is intentional, and if so, what's a potential workaround. Thanks

I see where the confusion comes from: you are expecting isGlobal and scope to work together and so not clearing the store. The reality is that isGlobal is ignored when scope gets used, as scope is in some form global already, being reachable from anywhere in the tree.

We could change behaviour and support what you are asking, but then when we render 2 scoped containers and we forget to add isGlobal to one, what should happen? Who should dictate if the store should be cleared on unmount?

I think it adds too much uncertainty on the behaviour. I think you have 3 options:

  1. Lift the Container up and make sure it is not unmounted
  2. Render another Container with same scope in another part of the tree that does not get unmounted
  3. Just use isGlobal and implement a keyed state yourself
commented

Thanks for clarifying @albertogasparin. The workarounds should be able to support the requested approach.