store2

store2 is a thin, dependency-free wrapper around the browser’s localStorage and sessionStorage that automatically handles JSON serialization, gracefully falls back to an in-memory “fake” store when persistent storage is unavailable, and adds conveniences like key namespacing, transactional updates, and iteration that the native Storage interface doesn’t provide. Calling store(key, value) sets data and store(key) reads and parses it, while store.session and store.page expose the same API against sessionStorage and a non-persistent in-memory area respectively. An extension system (store._.fn) lets a family of official add-ons — expiring cache entries, storage-event listeners, array helpers, cookie-backed storage, and more — plug into every store instance.

What You Get

• A callable store(key, value) / store(key) API for set/get, plus explicit store.set, store.get, store.has, store.remove, store.clear methods
• store.transact(key, fn, alt) for read-modify-write updates and store.each(fn) for iterating all stored key/value pairs
• store.namespace(prefix) to scope a group of keys under a shared prefix without manual string concatenation
• Separate store.session (sessionStorage) and store.page (non-persistent, page-lifetime) areas sharing the identical API as the default store.local
• Automatic in-memory fallback (isFake) when localStorage/sessionStorage are unavailable, so calls never throw in restrictive environments
• A documented extension system (store.cache, store.on, store.array, store.cookie, and others) that adds features like expiring keys, storage-event handling, and array helpers

Common Use Cases

• Persisting structured application state (objects, arrays) to localStorage without manually calling JSON.stringify/JSON.parse on every read and write
• Namespacing keys for a feature or module (e.g. a shopping cart) so its storage keys can’t collide with unrelated keys elsewhere in the app
• Adding expiring cache entries to localStorage via the store.cache.js extension, useful for caching API responses client-side
• Reacting to storage changes across browser tabs using the store.on.js extension’s per-key/per-namespace event handling

Under The Hood

Architecture The core (src/store2.js) implements a single callable store function/object that dispatches to set/get/transact/each behavior based on argument shape, wraps native Storage objects (or an in-memory fake when unavailable) behind a uniform internal interface, and exposes an store._ internals object (fn, area, revive, replace) that the many src/store.*.js extension files use to register new methods onto every store instance and namespace.

Tech Stack Plain, dependency-free JavaScript (pre-ES-module era, JSHint-linted) with a Grunt-based build pipeline producing dist/store2.js, hand-written TypeScript declarations (index.d.ts), and a test/ directory; the library and each extension are distributed as separate files so consumers only need to load the extensions they actually use.

Code Quality The public API is consistent across the many storage areas and namespaces, the extension mechanism cleanly separates optional features (expiry, events, cookies) from the small core, and there is a dedicated test/ directory, though several extensions are explicitly marked ‘alpha’ or ‘incomplete’ in the README and the project has seen minimal commit activity in recent history.

API Design The callable-object pattern (store(key, value) doubling as store.set) mirrors jQuery-era ergonomics that are immediately familiar to JS developers, store.namespace() and the session/page area split solve two very common pain points (key collisions and storage-type switching) with a single method call each, and the README documents every core method plus each extension with runnable examples, though the sheer number of optional extensions can make it unclear at first which pieces are core versus opt-in.