See the other comments in this thread from Tim and myself about updating React-Redux to use `React.createContext`.

Also, as a side note: we're open to adding a render props-based API at some point in the near future, since there's a number of people who have expressed interest in that.

Something like the Consumer usage, and a way to apply it to arbitrary transformations of state (see the README on that repo for an example), would go a long way towards de-boilerplating a lot of things. The code I deal with has a painful number of connect() calls just for outputting pieces of data from the store.

Mmm... not sure I really see a difference between that and what `connect` does right now. Can you clarify with a specific example?

Compare...

    // with connect
    import { connect } from 'react-redux'
    import { defaultSomething } from 'src/store/ducks/something'

    const Whatever = ({ something }) => <div>{something}</div>;

    export default connect(state => ({
      something: state.something || defaultSomething
    }))(Whatever);

...to...

    // with consumer
    import { identity } from 'ramda';
    import { SomethingConsumer } from 'src/store/consumers'

    const Whatever = () => <div><SomethingConsumer>{identity}</SomethingConsumer></div>;
    export default Whatever;

One more line in the second also goes away if the consumer defaults to an identity function if not given a suitable child.

    // with consumer
    import { SomethingConsumer } from 'src/store/consumers'

    const Whatever = () => <div><SomethingConsumer /></div>;
    export default Whatever;

The boilerplate in the first case also gets much, much worse if you're using Typescript, as type inference gets wobbly at best with HOCs and so for even simple usage you have to also define out your "inner" and "outer" props for each component you want to use connect with.

So... 5 lines of code, vs 4 or 3?

Perhaps it's just that I'm very used to `connect` as the "standard" way of doing things, or that I don't use TS myself, but I'm really not seeing that much of a change in those examples (especially if you're importing pieces from other files that already abstract some aspect of the process).

After we get done with version 6 (update to use new context), we are open to ideas for new API approaches for a v7. If you've got specific suggestions, please either file an issue, or wait for us to open up some discussions and give us your thoughts then.