Brian Vaughn
97e2911508
* Added unsafe_* lifecycles and deprecation warnings If the old lifecycle hooks (componentWillMount, componentWillUpdate, componentWillReceiveProps) are detected, these methods will be called and a deprecation warning will be logged. (In other words, we do not check for both the presence of the old and new lifecycles.) This commit is expected to fail tests. * Ran lifecycle hook codemod over project This should handle the bulk of the updates. I will manually update TypeScript and CoffeeScript tests with another commit. The actual command run with this commit was: jscodeshift --parser=flow -t ../react-codemod/transforms/rename-unsafe-lifecycles.js ./packages/**/src/**/*.js * Manually migrated CoffeeScript and TypeScript tests * Added inline note to createReactClassIntegration-test Explaining why lifecycles hooks have not been renamed in this test. * Udated NativeMethodsMixin with new lifecycle hooks * Added static getDerivedStateFromProps to ReactPartialRenderer Also added a new set of tests focused on server side lifecycle hooks. * Added getDerivedStateFromProps to shallow renderer Also added warnings for several cases involving getDerivedStateFromProps() as well as the deprecated lifecycles. Also added tests for the above. * Dedupe and DEV-only deprecation warning in server renderer * Renamed unsafe_* prefix to UNSAFE_* to be more noticeable * Added getDerivedStateFromProps to ReactFiberClassComponent Also updated class component and lifecyle tests to cover the added functionality. * Warn about UNSAFE_componentWillRecieveProps misspelling * Added tests to createReactClassIntegration for new lifecycles * Added warning for stateless functional components with gDSFP * Added createReactClass test for static gDSFP * Moved lifecycle deprecation warnings behind (disabled) feature flag Updated tests accordingly, by temporarily splitting tests that were specific to this feature-flag into their own, internal tests. This was the only way I knew of to interact with the feature flag without breaking our build/dist tests. * Tidying up * Tweaked warning message wording slightly Replaced 'You may may have returned undefined.' with 'You may have returned undefined.' * Replaced truthy partialState checks with != null * Call getDerivedStateFromProps via .call(null) to prevent type access * Move shallow-renderer didWarn* maps off the instance * Only call getDerivedStateFromProps if props instance has changed * Avoid creating new state object if not necessary * Inject state as a param to callGetDerivedStateFromProps This value will be either workInProgress.memoizedState (for updates) or instance.state (for initialization). * Explicitly warn about uninitialized state before calling getDerivedStateFromProps. And added some new tests for this change. Also: * Improved a couple of falsy null/undefined checks to more explicitly check for null or undefined. * Made some small tweaks to ReactFiberClassComponent WRT when and how it reads instance.state and sets to null. * Improved wording for deprecation lifecycle warnings * Fix state-regression for module-pattern components Also add support for new static getDerivedStateFromProps method
react-call-return
This is an experimental package for multi-pass rendering in React.
Its API is not as stable as that of React, React Native, or React DOM, and does not follow the common versioning scheme.
Use it at your own risk.
No, Really, It Is Unstable
This is an experiment.
We will replace this with a different API in the future.
It can break between patch versions of React.
We also know that it has bugs.
Don't rely on this for anything except experiments.
Even in experiments, make sure to lock the versions so that an update doesn't break your app.
Don't publish third party components relying on this unless you clearly mark them as experimental too.
They will break.
Have fun! Let us know if you find interesting use cases for it.
API
See the test case in src/__tests__/ReactCallReturn.js for an example.
What and Why
The API is not very intuitive right now, but this is a good overview of why it might be useful in some cases. We are very open to better API ideas for this concept.