Tracking down instigators of SAVE #100

New issue

Closed

opened 2016-02-24 10:11:38 +00:00 by guybenron · 4 comments

guybenron commented

2016-02-24 10:11:38 +00:00

(Migrated from github.com)

Love this package! :)

I'm using redux-storage-decorator-filter to restrict the save calls to a specific part of the state. I also just started using redux-sagas, so I put the three EFFECT_* actions into the storage blacklist, and they both work together beautifully.
However, I'm getting an extra REDUX_STORAGE_SAVE action which I have no clue why it's being dispatched, and there is no information I can see to help me figure it out. How do I track down the part of the code that caused the save operation to happen ... ?

Thanks !
-Guy

Love this package! :) I'm using redux-storage-decorator-filter to restrict the save calls to a specific part of the state. I also just started using redux-sagas, so I put the three `EFFECT_*` actions into the storage blacklist, and they both work together beautifully. However, I'm getting an extra `REDUX_STORAGE_SAVE` action which I have no clue why it's being dispatched, and there is no information I can see to help me figure it out. How do I track down the part of the code that caused the save operation to happen ... ? Thanks ! -Guy

michaelcontento commented

2016-02-25 11:45:23 +00:00

(Migrated from github.com)

You're welcome! 😎

It should be pretty easy, as redux-storage simply dispatches a whole new action (or in other words: no special dispatching magic involved!). So the action right before REDUX_STORAGE_SAVE should be the action that has triggerd this save operation.

NOTE: If your using redux-storage-decorator-debounce this relation is no longer valid, as it's the main job of decorator-debounce to delay the save operation 😉

Or is this the way you already tried to tackle it with no success?

You're welcome! :sunglasses: It should be pretty easy, as redux-storage simply dispatches a [whole new action](https://github.com/michaelcontento/redux-storage/blob/master/src/createMiddleware.js#L78-L80) (or in other words: no special dispatching magic involved!). So the action right before `REDUX_STORAGE_SAVE` should be the action that has triggerd this save operation. **NOTE**: If your using [redux-storage-decorator-debounce](https://github.com/michaelcontento/redux-storage-decorator-debounce) this relation is no longer valid, as it's the main job of `decorator-debounce` to delay the save operation :wink: Or is this the way you already tried to tackle it with no success?

guybenron commented

2016-02-25 13:11:23 +00:00

(Migrated from github.com)

Thanks for responding :)

I've tried to track it down like you said, but redux-sagas uses actions very liberally (almost every API call results in two actions) so it makes tracking down the source of the save very confusing. What I can say for sure after following a single flow, is that the save action is dispatched even if the filtered state doesn't change.

I'm also using redux-logger to log all of the actions, but just to make sure I listened in to the redux-sagas actions and JSON.stringified the state to the console. I'm seeing a bunch of EFFECT_TRIGGERED and EFFECT_RESOLVED, but the state does not change :(
The only thing that comes to mind is that maybe the before state and after state, while identical, aren't the same object - immutability etc. But it's really grasping at straws for me at this point...

Any suggestions as to how to further break this down and hunt the errant code?

Thanks for responding :) I've tried to track it down like you said, but redux-sagas uses actions very liberally (almost every API call results in two actions) so it makes tracking down the source of the save very confusing. What I can say for sure after following a single flow, is that the save action is dispatched even if the filtered state doesn't change. I'm also using redux-logger to log all of the actions, but just to make sure I listened in to the redux-sagas actions and JSON.stringified the state to the console. I'm seeing a bunch of `EFFECT_TRIGGERED` and `EFFECT_RESOLVED`, but the state does not change :( The only thing that comes to mind is that maybe the before state and after state, while identical, aren't the same object - immutability etc. But it's really grasping at straws for me at this point... Any suggestions as to how to further break this down and hunt the errant code?

michaelcontento commented

2016-02-25 13:56:32 +00:00

(Migrated from github.com)

@guybenron Would it be possible for you to checkout and use PR #102? This adds meta.origin to the action dispatched by redux-storage (only if NODE_ENV !== 'production').

@guybenron Would it be possible for you to checkout and use PR #102? This adds `meta.origin` to the action dispatched by `redux-storage` (only if `NODE_ENV !== 'production'`).

guybenron commented

2016-03-01 11:46:28 +00:00

(Migrated from github.com)

Looks like it's what I need, however something came up and I won't be able to check it out :(
If and when it becomes relevant again, will definitely look into it...
Again, thank you !!

Looks like it's what I need, however something came up and I won't be able to check it out :( If and when it becomes relevant again, will definitely look into it... Again, thank you !!

This discussion has been locked. Commenting is limited to contributors.