* warn when returning different hooks on next render
like it says. adds a field to Hook to track effect 'type', and compares when cloning subsequently.
* lint
* review changes
- numbered enum for hook types
- s/hookType/_debugType
- better dce
* cleaner detection location
* redundant comments
* different EffectHook / LayoutEffectHook
* prettier
* top level currentHookType
* nulling currentHookType
need to verify dce still works
* small enhancements
* hook order checks for useContext/useImperative
* prettier
* stray whitespace
* move some bits around
* better errors
* pass tests
* lint, flow
* show a before - after diff
* an error stack in the warning
* lose currentHookMatches, fix a test
* tidy
* clear the mismatch only in dev
* pass flow
* side by side diff
* tweak warning
* pass flow
* dedupe warnings per fiber, nits
* better format
* nit
* fix bad merge, pass flow
* lint
* missing hooktype enum
* merge currentHookType/currentHookNameInDev, fix nits
* lint
* final nits
* Revert "Revert "Disallow reading context during useMemo etc" (#14651)"
This reverts commit 5fce6488ce.
* Revert "Add test coverage for readContext() on the server (#14649)"
This reverts commit fe2ecd276e.
* Revert "Warn about incorrect use of useImperativeHandle() (#14647)"
This reverts commit 8f45a7fdc4.
* Revert "Disallow reading context during useMemo etc (#14648)"
This reverts commit 1fcbd22431.
* Revert "Warn about refs on lazy function components (#14645)"
This reverts commit 2a084f51a9.
* Revert "Fix typo (#14560)"
This reverts commit b5a3df6e88.
* Revert "fix typo (#14316)"
This reverts commit 9c146e6751.
* Revert "Mention forwardRef() in <Fn ref={...} /> errors and warnings (#14644)"
This reverts commit baa6d40fc8.
* Revert "Double-render function components with Hooks in DEV in StrictMode (#14643)"
This reverts commit a1414e8949.
* Revert "Add test coverage for readContext() on the server (#14649)"
This reverts commit fe2ecd276e.
* Revert "Warn about incorrect use of useImperativeHandle() (#14647)"
This reverts commit 8f45a7fdc4.
* Revert "Disallow reading context during useMemo etc (#14648)"
This reverts commit 1fcbd22431.
* Rename context variables
I just spent half an hour debugging why readContext(PurpleContext) doesn't work.
* Add test coverage for readContext() on the server
* Disallow reading context during useMemo etc
* Continue allowing readContext() in classes and context consumers
The previous commit check was too broad and incorrectly restricted classes from calling readContext(). This check is more precise and only targets components that are Hook-capable. It exploits the fact that `renderExpirationTime` is never `NoWork` after `renderWithHooks` -- something we already rely on.
* Double-render functions in strict mode
* Double-invoke first function component render too
* Mark TestRendererAsync test as internal and revert changes to it
TestRenderer is built with strict mode doublerender off.
We could change that but I'm not sure we want to. So I'll just flip the flag off for this test.
* Only double-invoke components using Hooks
* Revert unintentional change
* Fix handling of sync rejection
Reverts #14632 and adds a regression test.
* Handle rejection synchronously too
Fewer footguns and seems like nicer behavior anyway.
Specifying the directory as part of the `repository` field in a `package.json`
allows third party tools to provide better support when working with monorepos.
For example, it allows them to correctly construct a commit diff for a specific
package.
This format was accepted by npm in https://github.com/npm/rfcs/pull/19.
* Warn when mixing createRoot() and old APIs
* Move container checks to entry points
This way further warning check doesn't crash on bad inputs.
* Fix Flow
* Rename flag to be clearer
* managed by -> passed to
* Revert accidental change
* Fix Fire shim to match
* Don't bother comparing constructor when deps are not provided
When no dependencies are passed to an effect hook, what we used to do is
compare the effect constructor. If there was no change, then we would
skip firing the effect. In practice, this is a useless optimization
because the constructor will always be different when you pass an inline
closure. And if you don't pass an inline closure, then you can't access
any props or state.
There are some edge cases where an effect that doesn't close over props
or state could be useful, like reference counting the number of mounted
components. But those are rare and can be addressed by passing an empty
array of dependencies.
By removing this "optimization," we can avoid retaining the constructor
in the majority of cases where it's a closure that changes on
every render.
I made corresponding changes to the other hooks that accept
dependencies, too (useMemo, useCallback, and useImperativeHandle).
* Improve hook dependencies warning
It now includes the name of the hook in the message.
* Nits
* Allow useReducer to bail out of rendering by returning previous state
This is conceptually similar to `shouldComponentUpdate`, except because
there could be multiple useReducer (or useState) Hooks in a single
component, we can only bail out if none of the Hooks produce a new
value. We also can't bail out if any the other types of inputs — state
and context — have changed.
These optimizations rely on the constraint that components are pure
functions of props, state, and context.
In some cases, we can bail out without entering the render phase by
eagerly computing the next state and comparing it to the current one.
This only works if we are absolutely certain that the queue is empty at
the time of the update. In concurrent mode, this is difficult to
determine, because there could be multiple copies of the queue and we
don't know which one is current without doing lots of extra work, which
would defeat the purpose of the optimization. However, in our
implementation, there are at most only two copies of the queue, and if
*both* are empty then we know that the current queue must be.
* Add test for context consumers inside hidden subtree
Should not bail out during subsequent update. (This isn't directly
related to this PR because we should have had this test, anyway.)
* Refactor to use module-level variable instead of effect bit
* Add test combining state bailout and props bailout (memo)
Fixes https://github.com/facebook/react/issues/14583
Using `new Set([iterable])` does not work with IE11's non-compliant Set
implementation. By avoiding this pattern we don't need to require a Set
polyfill for IE11
* react-debug-tools accepts currentDispatcher ref as param
* ReactDebugHooks injected dispatcher ref is optional
* Support custom values for custom hooks
* PR feedback:
1. Renamed useDebugValueLabel hook to useDebugValue
2. Wrapped useDebugValue internals in if-DEV so that it could be removed from production builds.
* PR feedback:
1. Fixed some minor typos
2. Added inline comment explaining the purpose of rollupDebugValues()
3. Refactored rollupDebugValues() to use a for loop rather than filter()
4. Improve check for useDebugValue hook to lessen the chance of a false positive
5. Added optional formatter function param to useDebugValue
* Nitpick renamed a method
I don't think "array or iterator" is adding anything, and it may well be confusing, especially since this is one of the first and most common warnings that devs see.