danielstjules
commented
10 years ago Hopefully I can help clarify things!
localStorage is scoped to the origin (scheme + hostname + non-standard port). So http://a.example.com and http://b.example.com have isolated localStorage instances. But imagine if you wanted to sync some data across a range of your subdomains, or even completely different hosts. While some may use a root level cookie for this (scoped to example.com), it results in additional overhead for each request/response to the server, and is limited to 4kb. If you have a lot of services running on a given host, you can't have them all polluting that root cookie. So using cross-storage, you get to avoid that overhead, since it's all client-side, and you get significantly more space! Your resulting setup could then look like a.example.com, b.example.com and store.example.com, such that your subdomains all share a localstorage instance found on the store subdomain.
Of course, an alternative to using cross-storage or a root cookie would be establishing some APIs for the different services to consume. But here we get to shave off both developer time, and a few requests. :)
As for alternatives to this library, I'm not sure what you mean. globalStorage isn't a standard, and is considered obsolete. What alternative were you referring to?
srhyne
@danielstjules I'm sure many many hours were put into this project and it looks very interesting. I've used localStorage extensively and I'm a big Zendesk fan. However, I can't quickly identify the pain that cross-storage is relieving.
Perhaps you could incorporate some use cases into the README that explain scenarios where cross-storage would solve a big problem vs using the existing alternative.
Thank you!