Data: Respect changing props from withDispatch's mapDispatchToProps

[aduth]

Related (alternative to): #11866

This pull request seeks to update withDispatch to resolve an issue where if a different set of keys is returned from mapDispatchToProps, they are not immediately made available to the underlying component.

Implementation notes:

This approach abandons the prior implementation of "proxy props", which were introduced as a means to limit React's reconciliation process, since it's assumed that mapDispatchToProps will always define new function references in its return object. While the previous proxying avoided this behavior, it did so at the expense of needing to iterate keys of the return value of mapDispatchToProps, and of needing to call mapDispatchToProps once more at the time of the actual dispatch to account for any outer-scope variable definitions referenced by the dispatch callback. In fairness, the latter of these is a more minor point, since component dispatches very infrequently relative to rendering updates.

In all, there is likely little practical impact here so far as performance is concerned, but it does fix the previously-broken implication that mapDispatchToProps may return a different result in response to received ownProps. The approach in #11866 improves performance, but makes clear there is no support for changing the return shape of mapDispatchToProps.

Testing instructions:

Ensure tests pass:

npm run test

[youknowriad]

Any concerns about the new props we keep creating with this? (new instances of functions on each call?)

[aduth]

Any concerns about the new props we keep creating with this? (new instances of functions on each call?)

Yep, it's a trade-off between that and iterating to create proxyProps. I think there's a middle-ground option where we use static getDerivedStateFromProps and still defer to a proxied implementation. The proxying in general adds a bit of complexity, and in the end I'm not sure if it's saving us much in the end.

[aduth]

(FYI this is also expanded upon in the original comment)

[youknowriad]

Ultimately, it's your call, you're more aware of the details of these HoC than anyone else. My concern would be for a component like block-list/block where we'd rerender on each subscribe because of the props created on each subscribe, but maybe we don't even hit withDispatch because we don't receive new props?

[aduth]

Closed in favor of #11866.