Error retrieving and setting data in different structure

[Ruluk]

Hey,

Well, I wanted to share indexedDB data between two different apps. One is in angular but the other is not. My solution was to use LocalForage, given you based your work on it.

But saving a JS object with LocalForage and then using or updating it with this library didn't work, even though the database and table were the same. After some analysis, I noticed the cause to be that you wrap the object in a value property.

Whether you want your library to be compatible with LocalForage is another discussion, but I guess you may want to handle the errors more precisely.

Setup

Save a JS object, but don't wrap it in another object with the value property. Then make LocalStorage get or update this object.

Current behavior

getItem observable returns null.
setItem observable returns the error (I even thought it was related to #47):

IndexedDB setter issue : Key already exists in the object store.

More precise behavior

getItem observable throws an error or actually reads the current value.
setItem observable returns a more descriptive error or normalizes the structure to what it should be.

[cyrilletuzi]

Thanks for your feedback.

To be clear: this lib is based on localForage idea, but don't use localForage at all.

Indeed, value is wrapped in a { value: ... } object for indexedDb. To be honest, I don't remember why I did that in the first place. Tests seems to pass if I don't do so, so I'll need investigation to check if it was to manage some special cases or if I just wrongly assumed that only objects could be stored in indexedDb.

In all cases, changing that would be a breaking change for all existing apps: all previous stored data would be lost, which is not acceptable. So investigation will be needed to find a solution without breaking.

If we're going into interoperability with other libs like localForage, further work will be needed as currently you are using internals of this lib (database and store names), which is not a good practice as it could change at any time (even if it's unlikely). So configuration should be added for that.

[cyrilletuzi]

After some investigation, the main issue to allow the behavior you want is: what if someone stored an object like { value: 'test' }?

I can't find a way to know if it's wrapped because of the lib or if it's the real value. Any idea?

[cyrilletuzi]

My previous message concerns getItem.

The setItem behavior can be considered as a bug. I have a fix for it, I should release it tomorrow.

[cyrilletuzi]

Current work status:

• setItem will now work even if another value with a different structure was stored with another lib or the native API
• getItem will first look for the structure planned by the lib ({ value: ... }), or else will return the existing value as is.

As mentioned, problem is if { value: ... } was stored with the native API or another lib. Ideas welcomed.

[cyrilletuzi]

Fixed in 7.3.0, given some limitations and adaptations described in a special documentation.

Direct interoperability by unwrapping the value is considered in #67.

[Ruluk]

Thanks for the support, by the way! 😄

[cyrilletuzi]

Hi @Ruluk, can you test if you can achieve your interoperability goal with v8 beta? Instructions in #76, you'll be especially interested by the new interop guide, where there is an example config for interop with localforage.