Sync with redis - Githubissues

prazdevs / pinia-plugin-persistedstate

🍍 Configurable persistence and rehydration of Pinia stores.

https://prazdevs.github.io/pinia-plugin-persistedstate/

MIT License

1.93k stars 107 forks source link

Sync with redis #303

Open martinszeltins opened 1 month ago

martinszeltins commented 1 month ago

Describe the bug

It would be really nice to be able to store the pinia state in Redis. I don't understand the limitation of Storage must be synchronous. Why can't we simply trigger a Redis save and load on $subscribe?

Reproduction

n/a

System Info

n/a

Used Package Manager

n/a

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] The provided reproduction is a minimal reproducible of the bug.

prazdevs commented 1 month ago

Hi mutations in Pinia are synchronous, and this plugin uses the $subscribe API to react to mutations and save the state. You can still make async calls in a sync function, but you may experience unexpected behaviours, that's why it's not recommended.

See https://pinia.vuejs.org/core-concepts/state.html#Subscribing-to-the-state

The other way to implement async behavious with Pinia is actions.

martinszeltins commented 1 month ago

Hi mutations in Pinia are synchronous, and this plugin uses the $subscribe API to react to mutations and save the state. You can still make async calls in a sync function, but you may experience unexpected behaviours, that's why it's not recommended.

See pinia.vuejs.org/core-concepts/state.html#Subscribing-to-the-state

The other way to implement async behavious with Pinia is actions.

What are potential problems that can occur when making async calls on $subscribe?

prazdevs commented 1 month ago

Async calls are not awaited, if two mutations happen successively, the second call may resolve before the first one, resulting in outdated data replacing latest data.

martinszeltins commented 1 month ago

Async calls are not awaited, if two mutations happen successively, the second call may resolve before the first one, resulting in outdated data replacing latest data.

Perhaps this can be solved using timestamps?

Last Synced Mutation Time: 2024-05-27T19:34:49 

Mutation: user=john; timestamp=2024-05-27T19:34:49

// Rejected because timestamp is < last synced time
Mutation: user=joh; timestamp=2024-05-27T19:30:49

prazdevs commented 1 month ago

That could be a workaround for you, but this would be out of scope of the plugin, as we dont support async behaviours and side effects :)