Mutation of a networkHandler object

[RohovDmytro]

I've decided to apply deep-freeze to my reducers just to be sure I'm not accidentally mutating state. The technique is easy:

import deepFreeze from 'deep-freeze';

const ENV = process.env.NODE_ENV;

export default reducer => {
	return ENV === 'production'
		? reducer
		: (...args) => {
				const state = reducer(...args);
				return deepFreeze(state);
			};
};

But after freezing the queries reducer things stopped working. I believe, the reason is in networkHandler property which is stored in state. super-agent is trying to mutate this object, but failed to do so because of freezing.

Do-not-mutate-the-state is a crucial rule, but... speaking truly, I'm not sure how bad is this in out case. Should we fix this? Will we gain in performance? Is this an actual bug?

[ryanashcraft]

@rogovdm Yes we definitely cheat this rule. :P

It's definitely something that I've thought about. While I think this rule is critical for normal redux state, I'm not convinced it matters much for networkHandler (previously request). I could be wrong. Really don't think it would have any performance implications or cause any real-world bugs with normal usage.

That said, I would be OK with a new option that triggers redux-query not to store the networkHandler in the queries reducer. We'd just need to change cancellation/reset to get the networkHandler from some other location.