Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Watch localstorage for changes from other tabs #254

Open
3 tasks done
rudolfbyker opened this issue Nov 8, 2023 · 5 comments
Open
3 tasks done

[core] Watch localstorage for changes from other tabs #254

rudolfbyker opened this issue Nov 8, 2023 · 5 comments
Labels
✨ enhancement New feature or request

Comments

@rudolfbyker
Copy link

rudolfbyker commented Nov 8, 2023

Clear and concise description of the problem

pinia-plugin-persistedstate is ensuring that when something changes in Pinia, it is written to localstorage. But when another tab running the same web app changes something in localstorage, it is not detected by pinia-plugin-persistedstate. (Remember that localstorage is shared over all tabs that are running the same web app.)

Suggested solution

  • Use any kind of messaging between tabs to say to all other tabs: "Update Pinia from localstorage now" whenever we make a change in localstorage. The https://www.npmjs.com/package/broadcast-channel package makes this easy.
  • Alternatively, add to the pinia-plugin-persistedstate documentation how to set up pinia-shared-state in such as way as to play nicely with pinia-plugin-persistedstate to achieve the same effect.

Alternative

I'm currently using pinia-shared-state to work around this problem. It sends a Broadcast to update the pinia values in other tabs. It also has an option for using localstorage instead of Broadcast to do the updates. The made me think that, if we could just listen to the localstorage updates like they do in pinia-shared-state, we would not need pinia-shared-state for the stores that are already using pinia-plugin-persistedstate with localstorage.

Additional context

No response

Validations

@rudolfbyker rudolfbyker added the ✨ enhancement New feature or request label Nov 8, 2023
@prazdevs
Copy link
Owner

prazdevs commented Jan 3, 2024

That's interesting, I'm just curious about performance impact of pushing this as a base feature when it can be added with another plugin. My take would be to make sure it works well with other plugins more than adding it in persistedstate 🤔

Also it's really storage-dependant, and would not work as easily with other storages, making the option dependant on another 🤔

@prazdevs prazdevs changed the title Watch localstorage for changes from other tabs [core] Watch localstorage for changes from other tabs Jan 3, 2024
@rijenkii
Copy link

rijenkii commented Jan 9, 2024

Alternatively instead of broadcasting you can just use the storage event to listen for changes in localstorage from other tabs.

@AuroraTea
Copy link
Contributor

AuroraTea commented Mar 16, 2024

We may consider doing so at present.

const store = useStore()
// ... Other store ...
window.onstorage = ({key}) => {
  switch (key) {
    case <StorePersistKey>:
      store.$hydrate()
      break;
    // ... Other store case ...
}

// Or, addEventListener() for each store
// The advantage is that it can be written together with the store declaration.
const store = useStore()
window.addEventListener('storage', (e) => {
  if (e.key === <StorePersistKey>) {
    store.$hydrate()
  }
})

Of course, I also believe that having it as an optional configuration is essential, as it can help avoid having to write this externally for each store.

@EgeOnder
Copy link

Is there anyone working on this issue? It would be super cool to have this as a built-in feature.

@AuroraTea
Copy link
Contributor

Is there anyone working on this issue? It would be super cool to have this as a built-in feature.

Me.

Currently, progress is stuck at watching of cookies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants