Completely rewrite connect() to offer advanced API, separate concerns, and (probably) resolve a lot of those pesky edge cases

I rewrote connect() and extracted a connectAdvanced() It now uses reselect to handle merging/caching of the state/props/dispatch. It also extracts out a connectAdvanced() function that connect() just delegates to.

I’m not quite ready to ready to submit a PR (still tweaking), but I’d like to suggest that this eventually become the new implementation.

It passes tests and linting, with the only breaking change to the existing API being related to the “advanced scenarios” for factories that require setting another options flag. (I haven’t figured out how to detect the factory methods automatically… will give it another go, but it’s been tricky given how radically different my approach is.) solved

Things I’m still need to do:

• support factorying map*ToProps functions without an explcit flag
• add more comments
• performance testing. the tests run slightly faster on my machine but we’re talking insignificant amounts (250ms vs 230ms). do performance tests exist for this?
• reconcile with pending pull requests, as there would be zero chance of a successful merge. I’ve already covered the changes and new features in several of them, but some of the others will need reimplemented.
• keep tinkering. there’s some functionality in connect() that I’d like to make reusable for someone who wants extend its functionality in userspace

[jimbolla]

It’s all good. The more scrutiny the better. Believe me, I’m more worried that I missed something than you are. haha.

Current benchmarks using jimbolla/react-redux-perf, all 6 tabs opens at once, 331 connected components each:

Frames per second:

FPS	current	rewrite
Chrome	5	46
Firefox	2	45
IE 11	3	21

Milliseconds to render a frame:

MS	current	rewrite
Chrome	180	20
Firefox	400	23
IE 11	320	40

Same tests, this time with a Blocker component between the parent and children that always returns false for shouldComponentUpdate:

Frames per second:

FPS	current	rewrite
Chrome	5	51
Firefox	2	45
IE 11	3	25

Milliseconds to render a frame:

MS	current	rewrite
Chrome	190	19
Firefox	500	20
IE 11	380	37

Fascinatingly, current did worse with the blocker component, while the rewrite does even better. I think this is because in the rewrite, my current bottleneck is the shallowEqual compare on ownProps. With the Blocker component, the old props === new props and avoids the complicated part of shallowEqual.

[markerikson]

Haven’t had a chance to really dig through the code yet. My main suggestion at this point would be to document this to ridiculous levels:

• Overall motivation and intended benefits
• High-level conceptual overview of the new approach
• Conceptual comparison with the existing approach
• Document any new APIs, their purpose, and their usage
• Walkthrough of the new data flow sequence
• Some kind of dependency tree-ish thing for all the new selector functions
• Benchmarks, benchmarks, benchmarks (numbers, graphs, and actual runnable examples)

I know that’s asking for a good chunk of work, but given that you’re proposing to swap out an entire existing implementation that’s been reasonably battle-tested with a brand-new codebase, the burden of proof is basically on you to fully justify the switch and make sure that it’s sufficiently maintainable in the future.