[dev] better state persistence

[southerneer]

We need a more robust/general state persistence/rehydrate mechanism for handling cases like:

• Don't lose map options when upgrading or codepush-ing #4849
• Store user preferences that do not get deleted after upgrade or codepush #4410
• [dev] onboarded flag should be stored separately #4915

[bengtan]

In the medium to long term, I think we'll need a facility for storing per-device settings. Previously, we got away with just shoehorning everything into clientData but that's only a bandaid each time.

So, yes, I'm all for a per-device settings 'thing'. Let's do it and then we can start using it.

---

(I'm not sure what else you'd include in 'better state persistence')

[aksonov]

@southerneer I guess #4849 is ok to store on server-side, so it should not be listed here. About user preferences - I don't know others settings now, so only onboarded storage left, right?

I don't like idea of 'migration' tools implementation (in case of store shape changes), so I suggest to have just one-dimensional key/value map. What about adding deviceData value to Wocky and preserve it as part of minimalData?

[southerneer]

I guess #4849 is ok to store on server-side, so it should not be listed here

While it's "ok" to store mapOptions or any other piece of serializable data on the server, it's not optimal. Network roundtrip times can vary widely and if we can store the data reliably on the device I think we should. In this case, the user would potentially see a flash of the map view if they started up the app with the default selection and the network call to fetch mapOptions took a second or two to return with the persisted selection. If we can make a general solution to persisting data on the device this would improve the overall user experience.

I don't like idea of 'migration' tools implementation (in case of store shape changes), so I suggest to have just one-dimensional key/value map.

I don't really understand this argument. If we store persisted values as a one-dimensional map then we have to write additional code to convert that map to the MST store shape. And if the MST shape changes we still have to change that conversion code. It seems like storing the data in a different shape just adds one more layer of complexity.

[aksonov]

I don’t understand issues with shapes. Wocky.deviceData shape will never be changed, it will be just key/value map Sent с iPhone

…

17 марта 2020 г., в 20:28, Eric Kirkham ***@***.***> написал(а):  I guess #4849 is ok to store on server-side, so it should not be listed here While it's "ok" to store mapOptions or any other piece of serializable data on the server, it's not optimal. Network roundtrip times can vary widely and if we can store the data reliably on the device I think we should. In this case, the user would potentially see a flash of the map view if they started up the app with the default selection and the network call to fetch mapOptions took a second or two to return with the persisted selection. If we can make a general solution to persisting data on the device this would improve the overall user experience. I don't like idea of 'migration' tools implementation (in case of store shape changes), so I suggest to have just one-dimensional key/value map. I don't really understand this argument. If we store persisted values as a one-dimensional map then we have to write additional code to convert that map to the MST store shape. And if the MST shape changes we still have to change that conversion code. It seems like storing the data in a different shape just adds one more layer of complexity. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[southerneer]

Wocky.deviceData shape will never be changed, it will be just key/value map

...but you still have to convert that map into something we can use in MST. You're making the storage shape simpler at the expense of a more complicated and verbose converter. I'm not saying the suggestion is worse than mine, but I don't see a compelling reason why it's better.

[aksonov]

...but you still have to convert that map into something we can use in MST. You're making the storage shape simpler at the expense of a more complicated and verbose converter. I'm not saying the suggestion is worse than mine, but I don't see a compelling reason why it's better.

Could you rephrase your suggestion here? I don't understand where my suggestion is complex - dedicate simple key/value store OR as part of wocky. Add it getMinimalStoreData. It is very simple.

[aksonov]

Under 'map' I meant usual MST store with fixed structure (similar to current ClientData) - btw, I can't imagine why we will need to change 'shape' of this store in the future, so we will get all persistence for free

[southerneer]

OK, I think we're more or less talking about the same thing. I'm not sure what you meant by "one-dimensional key/value map", but if we're both talking about preserving the same shape of the MST store then I think we're on the same page.

dedicate simple key/value store OR as part of wocky.

I don't think it makes sense to store whatever structure as part of wocky since wocky is a child of the main store (defined in store.ts).