This release is brought to you by contributions from the following people: @jimbolla, @vhmth, @btd, @roncohen, @ynonp, and @appden. In addition, there were many non-code contributions in discussions on issues and testing the alpha, beta, and rc versions by many other folks (too many to list!). Thank you to everyone who made this a very positive, inclusive, well-critiqued, community-driven release!
- Backwards compatible API
- Major internal changes
- Significant performance improvements in common usage patterns
- Bugs fixed
- Additional features added to
- What's next?
Version 5.0 maintains API compatibility with v4.x but due to major internal changes and potential behavior differences across nearly all API surfaces, semver dictates a major version bump. Also, it's good marketing!
Internally, the code for
connect has been rewritten from the ground-up to be more modular, with the intention of greater maintainability and extensibility. This has also led to some new features and performance improvements.
Significant performance gains were achieved by avoiding extra calls to
render() by ensuring the order of change notifications to occur top-down, matching React's natural flow. Performance tests and benchmarks are discussed in #416.
Some bugs/issues are resolved, related to performance loss and also impure components not re-rendering.
New features added to connect()
The behavior of
connect() is now more customizable, by passing additional properties in the
options arg. These will be described in the API docs.
New top level API: connectAdvanced()
The new implementation of
connect() splits its behavior such that it is now a wrapper around a more-generalized
connectAdvanced() method can be called directly if you have extreme performance needs or want to craft an API different than that of
connect(). This will be described in the API docs.
We're looking at removing the
shouldComponentUpdate optimization. Since this version is much more performant on its own, that isn't needed. This will fix long-standing problems with other libraries that use React's
context API. There are workarounds, but things should work without either library authors having to bend over backwards or React having to make API changes.
We will accept bugfixes on the 4.x branch (the 3.x branch will be going away; but the tags to 3.x versions will remain!), but new features should be built against the
next branch. We love PRs, so keep them coming!