Don't mutate Connect's setWrappedInstance method

[gpoitch]

Follow up to #733

[timdorr]

I'm still not understanding how <Connect> gets frozen in the first place. redux-freeze is just a middleware operating on the state instance. How does this component get into there?

[gpoitch]

Good question. I agree that felt wrong.
In my case, my routing solution was storing the 'current route component' in the store.
I was able to work around it by just reorganizing things.

Feel free to merge or close. Still a good update for code clarity, and fixes whatever other scenarios others were hitting.

[markerikson]

In my case, my routing solution was storing the 'current route component' in the store.

Ah. Yes, that's not an encouraged pattern at all, per http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-non-serializable .

[larsbs]

But even if it's not an encouraged pattern, it's not forbidden. I stick to this line:

Ultimately, it's your application, and how you implement it is up to you.

So if this PR fixes an edge case that some users are hitting and doesn't break current redux applications neither does affect performance, I don't see why it shouldn't have a go.

[markerikson]

However, we do have the right to focus on core intended use cases, and not necessarily cater to unsupported usage patterns.

[jimbolla]

You shouldn't store references to components in the redux state. That means those components, and everything they keep in scope, are not being dereferenced + garbage collected. Combine that with something like redux devtools that keeps past versions of state alive for a long time, and now you have a huge memory leak. Or in this case, object freeze is trying to then freeze your components. I can't imagine React behaves well if component object as been frozen. (I bet setState would break.)

[larsbs]

However, we do have the right to focus on core intended use cases, and not necessarily cater to unsupported usage patterns.

Sure you do, I just don't see how that applies to this specific PR. I don't see how's this driving the focus away. Anyway, it doesn't apply for me anymore, I just moved my apps to redux-immutable-state-invariant as you suggested in the other thread. I'm just thinking about what I feel is one of the core values of this library, leaving a lot of free space to you to make your decisions.