Update: Released as alpha!

See below. You can now install this asreact-redux@next:

npm install --save react-redux@next

Please test it out!

TL;DR

Rewroteconnect, same basic API plus advanced options/API, all tests pass, roughly 8x faster, more modular/extensible design

Overview

I rewroteconnect into modular pieces because I wanted to be able to extend with custom behavior in my own projects. Now connect is a facade aroundconnectAdvanced, by passing it a compatibleselectorFactory function.

I also was able to greatly improve performance by changing the store subscriptions to execute top-down to work with React's natural flow of updates; component instances lower in the tree always get updated after those above them, avoiding unnecessary re-renders.

Design/Architecture

I split the originalconnect into many functions+files to compartmentalize concepts for better readability and extensibility. The important pieces:

• components/
  • connectAdvanced.js: the HOC that connects to the store and determines when to re-render
  • Provider.js: (hasn't changed)
• selectors/
  • connect.js: composes the other functions into a fully-compatible API, by creating a selectorFactory and options object to pass toconnectAdvanced.
    that performs memoiztion and detects if the first run returns another function, indicating a factory
  • mapDispatchToProps.js: used to create a selector factory from themapDispatchToProps parameter, to be passed toselectorFactory.js asinitMapDispatchToProps. Detects whethermapDispatchToProps is missing, an object, or a function
  • mapStateToProps.js: used to create a selector factory from themapStateToProps parameter, to be passed toselectorFactory.js asinitMapStateToProps. Detects whethermapStateToProps is missing or a function
  • mergeProps.js: used to create a selector factory from themergeProps parameter, to be passed toselectorFactory.js asinitMergeProps. Detects whethermergeProps is missing or a function.
• selectorFactory.js: givendispatch,pure,initMapStateToProps,initMapDispatchToProps, andinitMergeProps, creates aconnectAdvanced-compatible selector

• wrapMapToProps.js: helper functions for wrapping values ofmapStateToProps andmapDispatchToProps in compatible selector factories

• utils/
  • Subscription.js: encapsulates the hierachial subscription concept. used byconnectAdvanced.js to pass a parent's store Subscription to its children via context
  • verifyPlainObject.js: used to show a warning ifmapStateToProps,mapDispatchToProps, ormergeProps returns something other than a plain object

file graph

digraph files {  "connectAdvanced.js" -> "React"  "connectAdvanced.js" -> "Subscription.js"  "connect.js" -> "connectAdvanced.js"  "connect.js" -> "mapDispatchToProps.js"  "connect.js" -> "mapStateToProps.js"  "connect.js" -> "mergeProps.js"  "connect.js" -> "selectorFactory.js"  "mapDispatchToProps.js" -> "wrapMapToProps.js"  "mapStateToProps.js" -> "wrapMapToProps.js"}

The modular structure of all the functions inconnect/ should allow greater reuse for anyone that wants to create their ownconnect variant. For example, one could create a variant that handles whenmapStateToProps is an object by using reselect's createStructuredSelector:

customConnect.js:

importconnectfrom'react-redux/lib/connect/connect'importdefaultMapStateToPropsFactoriesfrom'react-redux/lib/connect/mapStateToProps'functioncreateStatePropsSelectorFromObject(mapStateToProps){constinitSelector=()=>createStructuredSelector(mapStateToProps)initSelector.dependsOnProps=truereturninitSelector}functionwhenStateIsObject(mapStateToProps){return(mapStateToProps&&typeofmapStateToProps==='object')    ?createStatePropsSelectorFromObject(mapStateToProps)    :undefined}}exportdefaultfunctioncustomConnect(mapStateToProps,mapDispatchToProps,mergeProps,options){returnconnect(mapStateToProps,mapDispatchToProps,mergeProps,{    ...options,mapStateToPropsFactories:defaultMapStateFactories.concat(whenStateIsObject)})}

ExampleComponent.js

// ...exportdefaultcustomConnect({thing:thingSelector,thong:thongSelector})(ExampleComponent)

And for scenarios where connect's three-function API is too constrictive, one can directly call, or build a wrapper around,connectAdvanced where they have full control over turningstate +props +dispatch into a props object.

Performance

I'm using amodified version of react-redux-perf to performance test+profile the changes. It's configured to try to fire up to 200 actions per second (but becomes CPU bound), with 301 connected components. There are 2 scenarios being tested:

• NB: a parent component with 300 child components, with no other React components between them.
• WB: the same setup as NB but there's a "Blocker" React component between the parent and children that always returns false forshouldComponentUpdate.

I measured the milliseconds needed to render a frame using thestats.js used by react-redux-perf:

On the conservitive end, the rewrite is about 8x faster under these circumstances, with Firefox even doubling that improvement. Much of the perf gains are attributed to avoiding calls tosetState() after a store update unless a re-render is necessary.

In order to make that work with nested connected components, store subscriptions were changed from "sideways" to top-down; parent components always update before their child components. Connected components detected whether they are nested by looking for an object of typeSubscription in the Reactcontext with the keystoreSubscription. This allowsSubscription objects build into a composite pattern.

After that I've used Chrome and Firefox's profilers to watch for functions that could be optimized. At this point, the most expensive method isshallowEqual, accounting for 4% and 1.5% CPU in Chrome and Firefox, respectively.

connectAdvanced(selectorFactory, options) API

In addition to the changed related to performance, the other key change is an additional API forconnectAdvanced().connectAdvanced is now the base forconnect but is less opinionated about how to combinestate,props, anddispatch. It makes no assumptions about defaults or intermediate memoization of results, and leaves those concerns up to the caller. It does memoize the inbound and outbound props objects. A full signature forconnectAdvanced with itsselectorFactory would look like:

exportdefaultconnectAdvanced(// selectorFactory receives dispatch and lots of metadata as named parameters. Most won't be// useful to a direct caller, but could be useful to a library author wrapping connectAdvanced(dispatch,options)=>(nextState,nextProps)=>({someProp://...anotherProp://...}),// options with their defaults:{getDisplayName:name=>`ConnectAdvanced(${name})`,methodName:'connectAdvanced',renderCountProp:undefined,shouldHandleStateChange:true,storeKey:'store',withRef:false,// you can also add extra options that will be passed through to your selectorFactory:custom1:'hey',fizzbuzz:fizzbuzzFunc})(MyComponent)

A simple usage may look like:

exportdefaultconnectAdvanced(dispatch=>{constbound=bindActionCreators(actionCreators,dispatch)return(store,props)=>({thing:state.things[props.thingId],saveThing:bound.saveThing})})(MyComponent)

An example usingreselect to create a bound actionCreator with a prop partially bound:

exportdefaultconnectAdvanced(dispatch=>{returncreateStructuredSelector({thing:(state,props)=>state.things[props.thingId],saveThing:createSelector((_,props)=>props.thingId,(thingId)=>inputs=>dispatch(actionCreators.saveThing(thingId,inputs)))})})(MyComponent)

An example doing custom memoization with actionCreator with a prop partially bound:

exportdefaultconnectAdvanced(dispatch=>{returncreateStructuredSelector({letthingIdletthingletresultconstsaveThing=inputs=>dispatch(actionCreators.saveThing(thingId,inputs))return(nextState,nextProps)=>{const nextThingId=nextProps.thingIdconstnextThing=nextState.things[nextThingId]if(nextThingId!==thingId||nextThing!==thing){        thingId=nextThingIdthing=nextThingresult={ thing, saveThing}}returnresult}})})(MyComponent)

Note these are meant as examples and not necessarily "best practices."

Pros/cons

I understand there is great risk to accepting such drastic changes, that would have to be justified with significant benefits. I'll reiterate the two main benefits I believe these changes offer:

1. Performance: There's potentially huge perf gains in situations where the number of connected components is high, stemming from conceptual changes to subscriptions so they go with the natural flow of events in React vs across them, as well as method profiling+optimizing using Chrome/FF.
2. Extensibility/Maintainability: By splitting the responibilities of connect into many smaller functions, it should be easier both for react-redux contributors to work with the codebase and end users to extend its functionality though the additional APIs. If users can add their desired features in their own projects, that will reduce the number of feature requests to the core project.

Despite passing all the automated tests as well as week of manual testing, there is risk of impacting users dependent on implicit behavior, or that performance is worse in some unexpected circumstances. To minimize risk of impacting end users and downstream library authors, I think it would be wise to pull these changes into a "next" branch and first release an alpha package. This would give early adopters a chance to test it and provide feedback

Thanks

I'd like to thank the other github users who have so far offered feedback on these changes in#407, especially@markerikson who has gone above and beyond.