Multiple stores?

[juristr]

Hi,

might it be possible to have multiple stores? Like I have the scenario where I save flags and settings of the app (which you'd normally put in localStorage). But then I also have some app data which I regularly sync. For that 2nd scenario, I simply do a wipe & resync when I need to refresh the data, but obviously I'd only like to .clear() the app data, not the user's settings and flags.
Ofc, what I could do is to use a single "key" and store an array of app data inside there, but since it's a lot of data (PDF documents in binary form), I wouldn't want to serialize/deserialize it continuously from memory.

With the current implementation this isn't possible I guess, right? Any interest/idea on adding this feature? Would also be willing to help in case.

[cyrilletuzi]

Hi @juristr,

I'm not opposed to the feature, how would you design it?

One thing that can be challenging is the feature should be compatible with IndexedDB and the localStorage fallback.

[juristr]

🤔 hmm...true that, didn't think about the localStorage fallback. One possibility would be to add the "store name" as a key prefix. But yes...you wouldn't get the same

[dphochman]

Hi @juristr & @cyrilletuzi,
It might suffice to removeItem multiple items, passing a prefix, or a pattern, or a list of keys. That would let us use a prefix as a substitute for a store name. Is that possible?

[cyrilletuzi]

@dphochman Can be done for getItem, setItem and removeItem, but the problem is for clear when in localStorage fallback scenario.

It would suppose to know all the keys with the wanted prefix stored in localStorage, and I don't know a way to do that.

[cyrilletuzi]

I see two options possible if this feature is implemented:

• restrict the API (no clear method in that case)
• warn that clear will not work in fallback scenarios.

[dphochman]

Thank you @cyrilletuzi.

I think that clear(prefix) could be the same as removeItems(prefix) in this case.

You could get the keys via something like Array(localStorage.length).fill(1).map((x,index) => localStorage.key(index)), and filter the keys by prefix/pattern, and then removeItem each of them in a Promise.all() inside the Observable, so that it all happens together and still emits one event.

FWIW, this library is insanely valuable in an enterprise environment that's trying to reduce network traffic, improve response time, and keep the codebase comprehensible.

[cyrilletuzi]

@dphochman I don't see from where comes index in your example.

To be sure we understand each other: when I talked about localStorage, it is the native API / variable (window.localStorage), not the service provided by the lib.

[cyrilletuzi]

@dphochman Damn, I didn't even know the localStorage.key method! Seems we have a solution then.

So I'll look into the implementation of this feature.

[cyrilletuzi]

@juristr How do you see the API of this feature, regarding to your needs?

[cyrilletuzi]

Thoughts for discussion:

Having:

.getItem('key', { storageName: 'test' })
.setItem('key', 'value', { storageName: 'test' })
.removeItem('key', { storageName: 'test' })

is not very useful. It's a little cleaner, but also more verbose. You could simply do with the current API:

.getItem('test_key')
.setItem('test_key', 'value')
.removeItem('test_key')

And then we could have this new option just for clear:

.clear({ startWith: 'test_' })

What do you think?

[dphochman]

@cyrilletuzi: that solution works for me, and it seems like an understandable way to partition the IndexDB & localStorage. It also seems like a much smaller footprint than what @juristr or i suggested, so it would be easier to test.