New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use new Context, forwardRef for 6.x (alternate implementation to #995) #997
Commits on Jul 14, 2018
-
fix connected props derived props generation
This commit fixes reduxjs#965 The essence of the problem is that getDerivedStateFromProps is called when the incoming props OR incoming local state changes. So we cannot store anything in state that is needed in shouldComponentUpdate. This commit splits up the tracking of incoming props, incoming store state changes, and removes getDerivedStateFromProps and the usage of local state to store any information. Instead, local state is used as a flag solely to track whether the incoming store state has changed. Since derived props are needed in shouldComponentUpdate, it is generated there and then compared to the previous version of derived props. If forceUpdate() is called, this bypasses sCU, and so a check in render() compares the props that should have been passed to sCU to those passed to render(). If they are different, it generates them just-in-time. To summarize: 1) shouldComponentUpdate is ONLY used to process changes to incoming props 2) runUpdater (renamed to triggerUpdateOnStoreStateChange) checks to see if the store state has changed, and stores the state, then updates the counter in local state in order to trigger a new sCU call to re-generate derived state. Because of these changes, getDerivedStateFromProps and the polyfill are both removed. All tests pass on my machine, but there is at least 1 side effects to the new design: - Many of the tests pass state unchanged to props, and pass this to child components. With these changes, the two updates are processed separately. Props changes are processed first, and then state changes are processed. I updated the affected tests to show that there are "in-between" states where the state and props are inconsistent and mapStateToProps is called with these changes. If the old behavior is desired, that would require another redesign, I suspect.
-
Commits on Jul 16, 2018
Commits on Aug 11, 2018
Commits on Aug 12, 2018
-
-
-
-
-
-
-
-
-
-
-
Merge pull request #4 from cellog/master
merge new rtl tests and test framework
-
almost fully working 16.4-context-based
passing store in props and hot update are only failing tests
-
-
this allows multiple concurrent react-redux subscriptions in the same component tree, using two root providers. By creating a custom context and passing that to the Provider and to connected components that use it, we get the full benefits of subscriptions with 2 different trees.
Commits on Aug 13, 2018
-
fully working. Implement forwardRef
* remove hot reloading test, this is unnecessary now because Provider handles subscription through React context, and updates store subscription on componentDidUpdate * remove ProviderMock, it is just Provider now, in connect.spec.js * remove ReduxConsumer, Connect is now ReduxConsumer * error out if withRef is passed, users are expected to use forwardRef now * connect now allows passing in forwardRef() elements too through react-is
-
fix linting errors, remove createProvider
* createProvider is no longer necessary, because it is replaced by passing in context provider to Provider and consumer to connected components. Also, nested providers is natively supported in React
-
-
-
-
update incorrect test, and fix updating store in props for Provider
This refactor also lifts the "value" up into state for Provider, which is simpler. The bug was that componentDidUpdate was using nextProps instead of lastProps. Switching the state setting to use this.props was the correct behavior
-
-
-
-