A new feature flag has been added, debugRenderPhaseSideEffectsForStrictMode. When enabled, StrictMode subtrees will also double-invoke lifecycles in the same way as debugRenderPhaseSideEffects.
By default, this flag is enabled for __DEV__ only. Internally we can toggle it with a GK.
This breaks several of our incremental tests which make use of the noop-renderer. Updating the tests to account for the double-rendering in development mode makes them significantly more complicated. The most straight forward fix for this will be to convert them to be run as internal tests only. I believe this is reasonable since we are the only people making use of the noop renderer.
Builds on top of PR #12083 and resolves issue #12044.
Coalesces deprecation warnings until the commit phase. This proposal extends the utility introduced in #12060 to also coalesce deprecation warnings.
New warning format will look like this:
> componentWillMount is deprecated and will be removed in the next major version. Use componentDidMount instead. As a temporary workaround, you can rename to UNSAFE_componentWillMount.
>
> Please update the following components: Foo, Bar
>
> Learn more about this warning here:
> https://fb.me/react-async-component-lifecycle-hooks
* New context API
Introduces a declarative context API that propagates updates even when
shouldComponentUpdate returns false.
* Fuzz tester for context
* Use ReactElement for provider and consumer children
* Unify more branches in createFiberFromElement
* Compare context values using Object.is
Same semantics as PureComponent/shallowEqual.
* Add support for Provider and Consumer to server-side renderer
* Store providers on global stack
Rather than using a linked list stored on the context type. The global
stack can be reset in case of an interruption or error, whereas with the
linked list implementation, you'd need to keep track of every
context type.
* Put new context API behind a feature flag
We'll enable this in www only for now.
* Store nearest provider on context object
* Handle reentrancy in server renderer
Context stack should be per server renderer instance.
* Bailout of consumer updates using bitmask
The context type defines an optional function that compares two context
values, returning a bitfield. A consumer may specify the bits it needs
for rendering. If a provider's context changes, and the consumer's bits
do not intersect with the changed bits, we can skip the consumer.
This is similar to how selectors are used in Redux but fast enough to do
while scanning the tree. The only user code involved is the function
that computes the changed bits. But that's only called once per provider
update, not for every consumer.
* Store current value and changed bits on context object
There are fewer providers than consumers, so better to do this work
at the provider.
* Use maximum of 31 bits for bitmask
This is the largest integer size in V8 on 32-bit systems. Warn in
development if too large a number is used.
* ProviderComponent -> ContextProvider, ConsumerComponent -> ContextConsumer
* Inline Object.is
* Warn if multiple renderers concurrently render the same context provider
Let's see if we can get away with not supporting this for now. If it
turns out that it's needed, we can fall back to backtracking the
fiber return path.
* Nits that came up during review
Added new StrictMode component for enabling async warnings (without enabling async rendering). This component can be used in the future to help with other warnings (eg compilation, Fabric).
Update debugRenderPhaseSideEffects behavior
This feature flag no longer double-invokes componentWillMount, componentWillReceiveProps, componentWillUpdate, or shouldComponentUpdate.
It continues to double-invoke the constructor, render, and setState updater functions as well as the recently added, static getDerivedStateFromProps method
Tests have been updated.
* 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
The TestUtils lost media events when they were pulled out of the
topLevelTypes constant. This commit adds them back by concatenating
the media event keys to the list of top level types.
In absence of a value, radio and checkboxes report a value of
"on". Between 16 and 16.2, we assigned a node's value to it's current
value in order to "dettach" it from defaultValue. This had the
unfortunate side-effect of assigning value="on" to radio and
checkboxes
Related issues:
https://github.com/facebook/react/issues/11998
* Add warning in server renderer if class doesn't extend React.Component
In dev mode, while server rendering, a warning will be thrown if there is a class that doesn't extend React.Component.
* Use `.toWarnDev` matcher and deduplicate warnings
* Deduplicate client-side warning if class doesn't extend React.Component
* Default componentName to Unknown if null
Removes the `useSyncScheduling` option from the HostConfig, since it's
no longer needed. Instead of globally flipping between sync and async,
our strategy will be to opt-in specific trees and subtrees.
* Updated misleading error message in production environment when adding ref to a functional component
* Reverted changes to codes.json
* Updated error message
* Warn about spying on the console
* Added suppress warning flag for spyOn(console)
* Nits
* Removed spy-on-console guard
* Fixed a potential source of false-positives in toWarnDev() matcher
Also updated (most of) ReactIncrementalErrorLogging-test.internal to use the new matcher
* Removed unused third param to spyOn
* Improved clarity of inline comments
* Removed unused normalizeCodeLocInfo() method
* enables ctrl + enter for keypress event on browsers other than firefox
* makes comment more descriptive as to affected platforms
* reverting fiber results
* Reset changes to results.json
* Remove old test file
* Add tests in the right place
* Bump deps to Jest 22
* Prevent jsdom from logging intentionally thrown errors
This relies on our existing special field that we use to mute errors.
Perhaps, it would be better to instead rely on preventDefault() directly.
I outlined a possible strategy here: https://github.com/facebook/react/issues/11098#issuecomment-355032539
* Update snapshots
* Mock out a method called by ReactART that now throws
* Calling .click() no longer works, dispatch event instead
* Fix incorrect SVG element creation in test
* Render SVG elements inside <svg> to avoid extra warnings
* Fix range input test to use numeric value
* Fix creating SVG element in test
* Replace brittle test that relied on jsdom behavior
The test passed in jsdom due to its implementation details.
The original intention was to test the mutation method, but it was removed a while ago.
Following @nhunzaker's suggestion, I moved the tests to ReactDOMInput and adjusted them to not rely on implementation details.
* Add a workaround for the expected extra client-side warning
This is a bit ugly but it's just two places. I think we can live with this.
* Only warn once for mismatches caused by bad attribute casing
We used to warn both about bad casing and about a mismatch.
The mismatch warning was a bit confusing. We didn't know we warned twice because jsdom didn't faithfully emulate SVG.
This changes the behavior to only leave the warning about bad casing if that's what caused the mismatch.
It also adjusts the test to have an expectation that matches the real world behavior.
* Add an expected warning per comment in the same test
* Migrated several additional tests to use new .toWarnDev() matcher
* Migrated ReactDOMComponent-test to use .toWarnDev() matcher
Note this test previous had some hacky logic to verify errors were reported against unique line numbers. Since the new matcher doesn't suppor this, I replaced this check with an equivalent (I think) comparison of unique DOM elements (eg div -> span)
* Updated several additional tests to use the new .toWarnDev() matcher
* Updated many more tests to use .toWarnDev()
* Updated several additional tests to use .toWarnDev() matcher
* Updated ReactElementValidator to distinguish between Array and Object in its warning. Also updated its test to use .toWarnDev() matcher.
* Updated a couple of additional tests
* Removed unused normalizeCodeLocInfo() methods
* Migrated several additional tests to use new .toWarnDev() matcher
* Migrated ReactDOMComponent-test to use .toWarnDev() matcher
Note this test previous had some hacky logic to verify errors were reported against unique line numbers. Since the new matcher doesn't suppor this, I replaced this check with an equivalent (I think) comparison of unique DOM elements (eg div -> span)
* Updated several additional tests to use the new .toWarnDev() matcher
* Updated many more tests to use .toWarnDev()
* Added toWarnInDev matcher and connected to 1 test
* Added .toLowPriorityWarnDev() matcher
* Reply Jest spy with custom spy. Unregister spy after toWarnDev() so unexpected console.error/warn calls will fail tests.
* console warn/error throws immediately in tests by default (if not spied on)
* Pass-thru console message before erroring to make it easier to identify
* More robustly handle unexpected warnings within try/catch
* Error message includes remaining expected warnings in addition to unexpected warning
The BeforeInputPlugin dispatches null elements in an array if
composition or beforeInput events are not extracted. This causes a
an extra array allocation, but more importantly creates null states in
later event dispatch methods that are annoying to account for.
This commit makes it so that BeforeInputPlugin never returns a null
element inside an array.
* Add basic snapshot tests to ReactART components (Circle, Rectangle, Wedge)
* More tests on Circle, Rectangle, Wedge
* linc warning fixes
* - remove tests to Wedge component internal function
* More test on Wedge component, update snapshots
* Call and Return components should use ReactElement
ReactChildFiber contains lots of branches that do the same thing for
different child types. We can unify them by having more child types be
ReactElements. This requires that the `type` and `key` fields are
sufficient to determine the identity of the child.
The main benefit is decreased file size, especially as we add more
component types, like context providers and consumers.
This updates Call and Return components to use ReactElement. Portals are
left alone for now because their identity includes the host instance.
* Move server render invariant for call and return types
* Sort ReactElement type checks by most likely
* Performance timeline should skip over call components
Don't think these were intentionally omitted from the blacklist of
component types.
I went ahead and updated getComponentName to include special types, even
though I don't think they're used anywhere right now.
* Remove surrounding brackets from internal display names
* use different eslint config for es6 and es5
* remove confusing eslint/baseConfig.js & add more eslint setting for es5, es6
* more clear way to run eslint on es5 & es6 file
* seperate ESNext, ES6, ES6 path, and use different lint config
* rename eslint config file & update eslint rules
* Undo yarn.lock changes
* Rename a file
* Remove unnecessary exceptions
* Refactor a little bit
* Refactor and tweak the logic
* Minor issues
* fix#11759. false positive warning in IE11 when using React.Fragment
* simplify createElementWithValidation type check
* fix mistake
* Add an explanation
* We shouldn't use `number` for anything else
* Clarify further
