I am finding that my state is not being populated correctly when the REDUX_STORAGE_LOAD action is dispatched -

I've ruled out a save occurring before load by whitelisting just one action.

My storage reducer is simply -

import { LOAD, SAVE } from 'redux-storage';

export default function storeageAwareReducer(state = { loaded: false }, action) {
  switch (action.type) {
    case LOAD:
      return { ...state, loaded: true };

    case SAVE:
      console.log('Something has changed and written to disk!');

    default:
      return state;
  }
}

My store setup is very standard and follows the example in the readme and I am using the redux-storage-engine-reactnativeasyncstorage engine -

import * as storage from 'redux-storage'
import createEngine from 'redux-storage-engine-reactnativeasyncstorage';
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import createLogger from 'redux-logger';
import { APP } from '../configs/index';
import api from 'CookAndCount/app/middleware/api';

import rootReducer from '../reducers/index';

// Wrap reducer for use with redux-storage
const reducer = storage.reducer(rootReducer);

const logger = createLogger();

// Create a storage engine for AsyncStorage
let storage_key = `cook-and-count-${APP.STORAGE_SUFFIX}`;

const engine = createEngine(storage_key);

// Create middleware - thunk and storage
const middleware = [thunk, api, logger, storage.createMiddleware(engine)];

// Create store with middleware applied
const store = createStore(rootReducer, applyMiddleware(...middleware));

// Load in previous app state
const load = storage.createLoader(engine);

load(store)

export default store;

When I listen to the promise I am getting the intended state and no errors -

load(store)
  .then((newState) => console.log('Loaded state:', newState))
  .catch(() => console.log('Failed to load previous state'));

I'm using Immutable decorator to load state data with localStorage engine. But on initial load I get a bunch of warnings from Immutable library:

iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error
    at src_Map__Map.Object.defineProperty.get (webpack:///./~/immutable/dist/immutable.js?:4632:21)
    at pathKey (webpack:///./~/lodash/index.js?:2452:51)
    at isArrayLike (webpack:///./~/lodash/index.js?:4075:40)
    at baseMergeDeep (webpack:///./~/lodash/index.js?:2416:13)
    at eval (webpack:///./~/lodash/index.js?:2366:11)
    at arrayEach (webpack:///./~/lodash/index.js?:1289:13)
    at baseMerge (webpack:///./~/lodash/index.js?:2358:7)
    at eval (webpack:///./~/lodash/index.js?:3024:13)
    at eval (webpack:///./~/lodash/index.js?:8152:31)
    at exports.default (webpack:///./~/redux-storage/lib/reducer.js?:13:76)
immutable.js:4637 iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error
    at src_Map__Map.Object.defineProperty.get (webpack:///./~/immutable/dist/immutable.js?:4632:21)
    at isTypedArray (webpack:///./~/lodash/index.js?:8998:51)
    at baseMergeDeep (webpack:///./~/lodash/index.js?:2416:60)
    at eval (webpack:///./~/lodash/index.js?:2366:11)
    at arrayEach (webpack:///./~/lodash/index.js?:1289:13)
    at baseMerge (webpack:///./~/lodash/index.js?:2358:7)
    at eval (webpack:///./~/lodash/index.js?:3024:13)
    at eval (webpack:///./~/lodash/index.js?:8152:31)
    at exports.default (webpack:///./~/redux-storage/lib/reducer.js?:13:76)
    at dispatch (webpack:///./~/redux/lib/createStore.js?:120:22)
immutable.js:4637 iterable.length has been deprecated, use iterable.size or iterable.count(). This warning will become a silent error in a future version. Error
    at src_Map__Map.Object.defineProperty.get (webpack:///./~/immutable/dist/immutable.js?:4632:21)
    at pathKey (webpack:///./~/lodash/index.js?:2452:51)
    at isArrayLike (webpack:///./~/lodash/index.js?:4075:40)
    at isArguments (webpack:///./~/lodash/index.js?:8469:37)
    at isPlainObject (webpack:///./~/lodash/index.js?:8924:77)
    at baseMergeDeep (webpack:///./~/lodash/index.js?:2421:18)
    at eval (webpack:///./~/lodash/index.js?:2366:11)
    at arrayEach (webpack:///./~/lodash/index.js?:1289:13)
    at baseMerge (webpack:///./~/lodash/index.js?:2358:7)

I guess, this is happening, because merge() function on lodash is used https://github.com/michaelcontento/redux-storage/blob/master/src/reducer.js#L8 when LOAD action being handled and it uses .length somehow.

What we can do with it?

This is an awesome solution for me, thanks!

I am using this with react-native and I'm wondering how to clear the state so i can start fresh if i mess something up in the state tree

For whatever reasons, the catch statement of the promise returned by load is being called, but the previous state is in fact loading. That's not the real issue that's causing me problems though--Redux's connect mapStateToProps functions aren't being called again when the state changes. I've pintpointed this as a Redux Storage issue because when I remove the load call of Redux Storage, everything works.

So my thinking is that it's "failing" not so much in that the loading of previous state fails, but failing in some other regards with how it interfaces with the rest of Redux. What are the common reasons the promise's catch would be triggered?

This is a bug that arises from using popular packages together. I'm posting the bug here, and hoping you can cooperate with the involved parties.

If a user reloads an app that uses redux-storage & redux-storage-engine-localstorage & react-router & react-router-redux then the app will eventually complain with the error Warning: You cannot PUSH the same path using hash history.

Cause: React-storage triggers react-router-redux's enhanced react-router history, since it's causing a change in state. This in turns causes a history.push(...) to the restored URL, which is the same since it's a reload of the same page, thus causing the warning.

This issue doesn't seem to be directly addressed in the other projects since it's caused by using this plugin which automatically loads router state. Note that loading the state before enhanced router will avoid this bug, but then redux-storage fails to restore previous state on the second reload.

Hi! I have a test reducer: myReducer = (state = { arr: [1, 2, 3] }, action) => action.type == 'TEST' ? { arr: [5] } : state It's save to store correctly after dispatch: { arr: 5 } But after load it's has a value { arr: [5, 2, 3] }. Lo-dash _.merge problem.

Reducer should, on load, return a NEW state object, instead of modifying state. Without this, it doesn't pass new state (reliably, at least) into components after load.

A pretty standard practice is for 3rd party reducers to use a prefix for all of their actions (eg redux-form/DESTROY). In my use case, I'd like to disallow every action triggered by a certain 3rd party reducer (eg every action that begins with redux-form/) .

Today, I'd have to know & list every single action that a 3rd party reducer can create. That's a long list. Plus, I run the risk of the list going stale when my 3rd party package updates or changes a constant.

I can accomplish what I want by iterating over the entire blacklist & checking to see if my blacklisted substring is found in each entry. However, your logic may differ.

That's why if we allow the whitelist to be a function, everyone wins. For example, I'd write something like this:

const whitelistFn = type => {
    const blacklistPrefixes = ['redux-form/', '@@router/'];
    for (let i = 0; i < blacklistPrefixes.length; i++) {
        const prefix = blacklistPrefixes[i];
        if (type.indexOf(prefix) !== -1) {
            return false;
        }
    }
    return true;
}

And you can use whatever logic you like. The idea is borrowed from webpack, where a bunch of config fields can either be an array or a function.

We are currently using redux-storage and are experiencing that it slows down our app quite significantly due to many writes (debouncing didn't help in our case). As a small experiment we put a setTimeout(.., 1000) around the engine.save() command because we only want to save stuff as soon as there is no UI thread doing anything. And lo and behold, that surely sped things up quite a bit.

Would it be possible to have this as a feature and if not, are there complications?

Cheers,

Danny

Hi,

I am just curious if you thought about store migrations? What if we change structure? I think it should be responsibility of every reducer reviver.

Right now, when using this package without immutable, it will still require immutablejs which is quite big.

Each decorators should be required separately or be in its own package.

Since release of [email protected], there's a

warning " > [email protected]" has incorrect peer dependency "[email protected]^3.0.0 || ^2.0.0 || ^1.0.0 || 1.0.0-alpha || 1.0.0-rc".

Is redux-storage compatible with [email protected]?

Despite the setup as below with no blacklisted or whitelisted actions, once I dispatch sertain actions all saving stops for the entire app.

const reducer = storage.reducer(combineReducers({
  menu: menuReducer,
  axios: axiosReducer,
  admin: combineReducers({
    storage: storageReducer,
    classes: classesReducer,
    classEdit: classEditReducer,
    classEditStudents: classEditStudentsReducer,
    deleteConfirm: deleteConfirmReducer,
    actionConfirm: actionConfirmReducer,
    saveDialog: saveDialogReducer,
    admins: adminsReducer,
    adminEdit: adminEditReducer,
    students: studentsReducer,
    studentView: studentViewReducer
  })
}));
const engine = createEngine('vs45tgfr5678ikhy');
const middleware = [thunk, storage.createMiddleware(engine)];
const store = createStore(
  reducer,
  applyMiddleware(...middleware)
);
const load = storage.createLoader(engine);
load(store);

load(store)
  .then((newState) => console.log('STATE LOADED FROM INDEXED D:', newState))
  .catch(() => console.log('Failed to load previous state from local db!'));

export default store;

Fails on anything dispatched in the deleteConfirm:

let initialState = {
    show: false,
    action: null,
    params: null,
    item: null
};

const deleteConfirmReducer = (state = initialState, action) => {
    let newState = {};
    let data = action.payload;

    switch (action.type) {
        case 'DELETE_CONFIRM_HIDE':
            newState = Object.assign({}, state);
            newState = {
                show: false,
                action: state.action,
                params: state.params,
                item: state.item
            };
            return newState;

        case 'DELETE_CONFIRM_UPDATE':
            newState = Object.assign({}, state);
            newState = {
                show: true,
                action: (!data.action) ? null : data.action,
                params: (!data.params) ? null : data.params,
                item: (!data.item) ? null : data.item
            };
            return newState;

        case 'DELETE_CONFIRM_RESET':
            newState = Object.assign({}, state);
            newState = {
                show: false,
                action: null,
                params: null,
                item: null
            };
            return newState;

        default:
            return state;
    }
};

export default deleteConfirmReducer;

I cannot seem to find anything as to why.

Apologies if this is deemed a duplicate issue, but I felt my case was different enough from some of the other similar issues people were experiencing.

I have a strange issue. I am using redux-storage to store to the device in react-native. In attempting to save some data in a large ImmutableJS object, I can create a reducer and query for the data on action REDUX_STORAGE_SAVE which looks like this:

[ { id: 49, status: 'COMPLETE', status_set: '2016-10-20T16:37:51.516385Z' } ]

The change to that data is the additions of the status_set property. After saving, if I continue to do things in the app, the state remains as reflected above.

If I then reload the application, it loads data from storage storageEngine.load(store) I get:

[ { id: 49, status: 'COMPLETE' } ]

To further confuse, if I change the status in this example so on REDUX_STORAGE_SAVE it looks like:

[ { id: 49, status: 'INCOMPLETE', status_set: '2016-10-20T16:37:51.516385Z' }

After loading I get:

[ { id: 49, status: 'INCOMPLETE' } ]

So it is ok with updating a field, but not adding a new one? There are so many other places we add new fields, etc. and they all work.

I am using the following redux-storage libraries:

• redux-storage
• redux-storage-decorator-debounce
• redux-storage-engine-reactnativeasyncstorage
• redux-storage-merger-immutablejs
• redux-storage-decorator-filter I use a bunch of white/black listing here, this particular state tree is entirely in the white list.
• redux-storage-decorator-migrate There are not migrations yet it should be noted.

Really stuck on this and could use any insight into how I can further debug the issue!