The entire use of the Expiration object in the lib needs to be rethought. It feels dumb to have so much coupling between the redis src and the lib.
The lib works great in the sense of isolating all of the expiration-centric logic. However, the lib also needs access to the storage object for reads/writes – hence the need for a storage context in almost every helper function. We simply cannot decouple by defaulting to a particular storage object since the expiration helper caller could be either of the web storage objects (localStorage of sessionStorage).
In rewriting expiration to a data-based solution, the tight coupling is creating circular call-stacks. The expiration logic should be kept in redis src to avoid all of these problems. With the splitting of the source into various API parts, all expiration logic and safe storage helpers (_retrieve, _store, _exists, etc) can be included in LocalRedis Core and distributed along with LocalRedis Keys and LocalRedis Strings.
The entire use of the Expiration object in the lib needs to be rethought. It feels dumb to have so much coupling between the redis src and the lib.
The lib works great in the sense of isolating all of the expiration-centric logic. However, the lib also needs access to the storage object for reads/writes – hence the need for a storage context in almost every helper function. We simply cannot decouple by defaulting to a particular storage object since the expiration helper caller could be either of the web storage objects (localStorage of sessionStorage).
In rewriting expiration to a data-based solution, the tight coupling is creating circular call-stacks. The expiration logic should be kept in redis src to avoid all of these problems. With the splitting of the source into various API parts, all expiration logic and safe storage helpers (_retrieve, _store, _exists, etc) can be included in LocalRedis Core and distributed along with LocalRedis Keys and LocalRedis Strings.