Nested connected components with different stores do not update correctly

[everdimension]

This is a bug in v5. In v4 everything works correctly.

I've created a small repo where I reproduce the problem. Demo: https://everdimension.github.io/react-redux-5-composition-bug/build/

Here's the code
Here's the repo

If you install react-redux@4, components are updated correctly.

My guess is that PR #589 might have something to do with the problem but I didn't read it thoroughly.

[timdorr]

This seems like an extreme edge case. You shouldn't be using more than one store in a Redux project, except in small edge cases. And you shouldn't be double-connecting a component either.

While this may be a legitimate bug, it's predicated on multiple anti-patterns that will lead to other scalability problems in your project. I'd suggest rethinking how you're using Redux and if it's applicable to your use case. It's not infallible and there are often better solutions for specific edge case scenarios.

[everdimension]

You should reopen the issue.

By the same logic you can call being able to pass store as a prop an anti-pattern, too, and not support it. But you do, because it's not an extreme edge case. If you support having multiple stores, then it's only natural that one connected component may be rendered somewhere inside another connected component.

As long as passing store as a prop is supported it should work in an expected way.

[naw]

I believe this is a bug, but I agree it's a rare edge case.

In v5, connected components try to piggyback on a subscription further up in the component tree.

In this scenario, your 2nd connected counter is piggybacking on the subscription from the 1st connected counter.

To fix this, we just need to ignore parent subscriptions if the parent subscription is for a different store.

In other words, this line needs to return null/undefined if parentSub.store !== this.store.

This would solve this particular issue, but if you're using propsMode (passing store in as a prop), there are going to be other subtleties you have to watch for regardless of this particular issue.

As a workaround, you could explicitly override the storeSubscription prop that the first connected counter is passing to the second connected counter, so that the 2nd counter doesn't see the first counter's subscription and try to use it incorrectly.