Some form of persistent local storage

[jbachhardie]

Is your feature request related to a problem? Please describe. I was trying to store some simple local settings using localforage and after some trial and error determined that all three of WebSQL, IndexedDB and localStorage are unavailable in the app context.

Describe the solution you'd like It doesn't need to be IndexedDB but some way to store local data which can remain consistent as the user navigates through viewports would be very useful.

Describe alternatives you've considered This could clearly be accomplished with server-side session storage but setting up a Redis instance or the like when a client-side store would suffice seems like overkill.

Another option is that the upcoming Datastore API is fast and flexible enough for this kind of usecase.

Additional context If the blocking of these browser APIs is intentional for security reasons then it would be good to have in the documentation some list of intentional limitations of the app environment along with recommended secure alternatives.

[jt-stripe]

@jbachhardie Great feedback.

Can you elaborate on your use case a little bit?

IndexedDB is somewhat challenging to open up but I do think that we should offer a simple, local key/value API backed by localstorage for things like oauth tokens and whatnot. More complex state management would need to be on a backend server (and hopefully eventually the Datastore API).

[jbachhardie]

The immediate use case is storing user preferences. Pretty rudimentary things like letting users choose whether to show or hide specific options. Any simple key-value store would be sufficient

[jt-stripe]

Great, thanks you.

On Fri, Jan 14, 2022 at 11:10 AM Jae Anne Bach Hardie < @.***> wrote:

The immediate use case is storing user preferences. Pretty rudimentary things like letting users choose whether to show or hide specific options. Any simple key-value store would be sufficient

— Reply to this email directly, view it on GitHub https://github.com/stripe/stripe-apps/issues/85#issuecomment-1013385637, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQKUVOL643ZLDN5MWQ7233UWBYLTANCNFSM5L7LQ65Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[jt-stripe]

@jbachhardie if you had the Datastore API would you use that so that preferences persisted across browsers or would you prefer the low latency of storing locally?

[jbachhardie]

I guess it depends on the exact amount of latency. If it's not very fast then having to load preferences from it on every single view, every time, might lead to a worse experience. It also depends on the storage and rate limits of the Datastore. If it's something that should be called sparingly then it would be particularly useful to have some persistent local storage, if nothing else to keep a cache of expensive requests

[bensontrent]

I'd like to echo my need for a persistent local storage. Access to window.sessionStorage would be ideal, but having the ability to set a custom object on ExtensionContextValue that can persist between multiple app viewports would be helpful. Or perhaps, another idea: if the context object were wrapped into a useContext provider, we could set the state between multiple viewports.

I'm developing a shipping app that has to perform a few expensive server calls to setup the user settings and fetch required data from Stripe. The data fetched could be warehouse information, shipping history or a list of unshipped invoices depending on the view. When a user browses from viewport to viewport, this initialization data has to be called each time a new viewport is loaded. It would be nice to have an in-app global variable I could set and read from once to prevent so many server calls per user.