Storage compression about angular-localforage

[rpannell]

When I was using local storage directly and before I found angular-localforage I was using that compression. Worked very well, but there was a small slow down.

It good 2.9 mb of data down to 0.16mb. So a huge difference!

[ocombe]

Wow that's huge, it could really be a good feature. You were using "pako" ?
The slow down is expected, and that's why it will be optional.

[mavrick]

+1 for lzstring

[JobaDiniz]

+1
Is there any news on this one?

[ocombe]

Not much, I don't have a lot of free time for now, but if you want to try to do that and do a PR, feel free to do so :)

[scotttrinh]

Let's put this back in the queue for 1.4.0.

[siddo420]

+1
any updates on this issue?

[scotttrinh]

nothing new to report, but it is definitely on the road map. PRs welcome!

[scotttrinh]

Quick question for those who would want to use this functionality: what about making a custom localForage driver that does this compression? That would keep our codebase cleaner by still just wrapping localForage and would help the upstream community. The downside is that we'd be subject to localForage's opinions and timeframes.

[scotttrinh]

Or maybe a separate compression decorator that just wraps the getItem/setItem calls to compress and decompress on the way in and out?

[scotttrinh]

Here is an example decorator using LZString:

http://plnkr.co/edit/r0tSMFNJwsbyUdLT35Or?p=preview

Not cut-n-paste production ready, but is a good starting point for those wishing to do this. Maybe we can just document this pattern and be done with it?