Redux-persist: localForage and getStoredState from Redux Persist

Created on 25 Jan 2017  路  8Comments  路  Source: rt2zz/redux-persist

Using getStoredState while in incognito mode or with cookies disabled in Safari causes the store to never be made available. localForage rejects it's promise with the SecurityError thrown by Safari.

Since understanding how redux-persist and localForage interplay in this scenario and how to resolve that is too large a task for me I simply revert to not using localForage if I can get an error by trying to access localStorage like so:

let enableLocalForage = true;
try {
  localStorage.setItem('__u', 'u');
}
catch (e) {
  // proxy to figure out if we're in an incompatible environment for localForage
  // since redux-persist doesn't play nice when localForage fails to start
  enableLocalForage = false;
}

const persistConfig = {
  storage: enableLocalForage ? localForage : null,
};

This stops my app from breaking when it starts but the console does get littered with warnings while in this mode.

Most helpful comment

Just wondering - looking one step back - wouldn't localForage by itself fail when localStorage is not available and simply go to the next driver? Wouldn't just defining memoryStorage as the fallback driver solve those issues (and still be within localForage functionality)?

PS: we could also simply extend isLocalStorageValid to actually try to call .setItem() and thus invalidate localStorage in case of Safari (or any other) errors.

All 8 comments

i wrote a fake local storage implementation that can be passed in as config.storage if enableLocalForage is false - this at least avoids all the errors / warnings that get spewed out.

@modosc awesome thanks for sharing!!

you can also use something like https://www.npmjs.com/package/redux-persist-cookie-storage to store cookies which do not cause errors or warning.

In the future we will probably ship a recommended redux-persist-storage-web that rolls localforage + cookie fallback into one. If you find such approach works, feel free to release said module 馃巿

Note that cookies also can be disabled. So, I guess we should just not store anything if the user opted not to

@zalmoxisus good idea. I wish there was a clear way to distinguish "storage not allowed" from "storage error". Perhaps we should just be conservative in our fallback and warn in dev.

we're using both localForage and redux-persist-cookie-storage - things that are required for SSR go into cookies, everything else goes into localForage. our localForage stores are 10x the size of our cookie stores - automatically adding those to cookies may not be ideal (and may also quickly hit the cookie size limit).

update: i published https://github.com/modosc/redux-persist-memory-storage as a general purpose solution - we've had to use this pattern for clients with cookies or localstorage disabled.

Just wondering - looking one step back - wouldn't localForage by itself fail when localStorage is not available and simply go to the next driver? Wouldn't just defining memoryStorage as the fallback driver solve those issues (and still be within localForage functionality)?

PS: we could also simply extend isLocalStorageValid to actually try to call .setItem() and thus invalidate localStorage in case of Safari (or any other) errors.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

openscript picture openscript  路  4Comments

thenewt15 picture thenewt15  路  3Comments

ssorallen picture ssorallen  路  4Comments

elado picture elado  路  4Comments

ejbp picture ejbp  路  3Comments