Skip to content
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.

Date being SAVEd is not fully the same data being LOADed. #171

Open
gijoehosaphat opened this issue Oct 20, 2016 · 6 comments
Open

Date being SAVEd is not fully the same data being LOADed. #171

gijoehosaphat opened this issue Oct 20, 2016 · 6 comments

Comments

@gijoehosaphat
Copy link

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!

@michaelcontento
Copy link
Owner

Sorry for the bad news but this package is no longer maintained. 😞

My focus has left the react / node ecosystem and I don't have to time to keep things up to date. But if you want to step in and become the new maintainer of redux-storage and all of it parts, just ping me! 😃

@michaelcontento
Copy link
Owner

Re-opened as @guns2410 want's to work on this project: Give him a warm welcome 👏

@guns2410
Copy link

guns2410 commented Nov 8, 2016

Thanks @michaelcontento

@gijoehosaphat can you confirm what your redux state looks like when you perform these actions. redux-storage saves your exact redux state as is.

@gijoehosaphat
Copy link
Author

I can confirm that the when inspecting the data on the action 'REDUX_STORAGE_SAVE' the data looks correct.

When inspecting the data on a subsequent load, the data is incorrect.

In the example above we are adding a new field to the object called status_set, that field seemingly gets dropped, however changes to the already existing fields are retained.

This overall state object structure looks like this:

{
  ...,
  mainKey: {
    ...,
    objectMap: {
      '0': {
        typeKey: [
          { id: 49, status: 'COMPLETE' },
          ...
        ],
        ...
      },
      ...
    },
    ...
  },
  ...
}

@guns2410
Copy link

guns2410 commented Nov 9, 2016

can you confirm that the reducer to update the state does not remove the key. May be you can post the reducer here and we can have a look.

@grebenyuksv-preply
Copy link

Looks like I'm having the same issue. I believe we could fix this relatively easy by actually doing a SAVE after LOAD on this line. That still heavily depends on the implementation (we have to make sure that we read useful data from localStorage before we rewrite it with the app's initial state). Another solution I'd suggest is just not SAVEing until we LOAD.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants