Add post-persistence global mutation to store #576

Open
opened 2019-06-13 07:06:53 +00:00 by hj · 8 comments
Owner

Problem: every time we change something in store persistent state will load old data. This was especially the case in Themes v2 and now it's in MastoAPI registration MR.

Current workaround: check what state is and work with that even if it's not exactly documented or mentioned in code

Proposed solution: add a "persistent state loaded" type of migration that would tell all vuex modules to check for old stuff and migrate it if needed.

Problem: every time we change something in store persistent state will load old data. This was especially the case in Themes v2 and now it's in MastoAPI registration MR. Current workaround: check what state is and work with that even if it's not exactly documented or mentioned in code Proposed solution: add a "persistent state loaded" type of migration that would tell all vuex modules to check for old stuff and migrate it if needed.

I don't understand this issue. Why does something load old data?

I don't understand this issue. Why does something load old data?
Author
Owner

Server had version 1 of FE. It was using version 1 of settings data
FE was updated to version 2. It's using new version 2 of settings data
User still has version 1 data in local storage and he opens up new version of FE

Expectation:
Old settings data is migrated to version 2.

Reality:
FE version 2 also supports importing version 1, version zero, version minus one etc.

Server had version 1 of FE. It was using version 1 of settings data FE was updated to version 2. It's using new version 2 of settings data User still has version 1 data in local storage and he opens up new version of FE **Expectation**: Old settings data is migrated to version 2. **Reality**: FE version 2 also supports importing version 1, version zero, version minus one etc.

ah, so essentially local storage migrations. That's easily (well, simply) done with indexeddb, with local storage we'll have to dig a bit deeper, but it's doable.

ah, so essentially local storage migrations. That's easily (well, simply) done with indexeddb, with local storage we'll have to dig a bit deeper, but it's doable.
Author
Owner

i don't know about indexeddb, i would rather just do it manually with whatever system storing a JSON and FE just migrating that.

i don't know about indexeddb, i would rather just do it manually with whatever system storing a JSON and FE just migrating that.
Author
Owner

Right now there's no real need for anything besides themes which already has the aforementioned "reality", but overall global post-persistence mutation needed for migrating/upgrading.

We need to consider another case where FE might be rolled back, so storing previous versions most likely a must.

Right now there's no real need for anything besides themes which already has the aforementioned "reality", but overall global post-persistence mutation needed for migrating/upgrading. We need to consider another case where FE might be rolled back, so storing previous versions most likely a must.

It's not as magical as it sounds. When you open a db with indexeddb, you specify a db version. if the version of the in-store db is lower than yours, an event is triggered in which you can modify the data in the db.

It's not as magical as it sounds. When you open a db with indexeddb, you specify a db version. if the version of the in-store db is lower than yours, an event is triggered in which you can modify the data in the db.
Member

@lambadalambda Can we discuss sth via dm? github.com/self-coding-crab is my profile.

@lambadalambda Can we discuss sth via dm? github.com/self-coding-crab is my profile.
Author
Owner

yes i know it's not magical but i'd still prefer using our own implementation because browser APIs tend to be shit.

yes i know it's not magical but i'd still prefer using our own implementation because browser APIs tend to be shit.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pleroma/pleroma-fe#576
No description provided.