Incompatible property enumeration and toJSON method

[semmel]

Unfortunately I rely on things like Object.keys(localStorage) to give me the keys of all items stored.

var isolated = new MemoryStorage('my-app');
isolated.setItem("test", JSON.stringify({ key: "value" }));
Object.keys(isolated);  
/// returns ["id", "length", "getItem", "setItem", "removeItem", "key", "clear", "test"]

localStorage.setItem("test", JSON.stringify({ key: "value" }));
Object.keys(localStorage); 
/// returns ["test"] 

It might be related, also that the output of applying JSON.stringify is not compatile to localStorage. It should be

JSON.stringify(localStorage)
// returns {"test":"{\"key\":\"value\"}"}

but instead it is

JSON.stringify(isolated)
// returns {"id":"my-app","length":1,"test":"{\"key\":\"value\"}"}

Perhaps one should define a .toJSON method to fix that behaviour.

With best regards
Semmel

[Download]

Yes. The API is compatible, but when you dig into it deeper there are differences.

Note that the Web Storage API has explicit methods for determining the keys.

returns {"id":"my-app","length":1,"test":"{"key":"value"}"}

This could probably be prevented by making the id and length properties not enumerable... I'm guessing the toJSON would then automatically do the right thing. The same goes for the other methods in the API... I think setting them all to not enumerable would fix this.

I'm going to leave this open for now. I have a deadline on jan. 1st so no time to pick this up right now but I hope to be able to change this later. Compatibility with localStorage in real-life use cases should be top priority for this project.

Good to know there is someone out there using/playing with it. :) If you want to make changes, I'll be happy to review/merge any pull requests you come up with :)

[semmel]

Yes, one could make the whole API getItem, clear, key,... non-enumerable. That would filter those functions out of the key collection.

But it is impossible to include the cloaked keys (i.e. those of the API) in the key collection :-(
I.e. "id", "length", etc. are right to be included in the result of JSON.stringify() and Object.keys() if there are values stored with such keys...

I guess in the future on could use an ES6 Proxy handler.ownKeys() method which intercepts Object.keys() in order to add the cloaked items.

Sadly today I still can not use native ES6 Proxies in all browsers. Polyfills for Proxy patch so many globals in the JavaScript context that it is to dangerous imho :-(

[Download]

But it is impossible to include the cloaked keys

Yes I thought about this a lot when working on it and basically decided to ignore it... weak I know :) However it might be a good reason not to expose the id property, or use a different name.

The point I took out of studying the web storage API is that if you worry about this stuff, the safest thing to do is only follow the API and limit yourself to length and key for discovery of keys in the set.

[Download]

I have an idea. Could you write a test or two that fail on the stuff where MemoryStorage differs from localStorage that are important to you? This makes my life much easier for fixing it.

[semmel]

the safest thing to do is only follow the API and limit yourself to length and key for discovery of keys in the set.

Indeed! The Web Storage API definitely needs a "Best Practices" guide:

• Always enumerate the keys using length and key(),
• always prefer setItem, getItem and removeItem over storage[key] = value, storage[key] and delete storage[key]

Maybe that could go into the Readme?

Herewith I am dropping my problem with JSON.stringify(memoryStorage). Because even the native browser implementations do not get it:

localStorage.setItem("getItem", "dummy value");
/// returns "{}"
JSON.stringify(localStorage)

The same with my problem with Object.keys(memoryStorage). I defer that until ES 6 Proxies arrive in all browsers, or I'll have a some minutes for an proxy experiment and will do a pull request with a fix.

Feel free to close this issue.