Adding async support for localstorage (#68)

[ernestomancebo]

Wrapping the update operation of the local storage on a Promise, which when completed calls the resolveOnUpdate function and pass down the key and new value as an object. When there's an error, calls the catchOnUpdate and pass the error.

Those functions are wrapped on the optional attribute asyncOperations in the config object and are defined as follow:

const configObject: LocalStorageConfig = {
    // Others attributes
    asyncOperations: AsyncOperations = {
        resolveOnUpdate: (state: any) => { },
        catchOnUpdate: (error: any) => { }
    }
};

Please review and let me know if any enhancement needs to be done

[btroncone]

@ernestomancebo What issue are we trying to address here? I'm torn on performing async operations in a meta-reducer.

[ernestomancebo]

I'm addressing for the item 68 (#68), not sure why didn't linked on the title.

The idea behind this is to call a function after the update state promise completes. Any suggestion to improve the design will be appreciated.

[ahoebeke]

New to your module. Noticed the similar "ngrx-store-ionic-storage", but glad to see you've made it possible in yours to use async operations too.

Will update after testing and using in own app! Thanks 👍

[ahoebeke]

@btroncone could you explain why? Am new to this all and don't intuitively understand why you wouldn't want async?
Maybe comparing with the "ngrx-store-ionic-storage" module might shed a light?

[michaelkariv]

@btroncone could you explain why? Am new to this all and don't intuitively understand why you wouldn't want async? Maybe comparing with the "ngrx-store-ionic-storage" module might shed a light?

I would like to expand on the explanation as there has been 4 or 5 years and things got updated.

TLDR: localstorage can be cleaned up, so solutions could be: 1. use indexedDB over localstorage and 2. use a mobile device native storage when the web code is used for a hybrid mobile application. Both requrie async / Promise

Long read.

Why we want async for a web (PWA) app.

• localstorage can be cleaned up by mobile browsers
• indexDB is robust, and has higher capacity than localstorage
• indexedDB is asynchronous for all practical purposes

Why we want async for hybrid (both web and mobile) apps

• this really is my motivation, personally
• I want the same exact code to run as a PWA in a browser, and as an app on Android or iOS. That is for business/marketing reasons.
• I looked at 3 technologies - capacitor/cordova, flutter, react native.
• Of these only capacitor allows exact code to run. Flutter feeels weird because it uses canvas, and react native code base is not the same for mobile vs web
• capacitor providers the browser-like runtime host for the html/js/css, but also plugins to access device capabilities. Most have fully capable PWA version. So they can be used exactly the same (from code perspective, not build procedure perspective) in PWA and mobile contexts.
• one such plugin is Preferences , which was ionic-storage refereed to in one of the prevoius comments.

Why wanting this from ngrx-store-localstorage and not create an alternative

• there are alternatives that attempted that, e.g. ngrx-store-sync uses localForage or ngrx-store-capacitor. The former even quotes ngrx-store-localstorage as an inspiration and is a fork
• they are not as actively maintained (ngrx-store-sync is only up to date with Angular 12)

Why I think ngrx-store-localstorage is close enough

• ngrx-store-localstorage is modular accepting a plug-in Storage as part of Options. It means any outside storage module is OK as long as it implements Storage internface, namely these three
• storage.getItem , storage.setItem, storage.removeItem
• though capacitor Preferences has methods named differently, (get(), set(), remove(), having options object as a param), it is nothing a simple Wrapper would not solve
• the only real problem is that localstorage (and Storege interface method) is synchronous. indexedDB and capacitor/Preferences is asynchronous.