Update connect to make it more extensible

[mhodgson]

I've attempted to refactor connect to provide additional (optional) exports that would allow the user to easily create a custom Connect class. This allows the user to override specific parts of Connect while maintaining all the existing caching and update logic. Here is an example of usage:

import { Connect, createConnect } from 'react-redux/components/connect'

class MyConnect extends Connect {
  handleChange() {
    if (!this.unsubscribe) {
      return
    }

    const prevStoreState = this.state.storeState
    const storeState = this.store.getState()

    if (!this.pure || prevStoreState !== storeState) {
      this.hasStoreStateChanged = true
      return new Promise((resolve) => { this.setState({ storeState }, resolve) })
    }
  }
}

export default createConnect(MyConnect)

In this example I've overridden the handleChange method to return a Promise that resolves when the changes have been flushed to the DOM.

You then just use this custom connect method to decorate your components instead of the default one from react-redux.

All but one of the tests are passing, but I'm interested in getting feedback on this before working on it further.

[gaearon]

Inheritance is generally problematic, and especially so when mixed with a functional paradigm. React components should not create class hierarchies, and even for this use case we don’t want to do that.

To solve #269, I would much prefer to extract the core logic from connect() so it can become a simple wrapper that is easy to write on your own with custom logic.

[mhodgson]

@gaearon thanks for the quick feedback. I'm really interested in getting something that works for this, but it seems you have pretty specific ideas about how it should work. Would you mind giving a little bit more guidance on how you'd like to see this structured? Happy to put the work in to get to something useful. I'm struggling to see how to get a clean API here without inheritance when so many lifecycle methods are involved. We could double wrap the component but that seems even worse to me.

[gaearon]

Something like subscribeComponentToStateChanges(store, callback, mapStateToProps, mapDispatchToProps, mergeProps, options)?

[slorber]

@mhodgson yes i'd also prefer to avoid inheritence but rather use composition / strategy pattern, where the default strategy remains compatible with current behavior.