* Add a failing test for legacy Suspense blocking context updates in memo
* Add more test case coverage for variations of #17356
* Don't bailout after Suspending in Legacy Mode
Co-authored-by: Tharuka Devendra <tsdevendra1@gmail.com>
* Add new test cli
* Remove --variant accidentally added to test-persist
* s/test/tests
* Updates from review
* Update package.json tests
* Missed a release channel in circle.yaml
* Update config.yml to use just run: with test commands
* Update release-channel options and add build dir checks
* Update test args to use the new release-channel options
* Fix error in circle config.yml
* Fix a wrong condition for the --variant check
* Fix a wrong condition for the --persistent check
* Prettier
* Require build check for devtool tests as well
* Re-enabled DebugTracing feature for old reconciler fork
It was temporarily removed by @sebmarkbage via PR #18697. Newly re-added tracing is simplified, since the lane(s) data type does not require the (lossy) conversion between priority and expiration time values.
@sebmarkbage mentioned that he removed this because it might get in the way of his planned discrete/sync refactor. I'm not sure if that concern still applies, but just in case- I have only re-added it to the old reconciler fork for now.
* Force Code Sandbox CI to re-run
DevTools has a feature to force a Suspense boundary to show a fallback.
This feature causes us to skip the first render pass (where we render
the primary children) and go straight to rendering the fallback.
There's a Legacy Mode-only codepath that failed to take this scenario
into account, instead assuming that whenever a fallback is being
rendered, it was preceded by an attempt to render the primary children.
SuspenseList can also cause us to skip the first pass, but the relevant
branch is Legacy Mode-only, and SuspenseList is not supported in
Legacy Mode.
Fixes a test that I had temporarily disabled when upstreaming the Lanes
implementation in #19108.
It was temporarily removed by @sebmarkbage via PR #18697. Newly re-added tracing is simplified, since the lane(s) data type does not require the (lossy) conversion between priority and expiration time values.
@sebmarkbage mentioned that he removed this because it might get in the way of his planned discrete/sync refactor. I'm not sure if that concern still applies, but just in case- I have only re-added it to the old reconciler fork for now.
* Add autofix to cross-fork lint rule
* replace-fork: Replaces old fork contents with new
For each file in the new fork, copies the contents into the
corresponding file of the old fork, replacing what was already there.
In contrast to merge-fork, which performs a three-way merge.
* Replace old fork contents with new fork
First I ran `yarn replace-fork`.
Then I ran `yarn lint` with autofix enabled. There's currently no way to
do that from the command line (we should fix that), so I had to edit the
lint script file.
* Manual fix-ups
Removes dead branches, removes prefixes from internal fields. Stuff
like that.
* Fix DevTools tests
DevTools tests only run against the old fork, which is why I didn't
catch these earlier.
There is one test that is still failing. I'm fairly certain it's related
to the layout of the Suspense fiber: we no longer conditionally wrap the
primary children. They are always wrapped in an extra fiber.
Since this has been running in www for weeks without major issues, I'll
defer fixing the remaining test to a follow up.
* Failing test: Infinite loop in beforeblur event
If the focused node is hidden by a Suspense boundary, we fire the
beforeblur event. Our check for whether a tree is being hidden isn't
specific enough. It should only fire when the tree is initially hidden,
but it's being fired for updates, too.
* Only fire beforeblur on visible -> hidden
Should only beforeblur fire if the node was previously visible. Not
during updates to an already hidden tree.
To optimize this, we should use a dedicated effect tag and mark it in
the render phase. I've left this for a follow-up, though. Maybe can
revisit after the planned refactor of the commit phase.
* Move logic to commit phase
isFiberSuspenseAndTimedOut is used elsewhere, so I inlined the commit
logic into the commit phase itself.
We need this so we can version them separately and use different
feature flags than we use for OSS RN.
I put them in a separate facebook-react-native folder which won't go
into the RN GH repo. I plan on moving the renderers there too but not yet.
This commit adds a new tab to the Settings modal: Debugging
This new tab has the append component stacks feature and a new one: break on warn
This new feature adds a debugger statement into the console override
This was originally added so you could use "break on caught exceptions"
but that feature is pretty useless these days since it's used for feature
detection and Suspense.
The better pattern is to use the stack trace, jump to source and set a
break point here.
Since DevTools injects its own console.error, we could inject a "debugger"
statement in there. Conditionally. E.g. React DevTools could have a flag
to toggle "break on warnings".
I accidentally committed this since I had it on locally so I didn't have
to manually convert things to const.
However, this causes things to always pass lint since CI also runs this.
I don't think we'll ever use this just because we have such a unique set up
for network delivery so we'll use something custom for this case.
Also, we don't need a profiling build for this since it doesn't have an
entry point.
* Lint bundles using the bundle config instead of scanning for files
This ensures that we look for all the files that we expect to see there.
If something doesn't get built we wouldn't detect it.
However, this doesn't find files that aren't part of our builds such as
indirection files in the root. This will need to change with ESM anyway
since indirection files doesn't work. Everything should be built anyway.
This ensures that we can use the bundles.js config to determine special
cases instead of relying on file system conventions.
* Run lint with flag
We really needed this for Flight before as well but we got away with it
because Blocks were lazy but with the removal of Blocks, we'll need this
to ensure that we can lazily stream in part of the content.
Luckily LazyComponent isn't really just a Component. It's just a generic
type that can resolve into anything kind of like a Promise.
So we can use that to resolve elements just like we can components.
This allows keys and props to become lazy as well.
To accomplish this, we suspend during reconciliation. This causes us to
not be able to render siblings because we don't know if the keys will
reconcile. For initial render we could probably special case this and
just render a lazy component fiber.
Throwing in reconciliation didn't work correctly with direct nested
siblings of a Suspense boundary before but it does now so it depends
on new reconciler.
* Gate test
* Delete entrypoints without Build Outputs from package.json and build output
If an entry point exists in bundles.js but doesn't have any bundleTypes,
I delete that entry point file from the build directory. I also remove it
from the files field in package.json if it exists.
This allows us to remove bundles from being built in the stable release
channel.
We currently prepare an extra stack frame before they're needed.
Particularly for propTypes. This causes problems as they can have
side-effects with the new component stacks and it's slow.
This moves it to be lazy.
* Bug: Spawning hydration in response to Idle update
Adds a test that fails in the new fork.
* Fix typos related to Idle priority
These are just silly mistakes that weren't caught by any of our tests.
There's a lot of duplication in the Lanes module right now. It's also
not super stable as we continue to refine our heuristics. Hopefully the
final state is simpler and less prone to these types of mistakes.
Facebook currently relies on being able to hydrate hidden HTML. So
skipping those trees is a regression.
We don't have a proper solution for this in the new API yet. So I'm
reverting it to match the old behavior.
Now the server renderer will treat LegacyHidden the same as a fragment,
with no other special behavior. We can only get away with this because
we assume that every instance of LegacyHidden is accompanied by a host
component wrapper. In the hidden mode, the host component is given a
`hidden` attribute, which ensures that the initial HTML is not visible.
To support the use of LegacyHidden as a true fragment, without an extra
DOM node, we will have to hide the initial HTML in some other way.
* Warn if MutableSource snapshot is a function
useMutableSource does not properly support snapshots that are functions. In part this is because of how it is implemented internally (the function gets mistaken for a state updater function). To fix this we could just wrap another function around the returned snapshot, but this pattern seems problematic to begin with- because the function that gets returned might itself close over mutable values, which would defeat the purpose of using the hook in the first place.
This PR proposes adding a new DEV warning if the snapshot returned is a function. It does not change the behavior (meaning that a function could still work in some cases- but at least the current behavior prevents passing around a closure that may later become stale unless you're really intentional about it e.g. () => () => {...}).
* Replaced .warn with .error
* useMutableSource hydration support
* Remove unnecessary ReactMutableSource fork
* Replaced root.registerMutableSourceForHydration() with mutableSources option
* Response to PR feedback:
1. Moved mutableSources root option to hydrationOptions object
2. Only initialize root mutableSourceEagerHydrationData if supportsHydration config is true
3. Lazily initialize mutableSourceEagerHydrationData on root object
This is a bit gross but I need to be able to access it without importing
the renderer.
There might be a better way but I need this to unblock internal bugfix.
Deferring a hidden tree is only supported in Concurrent Mode.
The missing check leads to an infinite loop when an update is scheduled
inside a hidden tree, because the pending work never gets reset.
This "accidentally" worked in the old reconciler because the heurstic
we used to detect offscreen trees was if `childExpirationTime`
was `Never`.
In the new reconciler, we check the tag instead. Which means we also
need to check the mode, like we do in the begin phase.
We should move this check out of the hot path. It shouldn't have been
in the hot path of the old reconciler, either.
Probably by moving `resetChildLanes` into the switch statement
in ReactFiberCompleteWork.
Need this to unblock www. Not sure yet how we'll support this properly
long term.
While adding this, I noticed that the normal "hidden" mode of
LegacyHidden doesn't work properly because it doesn't toggle the
visibility of newly inserted nodes. This is fine for now since we only
use it via a userspace abstraction that wraps the children in an
additional node. But implementing this correctly is required for us
to start using it like a fragment, without the wrapper node.
This package is missing the license attribute (or a license file).
Being a sub-package of React, it should get the same license, however, none was specified.
A scan with `license_checker` would recognize this as `UNKNOWN`.
* skip reading element for imported data
* rename nodes & enable store lookup for components tab
* replace names
* Added some more test coverage; reverted rename
Co-authored-by: Brian Vaughn <bvaughn@fb.com>
The function you provide will only be passed a child and an index. It will not be passed a key. This is confirmed in the source, the Flow types, and the jsdoc comments.
* Add LegacyHidden to server renderer
When the tree is hidden, the server renderer renders nothing. The
contents will be completely client rendered.
When the tree is visible it acts like a fragment.
The future streaming server renderer may want to pre-render these trees
and send them down in chunks, as with Suspense boundaries.
* Force client render, even at Offscreen pri
The motivation for doing this is to make it impossible for additional
uses of pre-rendering to sneak into www without going through the
LegacyHidden abstraction. Since this feature was already disabled in
the new fork, this brings the two closer to parity.
The LegacyHidden abstraction itself still needs to opt into
pre-rendering somehow, so rather than totally disabling the feature, I
updated the `hidden` prop check to be obnoxiously specific. Before, you
could set it to any truthy value; now, you must set it to the string
"unstable-do-not-use-legacy-hidden".
The node will still be hidden in the DOM, since any truthy value will
cause the browser to apply a style of `display: none`.
I will have to update the LegacyHidden component in www to use the
obnoxious string prop. This doesn't block merge, though, since the
behavior is gated by a dynamic flag. I will update the component before
I enable the flag.
* Failing useMutableSource test
If a source is mutated after initial read but before subscription is set
up, it should still entangle all pending mutations even if snapshot of
new subscription happens to match.
Test case illustrates how not doing this can lead to tearing.
* Fix useMutableSource tearing bug
Fix is to move the entanglement call outside of the block that checks
if the snapshot has changed.
* useMutableSource: "Entangle" instead of expiring
A lane is said to be entangled with another when it's not allowed to
render in a batch that does not also include the other lane.
This commit implements entanglement for `useMutableSource`. If a source
is mutated in between when it's read in the render phase, but before
it's subscribed to in the commit phase, we must account for whether the
same source has pending mutations elsewhere. The old subscriptions must
not be allowed to re-render without also including the new subscription
(and vice versa), to prevent tearing.
In the old reconciler, we did this by synchronously flushing all the
pending subscription updates. This works, but isn't ideal. The new
reconciler can entangle the updates without de-opting to sync.
In the future, we plan to use this same mechanism for other features,
like skipping over intermediate useTransition states.
* Use clz instead of ctrz to pick an arbitrary lane
Should be slightly faster since most engines have built-in support.
* [eslint-plugin-react-hooks] reproduce bug with a test and fix it (#18902)
Since we only reserve `-Effect` suffix, react-hooks/exhaustive-deps is
expected to succeed without warning on a custom hook which contains -Effect- in
the middle of it's name (but does NOT contain it as a suffix).
* [eslint-plugin-react-hooks] reproduced bug with a test and fix it
Since we only reserve `-Effect` suffix, react-hooks/exhaustive-deps is expected
to succeed without warning on a render helper which contains -use- in the middle
of it's name (but does NOT contain it as a prefix, since that would violate hook
naming convetion).
Co-authored-by: Boris Sergeyev <boris.sergeyev@quolab.com>
* First pass at scaffolding out the Node implementation of react-data.
While incomplete, this patch contains some changes to the react-data
package in order to start adding support for Node.
The first part of this change accounts for splitting react-data/fetch
into two discrete entries, adding (and defaulting to) the Node
implementation.
The second part is sketching out a rough approximation of `fetch` for
Node. This implementation is not complete by any means, but provides a
starting point.
* Remove NodeFetch module and put it directly into ReactDataFetchNode.
* Replaced react-data with react-fetch.
This patch shuffles around some of the scaffolding that was in
react-data in favor of react-fetch. It also removes the additional
"fetch" package in favor of something flatter.
* Tweak package organization
* Simplify and add a test
Co-authored-by: Dan Abramov <dan.abramov@me.com>
* Expose LegacyHidden type
I will use this internally at Facebook to migrate away from
<div hidden />. The end goal is to migrate to the Offscreen type, but
that has different semantics. This is an incremental step.
* Disable <div hidden /> API in new fork
Migrates to the unstable_LegacyHidden type instead. The old fork does
not support the new component type, so I updated the tests to use an
indirection that picks the correct API. I will remove this once the
LegacyHidden (and/or Offscreen) type has landed in both implementations.
* Add gated warning for `<div hidden />` API
Only exists so we can detect callers in www and migrate them to the new
API. Should not visible to anyone outside React Core team.
* Start MVP for showing inspected element key
* Add key in other places
* Add key from backend
* Remove unnecessary hydrateHelper call
* Hide copy button when no label
* Move above props
* Revert changes to InspectedElementTree.js
* Move key to left of component name
* Updated CSS
Co-authored-by: Brian Vaughn <brian.david.vaughn@gmail.com>
* Detect and prevent render starvation, per lane
If an update is CPU-bound for longer than expected according to its
priority, we assume it's being starved by other work on the main thread.
To detect this, we keep track of the elapsed time using a fixed-size
array where each slot corresponds to a lane. What we actually store is
the event time when the lane first became CPU-bound.
Then, when receiving a new update or yielding to the main thread, we
check how long each lane has been pending. If the time exceeds a
threshold constant corresponding to its priority, we mark it as expired
to force it to synchronously finish.
We don't want to mistake time elapsed while an update is IO-bound
(waiting for data to resolve) for time when it is CPU-bound. So when a
lane suspends, we clear its associated event time from the array. When
it receives a signal to try again, either a ping or an update, we assign
a new event time to restart the clock.
* Store as expiration time, not start time
I originally stored the start time because I thought I could use this
in the future to also measure Suspense timeouts. (Event times are
currently stored on each update object for this purpose.) But that
won't work because in the case of expiration times, we reset the clock
whenever the update becomes IO-bound. So to replace the per-update
field, I'm going to have to track those on the room separately from
expiration times.
There is a worry that `useOpaqueIdentifier` might run out of unique IDs if running for long enough. This PR moves the unique ID counter so it's generated per server renderer object instead. For people who render different subtrees, this PR adds a prefix option to `renderToString`, `renderToStaticMarkup`, `renderToNodeStream`, and `renderToStaticNodeStream` so identifiers can be differentiated for each individual subtree.
* Disable Profiler commit filtering
We used to filter "empty" DevTools commits, but it was error prone (see #18798). A commit may appear to be empty (no actual durations) because of component filters, but filtering these empty commits causes interaction commit indices to be off by N. This not only corrupts the resulting data, but also potentially causes runtime errors.
For that matter, hiding "empty" commits might cause confusion too. A commit *did happen* even if none of the components the Profiler is showing were involved.
* Restart flaky CI
In the new reconciler, I made a change to how render phase updates
work. (By render phase updates, I mean when a component updates
another component during its render phase. Or when a class component
updates itself during the render phase. It does not include when
a hook updates its own component during the render phase. Those have
their own semantics. So really I mean anything triggers the "`setState`
in render" warning.)
The old behavior is to give the update the same "thread" (expiration
time) as whatever is currently rendering. So if you call `setState` on a
component that happens later in the same render, it will flush during
that render. Ideally, we want to remove the special case and treat them
as if they came from an interleaved event.
Regardless, this pattern is not officially supported. This behavior is
only a fallback. The flag only exists until we can roll out the
`setState` warnning, since existing code might accidentally rely on the
current behavior.
* Don't attempt to render the children of a dehydrated Suspense boundary
The DehydratedFragment tag doesn't exist so doing so throws.
This can happen if we schedule childExpirationTime on the boundary and
bail out.
* Warn if scheduling work on a component before it is committed
* [Blocks Fixture] Add a tiny router
* Add a way to load nested entrypoint
* Only expose URL params to nested routers
* Add keys to route definitions
* [Blocks Fixture] Drop the Blocks
Adds several new experimental APIs to aid with automated testing.
Each of the methods below accepts an array of "selectors" that identifies a path (or paths) through a React tree. There are four basic selector types:
* Component: Matches Fibers with the specified React component type
* Role: Matches Host Instances matching the (explicit or implicit) accessibility role.
* Test name: Matches Host Instances with a data-testname attribute.
* Text: Matches Host Instances that directly contain the specified text.
* There is also a special lookahead selector type that enables further matching within a path (without actually including the path in the result). This selector type was inspired by the :has() CSS pseudo-class. It enables e.g. matching a <section> that contained a specific header text, then finding a like button within that <section>.
API
* findAllNodes(): Finds all Host Instances (e.g. HTMLElement) within a host subtree that match the specified selector criteria.
* getFindAllNodesFailureDescription(): Returns an error string describing the matched and unmatched portions of the selector query.
* findBoundingRects(): For all React components within a host subtree that match the specified selector criteria, return a set of bounding boxes that covers the bounds of the nearest (shallowed) Host Instances within those trees.
* observeVisibleRects(): For all React components within a host subtree that match the specified selector criteria, observe if it’s bounding rect is visible in the viewport and is not occluded.
* focusWithin(): For all React components within a host subtree that match the specified selector criteria, set focus within the first focusable Host Instance (as if you started before this component in the tree and moved focus forwards one step).
We've been shipping unprefixed experimental APIs (like `createRoot` and
`useTransition`) to the Experimental release channel, with the rationale
that because these APIs do not appear in any stable release, we're free
to change or remove them later without breaking any downstream projects.
What we didn't consider is that downstream projects might be tempted to
use feature detection:
```js
const useTransition = React.useTransition || fallbackUseTransition;
```
This pattern assumes that the version of `useTransition` that exists in
the Experimental channel today has the same API contract as the final
`useTransition` API that we'll eventually ship to stable.
To discourage feature detection, I've added an `unstable_` prefix to
all of our unstable APIs.
The Facebook builds still have the unprefixed APIs, though. We will
continue to support those; if we make any breaking changes, we'll
migrate the internal callers like we usually do. To make testing easier,
I added the `unstable_`-prefixed APIs to the www builds, too. That way
our tests can always use the prefixed ones without gating on the
release channel.
* Rename Flight to Transport
Flight is still the codename for the implementation details (like Fiber).
However, now the public package is react-transport-... which is only
intended to be used directly by integrators.
* Rename names
See PR #18796 for more information.
All of the changes I've made in this commit are behind the
`enableNewReconciler` flag. Merging this to master will not affect the
open source builds or the build that we ship to Facebook.
The only build that is affected is the `ReactDOMForked` build, which is
deployed to Facebook **behind an experimental flag (currently disabled
for all users)**. We will use this flag to gradually roll out the new
reconciler, and quickly roll it back if we find any problems.
Because we have those protections in place, what I'm aiming for with
this initial PR is the **smallest possible atomic change that lands
cleanly and doesn't rely on too many hacks**. The goal has not been to
get every single test or feature passing, and it definitely is not to
implement all the features that we intend to build on top of the new
model. When possible, I have chosen to preserve existing semantics and
defer changes to follow-up steps. (Listed in the section below.)
(I did not end up having to disable any tests, although if I had, that
should not have necessarily been a merge blocker.)
For example, even though one of the primary goals of this project is to
improve our model for parallel Suspense transitions, in this initial
implementation, I have chosen to keep the same core heuristics for
sequencing and flushing that existed in the ExpirationTimes model: low
priority updates cannot finish without also finishing high priority
ones.
Despite all these precautions, **because the scope of this refactor is
inherently large, I do expect we will find regressions.** The flip side
is that I also expect the new model to improve the stability of the
codebase and make it easier to fix bugs when they arise.
* Add test cases for support exhaustive deps ending in Effect
* Apply the exhaustive deps lint rule to any hook ending with Effect
* Add another test for supporting linting useXEffect hooks
Co-authored-by: Aaron Pettengill <aaron.pettengill@echoman.com>
Previously, we transformed
```
let Foo = styled.div``;
```
to
```
let Foo = _c1 = styled.div``;
```
and then babel-plugin-styled-components would infer `_c1` as the display name. Widen the existing case that applies to function expressions to apply to any type of variable declaration.
* Unhide Suspense trees without entanglement
When a Suspense boundary is in its fallback state, you cannot switch
back to the main content without also finishing any updates inside the
tree that might have been skipped. That would be a form of tearing.
Before we fixed this in #18411, the way this bug manifested was that a
boundary was suspended by an update that originated from a child
component (as opposed to props from a parent). While the fallback was
showing, it received another update, this time at high priority. React
would render the high priority update without also including the
original update. That would cause the fallback to switch back to the
main content, since the update that caused the tree to suspend was no
longer part of the render. But then, React would immediately try to
render the original update, which would again suspend and show the
fallback, leading to a momentary flicker in the UI.
The approach added in #18411 is, when receiving a high priority update
to a Suspense tree that's in its fallback state is to bail out, keep
showing the fallback and finish the update in the rest of the tree.
After that commits, render again at the original priority. Because low
priority expiration times are inclusive of higher priority expiration
times, this ensures that all the updates are committed together.
The new approach in this commit is to turn `renderExpirationTime` into a
context-like value that lives on the stack. Then, when unhiding the
Suspense boundary, we can push a new `renderExpirationTime` that is
inclusive of both the high pri update and the original update that
suspended. Then the boundary can be unblocked in a single render pass.
An advantage of the old approach is that by deferring the work of
unhiding, there's less work to do in the high priority update.
The key advantage of the new approach is that it solves the consistency
problem without having to entangle the entire root.
* Create internal LegacyHidden type
This only exists so we can clean up the internal implementation of
`<div hidden={isHidden} />`, which is not a stable feature. The goal
is to move everything to the new Offscreen type instead. However,
Offscreen has different semantics, so before we can remove the legacy
API, we have to migrate our internal usage at Facebook. So we'll need
to maintain both temporarily.
In this initial commit, I've only added the type. It's not used
anywhere. The next step is to use it to implement `hidden`.
* Use LegacyHidden to implement old hidden API
If a host component receives a `hidden` prop, we wrap its children in
an Offscreen fiber. This is similar to what we do for Suspense children.
The LegacyHidden type happens to share the same implementation as the
new Offscreen type, for now, but using separate types allows us to fork
the behavior later when we implement our planned changes to the
Offscreen API.
There are two subtle semantic changes here. One is that the children of
the host component will have their visibility toggled using the same
mechanism we use for Offscreen and Suspense: find the nearest host node
children and give them a style of `display: none`. We didn't used to do
this in the old API, because the `hidden` DOM attribute on the parent
already hides them. So with this change, we're actually "overhiding" the
children. I considered addressing this, but I figure I'll leave it as-is
in case we want to expose the LegacyHidden component type temporarily
to ease migration of Facebook's internal callers to the Offscreen type.
The other subtle semantic change is that, because of the extra fiber
that wraps around the children, this pattern will cause the children
to lose state:
```js
return isHidden ? <div hidden={true} /> : <div />;
```
The reason is that I didn't want to wrap every single host component
in an extra fiber. So I only wrap them if a `hidden` prop exists. In
the above example, that means the children are conditionally wrapped
in an extra fiber, so they don't line up during reconciliation, so
they get remounted every time `isHidden` changes.
The fix is to rewrite to:
```js
return <div hidden={isHidden} />;
```
I don't anticipate this will be a problem at Facebook, especially since
we're only supposed to use `hidden` via a userspace wrapper component.
(And since the bad pattern isn't very React-y, anyway.)
Again, the eventual goal is to delete this completely and replace it
with Offscreen.
* [Blocks] Use native fetch
* Use the prototype
* Support arrayBuffer() and blob()
* ctor
* Simplify
* Use an expando
* Keep a map of formats
* Unused
* Remove unnecessary second property read
* Keep it simple
* Store the original thenable
* Rename ReactCache -> ReactCacheOld
We still use it in some tests so I'm going to leave it for now. I'll start making the new one in parallel in the react package.
* Add react/unstable-cache entry point
* Add react-data entry point
* Initial implementation of cache and data/fetch
* Address review
* Root API should clear non-empty roots before mounting
Legacy render-into-subtree API removes children from a container before rendering into it. The root API did not do this previously, but just left the children around in the document.
This commit adds a new FiberRoot flag to clear a container's contents before mounting. This is done during the commit phase, to avoid multiple, observable mutations.
SuspenseList progressively renders items even if the list is CPU bound,
i.e. it isn't waiting for missing data. It does this by showing a
fallback for the remaining items, committing the items in that have
already finished, then starting a new render to continue working on
the rest.
When it schedules that subsequent render, it uses a slightly lower
priority than the current render: `renderExpirationTime - 1`.
This commit changes it to reschedule at `renderExpirationTime` instead.
I don't know what the original motivation was for bumping the expiration
time slightly lower. The comment says that the priorities of the two
renders are the same (which makes sense to me) so I imagine it was
motivated by some implementation detail. I don't think it's necessary
anymore, though perhaps it was when it was originally written. If it is
still necessary, we should write a test case that illustrates why.
Changes the internal fiber structure of the Suspense component. When a
Suspense boundary can't finish rendering and switches to a fallback, we
wrap the "primary" tree in a Fragment fiber and hide all its DOM nodes.
Then we mount the fallback tree into a separate Fragment fiber. Both
trees will render into the same parent DOM node (since React fragments
aren't part of the host tree), but the wrappers ensure that the children
in each tree are reconciled separately.
The old implementation would try to be clever and only add the fragment
wrapper when the fallback was in place, to save memory. This "worked"
but was prone to regressions, since this is the only such place in the
codebase where we wrap existing nodes in a new node. (In other words,
it's a form of reparenting, which we don't implement elsewhere).
Since the original implementation, we've also added lots of additional
requirements to the Suspense component that have led to an explosion in
complexity, like limited support in Legacy Mode (with very different
semantics) and progressive hydration.
We're planning to add even more features to the Suspense boundary, so
we're going to sacrifice a bit more memory for a simpler implementation
that is less prone to regressions.
This ended up removing a lot of weird hacks and edge cases, but there
are still plenty left over. Most of the remaining complexity is related
to Legacy mode. That's the next thing we should aim to drop support for.
Because this is a risky change, I've only changed this in the new
reconciler. It blocks some other features, but as of now we're not
planning to implement those in the old reconciler. If that changes, this
should cherry-pick to the other implementation without much effort.
* Add LanePriority type
React's internal scheduler has more priority levels than the external
Scheduler package. Let's use React as the source of truth for tracking
the priority of updates so we have more control. We'll still fall back
to Scheduler in the default case. In the future, we should consider
removing `runWithPriority` from Scheduler and replacing the valid use
cases with React-specific APIs.
This commit adds a new type, called a LanePriority to disambiguate from
the Scheduler one.
("Lane" refers to another type that I'm planning. It roughly translates
to "thread." Each lane will have a priority associated with it.)
I'm not actually using the lane anywhere, yet. Only setting stuff up.
* Remove expiration times train model
In the old reconciler, expiration times are computed by applying an
offset to the current system time. This has the effect of increasing
the priority of updates as time progresses. Because we also use
expiration times as a kind of "thread" identifier, it turns out this
is quite limiting because we can only flush work sequentially along
the timeline.
The new model will use a bitmask to represent parallel threads that
can be worked on in any combination and in any order.
In this commit, expiration times and the linear timeline are still in
place, but they are no longer based on a timestamp. Effectively, they
are constants based on their priority level.
* Stop using ExpirationTime to represent timestamps
Follow up to the previous commit. This converts the remaining places
where we were using the ExpirationTime type to represent a timestamp,
like Suspense timeouts.
* Fork Dependencies and PendingInteractionMap types
These contain expiration times
* Make ExpirationTime an opaque type
ExpirationTime is currently just an alias for the `number` type, for a
few reasons. One is that it predates Flow's opaque type feature. Another
is that making it opaque means we have to move all our comparisons and
number math to the ExpirationTime module, and use utility functions
everywhere else.
However, this is actually what we want in the new system, because the
Lanes type that will replace ExpirationTime is a bitmask with a
particular layout, and performing operations on it will involve more
than just number comparisions and artihmetic. I don't want this logic to
spread ad hoc around the whole codebase.
The utility functions get inlined by Closure so it doesn't matter
performance-wise.
I automated most of the changes with JSCodeshift, with only a few manual
tweaks to stuff like imports. My goal was to port the logic exactly to
prevent subtle mistakes, without trying to simplify anything in the
process. I'll likely need to audit many of these sites again when I
replace them with the new type, though, especially the ones
in ReactFiberRoot.
I added the codemods I used to the `scripts` directory. I won't merge
these to master. I'll remove them in a subsequent commit. I'm only
committing them here so they show up in the PR for future reference.
I had a lot of trouble getting Flow to pass. Somehow it was not
inferring the correct type of the constants exported from the
ExpirationTime module, despite being annotated correctly.
I tried converting them them to constructor functions — `NoWork`
becomes `NoWork()` — and that made it work. I used that to unblock me,
and fixed all the other type errors. Once there were no more type
errors, I tried converting the constructors back to constants. Started
getting errors again.
Then I added a type constraint everywhere a constant was referenced.
That fixed it. I also figured out that you only have to add a constraint
when the constant is passed to another function, even if the function is
annotated. So this indicates to me that it's probably a Flow bug. I'll
file an issue with Flow.
* Delete temporary codemods used in previous commit
I only added these to the previous commit so that I can easily run it
again when rebasing. When the stack is squashed, it will be as if they
never existed.
This could be used to do custom formatting of the stack trace in a way
that isn't compatible with how we use it. So we disable it while we use
it.
In theory we could call this ourselves with the result of our stack.
It would be a lot of extra production code though. My personal opinion
is that this should always be done server side instead of on the client.
We could expose a custom parser that converts it and passes it through
prepareStackTrace as structured data. That way it's external and doesn't
have to be built-in to React.
We currently use the stack to dedupe warnings in a couple of places.
This is a very heavy weight way of computing that a warning doesn't need
to be fired.
This uses parent component name as a heuristic for deduping. It's not
perfect but as soon as you fix one you'll uncover the next. It might be a
little annoying but having many logs is also annoying.
We now have no special cases for stacks. The only thing that uses stacks in
dev is the console.error and dev tools. This means that we could
externalize this completely to an console.error patching module and drop
it from being built-in to react.
The only prod/dev behavior is the one we pass to error boundaries or the
error we throw if you don't have an error boundary.
* Remove priority field from tracing
* Remove DebugTracing mode from new reconciler (temporarily)
* Run DebugTracing tests in the *other* variant so it's no on for new reconciler
* DevTools console override handles new component stack format
DevTools does not attempt to mimic the default browser console format for its component stacks but it does properly detect the new format for Chrome, Firefox, and Safari.
* Detect double stacks in the new format in tests
* Remove unnecessary uses of getStackByFiberInDevAndProd
These all execute in the right execution context already.
* Set the debug fiber around the cases that don't have an execution context
* Remove stack detection in our console log overrides
We never pass custom stacks as part of the args anymore.
* Bonus: Don't append getStackAddendum to invariants
We print component stacks for every error anyway so this is just duplicate
information.
* Upgrade fbjs-scripts
This script takes into account the NODE_ENV as part of jest cache keys.
This avoids flaky tests since we depend on different transforms in prod
and dev.
* Upgrade Fresh test to Babel 7 transform
* test: Add failing case for dangerouslySetInnerHtml=undefined
* fix: skip dangerouslySetInnerHtml warning if it's undefined
* test: add similar test that should trigger the warning
* chore: Remove redundant nullish check
* Poke yarn_test_www_variant which timed out
* test: Add smaller test for innerHTML=string to innerHTML=undefined
* Fix incorrect unmounted state update warning
We detach fibers (which nulls the field) when we commit a deletion, so any state updates scheduled between that point and when we eventually flush passive effect destroys won't have a way to check if there is a pending passive unmount effect scheduled for its alternate unless we also explicitly track this for both the current and the alternate.
This commit adds a new DEV-only effect type, `PendingPassiveUnmountDev`, to handle this case.
We typecheck the reconciler against each one of our host configs.
`yarn flow dom` checks it against the DOM renderer, `yarn flow native`
checks it against the native renderer, and so on.
To do this, we generate separate flowconfig files.
Currently, there is no root-level host config, so running Flow
directly via `flow` CLI doesn't work. You have to use the `yarn flow`
command and pick a specific renderer.
A drawback of this design, though, is that our Flow setup doesn't work
with other tooling. Namely, editor integrations.
I think the intent of this was maybe so you don't run Flow against a
renderer than you intended, see it pass, and wrongly think you fixed
all the errors. However, since they all run in CI, I don't think this
is a big deal. In practice, I nearly always run Flow against the same
renderer (DOM), and I'm guessing that's the most common workflow for
others, too.
So what I've done in this commit is modify the `yarn flow` command to
copy the generated `.flowconfig` file into the root directory. The
editor integration will pick this up and show Flow information for
whatever was the last renderer you checked.
Everything else about the setup is the same, and all the renderers will
continue to be checked by CI.
* Failing test for #18657
* Remove incorrect priority check
I think this was just poor factoring on my part in #18411. Honestly it
doesn't make much sense to me, but my best guess is that I must have
thought that when `baseTime > currentChildExpirationTime`, the function
would fall through to the
`currentChildExpirationTime < renderExpirationTime` branch below.
Really I think just made an oopsie.
Regardless, this logic is galaxy brainéd. A goal of the Lanes refactor
I'm working on is to make these types of checks -- is there remaining
work in this tree? -- a lot easier to think about. Hopefully.
* Move renderer `act` to work loop
* Delete `flushSuspenseFallbacksInTests`
This was meant to be a temporary hack to unblock the `act` work, but it
quickly spread throughout our tests.
What it's meant to do is force fallbacks to flush inside `act` even in
Concurrent Mode. It does this by wrapping the `setTimeout` call in a
check to see if it's in an `act` context. If so, it skips the delay and
immediately commits the fallback.
Really this is only meant for our internal React tests that need to
incrementally render. Nobody outside our team (and Relay) needs to do
that, yet. Even if/when we do support that, it may or may not be with
the same `flushAndYield` pattern we use internally.
However, even for our internal purposes, the behavior isn't right
because a really common reason we flush work incrementally is to make
assertions on the "suspended" state, before the fallback has committed.
There's no way to do that from inside `act` with the behavior of this
flag, because it causes the fallback to immediately commit. This has led
us to *not* use `act` in a lot of our tests, or to write code that
doesn't match what would actually happen in a real environment.
What we really want is for the fallbacks to be flushed at the *end` of
the `act` scope. Not within it.
This only affects the noop and test renderer versions of `act`, which
are implemented inside the reconciler. Whereas `ReactTestUtils.act` is
implemented in "userspace" for backwards compatibility. This is fine
because we didn't have any DOM Suspense tests that relied on this flag;
they all use test renderer or noop.
In the future, we'll probably want to move always use the reconciler
implementation of `act`. It will not affect the prod bundle, because we
currently only plan to support `act` in dev. Though we still haven't
completely figured that out. However, regardless of whether we support a
production `act` for users, we'll still need to write internal React
tests in production mode. For that use case, we'll likely add our own
internal version of `act` that assumes a mock Scheduler and might rely
on hacks that don't 100% align up with the public one.
I made a mistake when setting these up a while ago. Setting the NODE_ENV
in the CircleCI config doesn't work because it's also set in the node
script command.
The number of test commands is getting out of control. Might need to fix
it at some point. Not today for me.
* Migrate conditional tests to gate pragma
I searched through the codebase for this pattern:
```js
describe('test suite', () => {
if (!__EXPERIMENTAL__) { // or some other condition
test("empty test so Jest doesn't complain", () => {});
return;
}
// Unless we're in experimental mode, none of the tests in this block
// will run.
})
```
and converted them to the `@gate` pragma instead.
The reason this pattern isn't preferred is because you end up disabling
more tests than you need to.
* Add flag for www release channels
Using a heuristic where I check a flag that is known to only be enabled
in www. I left a TODO to instead set the release channel explicitly in
each test config.
* Add pragma for feature testing: @gate
The `@gate` pragma declares under which conditions a test is expected to
pass.
If the gate condition passes, then the test runs normally (same as if
there were no pragma).
If the conditional fails, then the test runs and is *expected to fail*.
An alternative to `it.experimental` and similar proposals.
Examples
--------
Basic:
```js
// @gate enableBlocksAPI
test('passes only if Blocks API is available', () => {/*...*/})
```
Negation:
```js
// @gate !disableLegacyContext
test('depends on a deprecated feature', () => {/*...*/})
```
Multiple flags:
```js
// @gate enableNewReconciler
// @gate experimental
test('needs both useEvent and Blocks', () => {/*...*/})
```
Logical operators (yes, I'm sorry):
```js
// @gate experimental && (enableNewReconciler || disableSchedulerTimeoutBasedOnReactExpirationTime)
test('concurrent mode, doesn\'t work in old fork unless Scheduler timeout flag is disabled', () => {/*...*/})
```
Strings, and comparion operators
No use case yet but I figure eventually we'd use this to gate on
different release channels:
```js
// @gate channel === "experimental" || channel === "modern"
test('works in OSS experimental or www modern', () => {/*...*/})
```
How does it work?
I'm guessing those last two examples might be controversial. Supporting
those cases did require implementing a mini-parser.
The output of the transform is very straightforward, though.
Input:
```js
// @gate a && (b || c)
test('some test', () => {/*...*/})
```
Output:
```js
_test_gate(ctx => ctx.a && (ctx.b || ctx.c, 'some test'), () => {/*...*/});
```
It also works with `it`, `it.only`, and `fit`. It leaves `it.skip` and
`xit` alone because those tests are disabled anyway.
`_test_gate` is a global method that I set up in our Jest config. It
works about the same as the existing `it.experimental` helper.
The context (`ctx`) argument is whatever we want it to be. I set it up
so that it throws if you try to access a flag that doesn't exist. I also
added some shortcuts for common gating conditions, like `old`
and `new`:
```js
// @gate experimental
test('experimental feature', () => {/*...*/})
// @gate new
test('only passes in new reconciler', () => {/*...*/})
```
Why implement this as a pragma instead of a runtime API?
- Doesn't require monkey patching built-in Jest methods. Instead it
compiles to a runtime function that composes Jest's API.
- Will be easy to upgrade if Jest ever overhauls their API or we switch
to a different testing framework (unlikely but who knows).
- It feels lightweight so hopefully people won't feel gross using it.
For example, adding or removing a gate pragma will never affect the
indentation of the test, unlike if you wrapped the test in a
conditional block.
* Compatibility with console error/warning tracking
We patch console.error and console.warning to track unexpected calls
in our tests. If there's an unexpected call, we usually throw inside
an `afterEach` hook. However, that's too late for tests that we
expect to fail, because our `_test_gate` runtime can't capture the
error. So I also check for unexpected calls inside `_test_gate`.
* Move test flags to dedicated file
Added some instructions for how the flags are set up and how to
use them.
* Add dynamic version of gate API
Receives same flags as the pragma.
If we ever decide to revert the pragma, we can codemod them to use
this instead.
* Add more edge cases to fixture
Also adjust some expectations. I think the column should ideally be 1 but varies.
The Example row is one line off because it throws on the hook but should ideally be the component.
Similarly class components with constructors may have the line in the constructor.
* Account for the construct call taking a stack frame
We do this by first searching for the first different frame, then find
the same frames and then find the first different frame again.
* Throw controls
Otherwise they don't get a stack frame associated with them in IE.
* Protect against generating stacks failing
Errors while generating stacks will bubble to the root. Since this technique
is a bit sketchy, we should probably protect against it.
* Don't construct the thing that throws
Instead, we pass the prototype as the "this". It's new every time anyway.
* Implement component stack extraction hack
* Normalize errors in tests
This drops the requirement to include owner to pass the test.
* Special case tests
* Add destructuring to force toObject which throws before the side-effects
This ensures that we don't double call yieldValue or advanceTime in tests.
Ideally we could use empty destructuring but ES lint doesn't like it.
* Cache the result in DEV
In DEV it's somewhat likely that we'll see many logs that add component
stacks. This could be slow so we cache the results of previous components.
* Fixture
* Add Reflect to lint
* Log if out of range.
* Fix special case when the function call throws in V8
In V8 we need to ignore the first line. Normally we would never get there
because the stacks would differ before that, but the stacks are the same if
we end up throwing at the same place as the control.
Modules that belong to one fork should not import modules that belong to
the other fork.
Helps make sure you correctly update imports when syncing changes across
implementations.
Also could help protect against code size regressions that might happen
if one of the forks accidentally depends on two copies of the same
module.
* Remove unnecessary workInProgress line
* Mutate workInProgress instead of returning
We were ambivalent about this before.
* Make handleError a void method too
We currently use the expiration time to represent the timeout of a
transition. Since we intend to stop treating work priority as a
timeline, we can no longer use this trick.
In this commit, I've changed it to store the event time on the update
object instead. Long term, we will store event time on the root as a map
of transition -> event time. I'm only storing it on the update object
as a temporary workaround to unblock the rest of the changes.
We can't patch the row. We could give these their own "built-in" stack
frame since they're conceptually HoCs. However, from a debugging
perspective this is not very useful meta data and quite noisy. So I'm
just going to exclude them.
Adds command `yarn merge-fork`.
```sh
yarn merge-fork --base-dir=packages/react-reconciler/src ReactFiberWorkLoop
```
This will take all the changes in `ReactFiberWorkLoop.new.js` and apply
them to `ReactFiberWorkLoop.old.js`.
You can merge multiple modules at a time:
```sh
yarn merge-fork \
--base-dir=packages/react-reconciler/src \
ReactFiberWorkLoop \
ReactFiberBeginWork \
ReactFiberCompleteWork \
ReactFiberCommitWork
```
You can provide explicit "old" and "new" file names. This only works
for one module at a time:
```sh
yarn merge-fork \
--base-dir=packages/react-reconciler/src \
--old=ReactFiberExpirationTime.js \
--new=ReactFiberLane.js
```
The default is to merge changes from the new module to the old one. To
merge changes in the opposite direction, use `--reverse`.
```sh
yarn merge-fork \
--reverse \
--base-dir=packages/react-reconciler/src \
ReactFiberWorkLoop
```
By default, the changes are compared to HEAD. You can use `--base-ref`
to compare to any rev. For example, while working on a PR, you might
make multiple commits to the new fork before you're ready to backport
them to the old one. In that case, you want to compare to the merge
base of your PR branch:
```sh
yarn merge-fork \
--base-ref=$(git merge-base HEAD origin/master)
--base-dir=packages/react-reconciler/src \
ReactFiberWorkLoop
```
All changes in this commit were generated by the following commands.
Copy each module that ends with `.old` to a new file that ends
with `.new`:
```sh
for f in packages/react-reconciler/src/*.old.js; do cp "$f" "$(echo "$f" | sed s/\.old/\.new/)"; done
```
Then transform the internal imports:
```sh
grep -rl --include="*.new.js" '.old' packages/react-reconciler/src/| xargs sed -i '' "s/\.old\'/\.new\'/g"
```
Some of our internal reconciler types have leaked into other packages.
Usually, these types are treated as opaque; we don't read and write
to its fields. This is good.
However, the type is often passed back to a reconciler method. For
example, React DOM creates a FiberRoot with `createContainer`, then
passes that root to `updateContainer`. It doesn't do anything with the
root except pass it through, but because `updateContainer` expects a
full FiberRoot, React DOM is still coupled to all its fields.
I don't know if there's an idiomatic way to handle this in Flow. Opaque
types are simlar, but those only work within a single file. AFAIK,
there's no way to use a package as the boundary for opaqueness.
The immediate problem this presents is that the reconciler refactor will
involve changes to our internal data structures. I don't want to have to
fork every single package that happens to pass through a Fiber or
FiberRoot, or access any one of its fields. So my current plan is to
share the same Flow type across both forks. The shared type will be a
superset of each implementation's type, e.g. Fiber will have both an
`expirationTime` field and a `lanes` field. The implementations will
diverge, but not the types.
To do this, I lifted the type definitions into a separate module.
* Drop the .internal.js suffix on some files that don't need it anymore
* Port some ops patterns to scheduler yield
* Fix triangle test to avoid side-effects in constructor
* Move replaying of setState updaters until after the effect
Otherwise any warnings get silenced if they're deduped.
* Drop .internal.js in more files
* Don't check propTypes on a simple memo component unless it's lazy
Comparing the elementType doesn't work for this because it will never be
the same for a simple element.
This caused us to double validate these. This was covered up because in
internal tests this was deduped since they shared the prop types cache
but since we now inline it, it doesn't get deduped.
* Don't use closures in DevTools injection
Nested closures are tricky. They're not super efficient and when they share
scope between multiple closures they're hard for a compiler to optimize.
It's also unclear how many versions will be created.
By hoisting things out an just make it simple calls the compiler can do
a much better job.
* Store injected hook to work around fast refresh
* Disable console log during the second rerender
* Use the disabled log to avoid double yielding values in scheduler mock
* Reenable debugRenderPhaseSideEffectsForStrictMode in tests that can
* Add failing tests for lazy components
* Fix bailout broken in lazy components due to default props resolving
We should never compare unresolved props with resolved props. Since comparing
resolved props by reference doesn't make sense, we use unresolved props in that
case. Otherwise, resolved props are used.
* Avoid reassigning props warning when we bailout
* Bugfix: Render phase update leads to dropped work
Render phase updates should not affect the `fiber.expirationTime` field.
We don't have to set anything on the fiber because we're going to
process the render phase update immediately.
We also shouldn't reset the `expirationTime` field in between render
passes because it represents the remaining work left in the update
queues. During the re-render, the updates that were skipped in the
original pass are not processed again.
I think my original motivation for using this field for render phase
updates was so I didn't have to add another module level variable.
* Add repro case for #18486
Co-authored-by: Dan Abramov <dan.abramov@me.com>
* Add another test for #18515 using pings
Adds a regression test for the same underlying bug as #18515 but using
pings.
Test already passes, but I confirmed it fails if you revert the fix
in #18515.
* Set nextPendingLevel after commit, too
* Reproduce a bug where `flushDiscreteUpdates` causes fallback never to be committed
* Ping suspended level when canceling its timer
Make sure the suspended level is marked as pinged so that we return back
to it later, in case the render we're about to start gets aborted.
Generally we only reach this path via a ping, but we shouldn't assume
that will always be the case.
* Clear finished discrete updates during commit phase
If a root is finished at a priority lower than that of the latest pending discrete
updates on it, these updates must have been finished so we can clear them now.
Otherwise, a later call of `flushDiscreteUpdates` would start a new empty render
pass which may cause a scheduled timeout to be cancelled.
* Add TODO
Happened to find this while writing a test. A JSX element comparison
failed because one of them elements had a functional component as an
owner, which should ever happen.
I'll add a regression test later.
Co-authored-by: Andrew Clark <git@andrewclark.io>
* Filter certain DOM attributes (e.g. src, href) if their values are empty strings
This prevents e.g. <img src=""> from making an unnecessar HTTP request for certain browsers.
* Expanded warning recommendation
* Improved error message
* Further refined error message
* Add useOpaqueIdentifier Hook
We currently use unique IDs in a lot of places. Examples are:
* `<label for="ID">`
* `aria-labelledby`
This can cause some issues:
1. If we server side render and then hydrate, this could cause an
hydration ID mismatch
2. If we server side render one part of the page and client side
render another part of the page, the ID for one part could be
different than the ID for another part even though they are
supposed to be the same
3. If we conditionally render something with an ID , this might also
cause an ID mismatch because the ID will be different on other
parts of the page
This PR creates a new hook `useUniqueId` that generates a different
unique ID based on whether the hook was called on the server or client.
If the hook is called during hydration, it generates an opaque object
that will rerender the hook so that the IDs match.
Co-authored-by: Andrew Clark <git@andrewclark.io>
* Add feature flag
* Split stack from current fiber
You can get stack from any fiber, not just current.
* Refactor description of component frames
These should use fiber tags for switching. This also puts the relevant code
behind DEV flags.
* We no longer expose StrictMode in component stacks
They're not super useful and will go away later anyway.
* Update tests
Context is no longer part of SSR stacks. This was already the case on the
client.
forwardRef no longer is wrapped on the stack. It's still in getComponentName
but it's probably just noise in stacks. Eventually we'll remove the wrapper
so it'll go away anyway. If we use native stack frames they won't have this
extra wrapper.
It also doesn't pick up displayName from the outer wrapper. We could maybe
transfer it but this will also be fixed by removing the wrapper.
* Forward displayName onto the inner function for forwardRef and memo in DEV
This allows them to show up in stack traces.
I'm not doing this for lazy because lazy is supposed to be called on the
consuming side so you shouldn't assign it a name on that end. Especially
not one that mutates the inner.
* Use multiple instances of the fake component
We mutate the inner component for its name so we need multiple copies.
* Remove unnecessary CapturedError fields.
componentName is not necessary and is misleading when the error is caused
elsewhere in the stack. The stack is sufficient.
The many error boundary fields are unnecessary because they can be inferred
by the boundary itself.
* Don't attempt to build a stack twice
If it was possible, it would've been done in createCapturedValue.
* Push the work needed by the works into the forks
This avoids needing this in the npm published case.
* Lazily initialize models as they're read intead of eagerly when received
This ensures that we don't spend CPU cycles processing models that we're
not going to end up rendering.
This model will also allow us to suspend during this initialization if
data is not yet available to satisfy the model.
* Refactoring carefully to ensure bundles still compile to something optimal
* Remove generic from Response
The root model needs to be cast at one point or another same as othe
chunks. So we can parameterize the read instead of the whole Response.
* Read roots from the 0 key of the map
The special case to read the root isn't worth the field and code.
* Store response on each Chunk
Instead of storing it on the data tuple which is kind of dynamic, we store
it on each Chunk. This uses more memory. Especially compared to just making
initializeBlock a closure, but overall is simpler.
* Rename private fields to underscores
Response objects are exposed.
* Encode server components as delayed references
This allows us to stream in server components one after another over the
wire. It also allows parallelizing their fetches and resuming only the
server component instead of the whole parent block.
This doesn't yet allow us to suspend deeper while waiting on this content
because we don't have "lazy elements".
* Eject CRA from Flight
We need to eject because we're going to add a custom Webpack Plugin.
We can undo this once the plugin has upstreamed into CRA.
* Add Webpack plugin build
I call this entry point "webpack-plugin" instead of "plugin" even though
this is a webpack specific package. That's because there will also be a
Node.js plugin to do the server transform.
* Add Flight Webpack plugin to fixture
* Rm UMD builds
* Transform classes
* Rename webpack-plugin to plugin
This avoids the double webpack name. We're going to reuse this for both
server and client.
* Remove /dist/ UMD builds
We publish UMDs to npm (and we're considering stopping even that).
This means we'll stop publishing to http://react.zpao.com/builds/master/latest/
* Update fixture paths
This is a variant of the fix in 5a0f1d. We can't rely on the primary
fiber's `childExpirationTime` field to be correct.
In this case, we can read from the Suspense boundary fiber instead.
This will include updates that exist in the fallback fiber, but that's
not a big deal; the important thing is that we don't drop updates.
* Enable prefer-const rule
Stylistically I don't like this but Closure Compiler takes advantage of
this information.
* Auto-fix lints
* Manually fix the remaining callsites
* Upgrade Closure
There are newer versions but they don't yet have corresponding releases
of google-closure-compiler-osx.
* Configure build
* Refactor ReactSymbols a bit
Provides a little better output.
`onInput` behaves the same as `onChange` for controlled inputs as far as I
know, so React should not print the following warning when `onInput` is
present.
> Failed prop type: You provided a `value` prop to a form field without an `onChange` handler. This will render a read-only field. If the field should be mutable use `defaultValue`. Otherwise, set either `onChange` or `readOnly`.
* add email input fixture to show cursor jump
* fix cursor jump in email input
Co-authored-by: Peter Potapov <dr.potapoff-peter@yandex.ru>
* add regression tests to ensure attributes are working
Co-authored-by: Peter Potapov <dr.potapoff-peter@yandex.ru>
* test(SuspenseList): Add failing test for class component
* Reset stateNode when resetWorkInProgress
This is supposed to put the Fiber into the same state as if it was just
created by child fiber reconciliation. For newly created fibers, that means
that stateNode is null.
Co-authored-by: Sebastian Silbermann <silbermann.sebastian@gmail.com>
* Enable new passive effect behavior for FB builds
Previously this behavior was controlled by GKs. This PR updates the flags to be enabled statically. It also enables the flags in the test builds.
* Revert "ReactDOM.useEvent: enable on internal www and add inspection test (#18395)"
This reverts commit e0ab1a429d.
* Revert "ReactDOM.useEvent: Add support for experimental scopes API (#18375)"
This reverts commit a16b349745.
* ReactDOM.useEvent: Add support for experimental scopes API
* Refactor: visit CallExpression
Instead of visiting the functions and looking up to see if they're in a Hook call, visit Hook calls and look down to see if there's a callback inside. I will need this refactor so I can visit functions declared outside the call.
* Check deps when callback body is outside the Hook call
* Handle the unknown case
* Bugfix: Suspended update must finish to unhide
When we commit a fallback, we cannot unhide the content without including
the level that originally suspended. That's because the work at level
outside the boundary (i.e. everything that wasn't hidden during that
render) already committed.
* Test unblocking with a high-pri update
We store an effect pointer so we can backtrack in the effect list in some
cases. This is a stateful variable. If we interrupt a render we need to
reset it.
This field was added after the optimization was added and I didn't remember
to reset it here.
Otherwise we end up not resetting the firstEffect so it points to a stale
list. As a result children don't end up inserted like we think they were.
Then we try to remove them it errors.
It would be nicer to just get rid of the effect list and use the tree for
effects instead. Maybe we still need something for deletions tho.
React can't directly detect a memory leak, but there are some clues that warn about one. One of these clues is when an unmounted React component tries to update its state. For example, if a component forgets to remove an event listener when unmounting, that listener may be called later and try to update state, at which point React would warn about the potential leak.
Warning signals like this are more useful if they're strong. For this reason, it's good to always avoid updating state from inside of an effect's cleanup function. Even when you know there is no potential leak, React has no way to know and so it will warn anyway.
In most cases we suggest moving state updates to the useEffect() body instead (to avoid triggering the warning). This works so long as the component is updating its own state (or the state of a descendant). However this will not work when a component updates its parent state in a cleanup function. If such a component is unmounted but its parent remains mounted, the state will be incorrect. For this reason, we now avoid showing the warning if a component is updating an ancestor.
This assignment should have been deleted in #18384. It was deleted in
the other branches, but I missed this one. About to open a PR that
includes a test that covers this branch.
* Minor test refactor: `resolveText`
Adds a `resolveText` method as an alternative to using timers. Also
removes dependency on react-cache (for just this one test file; can do
the others later).
Timer option is still there if you provide a `ms` prop.
* Bugfix: Dropped updates in suspended tree
When there are multiple updates at different priority levels inside
a suspended subtree, all but the highest priority one is dropped after
the highest one suspends.
We do have tests that cover this for updates that originate outside of
the Suspense boundary, but not for updates that originate inside.
I'm surprised it's taken us this long to find this issue, but it makes
sense in that transition updates usually originate outside the boundary
or "seam" of the part of the UI that is transitioning.
* Bugfix: Suspense fragment skipped by setState
Fixes a bug where updates inside a suspended tree are dropped because
the fragment fiber we insert to wrap the hidden children is not part of
the return path, so it doesn't get marked during setState.
As a workaround, I recompute `childExpirationTime` right before deciding
to bail out by bubbling it up from the next level of children.
This is something we should consider addressing when we refactor the
Fiber data structure.
* Add back `lastPendingTime` field
This reverts commit 9a541139dfe36e8b9b02b1c6585889e2abf97389.
I want to use this so we can check if there might be any lower priority
updates in a suspended tree.
We can remove it again during the expiration times refactor.
* Use `lastPendingTime` instead of Idle
We don't currently have an mechanism to check if there are lower
priority updates in a subtree, but we can check if there are any in the
whole root. This still isn't perfect but it's better than using Idle,
which frequently leads to redundant re-renders.
When we refactor `expirationTime` to be a bitmask, this will no longer
be necessary because we'll know exactly which "task bits" remain.
* Add a test for updating the fallback
This is equivalent to the jsx-runtime in that this is what the compiled
output on the server is supposed to target.
It's really just the same code for all the different Flights, but they
have different types in their arguments so each one gets their own entry
point. We might use this to add runtime warnings per entry point.
Unlike the client-side React.block call this doesn't provide the factory
function that curries the load function. The compiler is expected to wrap
this call in the currying factory.
* Formalize the Wakeable and Thenable types
We use two subsets of Promises throughout React APIs. This introduces
the smallest subset - Wakeable. It's the thing that you can throw to
suspend. It's something that can ping.
I also use a shared type for Thenable in the cases where we expect a value
so we can be a bit more rigid with our us of them.
* Make Chunks into Wakeables instead of using native Promises
This value is just going from here to React so we can keep it a lighter
abstraction throughout.
* Renamed thenable to wakeable in variable names
Originally the idea was to hide all suspending behind getters or proxies.
However, this has some issues with perf on hot code like React elements.
It also makes it too easy to accidentally access it the first time in an
effect or callback where things aren't allowed to suspend. Making it
an explicit method call avoids this issue.
All other suspending has moved to explicit lazy blocks (and soon elements).
The only thing remaining is the root. We could require the root to be an
element or block but that creates an unfortunate indirection unnecessarily.
Instead, I expose a readRoot method on the response. Typically we try to
avoid virtual dispatch but in this case, it's meant that you build
abstractions on top of a Flight response so passing it a round is useful.
DevTools previously used the NPM events package for dispatching events. This package has an unfortunate flaw though- if a listener throws during event dispatch, no subsequent listeners are called. I've replaced that event dispatcher with my own implementation that ensures all listeners are called before it re-throws an error.
This commit replaces that event emitter with a custom implementation that calls all listeners before re-throwing an error.
* Regression test for map() returning an array
* Add forgotten argument
This fixes the bug.
* Remove unused arg and retval
These aren't directly observable. The arg wasn't used, it's accidental and I forgot to remove. The retval was triggering a codepath that was unnecessary (pushing to array) so I removed that too.
* Flowify ReactChildren
* Tighten up types
* Rename getComponentKey to getElementKey
This reverts commit cf0081263c.
The changes to the test code relate to changes in JSDOM that come with Jest 25:
* Several JSDOM workarounds are no longer needed.
* Several tests made assertions to match incorrect JSDOM behavior (e.g. setAttribute calls) that JSDOM has now patched to match browsers.
* https://codesandbox.io/s/resets-value-of-datetime-input-to-fix-bugs-in-ios-safari-1ppwh
* JSDOM no longer triggers default actions when dispatching click events.
* https://codesandbox.io/s/beautiful-cdn-ugn8f
* JSDOM fixed (jsdom/jsdom#2700) a bug so that calling focus() on an already focused element does not dispatch a FocusEvent.
* JSDOM now supports passive events.
* JSDOM has improved support for custom CSS properties.
* But requires jsdom/cssstyle#112 to land to support webkit prefixed properties.
* Resolve Server-side Blocks instead of Components
React elements should no longer be used to extract arbitrary data but only
for prerendering trees.
Blocks are used to create asynchronous behavior.
* Resolve Blocks in the Client
* Tests
* Bug fix relay JSON traversal
It's supposed to pass the original object and not the new one.
* Lint
* Move Noop Module Test Helpers to top level entry points
This module has shared state. It needs to be external from builds.
This lets us test the built versions of the Noop renderer.
* Don't pool traversal context
* Remove traverseAllChildrenImpl indirection
All usages are internal so we can simply use the inner function directly.
* Implement forEach through map
* Remove second usage of traverseAllChildren
This isn't useful by itself but makes the layering easier to follow. traverseAllChildren is only used at the lowest layer now.
* Reimplement count() and toArray() in terms of map()
* Inline the only use of mapSingleChildIntoContext
* Move forEach down in the file
* Use the language
Get rid of the traversal context. Use closures.
* Make mapIntoArray take an already escaped prefix
* Move count state out of mapIntoArray
* Inline traverseAllChildren into mapIntoArray
* Inline handleChild into mapIntoArray
* Refactor Lazy Components
* Switch Blocks to using a Lazy component wrapper
Then resolve to a true Block inside.
* Test component names of lazy Blocks
This is a really old one and all callers have since been codemodded away
anyway because of problems.
This file is not really as rigorously maintained as the official Flow types
but has a few more specifics. However, the inconsistency causes problems
when you try to pass files typed using the built-in Flow typing for React
and mix it with these.
We just happen to get away with it because we compile out the types. If we
didn't we would hit those problems by even using these in our renderers.
* Rename lower case isomorphic default exports modules to upper case named exports
We're somewhat inconsistent here between e.g. ReactLazy and memo.
Let's pick one.
This also moves the responder, fundamental, scope creators from shared
since they're isomorphic and same as the other creators.
* Move some files that are specific to the react-reconciler from shared
Individual renderers are allowed to deep require into the reconciler.
* Move files specific to react-dom from shared
react-interactions is right now dom specific (it wasn't before) so we can
type check it together with other dom stuff. Avoids the need for
a shared ReactDOMTypes to be checked by RN for example.
* Move ReactWorkTags to the reconciler
* Move createPortal to export from reconciler
Otherwise Noop can't access it since it's not allowed deep requires.
I accidentally did that thing again where I updated a PR branch to
be the same as the tip of master, which confused GitHub and caused it
to run PR checks against master.
Follow ups from https://github.com/facebook/react/pull/18334
I also introduced the concept of a module reference on the client too.
We don't need this for webpack so that gets compiled out but we need it
for www. Similarly I also need a difference between preload and load.
Error codes don't need to be pulled from CI anymore because the ones
in source are already expected to match the build output.
I noticed this when running the 16.13.1 release. Patch releases are cut
with the commit used to build the previous release as a base. So the
publish script accidentally reverted the changes that had landed to
the error codes file since then.
The publish script was written before we switched to running patch
releases out-of-band, so when updating the local package.json version
numbers, it accidentally reverted other changes that have landed to
master since 16.13 was released.
Per discussion at Facebook, we think hooks have reached a tipping point where it is more valuable to lint against potential hooks in classes than to worry about false positives.
Test plan:
```
# run from repo root
yarn test --watch RuleOfHooks
```
* [DevTools] Add shortcut keys for tab switching
* Use LocalStorage to remember most recently selected tab
Resolves#18227 and #18226
Co-authored-by: Brian Vaughn <brian.david.vaughn@gmail.com>
There was an inconsistency present on line 99 regarding the punctuation of the comment, all other comments found end in a period and this line had it's period omitted.
* Move unsubscribe fork to EventListener
That way we can statically compile out more of these indirections.
* Don't use the EventListener fork for Modern WWW builds
* Change the warning to not say "function body"
This warning is more generic and may happen with class components too.
* Dedupe by the rendering component
* Don't warn outside of render
This PR adds the jsx-runtime and jsx-dev-runtime modules for the JSX Babel Plugin. WWW still relies on jsx/jsxs/jsxDEV from the "react" module, so once we refactor the code to point to the runtime modules we will remove jsx/jsxs/jsxDEV from the "react" module.
* improve error message for cross-functional component updates
* correctly use %s by quoting it
* use workInProgress and lint
* add test assertion
* fix test
* Improve the error message
Co-authored-by: Dan Abramov <dan.abramov@me.com>
Don't warn about unmounted state updates from within passive destroy function
* Fixed test conditional. (It broke after recent variant refactor.)
* Changed warning wording for setState from within useEffect destroy callback
* ReactFiberReconciler -> ReactFiberReconciler.old
* Set up infra for react-reconciler fork
We're planning to land some significant refactors of the reconciler.
We want to be able to gradually roll out the new implementation side-by-
side with the existing one. So we'll create a short lived fork of the
react-reconciler package. Once the new implementation has stabilized,
we'll delete the old implementation and promote the new one.
This means, for as long as the fork exists, we'll need to maintain two
separate implementations. This sounds painful, but since the forks will
still be largely the same, most changes will not require two separate
implementations. In practice, you'll implement the change in the old
fork and then copy paste it to the new one.
This commit only sets up the build and testing infrastructure. It does
not actually fork any modules. I'll do that in subsequent PRs.
The forked version of the reconciler will be used to build a special
version of React DOM. I've called this build ReactDOMForked. It's only
built for www; there's no open source version.
The new reconciler is disabled by default. It's enabled in the
`yarn test-www-variant` command. The reconciler fork isn't really
related to the "variant" feature of the www builds, but I'm piggy
backing on that concept to avoid having to add yet another
testing dimension.
For the browser extension, these views get rendered into portals and so they don't inherit the box-sizing style from the .DevTools wrapper element. This causes views like the Profiler commit selector to subtly break.
useMutableSource hook
useMutableSource() enables React components to safely and efficiently read from a mutable external source in Concurrent Mode. The API will detect mutations that occur during a render to avoid tearing and it will automatically schedule updates when the source is mutated.
RFC: reactjs/rfcs#147
* Bugfix: "Captured" updates on legacy queue
This fixes a bug with error boundaries. Error boundaries have a notion
of "captured" updates that represent errors that are thrown in its
subtree during the render phase. These updates are meant to be dropped
if the render is aborted.
The bug happens when there's a concurrent update (an update from an
interleaved event) in between when the error is thrown and when the
error boundary does its second pass. The concurrent update is
transferred from the pending queue onto the base queue. Usually, at this
point the base queue is the same as the current queue. So when we
append the pending updates to the work-in-progress queue, it also
appends to the current queue.
However, in the case of an error boundary's second pass, the base queue
has already forked from the current queue; it includes both the
"captured" updates and any concurrent updates. In that case, what we
need to do is append separately to both queues. Which we weren't doing.
That isn't the full story, though. You would expect that this mistake
would manifest as dropping the interleaved updates. But instead what
was happening is that the "captured" updates, the ones that are meant
to be dropped if the render is aborted, were being added to the
current queue.
The reason is that the `baseQueue` structure is a circular linked list.
The motivation for this was to save memory; instead of separate `first`
and `last` pointers, you only need to point to `last`.
But this approach does not work with structural sharing. So what was
happening is that the captured updates were accidentally being added
to the current queue because of the circular link.
To fix this, I changed the `baseQueue` from a circular linked list to a
singly-linked list so that we can take advantage of structural sharing.
The "pending" queue, however, remains a circular list because it doesn't
need to be persistent.
This bug also affects the root fiber, which uses the same update queue
implementation and also acts like an error boundary.
It does not affect the hook update queue because they do not have any
notion of "captured" updates. So I've left it alone for now. However,
when we implement resuming, we will have to account for the same issue.
* Ensure base queue is a clone
When an error boundary captures an error, we append the error update
to the work-in-progress queue only so that if the render is aborted,
the error update is dropped.
Before appending to the queue, we need to make sure the queue is a
work-in-progress copy. Usually we clone the queue during
`processUpdateQueue`; however, if the base queue has lower priority
than the current render, we may have bailed out on the boundary fiber
without ever entering `processUpdateQueue`. So we need to lazily clone
the queue.
* Add warning to protect against refactor hazard
The hook queue does not have resuming or "captured" updates, but if
we ever add them in the future, we'll need to make sure we check if the
queue is forked before transfering the pending updates to them.
This replaces the HTML renderer with instead resolving host elements into
arrays tagged with the react.element symbol. These turn into proper
React Elements on the client.
The symbol is encoded as the magical value "$". This has security implications
so this special value needs to remain escaped for other strings.
We could just encode the element as {$$typeof: "$", key: key props: props}
but that's a lot more bytes. So instead I encode it as:
["$", key, props] and then convert it back.
It would be nicer if React's reconciler could just accept these tuples.
* Add ReactFlightServerConfig intermediate
This just forwards to the stream version of Flight which is itself forked
between Node and W3C streams.
The dom-relay goes directly to the Relay config though which allows it to
avoid the stream part of Flight.
* Separate streaming protocol into the Stream config
* Split streaming parts into the ReactFlightServerConfigStream
This decouples it so that the Relay implementation doesn't have to encode
the JSON to strings. Instead it can be fed the values as JSON objects and
do its own encoding.
* Split FlightClient into a basic part and a stream part
Same split as the server.
* Expose lower level async hooks to Relay
This requires an external helper file that we'll wire up internally.
* Rename to clarify that it's client-only
* Rename FizzStreamer to FizzServer for consistency
* Rename react-flight to react-client/flight
For consistency with react-server. Currently this just includes flight
but it could be expanded to include the whole reconciler.
* Add Relay Flight Build
* Rename ReactServerHostConfig to ReactServerStreamConfig
This will be the config specifically for streaming purposes.
There will be other configs for other purposes.
* Require deep for reconcilers
* Delete inline* files
* Delete react-reconciler/persistent
This no longer makes any sense because it react-reconciler takes
supportsMutation or supportsPersistence as options. It's no longer based
on feature flags.
* Fix jest mocking
* Fix Flow strategy
We now explicitly list which paths we want to be checked by a renderer.
For every other renderer config we ignore those paths.
Nothing is "any" typed. So if some transitive dependency isn't reachable
it won't be accidentally "any" that leaks.
* Lazify Blocks
Blocks now initialize lazily.
* Initialize Blocks eagerly in ChildFiber
This is for the case when it's a new Block that hasn't yet initialized.
We need to first initialize it to see what "render function" it resolves
to so that we can use that in our comparison.
* Remove extra import type line
* Failing: Dropped effects in Legacy Mode Suspense
* Transfer mounted effects on suspend in legacy mode
In legacy mode, a component that suspends bails out and commit in
its previous state. If the component previously had mounted effects,
we must transfer those to the work-in-progress so they don't
get dropped.
In CI, we run our test suite against multiple build configurations. For
example, we run our tests in both dev and prod, and in both the
experimental and stable release channels. This is to prevent accidental
deviations in behavior between the different builds. If there's an
intentional deviation in behavior, the test author must account
for them.
However, we currently don't run tests against the www builds. That's
a problem, because it's common for features to land in www before they
land anywhere else, including the experimental release channel.
Typically we do this so we can gradually roll out the feature behind
a flag before deciding to enable it.
The way we test those features today is by mutating the
`shared/ReactFeatureFlags` module. There are a few downsides to this
approach, though. The flag is only overridden for the specific tests or
test suites where you apply the override. But usually what you want is
to run *all* tests with the flag enabled, to protect against unexpected
regressions.
Also, mutating the feature flags module only works when running the
tests against source, not against the final build artifacts, because the
ReactFeatureFlags module is inlined by the build script.
Instead, we should run the test suite against the www configuration,
just like we do for prod, experimental, and so on. I've added a new
command, `yarn test-www`. It automatically runs in CI.
Some of the www feature flags are dynamic; that is, they depend on
a runtime condition (i.e. a GK). These flags are imported from an
external module that lives in www. Those flags will be enabled for some
clients and disabled for others, so we should run the tests against
*both* modes.
So I've added a new global `__VARIANT__`, and a new test command `yarn
test-www-variant`. `__VARIANT__` is set to false by default; when
running `test-www-variant`, it's set to true.
If we were going for *really* comprehensive coverage, we would run the
tests against every possible configuration of feature flags: 2 ^
numberOfFlags total combinations. That's not practical, though, so
instead we only run against two combinations: once with `__VARIANT__`
set to `true`, and once with it set to `false`. We generally assume that
flags can be toggled independently, so in practice this should
be enough.
You can also refer to `__VARIANT__` in tests to detect which mode you're
running in. Or, you can import `shared/ReactFeatureFlags` and read the
specific flag you can about. However, we should stop mutating that
module going forward. Treat it as read-only.
In this commit, I have only setup the www tests to run against source.
I'll leave running against build for a follow up.
Many of our tests currently assume they run only in the default
configuration, and break when certain flags are toggled. Rather than fix
these all up front, I've hard-coded the relevant flags to the default
values. We can incrementally migrate those tests later.
* Implemented Profiler onCommit() and onPostCommit() hooks
* Added enableProfilerCommitHooks feature flag for commit hooks
* Moved onCommit and onPassiveCommit behind separate feature flag
* Revert "Revert "feat: honor displayName of context types (#18035)" (#18223)"
This reverts commit 3ee812e6b6.
* Add warning of displayName is set on the consumer
* dedupe warning
* This type is all wrong and nothing cares because it's all any
* Refine Flow types of Lazy Components
We can type each condition.
* Remove _ctor field from Lazy components
This field is not needed because it's only used before we've initialized,
and we don't have anything else to store before we've initialized.
* Check for _ctor in case it's an older isomorphic that created it
We try not to break across minors but it's no guarantee.
* Move types and constants from shared to isomorphic
The "react" package owns the data structure of the Lazy component. It
creates it and decides how any downstream renderer may use it.
* Move constants to shared
Apparently we can't depend on react/src/ because the whole package is
considered "external" as far as rollup is concerned.
* Bugfix: Expiring a partially completed tree (#17926)
* Failing test: Expiring a partially completed tree
We should not throw out a partially completed tree if it expires in the
middle of rendering. We should finish the rest of the tree without
yielding, then finish any remaining expired levels in a single batch.
* Check if there's a partial tree before restarting
If a partial render expires, we should stay in the concurrent path
(performConcurrentWorkOnRoot); we'll stop yielding, but the rest of the
behavior remains the same.
We will only revert to the sync path (performSyncWorkOnRoot) when
starting on a new level.
This approach prevents partially completed concurrent work from
being discarded.
* New test: retry after error during expired render
* Regression: Expired partial tree infinite loops
Adds regression tests that reproduce a scenario where a partially
completed tree expired then fell into an infinite loop.
The code change that exposed this bug made the assumption that if you
call Scheduler's `shouldYield` from inside an expired task, Scheduler
will always return `false`. But in fact, Scheduler sometimes returns
`true` in that scenario, which is a bug.
The reason it worked before is that once a task timed out, React would
always switch to a synchronous work loop without checking `shouldYield`.
My rationale for relying on `shouldYield` was to unify the code paths
between a partially concurrent render (i.e. expires midway through) and
a fully concurrent render, as opposed to a render that was synchronous
the whole time. However, this bug indicates that we need a stronger
guarantee within React for when tasks expire, given that the failure
case is so catastrophic. Instead of relying on the result of a dynamic
method call, we should use control flow to guarantee that the work is
synchronously executed.
(We should also fix the Scheduler bug so that `shouldYield` always
returns false inside an expired task, but I'll address that separately.)
* Always switch to sync work loop when task expires
Refactors the `didTimeout` check so that it always switches to the
synchronous work loop, like it did before the regression.
This breaks the error handling behavior that I added in 5f7361f (an
error during a partially concurrent render should retry once,
synchronously). I'll fix this next. I need to change that behavior,
anyway, to support retries that occur as a result of `flushSync`.
* Retry once after error even for sync renders
Except in legacy mode.
This is to support the `useOpaqueReference` hook, which uses an error
to trigger a retry at lower priority.
* Move partial tree check to performSyncWorkOnRoot
* Factor out render phase
Splits the work loop and its surrounding enter/exit code into their own
functions. Now we can do perform multiple render phase passes within a
single call to performConcurrentWorkOnRoot or performSyncWorkOnRoot.
This lets us get rid of the `didError` field.
* Added missing @flow pragma to React.js
* Fixed useContext() return type definition
* Fixed previously masked Flow errors in DevTools and react-interactions packages
* Added displayName to internal Context Flow type
* Removed Flow generic annotations for createResponder
This seems to cause a parsing error. (Not sure why.) The API is deprecated anyway so I'm being lazy for now and just adding a .
* Only use Rollup's CommonJS plugin for "react-art"
We still need it for the "art" UMD builds but nothing else should have
CommonJS dependencies anymore.
* react-debug-tools and jest-react should leave object-assign as an external dep
This avoids it being compiled into the output.
* Check in a forked version of object-assign
This one uses ES modules so that we can inline it into UMD builds.
We could wait for object-assign to make an ESM export but we're going to
remove this dependency and assume global polyfills in the next version
anyway. However, we'd have to figure out how to keep the copyright header
and it'll get counted in terms of byte size (even if other tooling removes
it).
A lot of headache when we have our own implementation anyway. So I'll just
use that.
Ours is not resilient to checking certain browser bugs but those browsers
are mostly unused anyway. (Even FB breaks on them presumably.)
We also don't need to be resilient to Symbols since the way React uses it
we shouldn't need to copy symbols
* Don't transpile Object.assign to object-assign in object-assign
The polyfill needs to be able to feature detect Object.assign.
* improve findByType error message
* fix flow typing
* Adding a test for the "Unknown" branch when `getComponentName()` returns a falsy value. The error message in this case not the most descriptive but seems consistent with the `getComponentName(type) || 'Unknown'` pattern seen in multiple places in this code base.
* Move remaining things to named exports
The interesting case here is the noop renderers. The wrappers around the
reconciler now changed to use a local export that gets mutated.
ReactNoop and ReactNoopPersistent now have to destructure the object to
list out the names it's going to export. We should probably refactor
ReactNoop away from createReactNoop. Especially since it's also not Flow
typed.
* Switch interactions to star exports
This will have esModule compatibility flag on them. They should ideally
export default instead.
Nothing interesting here except that ReactShallowRenderer currently exports
a class with a static method instead of an object.
I think the public API is probably just meant to be createRenderer but
currently the whole class is exposed. So this means that we have to keep
it as default export. We could potentially also expose a named export for
createRenderer but that's going to cause compatibility issues.
So I'm just going to make that export default.
Unfortunately Rollup and Babel (which powers Jest) disagree on how to
import this. So to make it work I had to move the jest tests to imports.
This doesn't work with module resetting. Some tests weren't doing that
anyway and the rest is just testing ReactShallowRenderer so meh.
The useState hook has always composed the useReducer hook. 1:1 composition like this is fine.
But some more recent hooks (e.g. useTransition, useDeferredValue) compose multiple hooks internally. This breaks react-debug-tools because it causes off-by-N errors when the debug tools re-renders the function.
For example, if a component were to use the useTransition and useMemo hooks, the normal hooks dispatcher would create a list of first state, then callback, then memo hooks, but the debug tools package would expect a list of transition then memo. This can break user code and cause runtime errors in both the react-debug-tools package and in product code.
This PR fixes the currently broken hooks by updating debug tools to be aware of the composite hooks (how many times it should call nextHook essentially) and adds tests to make sure they don't get out of sync again. We'll need to add similar tests for future composite hooks (like useMutableSource #18000).
The testing build versions of react-dom are included in the builds right now, but we're not ready to share them yet. This PR removes them for now (back soon for the next release)
We're not actually building this entry point. I can't think of a reason
we'd need to fork the isomorphic one. We don't really fork it for
anything since it's so generic to work with all renderers.
Since /profiling doesn't have this, it might confuse the story if we made
people alias two things for testing but not profiling.
* Add options for forked entry points
We currently fork .fb.js entry points. This adds a few more options.
.modern.fb.js - experimental FB builds
.classic.fb.js - stable FB builds
.fb.js - if no other FB build, use this for FB builds
.experimental.js - experimental builds
.stable.js - stable builds
.js - used if no other override exists
This will be used to have different ES exports for different builds.
* Switch React to named exports
* Export named exports from the export point itself
We need to re-export the Flow exported types so we can use them in our code.
We don't want to use the Flow types from upstream since it doesn't have the non-public APIs that we have.
This should be able to use export * but I don't know why it doesn't work.
This actually enables Flow typing of React which was just "any" before.
This exposed some Flow errors that needs fixing.
* Create forks for the react entrypoint
None of our builds expose all exports and they all differ in at least one
way, so we need four forks.
* Set esModule flag to false
We don't want to emit the esModule compatibility flag on our CommonJS
output. For now we treat our named exports as if they're CommonJS.
This is a potentially breaking change for scheduler (but all those apis
are unstable), react-is and use-subscription. However, it seems unlikely
that anyone would rely on this since these only have named exports.
* Remove unused Feature Flags
* Let jest observe the stable fork for stable tests
This lets it do the negative test by ensuring that the right tests fail.
However, this in turn will make other tests that are not behind
__EXPERIMENTAL__ fail. So I need to do that next.
* Put all tests that depend on exports behind __EXPERIMENTAL__
Since there's no way to override the exports using feature flags
in .intern.js anymore we can't use these APIs in stable.
The tradeoff here is that we can either enable the negative tests on
"stable" that means experimental are expected to fail, or we can disable
tests on stable. This is unfortunate since some of these APIs now run on
a "stable" config at FB instead of the experimental.
* Switch ReactDOM to named exports
Same strategy as React.
I moved the ReactDOMFB runtime injection to classic.fb.js
Since we only fork the entrypoint, the `/testing` entrypoint needs to
be forked too to re-export the same things plus `act`. This is a bit
unfortunate. If it becomes a pattern we can consider forking in the
module resolution deeply.
fix flow
* Fix ReactDOM Flow Types
Now that ReactDOM is Flow type checked we need to fix up its types.
* Configure jest to use stable entry for ReactDOM in non-experimental
* Remove additional FeatureFlags that are no longer needed
These are only flagging the exports and no implementation details so we
can control them fully through the export overrides.
* [eslint-plugin-react-hooks] Fix cyclic caching for loops containing a condition
* [eslint-plugin-react-hooks] prettier write
* [eslint-plugin-react-hooks] Fix set for tests
* Update packages/eslint-plugin-react-hooks/src/RulesOfHooks.js
Co-Authored-By: Luke Kang <kidkkr@icloud.com>
Co-authored-by: Luke Kang <kidkkr@icloud.com>
* Test automation for edge dev tools extension
* Linter changes
* Load extension automatically.
* Fixed path in `test` command
Co-authored-by: Brian Vaughn <brian.david.vaughn@gmail.com>
Exports from ReactDOM represents React's public API. This include types
exported by React. At some point we'll start building Flow types from
these files.
The duplicate name between DOMContainer and Container seems confusing too
since it was used in the same files even though they're the same.
* import * as React from "react";
This is the correct way to import React from an ES module since the ES
module will not have a default export. Only named exports.
* import * as ReactDOM from "react-dom"
I recently landed a change to the timing of passive effect cleanup functions during unmount (see #17925). This change defers flushing of passive effects for unmounted components until later (whenever we next flush pending passive effects).
Since this change increases the likelihood of a (not actionable) state update warning for unmounted components, I've suppressed that warning for Fibers that have scheduled passive effect unmounts pending.
Fixes a bug where lower priority updates on a components wrapped with
`memo` are sometimes left dangling in the queue without ever being
processed, if they are preceded by a higher priority bailout.
Cause
-----
The pending update priority field is cleared at the beginning of
`beginWork`. If there is remaining work at a lower priority level, it's
expected that it will be accumulated on the work-in-progress fiber
during the begin phase.
There's an exception where this assumption doesn't hold:
SimpleMemoComponent contains a bailout that occurs *before* the
component is evaluated and the update queues are processed, which means
we don't accumulate the next priority level. When we complete the fiber,
the work loop is left to believe that there's no remaining work.
Mitigation
----------
Since this only happens in a single case, a late bailout in
SimpleMemoComponent, I've mitigated the bug in that code path by
restoring the original update priority from the current fiber.
This same case does not apply to MemoComponent, because MemoComponent
fibers do not contain hooks or update queues; rather, they wrap around
an inner fiber that may contain those. However, I've added a test case
for MemoComponent to protect against a possible future regression.
Possible next steps
-------------------
We should consider moving the update priority assignment in `beginWork`
out of the common path and into each branch, to avoid similar bugs in
the future.
Adds a feature flag for when React.jsx warns you about spreading a key into jsx. It's false for all builds, except as a dynamic flag for fb/www.
I also included the component name in the warning.
This warning already exists for class components, but not for functions.
It does not apply to render phase updates to the same component, which
have special semantics that we do support.
Our current lint config assumes a browser environment, which means it won't warn you if you use a variable like `name` without declaring it earlier. This imports the same list as the one used by create-react-app, and enables it against our codebase.
* Re-throw errors thrown by the renderer at the root
React treats errors thrown at the root as a fatal because there's no
parent component that can capture it. (This is distinct from an
"uncaught error" that isn't wrapped in an error boundary, because in
that case we can fall back to deleting the whole tree -- not great, but
at least the error is contained to a single root, and React is left in a
consistent state.)
It turns out we didn't have a test case for this path. The only way it
can happen is if the renderer's host config throws. We had similar test
cases for host components, but none for the host root.
This adds a new test case and fixes a bug where React would keep
retrying the root because the `workInProgress` pointer was not advanced
to the next fiber. (Which in this case is `null`, since it's the root.)
We could consider in the future trying to gracefully exit from certain
types of root errors without leaving React in an inconsistent state. For
example, we should be able to gracefully exit from errors thrown in the
begin phase. For now, I'm treating it like an internal invariant and
immediately exiting.
* Add comment
* Split recent passive effects changes into 2 flags
Separate flags can now be used to opt passive effects into:
1) Deferring destroy functions on unmount to subsequent passive effects flush
2) Running all destroy functions (for all fibers) before create functions
This allows us to test the less risky feature (2) separately from the more risky one.
* deferPassiveEffectCleanupDuringUnmount is ignored unless runAllPassiveEffectDestroysBeforeCreates is true
Before attempting to land an expiration times refactor, I want to see
if this particular change will impact performance (either positively
or negatively). I will test this with a GK.
This babel transform is a fork of the @babel/plugin-transform-react-jsx transform and is for experimentation purposes only. We don't plan to own this code in the future, and we will upstream this to Babel at some point once we've proven out the concept.
As per the RFC to simplify element creation, we want to add the ability to auto import "react' directly from the babel plugin. This commit updates the babel plugin with two options:
1.) importSource: The React module to import from. Defaults to react.
2.) autoImport: The type of import. Defaults to none.
- none: Does not import React. JSX compiles to React.jsx etc.
- namespace: import * as _react from "react";. JSX compiles to _react.jsx etc.
- default: import _default from "react"; JSX compiles to _default.jsx etc.
- namedExports: import {jsx as _jsx} from "react"; JSX compiles to _jsx etc.
- require: var _react = _interopRequireWildcard(require("react"));. jSX compiles to _react.jsx etc.
namespace, default, and namedExports can only be used when sourceType: module and require can only be used when sourceType: script.
It also adds two pragmas (jsxAutoImport and jsxImportSource) that allow users to specify autoImport and importSource in the docblock.
* Build both stable and experimental WWW builds
* Flip already experimental WWW flags to true
* Remove FB-specific internals from modern FB builds
We think we're not going to need these.
* Disable classic features in modern WWW builds
* Disable legacy ReactDOM API for modern WWW build
* Don’t include user timing in prod
* Fix bad copy paste and add missing flags to test renderer
* Add testing WWW feature flag file
We need it because WWW has a different meaning of experimental now.
This section is empty, and imo isn't really helpful in React's changelog. I'm honestly not sure why this is even here? Figured I'd start a discussion with a PR, or we can remove it right now.
* Flush all passive destroy fns before calling create fns
Previously we only flushed destroy functions for a single fiber.
The reason this is important is that interleaving destroy/create effects between sibling components might cause components to interfere with each other (e.g. a destroy function in one component may unintentionally override a ref value set by a create function in another component).
This PR builds on top of the recently added deferPassiveEffectCleanupDuringUnmount kill switch to separate passive effects flushing into two separate phases (similar to layout effects).
* Change passive effect flushing to use arrays instead of lists
This change offers a small advantage over the way we did things previous: it continues invoking destroy functions even after a previous one errored.
The mock Scheduler that we use in our tests has its own fake timer
implementation. The `unstable_advanceTime` method advances the timeline.
Currently, a call to `unstable_advanceTime` will also flush any pending
expired work. But that's not how it works in the browser: when a timer
fires, the corresponding task is added to the Scheduler queue. However,
we will still wait until the next message event before flushing it.
This commit changes `unstable_advanceTime` to more closely resemble the
browser behavior, by removing the automatic flushing of expired work.
```js
// Before this commit
Scheduler.unstable_advanceTime(ms);
// Equivalent behavior after this commit
Scheduler.unstable_advanceTime(ms);
Scheduler.unstable_flushExpired();
```
The general principle is to prefer separate APIs for scheduling tasks
and flushing them.
This change does not affect any public APIs. `unstable_advanceTime` is
only used by our own test suite. It is not used by `act`.
However, we may need to update tests in www, like Relay's.
* apply changes on editablevalue on blur feature implemented
* Removed "Undo" button and unnecessary event.preventDefault()
Co-authored-by: Brian Vaughn <brian.david.vaughn@gmail.com>
This PR introduces adds `react/testing` and `react-dom/testing`.
- changes infra to generate these builds
- exports act on ReactDOM in these testing builds
- uses the new test builds in fixtures/dom
In the next PR -
- I'll use the new builds for all our own tests
- I'll replace usages of TestUtils.act with ReactDOM.act.
* Simplify Continuous Hydration Targets
Let's use a constant priority for this. This helps us avoid restarting
a render when switching targets and simplifies the model.
The downside is that now we're not down-prioritizing the previous hover
target. However, we think that's ok because it'll only do one level too
much and then stop.
* Add test meant to show why it's tricky to merge both hydration levels
Having both levels co-exist works. However, if we deprioritize hydration
using a single level, we might deprioritize the wrong thing.
This adds a test that catches it if we ever try a naive deprioritization
in the future.
It also tests that we don't down-prioritize if we're changing the hover
in the middle of doing continuous priority work.
* Flush useEffect clean up functions in the passive effects phase
This is a change in behavior that may cause broken product code, so it has been added behind a killswitch (deferPassiveEffectCleanupDuringUnmount)
* Avoid scheduling unnecessary callbacks for cleanup effects
Updated enqueuePendingPassiveEffectDestroyFn() to check rootDoesHavePassiveEffects before scheduling a new callback. This way we'll only schedule (at most) one.
* Updated newly added test for added clarity.
* Cleaned up hooks effect tags
We previously used separate Mount* and Unmount* tags to track hooks work for each phase (snapshot, mutation, layout, and passive). This was somewhat complicated to trace through and there were man tag types we never even used (e.g. UnmountLayout, MountMutation, UnmountSnapshot). In addition to this, it left passive and layout hooks looking the same after renders without changed dependencies, which meant we were unable to reliably defer passive effect destroy functions until after the commit phase.
This commit reduces the effect tag types to only include Layout and Passive and differentiates between work and no-work with an HasEffect flag.
* Disabled deferred passive effects flushing in OSS builds for now
* Split up unmount and mount effects list traversal
Update various parts of DevTools to account for the fact that the global "hook" might be undefined if DevTools didn't inject it (due to the page's `contentType`) it (due to the page's `contentType`)
This reverts commit 01974a867c.
* Failing test: Expiring a partially completed tree
We should not throw out a partially completed tree if it expires in the
middle of rendering. We should finish the rest of the tree without
yielding, then finish any remaining expired levels in a single batch.
* Check if there's a partial tree before restarting
If a partial render expires, we should stay in the concurrent path
(performConcurrentWorkOnRoot); we'll stop yielding, but the rest of the
behavior remains the same.
We will only revert to the sync path (performSyncWorkOnRoot) when
starting on a new level.
This approach prevents partially completed concurrent work from
being discarded.
* New test: retry after error during expired render
* Add test of Event Replaying using Flare
* Fix Event Replaying in Flare by Eagerly Adding Active Listeners
This effectively reverts part of https://github.com/facebook/react/pull/17513
* Failing test: Expiring a partially completed tree
We should not throw out a partially completed tree if it expires in the
middle of rendering. We should finish the rest of the tree without
yielding, then finish any remaining expired levels in a single batch.
* Check if there's a partial tree before restarting
If a partial render expires, we should stay in the concurrent path
(performConcurrentWorkOnRoot); we'll stop yielding, but the rest of the
behavior remains the same.
We will only revert to the sync path (performSyncWorkOnRoot) when
starting on a new level.
This approach prevents partially completed concurrent work from
being discarded.
* New test: retry after error during expired render
The changes to the test code relate to changes in JSDOM that come with Jest 25:
* Several JSDOM workarounds are no longer needed.
* Several tests made assertions to match incorrect JSDOM behavior (e.g. setAttribute calls) that JSDOM has now patched to match browsers.
* https://codesandbox.io/s/resets-value-of-datetime-input-to-fix-bugs-in-ios-safari-1ppwh
* JSDOM no longer triggers default actions when dispatching click events.
* https://codesandbox.io/s/beautiful-cdn-ugn8f
* JSDOM fixed (jsdom/jsdom#2700) a bug so that calling focus() on an already focused element does not dispatch a FocusEvent.
* JSDOM now supports passive events.
* JSDOM has improved support for custom CSS properties.
* But requires jsdom/cssstyle#112 to land to support webkit prefixed properties.
When owner and self are different for string refs, we can't easily convert them to callback refs. This PR adds a warning for string refs when owner and self are different to tell users to manually update these refs.
I moved unstable_SuspenseList internally. We don't need the FB build.
I plan on also removing the ReactDOM fb specific entry. We shouldn't add
any more FB specific internals nor APIs. If they're experimental they
should go onto the experimental builds to avoid too many permutations.
* Remove renderPhaseUpdates Map
Follow up to #17484, which was reverted due to a bug found in www.
* Failing test: Dropped updates
When resetting render phase updates after a throw, we should only clear
the pending queue of hooks that were already processed.
* Fix non-render-phase updates being dropped
Detects if a queue has been processed by whether the hook was cloned.
If we change the implementation to an array instead of a list, we'll
need some other mechanism to determine whether the hook was processed.
* Regression test: startTransition in render phase
useTransition uses the state hook as part of its implementation, so we
need to fork it in the dispatcher used for re-renders, too.
* Update Flow to 0.84
* Fix violations
* Use inexact object syntax in files from fbsource
* Fix warning extraction to use a modern parser
* Codemod inexact objects to new syntax
* Tighten types that can be exact
* Revert unintentional formatting changes from codemod
* Remove toString of dangerouslySetInnerHTML
As far as I can tell, the toString call was added here:
caae627cd5 (diff-5574f655d491348f422bca600ff6711dR887)
It was never really needed. Subsequently when we added Trusted Types,
this needed to be changed to a special call but we really should just
always let it pass through.
* Remove special casing of toString values when enableTrustedTypesIntegration
As far as I can tell, we only toString in user space because of IE8/9.
We don't really support IE8/9 anymore and by the time this flag is on,
we should be able to deprecate it.
Unless this is also an issue in IE11. I haven't tested yet.
* Revert "Revert "Dispatch commands to both UIManagers from both renderers (#17211)" (#17232)"
This reverts commit d0fc0ba0a6.
* Clean up another __DEV__ warning check
Previously, DevTools filtered empty commits on the backend, while profiling, through the use of a bailout heuristic that React currently happens to use. This approach was brittle and may have exacerbated the long-standing Profiler bug #16446.
This PR removes that heuristic and adds as a post-processing filtering pass instead. This removes the coupling between DevTools and a React internal implementation detail that may change.
I believe DevTools has two choices of criteria for this filtering:
* Filter commits that have no actual duration metadata.
* Filter commits that have no recorded operations (no mutations to the tree, no changed tree base durations).
I chose the first option, filtering by commits that have no reported metadata. It will miss an edge case, e.g. , but we would have nothing meaningful to show in the Profiler for those cases anyway. (This particular edge case is why one of the snapshots changed with this commit.)
The second option, filtering by recorded operations, could potentially miss a more important edge case: where a component *did* render, but its didn't change. (In that event, there would be no operations to send.)
As far as I can tell, the toString call was added here:
caae627cd5 (diff-5574f655d491348f422bca600ff6711dR887)
It was never really needed. Subsequently when we added Trusted Types,
this needed to be changed to a special call but we really should just
always let it pass through.
stateNode is not one of the fields that gets copied over by createWorkInProgress.
This is bad for persistent mode since it's not the same instance.
In HostComponent we happened to always end up transferring the current stateNode when we bail.
However, we didn't do this for HostText.
DevTools previously called in several places with user-defined values. This could lead to runtime errors if those values had an overriden attribute. This commit replaces those callse with instead.
New test cases have been added.
The Profiler stores:
1. A snapshot of the React tree when profiling started
2. The operations array for each commit
3. Profiling metadata (e.g. durations, what changed, etc) for each commit
It uses this information (snapshot + operations diff) to reconstruct the state of the application for a given commit as it's viewed in the Profiler UI. Because of this, it's very important that the operations and metadata arrays align. If they don't align, the profiler will be unable to correctly reconstruct the tree, and it will likely throw errors (like 'Could not find node…')
#16446 tracks a long-standing bug where these two arrays get misaligned. I am still not entirely sure what causes this bug, but with PR #17253, I exacerbated things by introducing another potential way for it to happen. This PR addresses the regression at least (and adds test coverage for it).
I will follow up this afternoon on the original #16446 issue. I think I may have a lead on what's happening at least, if not exactly an idea of how to reproduce it.
I used to disable the <- and -> buttons when you reached the beginning or end of the profiler data. This can be kind of annoying though when you just want to get to the last commit, and I don't think there's a good reason to enforce it anyway, so I backed that change out. The buttons now wrap around at the beginning or end of the list.
The param should probably be a generic type, but I'm not sure how to satisfy Flow with the current top-level Map. At least this adds basic coverage (which was missing before, oops).
Previously, when props/state contained a regexp, it was shown as an
empty object. This commit adds regexps as values in need of special
rehydration (like Symbols or TypedArrays), and display them as a user
might expect.
Co-authored-by: Zirak <zirakertan@gmail.com>
Moves the unit testing library for events into the `packages` directory so it can more easily be used in tests for other react packages, and mirrored internally to help with testing of event hooks we prototype in www.
Introduces a state machine around pointer events to produce more accurate mock
touch events. This allows multi-touch unit tests to be written entirely in
terms of mock pointer interactions, while producing the expected
'changedTouches', 'targetTouches', and 'touches' fields for mock touch events.
* Updated DevTools local development instructions to mention experimental build step
* Added a command to download latest experimental release (for DevTools)
* Updated build instructions for clarity
* Added build-for-devtools package alias
* Added rudimentary context menu hook and menu UI
* Added backend support for copying a value at a specific path for the inspected element
* Added backend support for storing a value (at a specified path) as a global variable
* Added special casing to enable copying undefined/unserializable values to the clipboard
* Added copy and store-as-global context menu options to selected element props panel
* Store global variables separately, with auto-incremented name (like browsers do)
* Added tests for new copy and store-as-global backend functions
* Fixed some ownerDocument/contentWindow edge cases
* Refactored context menu to support dynamic options
Used this mechanism to add a conditional menu option for inspecting the current value (if it's a function)
* Renamed "safeSerialize" to "serializeToString" and added inline comment
* Add feature flags
* Add Chunk type and constructor
* Wire up Chunk support in the reconciler
* Update reconciler to reconcile Chunks against the render method
This allows the query and args to be updated.
* Drop the ref. Chunks cannot have refs anyway.
* Add Chunk checks in more missing cases
* Rename secondArg
* Add test and fix lazy chunks
Not really a supported use case but for consistency I guess.
* Fix fragment test
* Favor fallthrough switch instead of case statements for work tags
Currently we're inconsistently handling tags that are only relevant
for certain flags. We should throw if the tag is not part of the built
feature flags. This should also mean that the case statements can be
eliminated.
We can achieve this effect by putting the invariant outside of the switch
and always early return in the switch. We already do this in beginWork.
This PR makes this consistent in other places.
* Fail if fundamental/scope tags are discovered without the flag on
* fix(dev-tools): fix show correct displayName with forwardRef in Dev Tools
allow set `displayName` after `React.forwardRef()`,
makesure Dev Tools show displayName as same as `getWrappedName` in `shared/getComponentName.js`
* Removed a little unnecessary/redundant code.
* Fixed lint error (removed unused var)
1. Enable nested values to be expanded/collapsed by clicking on values as well as keys.
2. Enable keys and values to be selectable (for copy-pasting purposes)
* Skip abandoned project folders in Jest config
This fixes a problem that occurs after renaming a package.
* Fix test_build_devtools to run test-build-devtools
* Exclude console.error plugin for DevTools packages
* Use correct release channel for DevTools tests
This should fix the createRoot error.
* Fix TZ dependent test
* Change DT job dependencies
* Replace all warning/lowPriWarning with console calls
* Replace console.warn/error with a custom wrapper at build time
* Fail the build for console.error/warn() where we can't read the stack
* Render phase updates can now be extracted from the pending queue
* Use a custom dispatcher for the second render pass
* Discard render phase updates if component throws
When aborting a render, we also need to throw out render phase updates.
Remove the updates from the queues so they do not persist to the next
render. We already did a single pass through the whole list of hooks, so
we know that any pending updates must have been dispatched during the
render phase. The ones that were dispatched before we started rendering
were already transferred to the current hook's queue.
* Improved inspected element props with inline previews
This mimics the inline preview shown by the brower console and dramatically improves the UX when inspecting deep values. I also updated tests to add more coverage for this new functionality.
* Cleaned up the DataView vs typed array check
* Added early bailouts to DevTools when generating preview strings for iterables/objects/arrays, to avoid doing unnecessary work
* prep for codemod
* prep warnings
* rename lint rules
* codemod for ifs
* shim www functions
* Handle more cases in the transform
* Thanks De Morgan
* Run the codemod
* Delete the transform
* Fix up confusing conditions manually
* Fix up www shims to match expected API
* Also check for low-pri warning in the lint rule
* Refactor Update Queues to Fix Rebasing Bug
Fixes a bug related to rebasing updates. Once an update has committed,
it should never un-commit, even if interrupted by a higher priority
update. The fix includes a refactor of how update queues work.
This commit is a combination of two PRs:
- #17483 by @sebmarkbage refactors the hook update queue
- #17510 by @acdlite refactors the class and root update queue
Landing one without the other would cause state updates to sometimes be
inconsistent across components, so I've combined them into a single
commit in case they need to be reverted.
Co-authored-by: Sebastian Markbåge <sema@fb.com>
Co-authored-by: Andrew Clark <git@andrewclark.io>
* Initialize update queue object on mount
Instead of lazily initializing update queue objects on the first update,
class and host root queues are created on mount. This simplifies the
logic for appending new updates and matches what we do for hooks.
Reverts b617db3d96.
Found some bugs when attempting to land in www. Reverting to fix master.
I'll land again *after* the change successfully land downstream.
Fixes a bug related to rebasing updates. Once an update has committed,
it should never un-commit, even if interrupted by a higher priority
update. The fix includes a refactor of how update queues work.
This commit is a combination of two PRs:
- #17483 by @sebmarkbage refactors the hook update queue
- #17510 by @acdlite refactors the class and root update queue
Landing one without the other would cause state updates to sometimes be
inconsistent across components, so I've combined them into a single
commit in case they need to be reverted.
Co-authored-by: Sebastian Markbåge <sema@fb.com>
Co-authored-by: Andrew Clark <git@andrewclark.io>
Tools like BetterTouchTool for macOS trigger middle-clicks with a 'buttons'
value that doesn't correspond to the middle-mouse button. To account for this
we also inspect the value of 'button'.
Close#17367
* Replace Babel plugin with an ESLint plugin
* Fix ESLint rule violations
* Move shared conditions higher
* Test formatting nits
* Tweak ESLint rule
* Bugfix: inside else branch, 'if' tests are not satisfactory
* Use a stricter check for exactly if (__DEV__)
This makes it easier to see what's going on and matches dominant style in the codebase.
* Fix remaining files after stricter check
* fix: make serializable data for bridge in react-devtools
* fix: add bigint data type in hydration
* refactor: remove console.log
* test: update unit tests for bigint in react-devtools
* We don't need the global state for this
* Move componentUpdateQueue and sideEffectTag out of global state
* Move firstWorkInProgressHook off global state
* Move remainingExpirationTime off global state
* Reset fiber to its current state if it throws
* Move rerender error check to avoid global state
This means that it's harder to find it since it's not in the dispatch
function's stack but we can add a DEV only one for that if we really
need it. Alternatively, we can check it in against the renderUpdates queue.
* Move next___Hook out of global state
* Assert that currentlyRenderingFiber is always set
When accessed, this should always be set. This could enforced by storing
this on the dispatcher for example.
* Add another test just to be safe
* Adjust SuspenseList CPU bound heuristic
In SuspenseList we switch to rendering fallbacks (or stop rendering further
rows in the case of tail="collapsed/hidden") if it takes more than 500ms
to render the list. The limit of 500ms is similar to the train model and
designed to be short enough to be in the not noticeable range.
This works well if each row is small because we time the 500ms range well.
However, if we have a few large rows then we're likely to exceed the limit
by a lot. E.g. two 480ms rows hits almost a second instead of 500ms.
This PR adjusts the heuristic to instead compute whether something has
expired based on the render time of the last row. I.e. if we think rendering
one more row would exceed the timeout, then we don't attempt.
This still works well for small rows and bails earlier for large rows.
The expiration is still based on the start of the list rather than the
start of the render. It should probably be based on the start of the render
but that's a bigger change and needs some thought.
* Comment
* [Fresh] Detect root updates more reliably
* [Fresh] Use WeakMap for root elements
* [Fresh] Make initial failures recoverable too
* Fix DevTools check
* Fix wrong flow type
* [eslint] Check forwardRef callbacks (#17220)
* [eslint] Make tests more realistic (#17220)
* [eslint] Check anonymous callback of React.memo for rules-of-hooks (#17220)
* [eslint] Add tests for callbacks not known to be components (#17220)
* [eslint] Correct comments and add another test (#17220)
Fixes a bug where `isPending` is only set to `true` if `startTransition`
is called from inside an input event. That's usually the case, but
not always.
Now it works regardless of where you call it.
* Move Flight DOM to Webpack Specific Packagee
We'll have Webpack specific coupling so we need to ensure that it can be
versioned separately from various Webpack versions. We'll also have builds
for other bundlers in the future.
* Move to peerDep
* Move DOM Flight Tests
* Merge ReactFlightIntegration into ReactFlightDOM
This was an integration test. We can add to it.
* Fix fixture paths
* Regression test: Effects dropped across roots
See #17066
* [Bugfix] Passive effects loop
The bug
-------
In a multi-root app, certain passive effects (`useEffect`) are never
fired. See #17066.
The underlying problem
----------------------
The implicit contract of `flushPassiveEffects` is that, right after
calling it, there should be no pending passive effects. In the normal
case, in concurrent mode, this is true. But the current implementation
fails to account for the case where a passive effect schedules
synchronous work, which in turn schedules additional passive effects.
This led to `rootWithPendingPassiveEffects` being overwritten in the
commit phase, because an assignment that assumed it was replacing null
was actually replacing a reference to another root, which has the
consequence of dropping passive effects on that root.
The fix
-------
The fix I've chosen here is, at the beginning of the commit phase, keep
flushing passive effects in a loop until there are no more.
This doesn't not change the "public" implementation of
`flushPassiveEffects`, though it arguably should work this way, too. I
say "public" because it's only used by implementation layers on top of
React which we control: mainly, the legacy version of `act` that does
not use the mock Scheduler build. So there's probably still a bug
in that `act` implementation.
I will address `act` in a follow-up. The ideal solution is to replace
the legacy `act` with one implemented directly in the renderer, using a
special testing-only build of React DOM. Since that requires a breaking
change, we'll need an interim solution. We could make the "public" `act`
recursively flush effects in a loop, as I've done for the commit phase.
However, I think a better solution is to stop automatically flushing the
synchronous update queue at the end of `flushPassiveEffects`, and
instead require the caller to explicitly call `flushSyncUpdateQueue` (or
the equivalent) if needed. This follows the same pattern we use
internally in the work loop, which is designed to avoid factoring
hazards like the one that resulted in this bug.
* Unify fields used for createRoot warning and event system
* Warn when doing createRoot twice on the same node
* Stricter check for modern roots
* Unmark asynchronously
* Fix Flow
* [Flight] Basic Integration Test
* Just act()
* Lint
* Remove unnecessary acts
* Use Concurrent Mode
* it.experimental
* Fix prod test by advancing time
* Don't observe initial state
* Return whether to keep flowing in Host config
* Emit basic chunk based streaming in the Flight server
When something suspends a new chunk is created.
* Add reentrancy check
The WHATWG API is designed to be pulled recursively.
We should refactor to favor that approach.
* Basic streaming Suspense support on the client
* Add basic suspense in example
* Add comment describing the protocol that the server generates
1. Add a Store test for memo, lazy, and forwardRef components
2. Remove dead code for React.lazy
3. Update DT tests to include HOC badge names in the serialized store
* [react-is] return correct typeOf value of forwardRef
* [react-devtools-shared] use correct displayName of memo(forwardRef(Component))
* [react-devtools-shared] add resolveFiberType and resolve fiber type of memo recursively
Resolving the fiber type of memo recursively before passing it to getDisplayName
will prevent it from displaying "Anonymous" as displayName for components
wrapped with both memo and forwardRef: memo(forwardRef(Component))
* rework resolveFiberType
There are two similar flags, `debugRenderPhaseSideEffects` and
`debugRenderPhaseSideEffectsForStrictMode`. The strict mode one is the
only one that is actually used. I think originally the theory is that
we would one day turn it on for all components, even outside strict
mode. But what we'll do instead is migrate everyone to strict mode.
The only place `debugRenderPhaseSideEffects` was being used was in
an internal test file. I rewrote those tests to use public APIs.
* Rename ReactFlightStreamer -> ReactFlightServer
* Unify Browser/Node stream tests into one file and use the client reader
* Defer to the actual ReactDOM for HTML rendering for now
This will need to use a variant of Fizz to do inline SSR in Flight.
However, I don't want to build the whole impl right now but also don't
want to exclude the use case yet. So I outsource it to the existing
renderer. Ofc, this doesn't work with Suspense atm.
* Change demo to server
* Expose client in package.json
* Reorganize tests
We don't want unit tests but instead test how both server and clients work
together. So this merges server/client test files.
* Fill in the client implementation a bit
* Use new client in fixture
* Add Promise/Uint8Array to lint rule
I'll probably end up deleting these deps later but they're here for now.
`it.experimental` marks that a test only works in Experimental builds.
It also asserts that a test does *not* work in the stable builds. The
main benefit is that we're less likely to accidentally expose an
experimental API before we intend. It also forces us to un- mark an
experimental test once it become stable.
* Add CodeSandbox CI Config
* Add default sandbox to build
* Make build more efficient and add scheduler
* Force build
* Add scheduler image
* Add scheduler/tracing to the build
* Force another build
* Add Flight Build and Unify HostFormat Config between Flight and Fizz
* Add basic resolution of models
* Add basic Flight fixture
Demonstrates the streaming protocol.
* Rename to flight-server to distinguish from the client parts
* Add Flight Client package and entry point
* Fix fixture
Already mounted rows that resuspend may be considered as part of a tail
if they're at the end. However, for purposes of the tail="..." option
they don't get deleted. We deal with that in cutOffTailIfNeeded.
However, if they're also the first to suspend in the "hidden" case, we have
a special case that deletes the actual rendered row. This needs to consider
if that row was already mounted or things go wrong.
* Failing test: DevTools hook freezes timeline
The DevTools hook calls `requestCurrentTime` after the commit phase has
ended, which has the accidnental consequence of freezing the start
time for subsequent updates. If enough time goes by, the next update
will instantly expire.
I'll push a fix in the next commit.
* Read current time without marking event start time
`requestCurrentTime` is only meant to be used for updates, because
subsequent calls within the same event will receive the same time.
Messing this up has bad consequences.
I renamed it to `requestCurrentTimeForUpdate` and created a new
function that returns the current time without the batching heuristic,
called `getCurrentTime`.
Swapping `requestCurrentTime` for `getCurrentTime` in the DevTools
hook fixes the regression test added in the previous commit.
Special version of Jest's `it` for experimental tests. Tests marked as
experimental will run **both** stable and experimental modes. In
experimental mode, they work the same as the normal Jest methods. In
stable mode, they are **expected to fail**. This means we can detect
when a test previously marked as experimental can be un-marked when the
feature becomes stable. It also reduces the chances that we accidentally
add experimental APIs to the stable builds before we intend.
I added corresponding methods for the focus and skip APIs:
- `fit` -> `fit.experimental`
- `it.only` -> `it.only.experimental` or `it.experimental.only`
- `xit` -> `xit.experimental`
- `it.skip` -> `it.skip.experimental` or `it.experimental.skip`
Since `it` is an alias of `test`, `test.experimental` works, too.
`yarn build` defaults to building in experimental mode. To opt-out, set
the `RELEASE_CHANNEL` environment variable to `stable`. This is the same
as what we do when running tests via `yarn test`, to make local
development easier.
* SuspenseList support in DevTools
This adds SuspenseList tags to DevTools so that the name properly shows
up.
It also switches to use the tag instead of Symbol type for Suspense
components. We shouldn't rely on the type for any built-ins since that
field will disappear from the fibers. How the Fibers get created is an
implementation detail that can change e.g. with a compiler or if we
use instanceof checks that are faster than symbol comparisons.
* Add SuspenseList test to shell app
* Add a failing test for SuspenseList bug
* Store lastEffect before rendering
We can't reset the effect list to null because we don't rereconcile the
children so we drop deletion effects if we do that.
Instead we store the last effect as it was before we started rendering
so we can go back to where it was when we reset it.
We actually already do something like this when we delete the last row
for the tail="hidden" mode so we had a field available for it already.
Without the enableSuspenseServerRenderer flag there will never be a boundary match. Also when it is enabled, there might not be a boundary match if something was conditionally rendered by mistake.
With this PR it will now client render the content of a Suspense boundary in that case and issue a DEV only hydration warning. This is the only sound semantics for this case.
Unfortunately, landing this will once again break #16938. It will be less bad though because at least it'll just work by client rendering the content instead of hydrating and issue a DEV only warning.
However, we must land this before enabling the enableSuspenseServerRenderer flag since it does this anyway.
I did notice that we special case fallback={undefined} due to our unfortunate semantics for that. So technically a workaround that works is actually setting the fallback to undefined on the server and during hydration. Then flip it on only after hydration. That could be a workaround if you want to be able to have a Suspense boundary work only after hydration for some reason.
It's kind of unfortunate but at least those semantics are internally consistent. So I added a test for that.
This changes the "default" retryTime to NoWork which schedules at Normal
pri.
Dehydrated bouundaries normally hydrate at Never priority except when they
retry where we accidentally increased them to Normal because Never was used
as the default value. This changes it so NoWork is the default.
Dehydrated boundaries however get initialized to Never as the default.
Therefore they now hydrate as Never pri unless their priority gets
increased by a forced rerender or selective hydration.
This revealed that erroring at this Never priority can cause an infinite
rerender. So I fixed that too.
If a JSX element has both a children prop and children (ie. <div children={childOne}>{childTwo}</div>), IE throws an Multiple definitions of a property not allowed in strict mode. This modifies the previous fix (which used an Object.assign) by making the duplicate children a sequence expression on the next prop/child instead so that ordering is preserved. For example:
```
<Component children={useA()} foo={useB()} children={useC()}>{useD()}</Component>
```
should compile to
```
React.jsx(Component, {foo: (useA(), useB()), children: (useC(), useD)})
```
I'm doing this here instead of in the downstream repo so that if the
sync diff gets reverted, it doesn't revert this, too.
Once the sync has landed, and the callers are updated in www, I will
remove this.
* Tests run in experimental mode by default
For local development, you usually want experiments enabled. Unless
the release channel is set with an environment variable, tests will
run with __EXPERIMENTAL__ set to `true`.
* Remove concurrent APIs from stable builds
Those who want to try concurrent mode should use the experimental
builds instead.
I've left the `unstable_` prefixed APIs in the Facebook build so we
can continue experimenting with them internally without blessing them
for widespread use.
* Turn on SSR flags in experimental build
* Remove prefixed concurrent APIs from www build
Instead we'll use the experimental builds when syncing to www.
* Remove "canary" from internal React version string
* Download correct artifacts for release channel
Experimental builds should pull artifacts from the
`process_artifacts_experimental` job.
I think instead of two separate CI workflows, a better approach might
be to build stable artifacts to the `build` directory and the
experimental artifacts to a `build_experimental` directory, and
generate both within the same workflow. This would take some work since
lots of things assume the output directory is `build`, but something
to consider in the future.
* Prevent experimental promotion to stable
Adds a check to the `prepare-stable` script to prevent experimental
builds from being published using stable semver versions.
* Don't bother including `unstable_` in error
The method names don't get stripped out of the production bundles
because they are passed as arguments to the error decoder.
Let's just always use the unprefixed APIs in the messages.
* Set up experimental builds
The experimental builds are packaged exactly like builds in the stable
release channel: same file structure, entry points, and npm package
names. The goal is to match what will eventually be released in stable
as closely as possible, but with additional features turned on.
Versioning and Releasing
------------------------
The experimental builds will be published to the same registry and
package names as the stable ones. However, they will be versioned using
a separate scheme. Instead of semver versions, experimental releases
will receive arbitrary version strings based on their content hashes.
The motivation is to thwart attempts to use a version range to match
against future experimental releases. The only way to install or depend
on an experimental release is to refer to the specific version number.
Building
--------
I did not use the existing feature flag infra to configure the
experimental builds. The reason is because feature flags are designed
to configure a single package. They're not designed to generate multiple
forks of the same package; for each set of feature flags, you must
create a separate package configuration.
Instead, I've added a new build dimension called the **release
channel**. By default, builds use the **stable** channel. There's
also an **experimental** release channel. We have the option to add more
in the future.
There are now two dimensions per artifact: build type (production,
development, or profiling), and release channel (stable or
experimental). These are separate dimensions because they are
combinatorial: there are stable and experimental production builds,
stable and experimental developmenet builds, and so on.
You can add something to an experimental build by gating on
`__EXPERIMENTAL__`, similar to how we use `__DEV__`. Anything inside
these branches will be excluded from the stable builds.
This gives us a low effort way to add experimental behavior in any
package without setting up feature flags or configuring a new package.
* Transfer any pending promises from inner boundary to list
For non-hidden modes, this boundary should commit so this shouldn't be
needed but the nested boundary can make a second pass which forces these
to be recreated without resuspending. In this case, the outer list assumes
that it can collect the inner promises to still rerender if needed.
* Propagate suspense "context" change to nested SuspenseLists
This means that we always rerender any nested SuspenseLists together.
This bug looks similar to the previous one but is not based on the lack of
retry but that the retry only happens on the outer boundary but the inner
doesn't get a retry ping since it didn't know about its own promise after
the second pass.
* Remove "Invariant Violation" from dev errors
When I made the change to compile `invariant` to throw expressions, I
left a small runtime to set the error's `name` property to "Invariant
Violation" to maintain the existing behavior.
I think we can remove it. The argument for keeping it is to preserve
continuity in error logs, but this only affects development errors,
anyway: production error messages are replaced with error codes.
* Pass prod error messages directly to constructor
Updates the `invariant` transform to pass an error message string
directly to the Error constructor, instead of mutating the
message property.
Turns this code:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
into this:
```js
if (!condition) {
throw Error(
__DEV__
? `A ${adj} message that contains ${noun}`
: formatProdErrorMessage(ERR_CODE, adj, noun)
);
}
```
* Updated DevTools shell ignore warning message to account for recent changes in warning text
* Update DevTools console patching to patch the parent window's console rather than the iframe, to more accurately simulate real usage environment
* Remove dormant createBatch experiment
In a hybrid React app with multiple roots, `createBatch` is used to
coordinate an update to a root with its imperative container.
We've pivoted away from multi-root, hybrid React apps for now to focus
on single root apps.
This PR removes the API from the codebase. It's possible we'll add back
some version of this feature in the future.
* Remove unused export
The `performance.now` returns a timestamp in milliseconds as a float.
The browser has the option to adjust the precision of the float, but
it's usually more precise than a millisecond. However, this precision
is lost when the timestamp is logged by the Scheduler profiler, because
we store the numbers in an Int32Array.
This change multiplies the millisecond float value by 1000, giving us
three more degrees of precision.
Adds an API to explicitly prioritize hydrating the path to a particular DOM node without relying on events to do it.
The API uses the current scheduler priority to schedule it. For the same priority, the last one wins. This allows a similar effect as continuous events. This is useful for example to hydrate based on scroll position, or prioritize components that will upgrade to client-rendered-only content.
I considered having an API that explicitly overrides the current target(s). However that makes it difficult to coordinate across components in an app.
This just hydrates one target at a time but if it is blocked on I/O we could consider increasing priority of later targets too.
Currently, when a node suspends, if its subtree contains a portal, the portal is not hidden. This hides portals in the subtree when it's not wrapped in a host component .
* Prioritize the last continuous target
This ensures that the current focus target is always hydrated first.
Slightly higher than the usual Never expiration time used for hydration.
The priority increases with each new queued item so that the last always
wins.
* Don't export the moving target
It's not useful for comparison purposes anyway.
The error transform works by replacing calls to `invariant` with
an `if` statement.
Since we're replacing a call expression with a statement, Babel wraps
the new statement in an immediately-invoked function expression (IIFE).
This wrapper is unnecessary in practice because our `invariant` calls
are always part of their own expression statement.
In the production bundle, the function wrappers are removed by Closure.
But they remain in the development bundles.
This commit updates the transform to confirm that an `invariant` call
expression's parent node is an expression statement. (If not, it throws
a transform error.)
Then, it replaces the expression statement instead of the expression
itself, effectively removing the extraneous IIFE wrapper.
* Regression test: Suspense + hydration + legacy
* Allow Suspense Mismatch on the Client to Silently Proceed
This fixes but isn't actually the semantics that we want this case to have.
* Update useEditableValue to mirror value cahnges
Previously, the hook initialized local state (in useState) to mirror the prop/state value. Updates to the value were ignored though. (Once the state was initialized, it was never updated.) The new hook updates the local/editable state to mirror the external value unless there are already pending, local edits being made.
* Optimistic CHANGELOG update
* Added additional useEditableValue() unit test cases
* Rename lowPriorityWarning to lowPriorityWarningWithoutStack
This maintains parity with the other warning-like functions.
* Duplicate the toWarnDev tests to test toLowPriorityWarnDev
* Make a lowPriorityWarning version of warning.js
* Extract both variants in print-warning
Avoids parsing lowPriorityWarning.js itself as the way it forwards the
call to lowPriorityWarningWithoutStack is not analyzable.
* Idle updates should not be blocked by hidden work
Use the special `Idle` expiration time for updates that are triggered at
Scheduler's `IdlePriority`, instead of `Never`.
The key difference between Idle and Never¹ is that Never work can be
committed in an inconsistent state without tearing the UI. The main
example is offscreen content, like a hidden subtree.
¹ "Never" isn't the best name. I originally called it that because it
"never" expires, but neither does Idle. Since it's mostly used for
offscreen subtrees, we could call it "Offscreen." However, it's also
used for dehydrated Suspense boundaries, which are inconsistent in the
sense that they haven't finished yet, but aren't visibly inconsistent
because the server rendered HTML matches what the hydrated tree would
look like.
* Reset as early as possible using local variable
* Updates in a hidden effect should be Idle
I had made them Never to avoid an extra render when a hidden effect
updates the hidden component -- if they are Idle, we have to render once
at Idle, which bails out on the hidden subtree, then again at Never to
actually process the update -- but the problem of needing an extra
render pass to bail out hidden updates already exists and we should fix
that properly instead of adding yet another special case.
PR #16752 changed how we were injecting the backend script to be done by the content script in order to work around Trusted Type limitations with our previous approach. This may have caused a regression (see #16840) so I'm backing it out to verify.
* Fixed a regression in hooks editor from a recent EditableValue change
* Fixed a reset/state bug in useEditableValue() hook and removed unnecessary useMemo()
* Outline push/pop logic in `renderRoot`
I want to get rid of the the `isSync` argument to `renderRoot`, and
instead use separate functions for concurrent and synchronous render.
As a first step, this extracts the push/pop logic that happens before
and after the render phase into helper functions.
* Extract `catch` block into helper function
Similar to previous commit. Extract error handling logic into
a separate function so it can be reused.
* Fork `renderRoot` for sync and concurrent
Removes `isSync` argument in favor of separate functions.
* Extra "root completion" logic to separate function
Moving this out to avoid an accidental early return, which would
bypass the call to `ensureRootIsScheduled` and freeze the UI.
* Inline `renderRoot`
Inlines `renderRoot` into `performConcurrentWorkOnRoot` and
`performSyncWorkOnRoot`. This lets me remove the `isSync` argument
and also get rid of a redundant try-catch wrapper.
* [suspense][error handling] Add failing unit test
Covers an edge case where an error is thrown inside the complete phase
of a component that is in the return path of a component that suspends.
The second error should also be handled (i.e. able to be captured by
an error boundary.
The test is currently failing because there's a call to
`completeUnitOfWork` inside the main render phase `catch` block. That
call is not itself wrapped in try-catch, so anything that throws is
treated as a fatal/unhandled error.
I believe this bug is only observable if something in the host config
throws; and, only in legacy mode, because in concurrent/batched mode,
`completeUnitOfWork` on fiber that throws follows the "unwind" path
only, not the "complete" path, and the "unwind" path does not call
any host config methods.
* [scheduler][profiler] Start time of delayed tasks
Fixes a bug in the Scheduler profiler where the start time of a delayed
tasks is always 0.
* Remove ad hoc `throw`
Fatal errors (errors that are not captured by an error boundary) are
currently rethrown from directly inside the render phase's `catch`
block. This is a refactor hazard because the code in this branch has
to mirror the code that happens at the end of the function, when exiting
the render phase in the normal case.
This commit moves the throw to the end, using a new root exit status.
* Handle errors that occur on unwind
* Add Event Replaying Infra
* Wire up Roots and Suspense boundaries, to retry events, after they commit
* Replay discrete events in order in a separate scheduler callback
* Add continuous events
These events only replay their last target if the target is not yet
hydrated. That way we don't have to wait for a previously hovered
boundary before invoking the current target.
* Enable tests from before
These tests were written with replaying in mind and now we can properly
enable them.
* Unify replaying and dispatching
* Mark system flags as a replay and pass to legacy events
That way we can check if this is a replay and therefore needs a special
case. One such special case is "mouseover" where we check the
relatedTarget.
* Eagerly listen to all replayable events
To minimize breakages in a minor, I only do this for the new root APIs
since replaying only matters there anyway. Only if hydrating.
For Flare, I have to attach all active listeners since the current
system has one DOM listener for each. In a follow up I plan on optimizing
that by only attaching one if there's at least one active listener
which would allow us to start with only passive and then upgrade.
* Desperate attempt to save bytese
* Add test for mouseover replaying
We need to check if the "relatedTarget" is mounted due to how the old
event system dispatches from the "out" event.
* Fix for nested boundaries and suspense in root container
This is a follow up to #16673 which didn't have a test because it wasn't
observable yet. This shows that it had a bug.
* Rename RESPONDER_EVENT_SYSTEM to PLUGIN_EVENT_SYSTEM
Makes sure that touch events with modifier keys behave the same way as other
pointer types (i.e., does not call `onTapStart` if the gesture begins with a
modifier key held down)
This is because the HostConfig can't be guaranteed to be consistent with
other code such as code that touches the DOM directly.
Ideally we'd have a more systemic solution to this since it will pop
up for other packages later too.
This patch limits the `onTap*` callbacks to the primary pointer button.
Auxiliary button and modified primary button interactions call
`onAuxiliaryTap`, cancel any active tap, and preserve the native behavior.
* prevent firefox marking required textareas invalid
Bug was caused by an IE10/IE11 bugfix dealing with the placeholder attribute and textContent. Solved by avoiding the IE bugfix when textContent was empty.
Closes#16402
* more explicit conditional check for textContent
re: @philipp-spiess code review
* clarify textarea test fixture's expected result
better describe the behavior we are testing for
re: @philipp-spiess code review
* [react-devtools-shared] Added string type check for object name prop in getDisplayName function from utils.js file; tests included;
* Re-added empty string check to getDisplayName()
* Tweaked tests to use real functions
This more closely simulates how the utility is being used in production, and would catch cases like anonymous functions (with empty string names).
This implements 'usePress' in user-space as a combination of 'useKeyboard' and 'useTap'. The existing 'usePress' API is preserved for now. The previous 'usePress' implementation is moved to 'PressLegacy'.
This accounts for all clicks that are natively dispatched following relevant
keyboard interactions (e.g., key is "Enter"), as well as programmatic clicks,
and screen-reader virtual clicks.
* Add trusted types to react on client side
* Implement changes according to review
* Remove support for trusted URLs, change TrustedTypes to trustedTypes
* Add support for deprecated trusted URLs
* Apply PR suggesstions
* Warn only once, remove forgotten check, put it behind a flag
* Move comment
* Fix PR comments
* Fix html toString concatenation
* Fix forgotten else branch
* Fix PR comments
If a Scheduler profile runs without stopping, the event log will grow
unbounded. Eventually it will run out of memory and the VM will throw
an error.
To prevent this from happening, let's automatically stop the profiler
once the log exceeds a certain limit. We'll also print a warning with
advice to call `stopLoggingProfilingEvents` explicitly.
* Support disabling interaction tracing for suspense promises
If a thrown Promise has the __reactDoNotTraceInteractions attribute, React will not wrapped its callbacks to continue tracing any current interaction(s).
* Added optional '__reactDoNotTraceInteractions' attribute to Flow Thenable type
This reverts commit ab4951fc03.
* Track "pending" and "suspended" ranges
A FiberRoot can have pending work at many distinct priorities. (Note: we
refer to these levels as "expiration times" to distinguish the concept
from Scheduler's notion of priority levels, which represent broad
categories of work. React expiration times are more granualar. They're
more like a concurrent thread ID, which also happens to correspond to a
moment on a timeline. It's an overloaded concept and I'm handwaving over
some of the details.)
Given a root, there's no convenient way to read all the pending levels
in the entire tree, i.e. there's no single queue-like structure that
tracks all the levels, because that granularity of information is not
needed by our algorithms. Instead we track the subset of information
that we actually need — most importantly, the highest priority level
that exists in the entire tree.
Aside from that, the other information we track includes the range of
pending levels that are known to be suspended, and therefore should not
be worked on.
This is a refactor of how that information is tracked, and what each
field represents:
- A *pending* level is work that is unfinished, or not yet committed.
This includes work that is suspended from committing.
`firstPendingTime` and `lastPendingTime` represent the range of
pending work. (Previously, "pending" was the same as "not suspended.")
- A *suspended* level is work that did not complete because data was
missing. `firstSuspendedTime` and `lastSuspendedTime` represent the
range of suspended work. It is a subset of the pending range. (These
fields are new to this commit.)
- `nextAfterSuspendedTime` represents the next known level that comes
after the suspended range.
This commit doesn't change much in terms of observable behavior. The one
change is that, when a level is suspended, React will continue working
on the next known level instead of jumping straight to the last pending
level. Subsequent commits will use this new structure for a more
substantial refactor for how tasks are scheduled per root.
* Get next expiration time from FiberRoot
Given a FiberRoot, we should be able to determine the next expiration
time that needs to be worked on, taking into account the levels that
are pending, suspended, pinged, and so on.
This removes the `expirationTime` argument from
`scheduleCallbackForRoot`, and renames it to `ensureRootIsScheduled` to
reflect the new signature. The expiration time is instead read from the
root using a new function, `getNextExpirationTimeToWorkOn`.
The next step will be to remove the `expirationTime` argument from
`renderRoot`, too.
* Don't bind expiration time to render callback
This is a fragile pattern because there's only meant to be a single
task per root, running at a single expiration time. Instead of binding
the expiration time to the render task, or closing over it, we should
determine the correct expiration time to work on using fields we
store on the root object itself.
This removes the "return a continuation" pattern from the
`renderRoot` function. Continuation handling is now handled by
the wrapper function, which I've renamed from `runRootCallback` to
`performWorkOnRoot`. That function is merely an entry point to
`renderRoot`, so I've also removed the callback argument.
So to sum up, at at the beginning of each task, `performWorkOnRoot`
determines which expiration time to work on, then calls `renderRoot`.
And before exiting, it checks if it needs to schedule another task.
* Update error recovery test to match new semantics
* Remove `lastPendingTime` field
It's no longer used anywhere
* Restart on update to already suspended root
If the work-in-progress root already suspended with a delay, then the
current render definitely won't finish. We should interrupt the render
and switch to the incoming update.
* Restart on suspend if return path has an update
Similar to the previous commit, if we suspend with a delay, and
something in the return path has a pending update, we should abort
the current render and switch to the update instead.
* Track the next unprocessed level globally
Instead of backtracking the return path. The main advantage over the
backtracking approach is that we don't have to backtrack from the source
fiber. (The main disadvantages are that it requires another module-level
variable, and that it could include updates from unrelated
sibling paths.)
* Re-arrange slightly to prevent refactor hazard
It should not be possible to perform any work on a root without
calling `ensureRootIsScheduled` before exiting. Otherwise, we could
fail to schedule a callback for pending work and the app could freeze.
To help prevent a future refactor from introducing such a bug, this
change makes it so that `renderRoot` is always wrapped in try-finally,
and the `finally` block calls `ensureRootIsScheduled`.
* Remove recursive calls to `renderRoot`.
There are a few leftover cases where `renderRoot` is called recursively.
All of them are related to synchronously flushing work before its
expiration time.
We can remove these calls by tracking the last expired level on the
root, similar to what we do for other types of pending work, like pings.
* Remove argument from performSyncWorkOnRoot
Read the expiration time from the root, like we do
in performConcurrentWorkOnRoot.
Our infra currently doesn't support loading a separate profiling
build of Scheduler. Until that's fixed, the recommendation is to load
a single build and gate the profiling feature behind a flag.
Alternative to #16659
* Moved backend injection logic to content script
* Moved backend injection logic to content script
* Moved injection logic to content script
* Formatting changes
* remove ability to inject arbitrary scripts
* Removed done(), added some comments explaining the change
* Lint fixes
* Moved inline comment.
* Deleted inject() script since it was no longer being used
* Track "pending" and "suspended" ranges
A FiberRoot can have pending work at many distinct priorities. (Note: we
refer to these levels as "expiration times" to distinguish the concept
from Scheduler's notion of priority levels, which represent broad
categories of work. React expiration times are more granualar. They're
more like a concurrent thread ID, which also happens to correspond to a
moment on a timeline. It's an overloaded concept and I'm handwaving over
some of the details.)
Given a root, there's no convenient way to read all the pending levels
in the entire tree, i.e. there's no single queue-like structure that
tracks all the levels, because that granularity of information is not
needed by our algorithms. Instead we track the subset of information
that we actually need — most importantly, the highest priority level
that exists in the entire tree.
Aside from that, the other information we track includes the range of
pending levels that are known to be suspended, and therefore should not
be worked on.
This is a refactor of how that information is tracked, and what each
field represents:
- A *pending* level is work that is unfinished, or not yet committed.
This includes work that is suspended from committing.
`firstPendingTime` and `lastPendingTime` represent the range of
pending work. (Previously, "pending" was the same as "not suspended.")
- A *suspended* level is work that did not complete because data was
missing. `firstSuspendedTime` and `lastSuspendedTime` represent the
range of suspended work. It is a subset of the pending range. (These
fields are new to this commit.)
- `nextAfterSuspendedTime` represents the next known level that comes
after the suspended range.
This commit doesn't change much in terms of observable behavior. The one
change is that, when a level is suspended, React will continue working
on the next known level instead of jumping straight to the last pending
level. Subsequent commits will use this new structure for a more
substantial refactor for how tasks are scheduled per root.
* Get next expiration time from FiberRoot
Given a FiberRoot, we should be able to determine the next expiration
time that needs to be worked on, taking into account the levels that
are pending, suspended, pinged, and so on.
This removes the `expirationTime` argument from
`scheduleCallbackForRoot`, and renames it to `ensureRootIsScheduled` to
reflect the new signature. The expiration time is instead read from the
root using a new function, `getNextExpirationTimeToWorkOn`.
The next step will be to remove the `expirationTime` argument from
`renderRoot`, too.
* Don't bind expiration time to render callback
This is a fragile pattern because there's only meant to be a single
task per root, running at a single expiration time. Instead of binding
the expiration time to the render task, or closing over it, we should
determine the correct expiration time to work on using fields we
store on the root object itself.
This removes the "return a continuation" pattern from the
`renderRoot` function. Continuation handling is now handled by
the wrapper function, which I've renamed from `runRootCallback` to
`performWorkOnRoot`. That function is merely an entry point to
`renderRoot`, so I've also removed the callback argument.
So to sum up, at at the beginning of each task, `performWorkOnRoot`
determines which expiration time to work on, then calls `renderRoot`.
And before exiting, it checks if it needs to schedule another task.
* Update error recovery test to match new semantics
* Remove `lastPendingTime` field
It's no longer used anywhere
* Restart on update to already suspended root
If the work-in-progress root already suspended with a delay, then the
current render definitely won't finish. We should interrupt the render
and switch to the incoming update.
* Restart on suspend if return path has an update
Similar to the previous commit, if we suspend with a delay, and
something in the return path has a pending update, we should abort
the current render and switch to the update instead.
* Track the next unprocessed level globally
Instead of backtracking the return path. The main advantage over the
backtracking approach is that we don't have to backtrack from the source
fiber. (The main disadvantages are that it requires another module-level
variable, and that it could include updates from unrelated
sibling paths.)
* Re-arrange slightly to prevent refactor hazard
It should not be possible to perform any work on a root without
calling `ensureRootIsScheduled` before exiting. Otherwise, we could
fail to schedule a callback for pending work and the app could freeze.
To help prevent a future refactor from introducing such a bug, this
change makes it so that `renderRoot` is always wrapped in try-finally,
and the `finally` block calls `ensureRootIsScheduled`.
* Remove recursive calls to `renderRoot`.
There are a few leftover cases where `renderRoot` is called recursively.
All of them are related to synchronously flushing work before its
expiration time.
We can remove these calls by tracking the last expired level on the
root, similar to what we do for other types of pending work, like pings.
* Remove argument from performSyncWorkOnRoot
Read the expiration time from the root, like we do
in performConcurrentWorkOnRoot.
This happens for example when a deleted boundary transfers its pending
promises to the list so that the list can be retried.
This wasn't caught by unit tests because this flag wasn't on in those
tests.
* Fix DevTools new prop input size
* Don't allow adding new values unless an overridePropsFn function has been provided.
* Do not show empty 'none' label ablve a new prop input
* Extracted sanitizeForParse
* Added canAddEntries flag to InspectedElementTree
* Added EditableKey component.
* Added support to add an additional entry.
* Added support to add more complex data structures in the EditableValue component. Added support to change the dataType of the value that is being changed.
* Fixed flow error.
* Removed unneeded fragment.
* Renamed EditableKey -> EditableName
* Removed unneeded dependency
* Removed problematic props to state hook.
* Prettified changes.
* Removed unused import.
* Fixed shouldStringify check.
* Removed testing props from EditableProps.
* Made some inline tweaks
* Correct link for troubleshooting react-dev-tools (#16690)
As pointed out in #16690 - the link for 'React Tab Doesn't Show Up' points to the empty README.MD.
This points it to that section in the v3 version README.MD - until an updated section will be added to the new dev-tools.
* Add a "The React Tab Doesn't Show Up" section
Add the troubleshooting section to the react dev tools readme
* point to the correct section in react-dev-tools readme
After adding the troubleshooting section to the readme - this will point to the correct place
* Moved README file to GitHub
* Update new issue link to include DevTools label
If we find a Container that might mean that we're on a node that is inside
a Suspense boundary that is directly inside the Container root.
Imagine the div is a Container and the span is a dehydrated instance:
```
<div>
<!--$-->
<span />
<!--/$-->
</div>
```
There's no way to tests this yet since I'm not actually utilizing
the return value yet.
The solution is to just use the same path to check for a Suspense boundary
as if we find a parent instance.
* Don't invoke listeners on parent of dehydrated event target
* Move Suspense boundary check to getClosestInstanceFromNode
Now getClosestInstanceFromNode can return either a host component,
host text component or suspense component when the suspense
component is dehydrated.
We then use that to ignore events on a suspense component.
* Attach the HostRoot fiber to the DOM container
This lets us detect if an event happens on this root's subtree before it
has rendered something.
* Add todo
The approach of checking isFiberMounted answers if we might be in an
in-progress hydration but it doesn't answer which root or boundary
might be in-progress so we don't know what to wait for.
This needs some refactoring.
* Refactor isFiberMountedImpl to getNearestMountedFiber
We'll need the nearest boundary for event replaying so this prepares for
that.
This surfaced an issue that we attach Hydrating tag on the root but normally
this (and Placement) is attached on the child. This surfaced an issue
that this can lead to both Placement and Hydrating effects which is not
supported so we need to ensure that we only ever use one or the other.
* Add todo for bug I spotted
* Cache tags
* Check the ContainerInstanceKey before the InstanceKey
The container is inside the instance, so we must find it before the
instance, since otherwise we'll miss it.
This is a partial replacement for the 'Press' responder:
1. `useTap` is scoped to pointers (no keyboard support). Our current thinking is
that "responders" should be limited to working with pointers, and that they can
be combined with 'useKeyboard' in user-space. For example, we might create a
'usePress' hook in user-space that combines 'useTap' with 'useKeyboard' to react
to both pointers and keyboard interactions.
2. `useTap` cancels the gesture once the pointer moves over an element that is
not within the responder target's subtree. This differs from `usePress` (and
React Native), where the gesture remains active after the pointer exits the
target's subtree and is restarted once the pointer reenters. One of the
drawbacks with the `usePress` behavior is that it requires repeatedly measuring
DOM elements (which can cause jank) to perform hit region tests. `useTap` avoids
doing this and relies on `document.elementFromPoint` only to support the
TouchEvent fallbacks.
3. `useTap` calls `onTapUpdate` when the active gesture's state changes,
`onTapEnd` when the gesture successfully completes. and `onTapCancel` when it
fails. There is no `onTap` callback. `usePress` did not explicitly report back
when the gesture failed, and product developers were confused about the
difference between `onPress` and `onPressEnd`.
4. `useTap` explicitly separates the PointerEvent implementation from the
MouseEvent/TouchEvent fallback.
5. `useTap` has better unit test coverage . All pointer types and the fallback
environment are tested. The shape of the gesture state object is also defined
and tested.
* Added anchor dom element in order to successfully download profiling data.
* Reworked downloadFile to accept a DOMElement in order for FF to successfully download profiling data.
* Prettify downloadFile changes.
In order to foster healthy open source communities, we're adopting the
[Contributor Covenant](https://www.contributor-covenant.org/). It has been
built by open source community members and represents a shared understanding of
what is expected from a healthy community.
This babel transform is a fork of the @babel/plugin-transform-react-jsx transform and is for experimentation purposes only. We don't plan to own this code in the future, and we will upstream this to Babel at some point once we've proven out the concept.
As per the RFC to simplify element creation, we want to change the JSX transform from targeting React.createElement(type, props, children) to React.jsx(type, props, key). This modifies the existing @babel/plugin-transform-react-jsx (and helper) babel plugin to support React.jsx and React.jsxDEV.
The main differences between React.jsx/React.jsxDEV and React.createElement are:
1.) key is now passed as an explicit argument rather than through props
3.) children are now passed through props rather than as an explicit argument
4.) props must always be an object
5.) __source and and __self are now passed as separate arguments into React.jsxDEV rather than through props
Part of the rationale for this change is that we want to deprecate key spread through props because this is an expensive dynamic comparison operation. We want users instead always explicitly pass key as a prop. However, in the interim, we need a way to distinguish between <div {...props} key={foo} /> and <div key={foo} {...props} />. Therefore, until we completely deprecate key spreading, we will use React.createElement to transform <div {...props} key="Hi" /> and React.jsx to transform everything else.
* Revert "Revert "[Scheduler] Profiling features (#16145)" (#16392)"
This reverts commit 4ba1412305.
* Fix copy paste mistake
* Remove init path dependency on ArrayBuffer
* Add a regression test for cancelling multiple tasks
* Prevent deopt from adding isQueued later
* Remove pop() calls that were added for profiling
* Verify that Suspend/Unsuspend events match up in tests
This currently breaks tests.
* Treat Suspend and Resume as exiting and entering work loop
Their definitions used to be more fuzzy. For example, Suspend didn't always fire on exit, and sometimes fired when we did _not_ exit (such as at task enqueue).
I chatted to Boone, and he's saying treating Suspend and Resume as strictly exiting and entering the loop is fine for their use case.
* Revert "Prevent deopt from adding isQueued later"
This reverts commit 9c30b0b695d81e9c43b296ab93d895e4416ef713.
Unnecessary because GCC
* Start counter with 1
* Group exports into unstable_Profiling namespace
* No catch in PROD codepath
* No label TODO
* No null checks
* Refactor a bit to use less property access
* Add test for invoking an event before mount
* Add Hydration effect tag
This is equivalent to a "Placement" effect in that it's a new insertion
to the tree but it doesn't need an actual mutation.
It is only used to determine if a subtree has actually mounted yet.
* Use the Hydration flag for Roots
Previous roots had a Placement flag on them as a hack for this case but
since we have a special flag for it now, we can just use that.
* Add Flare test
The semantics of 'button' on events differs between PointerEvent and
MouseEvent, whereas they are the same for 'buttons'. Furthermore, 'buttons'
allows developers to determine when multiple buttons are pressed as the same
time.
https://w3c.github.io/pointerevents/#the-button-property
* Add a way to skip/only tests to RulesOfHooks test
* [ESLint] Forbid top-level use*() calls
* Add a regression test for logical expressions
This is not a change. Just adding more coverage.
This patch formalizes the mock native events and event sequences used in unit tests.
The `createEventTarget` function returns an object that can be used to dispatch native event sequences on the target without having to manually do so across all the scenarios we need to account for. Unit tests can be written as if we were only working with PointerEvent, but they will dispatch realistic native event sequences based on the execution environment (e.g., is PointerEvent supported?) and pointer type.
```
describe.each(environments)('Suite', (hasPointerEvents) => {
beforeEach(() => {
// setup
});
test.each(pointerTypes)('Test', (pointerType) => {
const target = createEventTarget(node);
target.pointerdown({pointerType});
expect(callback).toBeCalled();
});
});
```
Every native event that is dispatched now includes a complete object by default. The properties of the events can be customized. Properties that shouldn't be relied on in responder implementations are excluded from the mock native events to ensure tests will fail. Equivalent properties are normalized across different event types, e.g., 'pointerId' is converted to 'identifier' before a TouchEvent is dispatched.
1. Run the tests in both an environment without PointerEvent and one with PointerEvent.
2. Improve test coverage to include both mouse and touch pointers.
3. Change 'Press' so that it only listens to either pointer events or fallbacks events.
* Fixed issue with def being undefined while referencing arguments.
* Removed todo comment.
* Skip exhaustive deps check if def is null.
* Fixed code formatting in ExhaustiveDeps.
* Removed unneeded comment in ExhaustiveDeps.
* [Scheduler] Mark user-timing events
Marks when Scheduler starts and stops running a task. Also marks when
a task is initially scheduled, and when Scheduler is waiting for a
callback, which can't be inferred from a sample-based JavaScript CPU
profile alone.
The plan is to use the user-timing events to build a Scheduler profiler
that shows how the lifetime of tasks interact with each other and
with unscheduled main thread work.
The test suite works by printing an text representation of a
Scheduler flamegraph.
* Expose shared array buffer with profiling info
Array contains
- the priority Scheduler is currently running
- the size of the queue
- the id of the currently running task
* Replace user-timing calls with event log
Events are written to an array buffer using a custom instruction format.
For now, this is only meant to be used during page start up, before the
profiler worker has a chance to start up. Once the worker is ready, call
`stopLoggingProfilerEvents` to return the log up to that point, then
send the array buffer to the worker.
Then switch to the sampling based approach.
* Record the current run ID
Each synchronous block of Scheduler work is given a unique run ID. This
is different than a task ID because a single task will have more than
one run if it yields with a continuation.
Provides partial support for React.lazy() components from the existing PartialRenderer server-side renderer.
Lazy components which are already resolved (or rejected), perhaps with something like `react-ssr-prepass`, can be continued into synchronously. If they have not yet been initialized, they'll be initialized before checking, opening the possibility to exploit this capability with a babel transform. If they're pending (which will typically be the case for a just initialized async ctor) then the existing invariant continues to be thrown.
* Test that we can suspend updates while waiting to hydrate
* Attempt hydration at a higher pri first if props/context changes
* Retrying a dehydrated boundary pings at the earliest forced time
This might quickly become an already expired time.
* Mark the render as delayed if we have to retry
This allows the suspense config to kick in and we can wait for much longer
before we're forced to give up on hydrating.
If we get an insertion after a boundary, that has not yet been hydrated,
we take our best guess at which state the HTML is showing.
isSuspenseInstancePending means that we're still waiting for more server
HTML before we can hydrate. This should mean that we're showing the
fallback state.
isSuspenseInstanceFallback means that we want to client render something.
That most likely means that the server was unable to render and is
displaying a fallback state in this slot.
Adds tests to ensure that dehydrated components don't consider the force
flag.
* Move dehydrated to be child of regular SuspenseComponent
We now store the comment node on SuspenseState instead and that indicates
that this SuspenseComponent is still dehydrated.
We also store a child but that is only used to represent the DOM node for
deletions and getNextHostSibling.
* Move logic from DehydratedSuspenseComponent to SuspenseComponent
Forked based on SuspenseState.dehydrated instead.
* Retry logic for dehydrated boundary
We can now simplify the logic for retrying dehydrated boundaries without
hydrating. This is becomes simply a reconciliation against the dehydrated
fragment which gets deleted, and the new children gets inserted.
* Remove dehydrated from throw
Instead we use the regular Suspense path. To save code, we attach retry
listeners in the commit phase even though technically we don't have to.
* Pop to nearest Suspense
I think this is right...?
* Popping hydration state should skip past the dehydrated instance
* Split mount from update and special case suspended second pass
The DidCapture flag isn't used consistently in the same way. We need
further refactor for this.
* Reorganize update path
If we remove the dehydration status in the first pass and then do a second
pass because we suspended, then we need to continue as if it didn't
previously suspend. Since there is no fragment child etc.
However, we must readd the deletion.
* Schedule context work on the boundary and not the child
* Warn for Suspense hydration in legacy mode
It does a two pass render that client renders the content.
* Rename DehydratedSuspenseComponent -> DehydratedFragment
This now doesn't represent a suspense boundary itself. Its parent does.
This Fiber represents the fragment around the dehydrated content.
* Refactor returns
Avoids the temporary mutable variables. I kept losing track of them.
* Add a comment explaining the type.
Placing it in the type since that's the central point as opposed to spread
out.
This is a bad bug. It means that we sometimes inherit
didReceiveUpdate from a previous component's begin.
Effectively this only means that we're overrendering in some cases.
We should refactor to get rid of this as a global flag.
* Disabled (with a follow up TODO) the call in the reload-and-profile toggle.
* Disabled reload-and-profile in Firefox extension for now, since it was triggering a disconnected port error.
* Fixed Safari layout bug that caused profiler charts to be hidden.
Separate the PointerEvent and fallback implementations.
Fix the unit tests to cover both PointerEvent and non-PointerEvent environments.
Fix the focus-visible related callbacks to get called when keys other than "Tab" are used.
@acdlite while browsing Twitter, I saw [an opportunity][1] to do
something more productive than browsing Twitter.
[1]: https://twitter.com/acdlite/status/1160247965908234240
Test plan:
`yarn flow-ci`, `yarn test-prod`, `yarn lint`
This code is being compiled incorrectly by something in the Facebook
build pipeline. I'm removing it temporarily to unblock the sync while
we investigate.
Currently this is getting marked as Never which is the normal continuation
for a dehydrated boundary, but if it is client-rendered it has a higher
priority. That causes us to drop the interaction tracing for that render.
This colocates the marking where we actually set the expiration time.
**Problem**
The existing responders listen to pointer events by default and add fallback events if PointerEvent is not supported. However, this complicates the responders and makes it easy to create a problematic unit test environment. jsdom doesn't support PointerEvent, which means that the responders end up listening to pointer events *and* fallback events in unit tests. This isn't a direct problem in production environments, because no browser will fire pointer events if they aren't supported. But in the unit test environment, we often dispatch event sequences taken from browsers that support pointer events. This means that what we're often testing is actually a (complex) scenario that cannot even occur in production: a responder that is listening to and receives both pointer events and fallback events. Not only does this risk making responders more complicated to implement but it could also hide bugs in implementations.
**Response**
Implement the responders so that they're only listening to *either* pointer events *or* fallback events, never both. This should make the default pointer events implementations significantly simpler and easier to test, as well as free to rely on the complete PointerEvents API. In the future it should also make DCE easier for target environments that are known to support PointerEvents, as we can use build tools with an equivalent of the runtime check. The fallback events (touch and mouse) need to coexist and be resilient to browser emulated events. Our unit tests should express a suite of high-level interactions that can be run in environments with and without PointerEvents support.
These were discovered by @SimenB in https://github.com/facebook/react/pull/16332. We weren't making actual assertions on some values. This PR makes the assertions, and fixes the tests.
In a previous version of act(), we used a dummy dom element to flush effects. This doesn't need to exist anymore, and this PR removes it. The warning doesn't need to be there either (React will fire a wrong renderer act warning if needed).
When React detects a deprectated/unsafe lifecycle method, the warning points to a page with more details on the why/what of the warning. However, the actual link (https://fb.me/react-async-component-lifecycle-hooks) uses the phrase "lifecycle-hooks" which is confusing since it doesn't have anything to do with hooks. This PR changes the link to something less confusing - https://fb.me/react-unsafe-component-lifecycles.
Upgraded from Babel 6 to Babel 7.
The only significant change seems to be the way `@babel/plugin-transform-classes` handles classes differently from `babel-plugin-transform-es2015-classes`. In regular mode, the former injects a `_createClass` function that increases the bundle size, and in the latter it removes the safeguard checks. However, this is okay because we don't all classes in new features, and we want to deprecate class usage in the future in the react repo.
Co-authored-by: Luna Ruan <luna@fb.com>
Co-authored-by: Abdul Rauf <abdulraufmujahid@gmail.com>
Co-authored-by: Maksim Markelov <maks-markel@mail.ru>
* [Scheduler] Store Tasks on a Min Binary Heap
Switches Scheduler's priority queue implementation (for both tasks and
timers) to an array-based min binary heap.
This replaces the naive linked-list implementation that was left over
from the queue we once used to schedule React roots. A list was arguably
fine when it was only used for roots, since the total number of roots is
usually small, and is only 1 in the common case of a single-page app.
Since Scheduler is now used for many types of JavaScript tasks (e.g.
including timers), the total number of tasks can be much larger.
Binary heaps are the standard way to implement priority queues.
Insertion is O(1) in the average case (append to the end) and O(log n)
in the worst. Deletion is O(log n). Peek is O(1).
* Sophie nits
We might reenter a hydration state, when attempting to hydrate a boundary.
We need to ensure that we reset it to not hydrating once we exit it.
Otherwise the next sibling will still be in hydration mode.
This happens in this case: `<!--$!--><!--$!-->...<!--/$--><!--/$-->...`
getNextHydratableInstanceAfterSuspenseInstance didn't take
SUSPENSE_FALLBACK_START_DATA or SUSPENSE_PENDING_START_DATA into account
so if a boundary was in one of those states, it wouldn't be considered to
push the stack of boundaries. As a result the first end comment was
considered the end but it really should've been the second end comment.
The next comment then would've been considered something that can be
skipped. However, since the logic in there considered all comments as
"hydratable", it was considered a hydratable node. Since it was considered
a node that didn't actually correspond to anything in the React tree it got
deleted.
The HTML is now `<!--$!--><!--$!-->...<!--/$-->...` and the trailing
content is now hydrated since it did match something.
Next, since this was client rendered, we're going to delete the suspended
boundary by calling clearSuspenseBoundary and then inserting new content.
However, clearSuspenseBoundary *is* aware of SUSPENSE_FALLBACK_START_DATA
and assumes that there must be another `<!--/$-->` after the first one.
As a result it deleted the trailing content from the DOM since it should
be part of the boundary. However, those DOM nodes were already hydrated in
the React tree. So we end up in an inconsistent state.
When we then try to insert the new content we throw as a result.
I think we would have recovered correctly if clearSuspenseBoundary and
getNextHydratableInstanceAfterSuspenseInstance had the *same* bug but
because they were inconsistent we ended up in a bad place.
We have behaviour divergence for act() between prod and dev (specifically, act() + concurrent mode does not flush fallbacks in prod. This doesn't affect anyone in OSS yet)
We also don't have a good story for writing tests in prod (and what from what I gather, nobody really writes tests in prod mode).
We could have wiped out act() in prod builds, except that _we_ ourselves use act() for our tests when we run them in prod mode.
This PR is a compromise to all of this. We will log a warning if you try to use act() in prod mode, and we silence it in our test suites.
When React schedules a rendering task, it passes a `timeout` option
based on its expiration time. This is intended to avoid starvation
by other React updates. However, it also affects the relative priority
of React tasks and other Scheduler tasks at the same level, like
data processing.
This adds a feature flag to disable passing a `timeout` option to
Scheduler. React tasks will always append themselves to the end of
the queue, without jumping ahead of already scheduled tasks.
This does not affect the order in which React updates within a single
root are processed, but it could affect updates across multiple roots.
This also doesn't remove the expiration from Scheduler. It only means
that React tasks are not given special treatment.
Previously, the suspense priority warning was fired even if the Root wasn't suspended. Changed the warning to fire only when the root is suspended.
Also refactored the suspense priority warning so it's easier to read.
The clean-up function of a passive effect (`useEffect`) usually fires
in a post-commit task, after the browser has painted. However, there is
an exception when the component (or its parent) is deleted from the
tree. In that case, we fire the clean-up function during the
synchronous commit phase, the same phase we use for layout effects.
This is a concession to implementation complexity. Calling it in the
passive effect phase would require either traversing the children of the
deleted fiber again, or including unmount effects as part of the fiber
effect list.
Because the functions are called during the sync phase in this case,
the Scheduler priority is Immediate (the one used for layout) instead
of Normal. We may want to reconsider this trade off later.
If there are adjacent updates we bail out of rendering the suspense list
at all but we may still complete the node. We need to reset the render
state in that case.
I restructured so that this is in the same code path so we don't forget it
in the future.
* Add a feature flag to disable legacy context
* Address review
- invariant -> warning
- Make this.context and context argument actually undefined
* Increase test coverage for lifecycles
* Also disable it on the server is flag is on
* Make this.context {} when disabled, but function context is undefined
* Move checks inside
This wasn't reliable because of browser extension API limitations and required serious throttling to avoid harming performance, so I've decided to just remove it entirely for now.
This dialog is shown in the browser extension the first time a user views v4. It is off by default for the standalone extension, but can be enabled via a public API.
* [act] Wrap IsThisRendererActing in DEV check
So that it doesn't leak into the production bundle. Follow-up to #16240.
* Disable Suspense fallback test in prod
* Bugfix: Priority when effects are flushed early
The priority of passive effects is supposed to be the same as the
priority of the render. This fixes a bug where the priority is sometimes
wrong if the effects are flushed early.
But the priority should really never be higher than Normal Priority.
I'll change that in the next commit.
* Effects never have higher than normal priority
Effects currently have the same priority as the render that spawns them.
This changes the behavior so that effects always have normal priority,
or lower if the render priority is lower (e.g. offscreen prerendering).
The implementation is a bit awkward because of the way `renderRoot`,
`commitRoot`, and `flushPassiveEffects` are split. This is a known
factoring problem that I'm planning to address once 16.9 is released.
In this PR, for tests (specifically, code inside an `act()` scope), we immediately trigger work that would have otherwise required a timeout. This makes it simpler to tests loading/spinner states, and makes tests resilient to changes in React.
For some of our tests(specifically, ReactSuspenseWithNoopRenderer-test.internal), we _don't_ want fallbacks to immediately trigger, because we're testing intermediate states and such. Added a feature flag `flushSuspenseFallbacksInTests` to disable this behaviour on a per case basis.
Concurrent/Batched mode tests should always be run with a mocked scheduler (v17 or not). This PR adds a warning for the same. I'll put up a separate PR to the docs with a page detailing how to mock the scheduler.
This change adds support for element inspecting within `<iframe/>`s.
The iframes are kept in a Set so that we only append listeners once and
clean them up properly. I’ve run a few tests and it seems to behave as
expected.
The fixture includes a cross-origin iframe to make sure we do not error
in this case.
1. Compare element indices rather than ids (since these don't necessarily correlate)
2. Restored previous behaior when new search text reduces the number of results past the currently-selected element.
Merge PR #353 from @fanny
This change changes search beahvior to initially select the result nearest the currently selected element (rather than selecting the first result in the set).
Adds experimental flag to yield many times per frame using a message
event loop, instead of the current approach of guessing the next vsync
and yielding at the end of the frame.
This new approach forgoes a `requestAnimationFrame` entirely. It posts a
message event and performs a small amount of work (5ms) before yielding
to the browser, regardless of where it might be in the vsync cycle. At
the end of the event, if there's work left over, it posts another
message event.
This should keep the main thread responsive even for really high frame
rates. It also shouldn't matter if the hardware frame rate changes after
page load (our current heuristic only detects if the frame rate
increases, not decreases).
The main risk is that yielding more often will exacerbate main thread
contention with other browser tasks.
Let's try it and see.
CSS source maps require the style-loader to use URL.createObjectURL (rather than just a <style> tag). For some reason, this crashes Electron's webview process, which completely breaks the embedded extension inside of Nuclide and other Electron apps. This commit turns (CSS) source maps off for production builds to avoid this crash.
* Do not hyphenate custom CSS property
* Move check into the processStyleName fn
* Formatting
* add test
* Put isCustomProperty check after conditional return
* add test to `ReactDOMServerIntegration` and supress warning
* Don't indexOf twice
* Simpler fix
Not returning the value of flushPassiveEffects() in flushWork() meant that with async act, we wouldn't flush all work with cascading effects. This PR fixes that oversight, and adds some tests to catch this in the future.
The Scheduler implementation uses browser APIs like `MessageChannel`,
`requestAnimationFrame`, and `setTimeout` to schedule work on the main
thread. Most of our tests treat these as implementation details;
however, the sequence and timing of these APIs are not precisely
specified, and can vary wildly across browsers.
To prevent regressions, we need the ability to simulate specific edge
cases that we may encounter in various browsers.
This adds a new test suite that mocks all browser methods used in our
implementation. It assumes as little as possible about the order and
timing of events. The only thing it assumes is that
requestAnimationFrame is passed a frame time that is equal to or less
than the time returned by performance.now. Everything else can be
controlled at will.
It also includes Scheduler-specific invariants, e.g. only one rAF
callback can be scheduled at a time.
It overlaps slightly with the existing SchedulerDOM-test suite, which
also mocks the browser APIs, but exposes a higher-level set of testing
primitives. I will consolidate the two suites in a follow-up.
But only do this if we can verify the element file path. This hopefully avoids the case where clicking the button does nothing because of an invalid/incomplete path.
* Added shadow to modals
* Change default "collapse new nodes" to be disabled rather than enabled
* Changed setting label "Collapse newly added components by default" to "Expand component tree by default"
* Change CSS media query for settings popup to show labels at smaller size
* Hide "Inspect the matching DOM element" button (since it doesnt really serve a purpose in standalone)
* Fixed small size bug for settings icon (viewbox of 20x20 instead of 24x24)
* bugfix: window.addEventListener/window.removeEventListener is not defined in Hermes.
This adds a 'SuspenseCallback' feature flag. When the property is set on
a suspense component it will be called during the commit phase with a
set of the immediate thenable for this component. This will allow user
code to build runtime tracing of the cause for a suspense boundary.
Given this snippet:
```jsx
TestRenderer.act(() => {
TestUtils.act(() => {
TestRenderer.create(<Effecty />);
});
});
```
We want to make sure that all work is only flushed on exiting the outermost act().
Now, naively doing this based on actingScopeDepth would work with a mocked scheduler, where flushAll() would flush all work across renderers.
This doesn't work without mocking the scheduler though; and where flushing work only works per renderer. So we disable this behaviour for a non-mocked scenario. This seems like an ok tradeoff.
Noticed when looking at the performance profiler with Luna that it's
hard to tell which event causes `performWorkUntilDeadline` to fire
because these functions are anonymous.
Always sets `isRAFLoopRunning` back to false when an animation frame is
scheduled. Fixes a bug where two rAFs fire in the same frame, but the
second one exits and fails to schedule a new rAF.
Fixes bug observed in Safari.
Prevents Spacebar from scrolling the window.
Prevents Enter from triggering a navigation if preventDefault is true.
Fixes the emulated mouse events test.
Improved warning whenever lower priority events (ex. data fetching, page load) happen during a high priority update (ex. hover/click events) to include:
1.) Name of component that triggered the high priority update or
2.) Information that the update was triggered on the root
Scheduler uses `requestAnimationFrame` to post tasks to the browser.
If this happens at the beginning of a frame, the callback might not
fire until the subsequent frame, even if the main thread is idle.
Our theory was that this wouldn't be an issue in practice, because once
the first rAF fires, we schedule the next rAF as early as possible in
that frame. Combined with our heuristic for computing frame deadlines,
we shouldn't get any idle time in between frames — only before the
*first* frame.
This reasoning holds true when you have a small number of large tasks,
such as the ones posted by React. The idle time before the task starts
is negligible relative to the lifetime of the entire task.
However, it does not hold if you have many small tasks posted over a
span of time, perhaps spawned by a flurry of IO events. In this case,
instead of single, contiguous rAF loop preceded by an idle frame, you
get many rAF loops preceded by many idle frames. Our new theory is that
this is contributing to poor main thread utilization during page loads.
To try to reclaim as much idle time as possible, this PR adds two
experimental flags. The first one adds a `requestIdleCallback` call to
start the rAF loop, which will fire before rAF if there's idle time left
in the frame. (We still call rAF in case there isn't. We start working
in whichever event fires first.)
The second flag tries a similar strategy using `setTimeout(fn, 0)`. If
the timer fires before rAF, we'll assume that the main thread is idle.
If either `requestIdleCallback` or `setTimeout` fires before rAF, we'll
immediately peform some work. Since we don't have a real frame time that
we can use to compute the frame deadline, we'll do an entire frame
length of work. This will probably push us past the vsync, but this is
fine because we can catch up during the next frame, by which point a
real rAF will have fired and the loop can proceed the same way it
does today.
Test plan: Try this on Facebook to see if it improves load times
* Patch console.warn and console.error to auto-append owners-only component stacks.
This setting is enabled by default and will work for React Native even if no front-end DevTools shell is being used. The setting can be disabled via a new, persisted user preference though.
- redoes #15431 from scratch, taking on the feedback there
- unifies the messaging between "deprecated" and UNSAFE_ lifecycle messages. It reorganizes ReactStrictModeWarnings.js to capture and flush all the lifecycle warnings in one procedure each.
- matches the warning from ReactPartialRenderer to match the above change
- passes all the tests
- this also turns on `warnAboutDeprecatedLifecycles` for the test renderer. I think we missed doing so it previously. In a future PR, I'll remove the feature flag altogether.
- this DOES NOT do the same treatment for context warnings, I'll do that in another PR too
This returns the current value of ReactCurrentFiber and enables DevTools to append a custom (owner-only) component stack to warnings and errors in DEV mode.
* Add version 4 react-devtools and react-devtools-core packages which support both React Native and e.g. Safari or iframe DOM usage.
* Replaces typed operations arrays with regular arrays in order to support Hermes. This is unfortunate, since in theory a typed array buffer could be more efficiently transferred between frontend and backend for the web extension, but this never actually worked properly in v8, only Spidermonkey, and it fails entirely in Hermes so for the time being- it's been removed.
* Adds support for React Native (paper renderer)
* Adds a style editor for react-native and react-native-web
Real Maps should now be used in RN JS engines. In theory this should
be faster (but might not actually be in practice), and it avoids hitting
upper bounds of property max counts.
We don't use these types of Maps in Fabric.
When executing a task, wraps the callback in an extra function whose
name includes the current priority level. Profiling tools with access
to function names can use this to determine the priority of the task.
1. Allow auxillary button clicks (i.e., middle mouse button) to trigger 'onPressStart' and 'onPressEnd', but never 'onPress'.
2. Report the button type – 'primary' or 'auxillary' – on the press event.
* [fail] reset IsThisRendererActing correctly
I missed this in https://github.com/facebook/react/pull/16039. I'd pointed at the wrong previous state, corrupting it in further use. This PR fixes that, and adds a test to make sure it doesn't happen again.
* warn for unacted effects only in strict mode
* only warn on unacted effects for strict / non sync modes
(basically, when `fiber.mode !== 0b0000`)
Warnings on unacted effects may be too noisy, especially for legacy apps. This PR fires the warning only when in a non sync mode (concurrent/batched), or when in strict mode. This should make updating easier.
I also added batched mode tests to the act() suite.
* explicitly check for modes before warning, explicit tests for all modes
* allow nested `act()`s from different renderers
There are usecases where multiple renderers need to oprate inside an act() scope
- ReactDOM.render being used inside another component tree. The parent component will be rendered using ReactTestRenderer.create for a snapshot test or something.
- a ReactDOM instance interacting with a ReactTestRenderer instance (like for the new devtools)
This PR changes the way the acting sigils operate to allow for this. It keeps 2 booleans, one attached to React, one attached to the renderer. act() changes these values, and the workloop reads them to decide what warning to trigger.
I also renamed shouldWarnUnactedUpdates to warnsIfNotActing
* s/ReactIsActing/IsSomeRendererActing and s/ReactRendererIsActing/IsThisRendererActing
* Add tail="collapsed" option
* Fix issue with tail exceeding the CPU time limit
We used to assume that this didn't suspend but this branch happens in
both cases. This fixes it so that we first check if we suspended.
Now we can fix the tail so that it always render an additional fallback
in this scenario.
* added flush sync test
* added code to run flushSync with ImmediatePriority
* added code to run flushSync with ImmediatePriority
* fixed flow error
* fixed flow error
* Add a bunch of optimizations to SuspenseList
We now are able to bail out of reconciliation and splitting out the tail
during deep updates that hasn't changed the child props. This only
works while the list wasn't suspended before.
I also moved the second render of the "head" to the complete phase. This
cleans it up a bit for the tail collapsing PR.
For this second pass I also use a new technique of resetting the child
Fibers for the second pass. This is effectively a fast path to avoid
reconciling the children against props again.
* Move to didSuspend from SuspenseListState to the effectTag
The effectTag now tracks whether the previous commit was suspended.
This frees up SuspenseListState to be render-phase only state.
We use null to mean the default "independent" mode.
* Rename to SuspenseListState to SuspenseListRenderState
* Reuse SuspenseListRenderState across render passes
* Add optimization to bail out of scanning children if they can't be suspended
This optimized the deep update case or initial render without anything
suspending.
We have some information available to us that tell us if nothing has
suspended in the past and nothing has suspended this render pass.
This also fixes a bug where we didn't tag the previous render as having
suspended boundaries if we didn't need to force a rerender.
* rm printChildren
oops
* Slightly improve performance of hydration.
Avoid loading nodeType and data couple times from the same node in a row,
but instead load them only once, which will help engines to run this code
faster, especially during startup of the application. The general approach
is still not ideal, since hydrating this way forces the browser engine
to materialize JavaScript wrapper objects for all DOM nodes, even if they
are not interesting to hydration itself.
* Fix condition for COMMENT_NODEs.
* Improve general code readability
Preemptively update tests wrt 'parser' requiring an absolute
path rather than a package name, even though the project is
still using ESLint 4.
Fixes#15971
* use toWarnDev for dom fixture tests
forks toWarnDev from root into fixture/dom, updates tes tests to use it
* disable act() warnings for react-art()
- For 'secondary' renderers like react-act, we don't want to fire missing act() warnings; the wrapping renderer will fire warnings anyway, and when it flushes, it flushes effects *across* renderers.
- I could have used isPrimaryRenderer as the flag, but this is marked as false for react-test-renderer, and we *do* want the warning to fire for it. Hence a new flag.
* add missing dependency `art` to fixtures/dom
* Retry failed roots on refresh
* Don't prevent retry after error -> render(null) special case
The check wasn't very resilient because in Concurrent Mode it looks like we can get further follow-up commits even if we captured an error. So we can't reliably distinguish the case where after an error you _manually_ rendered null.
Retrying on an edit after a tree failed _and_ you rendered null in the same tree seems fine. It's also very unlikely a pattern like this actually exists in the wild.
* warn if passive effects get queued outside of an act() call
While the code itself isn't much (it adds the warning to mountEffect() and updateEffect() in ReactFiberHooks), it does change a lot of our tests. We follow a bad-ish pattern here, which is doing asserts inside act() scopes, but it makes sense for *us* because we're testing intermediate states, and we're manually flush/yield what we need in these tests.
This commit has one last failing test. Working on it.
* pass lint
* pass failing test, fixes another
- a test was failing in ReactDOMServerIntegrationHooks while testing an effect; the behaviour of yields was different from browser and server when wrapped with act(). further, because of how we initialized modules, act() around renders wasn't working corrrectly. solved by passing in ReactTestUtils in initModules, and checking on the finally yielded values in the specific test.
- in ReactUpdates, while testing an infinite recursion detection, the test needed to be wrapped in an act(), which would have caused the recusrsion error to throw. solived by rethrowing the error from inside the act().
* pass ReactDOMServerSuspense
* stray todo
* a better message, consistent with the state update one.
* [Scheduler] requestPaint
Signals to Scheduler that the browser needs to paint the screen. React
will call it in the commit phase. Scheduler will yield at the end of
the current frame, even if there is no pending input.
When `isInputPending` is not available, this has no effect, because we
yield at the end of every frame regardless.
React will call `requestPaint` in the commit phase as long as there's at
least one effect. We could choose not to call it if none of the effects
are DOM mutations, but this is so rare that it doesn't seem worthwhile
to bother checking.
* Fall back gracefully if requestPaint is missing
At the end of each frame, Scheduler yields control of the main thread so
the browser can execute important tasks; most importantly, painting the
screen and responding to user input. There's some overhead involved in
regaining control of the main thread, so we'd like to yield as
infrequently as possible to keep the UI responsive.
The reason we yield on every frame is because there's no way for us to
know whether we're blocking user input.
`isInputPending` is an experimental browser API that gives us this
information. It tells us whether there's a pending user input, which
also means it tells us if there's *not* a pending user input. We can use
this signal to decide whether it's OK not to yield.
There's a max frame length after which we'll yield regardless, as a
precaution against blocking non-input tasks that we don't know about.
* Expire rendering the tail of SuspenseList after a timeout
This is the first Suspense feature that isn't actually dependent on IO.
The thinking here is that it's normal for a SuspenseList to show loading
states, and it'll be designed to handle it one at a time.
However, sometimes there are lists with really big items that take a long
time to CPU render. Since data can become available as we do that, it is
likely that we have all the data and become CPU bound.
In that case, the list would naively just render until the end and then
display all items at once. I think that's actually what you want for fast
lists. However, for slow ones (like News Feed), you're better off showing
a few rows at a time.
It's not necessarily one at a time because if you can do many in a short
period of time and fit them all on the screen, then it's better to do them
all at once than pop them in one at a time very quickly.
Therefore, I use a heuristic of trying to render as many rows as I can in
500ms before giving up.
This timer starts before the first row of the tail and we only check it
after. This ensures that we always make a little progress each attempt.
An alternative approach could be to start the time before doing the head
of the list but we don't want that being slow prevent us from making
further progress.
Currently, I disable this optimization at Never priority because there's
nothing intermediate that becomes visible anyway.
* Fix tracing through a SuspenseList
This ensures that we can spawn new work during render through arbitrary
priorities.
We'll need this for other features too.
Since each priority can commit separately we need to use an array to
include the current interactions on each priority.
The responder region calculation logic wasn't updating the deactivation region
during the lifetime of an event instance, causing incorrect behaviour when the
current press ends outside the press target and if the press target has moved
since the last time the first-and-only time the deactivation region was
measured.
* Add forwards option
* Add backwards option
* Add comment
* Add customized warning messages for case and typos
* Add some more tests for insertions and updates in start/middle/end
* reset scope depth on synchronous errors
we weren't resetting the acting scope depth on sync errors thrown in the callback. this fixes that.
* typos
* add a test to make sure sync error propagate
* Add SuspenseList component type
* Push SuspenseContext for SuspenseList
* Force Suspense boundaries into their fallback state
In the "together" mode, we do a second render pass that forces the
fallbacks to stay in place, if not all can unsuspend at once.
* Add test
* Transfer thennables to the SuspenseList
This way, we end up retrying the SuspenseList in case the nested boundary
that just suspended doesn't actually get mounted with this set of
thennables. This happens when the second pass renders the fallback
directly without first attempting to render the content.
* Add warning for unsupported displayOrder
* Add tests for nested sibling boundaries and nested lists
* Fix nested SuspenseList forwarding thennables
* Rename displayOrder to revealOrder
Display order has some "display list" connotations making it sound like
a z-index thing.
Reveal indicates that this isn't really about when something gets rendered
or is ready to be rendered. It's about when content that is already there
gets to be revealed.
* Add test for avoided boundaries
* Make SuspenseList a noop in legacy mode
* Use an explicit suspense list state object
This will be used for more things in the directional case.
* Track mounted roots via DevTools Hook
* Add helper utilities to the runtime
These utilities will likely be needed by all module systems, so let's just put them here.
* Wrap more things in __DEV__
* Fix tests to also be DEV-only
Adds a `delay` option to `scheduleCallback`. When specified, the task is
not scheduled until after the delay has elapsed.
Delayed tasks are scheduled on a timer queue maintained by Scheduler,
instead of directly with the browser. The main benefit is to reduce the
number of native browser timers that Scheduler's `message` event handler
has to contend with; so, after yielding to the browser at the end of the
frame, Scheduler will more quickly regain control of the main thread.
Because we're able to flush the timer queue without yielding to browser
timer events, there's also less task switching overhead (though in the
absence of `isInputPending`, this is mostly a theoretical win since we
yield every frame regardless).
If the queue of non-delayed tasks is non-empty — that is, if there is
pending CPU bound work — Scheduler is able to avoid a browser timer
entirely by periodically checking its own timer queue while flushing
tasks (inside the `message` event handler). Once the CPU-bound work is
complete, if there are still pending delayed tasks, Scheduler will
schedule a single browser timer that fires once the earliest delay
has elapsed.
* [scheduler] Internal rename: Callback -> Task
Rename Callback type to Task. Does not affect the public API, only
internal names, though eventually we'll probably want to align with the
WICG Main-thread Scheduling proposal
(https://github.com/WICG/main-thread-scheduling).
* [scheduler] flushFirstTask() -> flushTask(task)
Pass task as an argument to `flushTask` instead of using a module-
level variable.
* [scheduler] Add startTime field
This does not change any semantics, but in the future `startTime` may
represent a future time, to support delayed tasks.
* [Scheduler] Use continuation pattern for host cb
As I prepare to implement integrated timers, I noticed some
peculiarities in the Scheduler implementation that could afford to be
cleaned up.
This is a refactor and shouldn't affect any observable behavior; mostly
it removes some concepts that existed in earlier iterations of Scheduler
and are no longer needed.
The main change is to how the DOM implementation schedules an additional
callback before yielding to the main thread. It used to follow the same
code path for scheduling task; now it has its own branch directly
inside the message event handler. The special case for error handling
— where we call `postMessage` immediately without waiting for rAF —
has similarly been localized inside the catch block of the message
event handler.
* Rename `disableContextMenu` to `preventContextMenu`
* Change the behaviour of `preventContextMenu` so that `onContextMenu` is still called when the native context menu is prevented.
* Run Fresh tests in two modes: with and without destructuring
Destructuring transform messes up the way we collect signatures for Hooks. This adds failing tests.
* Extract collecting calls to Hooks into a separate visitor
This introduces a bit of a perf penalty but makes our plugin resilient to presence of destructuring transform and their order. Fixes new tests.
* Inline some logic into the call visitor
Follow up to #15861.
Turns out you can't set `!important` using a normal property assignment.
You have to use `style.setProperty`.
Maybe Andrew *should* just learn CSS.
IE9 doesn't support `style.setProperty` so we'll fall back to setting
`display: none` without `important`, like we did before #15861 Our
advice for apps that need to support IE9 will be to avoid using
`!important`. Which seems like good advice in general, but IANACSSE.
Tested on FB and using our Suspense DOM fixture.
Suspended nodes are hidden using an inline `display: none` style. We do
this instead of removing the nodes from the DOM so that their state is
preserved when they are shown again.
Inline styles have the greatest specificity, but they are superseded by
`!important`. To prevent an external style from overriding React's, this
commit changes the hidden style to `display: none !important`.
MaYBE AnDREw sHOulD JusT LEArn Css
I attempted to write a unit test using `getComputedStyle` but JSDOM
doesn't respect `!important`. I think our existing tests are sufficient
but if we were to decide we need something more robust, I would set up
an e2e test.
* Fix existing test
This test included a change in variable name. It wasn't needed, and distracts from the actual thing being tested (the annotation).
* Reset state on edits to initial state argument
* Add a way to check whether there are hot updates
prepareUpdate() now returns null if there are none.
* Add a way to query host nodes for families
* Split the signature call into two calls
This adds a render-time signature call by making __signature__ curried. We need both calls. The init time tells us which type has which signature. The render time call says when's a good time to capture the lazy Hooks tree. This is necessary for supporting inline requires. I will do that in next commit.
* Lazily compute Hook list on first render
This ensures inline requires don't break comparisons between Hook signatures of previous and next versions by caching Hook list at the time of first render.
* Refactor computing Hook signature keys
Instead of a traversal during the comparison, explicitly compute full keys. This makes it easier to debug mismatches.
* Remount classes during hot reload
* Fix a crash when Hook isn't in scope inside the signature
* Minor tweaks
* Support a comment annotation to force state reset
* Refactoring: pass a function instead of WeakMap
This hides the implementation a little bit and reduces how much React knows about the underlying mechanism.
* Refactor: use forceReset to remount unknown Hooks
We already have the logic to reset a component, so let's just reuse it instead of that special case.
* Same as previous commit, but for Flare
I don't know what the public API for setting the event priority should
be. Right now it accepts a numeric enum, but is this what we want?
Maybe it should be a string enum? I've punted on this for now.
* Add test for hover events
* [Events] Add EventPriority enum
React DOM's DispatchConfig for synthetic events has an `isDiscrete`
field that affects how updates triggered by an event are scheduled.
Events are either discrete or continuous.
This commit adds an additional type of configuration where an event
has user-blocking priority, but is not discrete. E.g. updates triggered
by hover are more important than the default, but they don't need to
be processed serially. Because there are now three types of event
priority instead of two, I've replaced the `isDiscrete` boolean with an
enum: `eventPriority`.
This commit implements the new enum value but does not change any
behavior. I'll enable it behind a feature flag in the next commit.
I've only implemented this in the legacy event system. I'll leave Flare
for a follow-up.
* enableUserBlockingEvents feature flag
Adds a feature flag to increase the priority of events like `mouseover`,
without making them discrete.
As a result, paddings and sizes (e.g. tab bar heights) will also be impacted now by this preference. More importantly, Profile charts will also use the line height preference, so the 'comfortable' setting will hopefully make profiling data easier to read.
Compare the viewport-relative coordinates of getBoundingClientRect with those
of the event's client{X,Y} values. This fixes press within scrollable nodes.
1. Bugfix: Hide tree grouping/background coloring when inside of collapsed subtree.
2. Bugfix: Don't measure and udpate indentation when Components tab is hidden.
3. Tweak: Lower background color for selected subtree in light theme to increase contrast for text.
4. Tweak: Remove FB-specific displayName check/hack since we will address that by modifying the internal require JS transform.
This commit is a follow-up to https://github.com/facebook/react/pull/15604, which explains more of the rationale behind moving React Native to path-based imports and the work needed in the React repository. In that linked PR, the generated renderers were updated but not the shims; this commit updates the shims.
The problem is that FB needs a different copy of the built renderers than the OSS versions so we need a way for FB code to import different modules than in OSS. This was previously done with Haste, but with the removal of Haste from RN, we need another mechanism. Talking with cpojer, we are using a `.fb.js` extension that Metro can be configured to prioritize over `.js`.
This commit generates FB's renderers with the `.fb.js` extension and OSS renderers with just `.js`. This way, FB can internally configure Metro to use the `.fb.js` implementations and OSS will use the `.js` ones, letting us swap out which implementation gets bundled.
Test Plan: Generated the renderers and shims with `yarn build` and then verified that the generated shims don't contain any Haste-style imports. Copied the renderers and shims into RN manually and launched the RNTester app to verify it loads end-to-end. Added `.fb.js` to the extensions in `metro.config.js` and verified that the FB-specific bundles loaded.
This is important since we are caching element sizes by DOM (in a WeakMap). Toggling (as well as insertion/deletion) might otherwise break this in some cases.
Remove selected guideline in favor of background color for selected subtree.
Add badges in grid format to selected elements prop panel.
Show badges beside owners list.
If an event in the old system is dispatched synchronously within an
event from the new system, or vice versa, and the inner event is a
discrete update, React should not flush pending discrete updates before
firing the inner event's handlers, even if the outer event is not
discrete.
Another way of saying this is that nested events should never force
React to flush discrete updates.
Arguably, if the outer event is not a discrete event, then the inner
event _should_ flush the pending events. However, that would be a
breaking change. I would argue this isn't so bad, however, given that
nested events are pretty rare. They don't fit nicely into our event
model regardless, since we don't support nested React renders. In the
future we should consider warning when events are nested.
WorkPhase is an enum that represents the currently executing phase of
the React update -> render -> commit cycle. However, in practice, it's
hard to use because different "phases" can be nested inside each other.
For example, the commit phase can be nested inside the
"batched phase."
This replaces WorkPhase with a different concept: ExecutionContext.
ExecutionContext is a bitmask instead of an enum. It represents a stack
of React entry points. For example, when `batchedUpdates` is called
from inside an effect, the ExecutionContext is
`BatchedContext | CommitContext`.
* Fix issue with Tab+alt not being considered as isGlobalFocusVisible candidate on Mac
* Add test for Tab+alt on Mac setting pointerType: "keyboard" on a focus event
* Track most recent commit time of a fallback globally
This value is going to be used to avoid committing too many fallback
states in quick succession. It doesn't really matter where in the tree
that happened.
This means that we now don't really need the concept of SuspenseState
other than has a flag. It could be made cheaper/simpler.
* Change suspense heuristic
This now eagerly commits non-delayed suspended trees, unless they're
only retries in which case they're throttled to 500ms.
* Restart early if we're going to suspend later
* Use the local variable where appropriate
* Make ReactLazy tests less specific on asserting intermediate states
They're not testing the exact states of the suspense boundaries, only
the result. I keep assertions that they're not already resolved early.
* Adjust Profiler tests to the new heuristics
* Update snapshot tests for user timing tests
I also added a blank initial render to ensuree that we cover the suspended
case.
* Adjust Suspense tests to account for new heuristics
Mostly this just means render the Suspense boundary first so that it
becomes an update instead of initial mount.
* Track whether we have a ping on the currently rendering level
If we get a ping on this level but have not yet suspended, we might
still suspend later. In that case we should still restart.
* Add comment about moving markers
We should add this to throwException so we get these markers earlier.
I've had to rewrite tests that test restarting to account for the delayed
restarting heuristic.
Ideally, we should also be able to restart from within throwException if
we're already ready to restart. Right now we wait until the next yield.
* Add test for restarting during throttled retry
* Add test that we don't restart for initial render
* Add Suspense Heuristics as a comment in Throw
The previous naming scheme used the name of the resulting bundle file.
However, there are cases where multiple bundles have the same filename.
This meant whichever bundle finishes last overwrites the previous ones
with the same name.
The updated naming scheme is `bundle-sizes-<CI_NODE_INDEX>.json`.
Instead of generating a separate info file per bundle, it now creates
one per process.
* warn when using the wrong renderer's act around another renderer's updates
like it says. it uses a real object as the sigil (instead of just a boolean). specifically, it uses a renderer's flushPassiveEffects as the sigil. We also run tests for this separate from our main suite (which doesn't allow loading multiple renderers in a suite), but makes sure to run this in CI as well.
* unneeded (and wrong) comment
* run the dom fixture on CI
* update the sigil only in __DEV__
* remove the obnoxious comment
* use an explicit export for the sigil
* Write size info to separate file per bundle
`bundle-sizes.json` contains the combined size information for every
build. This makes it easier to store and process, but it prevents us
from parallelizing the build script, because each process would need to
write to the same file.
So I've updated the Rollup script to output individual files per build.
A downstream CI job consolidates them into a single file.
I have not parallelized the Rollup script yet. I'll do that next.
* Parallelize the build script
Uses CircleCI's `parallelism` config option to spin up multiple build
processes.
Removes `--extract-errors` argument from CI build script command.
Instead, the author is expected to run `yarn extract-errors` locally
or manually edit the error code map.
The lint rule should be sufficient to catch unminified errors, but
as an extra precaution, I added a post-build step that greps the
production bundles. The post-build step works even if someone disables
the lint rule for a specific line or file.
* Lint rule for unminified errors
Add a lint rule that fails if an invariant message is not part of the
error code map.
The goal is to be more disciplined about adding and modifiying
production error codes. Error codes should be consistent across releases
even if their wording changes, for continuity in logs.
Currently, error codes are added to the error code map via an automated
script that runs right before release. The problem with this approach is
that if someone modifies an error message in the source, but neglects to
modify the corresponding message in the error code map, then the message
will be assigned a new error code, instead of reusing the existing one.
Because the error extraction script only runs before a release, people
rarely modify the error code map in practice. By moving the extraction
step to the PR stage, it forces the author to consider whether the
message should be assigned a new error code. It also allows the reviewer
to review the changes.
The trade off is that it requires more effort and context to land new
error messages, or to modify existing ones, particular for new
contributors who are not familiar with our processes.
Since we already expect users to lint their code, I would argue the
additional burden is marginal. Even if they forget to run the lint
command locally, they will get quick feedback from the CI lint job,
which typically finishes within 2-3 minutes.
* Add unreleased error messages to map
* Generate signatures for Hooks
This currently only works one level deep. For custom Hooks, we'll need to add some way to compose signatures.
* Be more resilient to plugin conflicts
This prevents a class of problems where other plugins cause our visitor to re-run.
It's a standard Babel practice, e.g.:
8c7d4b55c9/packages/babel-plugin-transform-react-constant-elements/src/index.js (L85-L86)
* Remove unnecessary stuff from debugging
* Include Foo.useHookName() calls into the signature
* Add an integration test for adding/removing an effect
* Add integration test for changing custom Hook order
* Include custom Hooks into the signatures
* Fix inferred names for function expressions
* Support export default hoc(Foo) when Foo is defined separately
* Add more built-in Hooks
expirationTime has already been checked if it's sync.
timeout can now be longer than 5 seconds when a suspense config is used.
We might want to adjust the heuristics but it's not internally consistent
without this.
1. Removed auto-updates XML (since the feature doens't work for self hosted extensions)
2. Replaced CRX with packed ZIP (since people are having trouble with the CRX, and auto-udpates doesn't work anyway)
Sometimes the status of the `build` job is not in the first page of
the `/statuses` endpoint. The combined `/status` endpoint consolidates
the entries, though, so it always appears there.
* Refactor component search to prepare for deeper traversals
* Register HOCs with intermediate results
* Register components that are used as JSX types
* Add integration test skeleton
The integration test combines testing runtime together with the Babel plugin. It's a bit harder to debug because multiple things can go wrong, but it helps us build confidence that specific scenarios work well.
* Add HOC integration test and fix conflict with JSX transform
* Infer usage from createElement too
This helps us avoid dependency on the plugin order.
* Remove outdated comments
* Wrap tests in __DEV__
* Support export default hoc(...) for anonymous functions
* Fix test indentation
* Fix comment typo
* Use named function for test as this case is more important
* Rename ReactFiberScheduler to ReactFiberWorkLoop
The scheduling part is mostly extracted out to the scheduler package.
What's remaining is mostly around the loop around each section of work.
I name it something with Work in it because it's very related to the
BeginWork, CompleteWork and UnwindWork sections.
* Extract throwException from UnwindWork
Our throwing works more like algebraic effects in that it's a separate
phase where we find a handler and we later unwind.
* [react-native] Use path-based imports instead of Haste for the RN renderer
To move React Native to standard path-based imports instead of Haste, the RN renderer that is generated from the code in this repo needs to use path-based imports as well since the generated code is vendored by RN. This commit makes it so the interface between the generated renderers and RN does not rely on Haste and instead uses a private interface explicitly defined by RN. This inverts control of the abstraction so that RN decides the internals to export rather than React deciding what to import.
On RN's side, a new module named `react-native/Libraries/ReactPrivate/ReactNativePrivateInterface` explicitly exports the modules used by the renderers in this repo. (There is also a private module for InitializeCore so that we can import it just for the side effects.) On React's side, the various renderer modules access RN internals through the explicit private interface.
The Rollup configuration becomes slimmer since the only external package is now `react-native`, and the individual modules are instead listed out in `ReactNativePrivateInterface`.
Task description: https://github.com/facebook/react-native/issues/24770
Sister RN PR (needs to land before this one): https://github.com/facebook/react-native/pull/24782
Test Plan: Ran unit tests and Flow in this repo. Generated the renderers and manually copied them over to the RN repo. Ran the RN tests and launched the RNTester app.
* Access natively defined "nativeFabricUIManager" instead of importing it
Some places in the Fabric renderers access `nativeFabricUIManager` (a natively defined global) instead of importing UIManager. While this is coupling across repos that depends on the timing of events, it is necessary until we have a way to defer top-level imports to run after `nativeFabricUIManager` is defined. So for consistency we use `nativeFabricUIManager` everywhere (see the comment in https://github.com/facebook/react/pull/15604#pullrequestreview-236842223 for more context).
The sizebot scrapes the GitHub `/statuses` endpoint to get the lastest
CircleCI build number for master, in order to fetch the bundle size
info for that build, which are stored as build artifacts. (There's gotta
be a better way to do this, but that's what we have for now.) This
updates the script to match the name of the updated CircleCI job that
generates the bundle sizes.
* Add initial Babel plugin implementation
* Register exported functions
* Fix missing declarations
Always declare them at the bottom and rely on hoisting.
* Remove unused code
* Don't pass filename to tests
I've decided for now that the plugin doesn't need filename, and it will be handled by module runtime integration instead.
* Fix bugs
* Coalesce variable declarations
Updates the CircleCI config to use the workflows features to run jobs in
parallel, instead of the `parallelism` option. This change alone doesn't
improve the overall build time much, since almost all of the total time
is spent running the Rollup script, which runs entirely sequentially.
But it does improve reporting, and should make it easier to add
additional parallel jobs in the future.
* Fix missing return pointer assignment
I found a bug using the fuzz tester that manifested as incorrect
ordering of children in the host tree, but whose root cause was a
missing `return` pointer assignment on a work-in-progress fiber.
Usually return pointers are set during reconciliation
(`reconcileChildFibers`) but this particular assignment happens inside
the custom reconciliation implementation used by Suspense boundaries.
I would not be surprised if there were similar bugs related to incorrect
return pointers. You're supposed to update the return pointer
whenever a work-in-progress fiber is created, but there's nothing in
the contract of the `createFiber` or `createWorkInProgress` function
that implies this. I propose that we update their signatures to accept
the return fiber as an argument. I will do this in a follow-up.
In this commit, I rearranged `updateSuspenseComponent` slightly so that
every call to `createWorkInProgress` or a `createFiber*` function is
immediately followed by a return pointer assignment.
I hardcoded the fuzz test case that surfaced the bug.
* Update all progressed children in list
`progressedPrimaryChild` is a list, not a single fiber. Need to iterate
through every child and update their return pointers.
* Add a stub for React Fresh Babel plugin package
* Move ReactFresh-test into ReactFresh top level directory
* Add a stub for React Fresh Runtime entry point
* Extract Fresh runtime from tests into its entry point
* Don't traverse children when hot reloading needs a remount
If we're gonna remount that tree anyway, there is no use in traversing its children beforehand.
* Add a test verifying hot reload batches updates
Otherwise there is a risk of it being super slow due to cascades.
* Add a minimal failing test for hot reload
* Set up scaffolding for React Fresh
* Consider type family when comparing elementType
Rendering an element with stale type should not cause it to remount.
We only do this for FunctionComponent tag since checking is unnecessary for classes or host components.
* Add support for forwardRef()
Initially I thought I would compare families of inner .render functions.
However, there is a corner case where this can create false positives. Such as when you forwardRef(X) the same X twice. Those are supposed to be distinct. But if we compare .render functions, we wouldn't be able to distinguish them after first reload.
It seems safer to rely on explicit registration for those. This should be easy when forwardRef() call is in the same file, and usually it would be. For cases like HOCs and style.div`...` factories that return forwardRef(), we could have the __register__ helper itself "dig deeper" and register the inner function.
* Show how forwardRef inner identity can be inferred
The __register__ implementation can read the inner identity itself.
* Add missing __DEV__ to tests
* Add support for memo() (without fixing bailouts)
This adds rudimentary support for memo components. However, we don't actually skip bailouts yet, so this is not very useful by itself alone. Tests have TODOs that we need to remove after bailout skipping is done.
* Refactor type comparison for clarity
* Hot update shouldn't re-render ancestor components unnecessarily
My code had a bug where it checked for a wrong thing in a wrong set, leading us to always re-render.
This fixes the checks so that we only schedule updates for things that were actually edited.
* Add test coverage for memo(fn, areEqual)
* Explicitly skip bailouts for hot reloading fibers
This forces even memo() with shallow comparison to re-render on hot update.
* Refactor scheduling update to reduce duplication
* Remove unused variable in test
* Don't check presence in a set while not hot reloading
* Make scheduleHotUpdate() take named arguments
* Don't keep unedited component types in the type => family map
It's unnecessary because if they haven't been edited, there's no special reconciliation logic.
* Add signatures that force remounting
Signatures let us force a remount of a type even if from React's point of view, type is the same.
A type has one current signature. If that signature changes during next hot update, all Fibers with that type should be deleted and remounted.
We do this by mutating elementType scheduling a parent.
This will be handy to force remount of mismatching Hooks, as well as failed error boundaries.
For this to fully work, we'll need to add a way to skip built-in bailouts for all Fiber types. This will be the most invasive and annoying change. I did it for HostRoot in this PR but there's more. I'll add an automated test case that catches the missing bailout bailouts.
* Support forced remounting for all component types
This teaches all parent component types to remount their child if necessary.
It also adds tests for them.
* Remount effects while preserving state for hot reloaded components
This makes sure that changes to *code* always propagate.
It can break components that aren't resilient to useEffect over-firing, but that seems like a good constraint since you might need to add a dependency later anyway, and this helps avoid coding yourself into the corner.
* Add missing __DEV__ blocks to tests
* Fix unused variables in tests
* Remove outdated TODO
* Expose scheduleHotUpdate directly
* Inline isCompatibleType
* Run one check per component for invalidating deps
This also makes the bailouts more targeted--no need to remount useEffect for a parent component of remounted fiber.
* Resolve .type early
This moves resolving to set up the right .type early instead of doing this before render.
A bit more future-proof in case we want to restructure the begin phase later.
ForwardRef is special because its type is a wrapper but it can be hot reloaded by itself.
So we have a special overload for it that reconstucts the wrapper type if needed.
* Add a Suspense todo
* Use current.type !== workInProgress.type for ignoring deps
This gets rid of one of the sets.
* Use workInProgress.type !== current.type check for force re-render
We still use a set for forced remount though.
* Use wip.type !== current.type check in more places
This also disables the remounting tests. They need a separate approach.
* Use a dedicated remount mechanism
* Add a test for offscreen trees
It has a TODO because it seems like offscreen updates are incorrectly applied too soon.
* Enable offscreen test now that it is fixed
* Fix corner cases in the new remounting mechanism
* Remount failed error boundaries on hot reload
* Fix test now that act() flushes
This test is manual so I don't actually want act here.
* Nits
* Add comments
* Add suspendIfNeeded API and a global scope to track it
Adds a "current" suspense config that gets applied to all updates scheduled
during the current scope.
I suspect we might want to add other types of configurations to the "batch"
so I called it the "batch config".
This works across renderers/roots but they won't actually necessarily go
into the same batch.
* Add the suspenseConfig to all updates created during this scope
* Compute expiration time based on the timeout of the suspense config
* Track if there was a processed suspenseConfig this render pass
We'll use this info to suspend a commit for longer when necessary.
* Mark suspended states that should be avoided as a separate flag
This lets us track which renders we want to suspend for a short time vs
a longer time if possible.
* Suspend until the full expiration time if something asked to suspend
* Reenable an old test that we can now repro again
* Suspend the commit even if it is complete if there is a minimum delay
This can be used to implement spinners that don't flicker if the data
and rendering is really fast.
* Default timeoutMs to low pri expiration if not provided
This is a required argument in the type signature but people may not
supply it and this is a user facing object.
* Rename to withSuspenseConfig and drop the default config
This allow opting out of suspending in some nested scope.
A lot of time when you use this function you'll use it with high level
helpers. Those helpers often want to accept some additional configuration
for suspense and if it should suspend at all. The easiest way is to just
have the api accept null or a suspense config and pass it through. However,
then you have to remember that calling suspendIfNeeded has a default.
It gets simpler by just saying tat you can pass the config. You can have
your own default in user space.
* Track the largest suspense config expiration separately
This ensures that if we've scheduled lower pri work that doesn't have a
suspenseConfig, we don't consider its expiration as the timeout.
* Add basic tests for functionality using each update mechanism
* Fix issue when newly created avoided boundary doesn't suspend with delay
* Add test for loading indicator with minLoadingDurationMs option
* s/flushPassiveEffects/unstable_flushWithoutYielding
a first crack at flushing the scheduler manually from inside act(). uses unstable_flushWithoutYielding(). The tests that changed, mostly replaced toFlushAndYield(...) with toHaveYielded(). For some tests that tested the state of the tree before flushing effects (but still after updates), I replaced act() with bacthedUpdates().
* ugh lint
* pass build, flushPassiveEffects returns nothing now
* pass test-fire
* flush all work (not just effects), add a compatibility mode
of note, unstable_flushWithoutYielding now returns a boolean much like flushPassiveEffects
* umd build for scheduler/unstable_mock, pass the fixture with it
* add a comment to Shcduler.umd.js for why we're exporting unstable_flushWithoutYielding
* run testsutilsact tests in both sync/concurrent modes
* augh lint
* use a feature flag for the missing mock scheduler warning
I also tried writing a test for it, but couldn't get the scheduler to unmock. included the failing test.
* Update ReactTestUtilsAct-test.js
- pass the mock scheduler warning test,
- rewrite some tests to use Scheduler.yieldValue
- structure concurrent/legacy suites neatly
* pass failing tests in batchedmode-test
* fix pretty/lint/import errors
* pass test-build
* nit: pull .create(null) out of the act() call
Uses a dynamic flag in www's test renderer build so we can condtionally
disable the passive effects bugfix. Matches the dynamic flag used in
the www React DOM build.
PR #15650 is a bugfix but it's technically a semantic change that could
cause regressions. I don't think it will be an issue, since the
previous behavior was both broken and incoherent, but out of an
abundance of caution, let's wrap it in a flag so we can easily revert
it if necessary.
* Failing test for false positive warning
* Flush passive effects before discrete events
Currently, we check for pending passive effects inside the `setState`
method before we add additional updates to the queue, in case those
pending effects also add things to the queue.
However, the `setState` method is too late, because the event that
caused the update might not have ever fired had the passive effects
flushed before we got there.
This is the same as the discrete/serial events problem. When a serial
update comes in, and there's already a pending serial update, we have to
do it before we call the user-provided event handlers. Because the event
handlers themselves might change as a result of the pending update.
This commit moves the `flushPassiveEffects` call to before the discrete
event handlers are called, and removes it from the `setState` method.
Non-discrete events will not cause passive effects to flush, which is
fine, since by definition they are not order dependent.
Strengthened the I/O-boundary type conversion logic.
Fixed type inconsistencies uncovered by removing `any` and
by making explicit type annotations and transformations.
In particular, these were likely malformed when restored from a file:
- `commitDetails`
- `interactions`
- `initialTreeBaseDurations`
The mismatches were Map vs interleaved Array.
If React finishes rendering a tree, delays committing it (e.g.
Suspense), then subsequently starts over or renders a new tree, the
pending tree is no longer valid. That's because rendering a new work-in
progress mutates the old one in place.
The current structure of the work loop makes this hard to reason about
because, although `renderRoot` and `commitRoot` are separate functions,
they can't be interleaved. If they are interleaved by accident, it
either results in inconsistent render output or invariant violations
that are hard to debug.
This commit adds an invariant that throws if the new tree is the same as
the old one. This won't prevent all bugs of this class, but it should
catch the most common kind.
To implement the invariant, I store the finished tree on a field on the
root. We already had a field for this, but it was only being used for
the unstable `createBatch` feature.
A more rigorous way to address this type of problem could be to unify
`renderRoot` and `commitRoot` into a single function, so that it's
harder to accidentally interleave the two phases. I plan to do something
like this in a follow-up.
* Add ReactDOM.unstable_createSyncRoot
- `ReactDOM.unstable_createRoot` creates a Concurrent Mode root.
- `ReactDOM.unstable_createSyncRoot` creates a Batched Mode root. It
does not support `createBatch`.
- `ReactDOM.render` creates a Legacy Mode root. It will eventually be
deprecated and possibly moved to a separate entry point, like
`react-dom/legacy`.
* Rename internal ReactRoot types
* Add Batched Mode
React has an unfortunate quirk where updates are sometimes synchronous
-- where React starts rendering immediately within the call stack of
`setState` — and sometimes batched, where updates are flushed at the
end of the current event. Any update that originates within the call
stack of the React event system is batched. This encompasses most
updates, since most updates originate from an event handler like
`onClick` or `onChange`. It also includes updates triggered by lifecycle
methods or effects. But there are also updates that originate outside
React's event system, like timer events, network events, and microtasks
(promise resolution handlers). These are not batched, which results in
both worse performance (multiple render passes instead of single one)
and confusing semantics.
Ideally all updates would be batched by default. Unfortunately, it's
easy for components to accidentally rely on this behavior, so changing
it could break existing apps in subtle ways.
One way to move to a batched-by-default model is to opt into Concurrent
Mode (still experimental). But Concurrent Mode introduces additional
semantic changes that apps may not be ready to adopt.
This commit introduces an additional mode called Batched Mode. Batched
Mode enables a batched-by-default model that defers all updates to the
next React event. Once it begins rendering, React will not yield to
the browser until the entire render is finished.
Batched Mode is superset of Strict Mode. It fires all the same warnings.
It also drops the forked Suspense behavior used by Legacy Mode, in favor
of the proper semantics used by Concurrent Mode.
I have not added any public APIs that expose the new mode yet. I'll do
that in subsequent commits.
* Suspense in Batched Mode
Should have same semantics as Concurrent Mode.
* Use RootTag field to configure type of root
There are three types of roots: Legacy, Batched, and Concurrent.
* flushSync should not flush batched work
Treat Sync and Batched expiration times separately. Only Sync updates
are pushed to our internal queue of synchronous callbacks.
Renamed `flushImmediateQueue` to `flushSyncCallbackQueue` for clarity.
* Don't consider "Never" expiration as part of most recent event time
This doesn't happen with deprioritization since those are not "updates"
by themselves so they don't go into this accounting.
However, they are real updates if they were scheduled as Idle pri using
the scheduler explicitly. It's unclear what suspense should do for these
updates. For offscreen work, we probably want them to commit immediately.
No point in delay them since they're offscreen anyway. However if this is
an explicit but very low priority update that might not make sense.
So maybe this means that these should have different expiration times?
In this PR I just set the suspense to the lowest JND.
However, we don't want is for these things to commit earlier in case
they got batched in with other work so I also ensured that they're not
accounted for in in the workInProgressRootMostRecentEventTime calculation
at all. This makes them commit immediately if they're by themselves, or
after the JND of whatever they were batched in with.
Ultimately, I think that we should probably never schedule anything at
Never that isn't truly offscreen so this should never happen.
However, that begs the question what happens with very low pri work that
suspends. Do we always work at that level first?
* Adjust test to account for the new shorter suspense time
This simplifies your test helpers to loop until all timers are flushed (including the ones that get queued after updates), and works in concurrent mode. I also renamed actSuspense to actAsync to be clearer.
Owners in the list may have been filtered out of the Store, but in the owners list view- it's important to still show them. The frontend cannot do this on its own, so this list needs to come from the renderer interface.
* Warn when suspending at wrong priority
Adds a warning when a user-blocking update is suspended.
Ideally, all we would need to do is check the current priority level.
But we currently have no rigorous way to distinguish work that was
scheduled at user- blocking priority from work that expired a bit and
was "upgraded" to a higher priority. That's because we don't schedule
separate callbacks for every level, only the highest priority level per
root. The priority of subsequent levels is inferred from the expiration
time, but this is an imprecise heuristic.
However, we do store the last discrete pending update per root. So we
can reliably compare to that one. (If we broaden this warning to include
high pri updates that aren't discrete, then this won't be sufficient.)
My rationale is that it's better for this warning to have false
negatives than false positives.
Potential follow-ups:
- Bikeshed more on the message. I don't like what I landed on that much
but I think it's good enough to start.
- Include the names of the components that updated. (The ideal place to
fire the warning is during the setState call but we don't know if
something will suspend until the next update. Maybe we could be clever
and warn during a subsequent update to the same component?)
* Move Suspense priority check to throwException
* Fixes a bug in the cancellation logic. The cancel events are now correctly listened to on the root.
* Fixes cancellation in Safari by using the dragstart event as a proxy for cancellation (i.e., the event dispatched when move-during-press occurs on an anchor tag)
Propagate `rootID` throughout the code for `captureScreenshot`.
Rename private profiling maps of `store` to make relations more clear.
Fix missing cleanup for screenshots data in `set importedProfilingData` of `store`.
There are many unnecessary typecasts through `any` which
break the Flow of types across the program.
It's more bulletproof to avoid lying to ourselves about types.
Also fixed sketchy null check where zero ID would be skipped:
```diff
- } else if (selectedElementID) {
+ } else if (selectedElementID !== null) {
```
https://github.com/flowtype/flow-bin/issues/138#issuecomment-448416874https://github.com/flowtype/flow-bin/issues/138#issuecomment-450367472
> This will stop flow from trying to consume too many virtual CPUs (which CircleCI doesn't actually provide), letting it run to completion without first running out of memory and killing its sub processes.
The log output in CircleCI was:
https://circleci.com/gh/bvaughn/react-devtools-experimental/201
```
#!/bin/bash -eo pipefail
yarn flow
yarn run v1.10.1
$ /home/circleci/repo/node_modules/.bin/flow
Launching Flow server for /home/circleci/repo
Spawned flow server (pid=259)
Logs will go to /tmp/flow/zShomezScirclecizSrepo.log
Monitor logs will go to /tmp/flow/zShomezScirclecizSrepo.monitor_log
Launching Flow server for /home/circleci/repo
Spawned flow server (pid=361)
Logs will go to /tmp/flow/zShomezScirclecizSrepo.log
Monitor logs will go to /tmp/flow/zShomezScirclecizSrepo.monitor_log
Launching Flow server for /home/circleci/repo
Spawned flow server (pid=464)
Logs will go to /tmp/flow/zShomezScirclecizSrepo.log
Monitor logs will go to /tmp/flow/zShomezScirclecizSrepo.monitor_log
Launching Flow server for /home/circleci/repo
Spawned flow server (pid=567)
Logs will go to /tmp/flow/zShomezScirclecizSrepo.log
Monitor logs will go to /tmp/flow/zShomezScirclecizSrepo.monitor_log
Lost connection to the flow server (0 retries remaining): -Out of retries, exiting!
error Command failed with exit code 7.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Exited with code 1
```
* [React Native] Inline calls to FabricUIManager in shared code
* Call global.nativeFabricUIManager directly as short term fix
* Add flow types
* Add nativeFabricUIManager global to eslint config
* Adding eslint global to bundle validation script
Called when focus visibility changes. Focus is only considered visible if a
focus event occurs after keyboard navigation. This provides a way for people to
provide visual focus styles for keyboard accessible UIs without those styles
appearing if focus is triggered by mouse, touch, pen.
Fixes https://github.com/bvaughn/react-devtools-experimental/issues/217
The error reproduces with any two React websites, e.g. `https://reactjs.org` and `https://nextjs.org`, by keeping the DevTools Components tab open and switching between these websites in the same browser tab.
There are several issues with the code that contribute to this:
1. `Bridge` leaves behind a dangling timer that fires `_flush` after the bridge has been abandoned ("shutdown").
2. `bridge.send('shutdown')` is asynchronous, so the event handlers do not get unsubscribed in time.
3. `port.onDisconnect` does not trigger on in-tab navigation like new URL or back/forward navigation.
4. State management design of the code that uses shared variables and callbacks makes it hard to handle race conditions originating from the browser.
This commit cleans up some of the lacking symmetry when using `addListener`/`removeListener`, but the code in `shells/browser/shared/src/main.js` is hard to reason about with regards to race conditions, and there are many possible race conditions originating from the browser, so maybe there could be a better design paradigm (like a formal state machine) to manage the state changes in response to sequences of events than plain old event listeners, callbacks, and shared variables.
Unrelated, but clicking Chrome Back/Forward/Back/Forward very fast makes the browser and the DevTools and the DevTools of DevTools stall and become unresponsive for some time, then recovers but the Back/Forward/Stop/Refresh button and favicon loading indicator may remain broken. Looks like a Chrome bug, some kind of a temporary deadlock in handling the browser history.
Flow IDE shows the original type, not the file-scoped alias,
so it's confusing to see incompatible variables that have types
with the same name.
This started from `src/devtools/ProfilingCache.js` where
`ProfilingSummary` was incompatible, but I decided to make a bigger
change for consistency and to avoid similar mistakes in the future.
Let's make impossible states truly impossible, and fix Flow types, too.
All three usages of Agent called addBridge right after constructing it.
Agent has one field `_bridge` which is force-typed as not-null despite
there's a temporary zone between the constructor end and addBridge start
where `_bridge` is null.
Fixes https://github.com/bvaughn/react-devtools-experimental/issues/131
Uses the new function `findAllCurrentHostFibers`.
Removes dependency on React's `renderer.findHostInstanceByFiber` function
which used to highlight only the first DOM element of a Fragment.
Reworked `src/backend/views/Overlay` to support highlighting
more than one element rectangle annotated with one tooltip.
Fixed minor issues with the tooltip position calculation.
This is being done to fix a drill-through bug, although the initial fix is perhaps not the most performant one. At least we have test coverage now and a temporary fix.
This patch fixes an issue related to determining whether the end event occurs
within the responder region. Previously we only checked if the event target was
within the responder region for moves, otherwise we checked if the target was
within the event component. Since the dimensions of the child element can
change after activation, we need to recalculate the responder region before
deactivation as well if the target is not within the event component.
* ADD: disablePictureInPicture attribute for HTML5 videos
* ADD: disablePictureInPicture as DOMProperty and attribute
* Update: Replace camelCase with lowercase and vice-versa
* FIX: Missing comma on attribute (prettier)
https://webpack.js.org/plugins/define-plugin/
Webpack's DefinePlugin has the ability to replace `typeof expr` to a constant in compile-time, which should lead to better dead-code-elimination.
This implements matching Fibers against the tracked selection path.
The algorithm is optimized to do as little checks as possible:
* When not trying to restore selection, we don't do anything
* When restoring selection, we only check .return pointers of new mounts
* Only when .return pointers match our current deepest match, we compare the frames
Normally, Fibers have key or index which we'll use to match things up between reloads. However, roots don't have such a concept. We'll use their insertion order as an approximation. If it's consistent, we'll be able to restore the selection.
This implements the infrastructure for saving and restoring renderer-specific selection state in the session storage.
Note this doesn't actually implement the calculation and tracking of paths in the renderer. It only simulates that the renderer can do it. The actual implementation will come in a later commit.
Bugfix for `inferPriorityFromExpirationTime` function. It happened to
work in our existing tests because we use virtual time.
Flow would have caught this if expiration times were an opaque type. We
should consider that in the future. (The downside of opaque types is
that all operations would have to go through helper functions, which may
or may not get inlined by Closure.)
Fixes a bug where the timeout passed to `scheduleCallback` represented
an absolute timestamp, instead of the amount of time until that
timestamp is reached. The solution is to subtract the current time
from the expiration.
The bug wasn't caught by other tests because we use virtual times that
default to 0, and most tests don't advance time.
I also moved the `initialTimeMs` offset to the
`SchedulerWithReactIntegration` module so that we don't have to remember
to subtract the offset every time. (We should consider upstreaming this
to the Scheduler package.)
The implementation is wrong, but also it's not that useful for
debugging. Implementing it properly would involve tracking more
information than we do currently. Perhaps including the priority
of the callback in the message would be helpful, but not sure. For now
I'll just remove it.
This commit leaves a few major things uunresolved:
* We aren't yet polling for updates
* We aren't yet using the two setState pattern
* The resource cache will grow unbounded over time because we aren't yet clearing items from it
* The renderer interface is not smart enough to avoid resending unchanged data between requests
Refactor of Press and additional regression coverage.
The logic for "start", "move", "end", and "cancel" events is consolidated into a single block to reduce duplication and improve consistency of the UX across input-types. Also reduces code size.
The bailout logic for anchor tags is removed since we preventDefault for click by default. We can discuss scenarios where it makes sense to limit functionality around interactions on anchor tags.
The logic for ignoring emulated events is simplified and improved. Pointer events can produce emulated touch (immediately after pointer) and mouse events (delayed) which is now accounted for and tested.
Selecting the tab when the mouse is pressed rather than only when it is
released makes tab switching feel faster and also matches how the Chrome dev
tools behave.
The previous tab selection handler which listens for the radio button's
selection has been kept for the benefit of interaction methods which
don't trigger the mousedown handler.
This patch makes a change to the Focus module so that it only reports
focus/blur on the host node that's a direct child of the event component. This
brings the expected behaviour in line with the browser default of focus/blur
events not bubbling for Pressable.
This doesn't change any logic, just the shape of the control flow.
I want to unify some branches at the end, so it's easier if there are no early returns.
Moves the cancelTimeout call to right before creating a new work-in-
progress root. Fixes a class of bugs where a pending commit is not
cancelled, causing an incomplete tree to accidentally commit.
In the interest of fixing downstream bugs quickly, I'm landing this
without a test case; I'll add one in a follow up.
The Pointer Events spec mentions that the value of `button` in a nativeEvent
can be anything between 0 and 5 for "down" events. We only care about those
with a value of 0.
1. Fix hiding context menu for longpress via touch.
2. Fix scrolling of viewport for longpress via spacebar key.
3. Add tests for anchor-related behaviour and preventDefault.
4. Add a deactivation delay for forced activation
5. Add pointerType to Press events.
NOTE: this currently extends pointerType to include `keyboard`.
NOTE: React Native doesn't have a deactivation delay for forced activation, but this is possibly because of the async bridge meaning that the events aren't dispatched sync.
This implementation differs from equivalents in React Native in the following ways:
1. A move during a press will not cancel onLongPress.
2. A move to outside the retention target will cancel the press and not
reactivate when moved back within the retention target.
* Track the earliest event time in this render
Rebase
* Track the time of the fallback being shown as an event time
When we switch back from fallback to content, we made progress and we track
the time from when we showed the fallback in the first place as the
last time we made progress.
* Don't retry if synchronous
* Only suspend when we switch to fallback mode
This ensures that we don't resuspend unnecessarily if we're just retrying
the same exact boundary again. We can still unnecessarily suspend
for nested boundaries.
* Rename timedOutAt to fallbackExpirationTime
* Account for suspense in devtools suspense test
The React Native build does not minify error messages in production,
but it still needs to run the error messages transform to compile
`invariant` calls to `ReactError`. To do this, I added a `noMinify`
option to the Babel plugin. I also renamed it from
`minify-error-messages` to the more generic `transform-error-messages`.
* [React Native] Add tests to paper renderer for measure, measureLayout
* [React Native] measure calls will now call FabricUIManager
The Fabric renderer was previously calling the paper UIManager's measure calls and passing the react tag. This PR changes the renderer to now call FabricUIManager passing the node instead.
One of the parts of this that feels more controversial is making NativeMethodsMixin and ReactNative.NativeComponent warn when calling measureLayout in Fabric. As Seb and I decided in https://github.com/facebook/react/pull/15126, it doesn't make sense for a component created with one of these methods to require a native ref but not work the other way around. For example: a.measureLayout(b) might work but b.measureLayout(a) wouldn't. We figure we should keep these consistent and continue migrating things off of NativeMethodsMixin and NativeComponent.
If this becomes problematic for the Fabric rollout then we should revisit this.
* Fixing Flow
* Add FabricUIManager to externals for paper renderer
* import * as FabricUIManager from 'FabricUIManager';
* Update tests
* Shouldn't have removed UIManager import
* Update with the new tests
We use bitwise operations to compute expiration times, which means they
need to be smaller than 31 bits. So we measure times relative to module
initialization, similar to `performance.now`.
This was already working in the old fiber scheduler, but we didn't have
a test for it.
If click-to-inspect then hover an element in just the right place, it flickers between two elements because this "tip" element catches the hover. This should fix it.
When an async update expires, React renders at the expiration time that
corresponds to the current time, not at the original update's expiration
time. That way, all the expired work in the tree is flushed in a
single batch.
This is implemented inside `renderRoot` by comparing the next render
expiration time to the current time. If the current time is later,
`renderRoot` will restart at the later time.
Because of poor factoring, the check is currently performed right before
entering the work loop. But the work loop is usually entered multiple
times in a single callback: each time a component throws or suspends.
This led to an infinite loop where React would detect that an update
expired, restart at the current time, make a bit of progress, suspend,
check for expired work again, and start the loop again.
I fixed this by moving the expired work check to the beginning of
`renderRoot`, so that it is not performed every time something suspends.
This isn't ideal, because you could technically still fall into a loop
if more than 10ms lapse in between exiting `renderRoot` and entering it
again. The proper fix is to lift the check outside of `renderRoot`
entirely so that the function can restart without checking for expired
work again. Since this is exceedingly unlikely (and this whole thing is
still behind a flag), I'll do the better fix in an already-planned
follow up to fork `renderRoot` into separate functions for sync and
async work.
* Add HoverProps type
* Add more Hover event module tests
* Add more Press event module tests
* Change default longPress delay from 1000 to 500
* Rename dispatchPressEvent -> dispatchEvent
* Consolidate state updates in Press event module
* Add keyboard support for Press events
* Add FocusProps type and unit tests
* Allow DevTools to toggle Suspense state
* Change API to overrideSuspense
This lets detect support for overriding Suspense from DevTools.
* Add ConcurrentMode test
* Newlines
* Remove unnecessary change
* Naming changes
* Store FB bundles as CI artifacts
Updates the Circle CI config to store Facebook bundles as build
artifacts. We already do this for our npm packages.
* Might as well store everything in build/
* Store build directory as a tarball
So it's easy to download
This doesn't rely on checking the tag. When the alternate of a parent
is missing, it assumes it's a fragment indirection and moves onto the
next parent fiber.
The Facebook build of React DOM uses a forked entry point that exposes
additional secret internals. I didn't account for this when I added
the react-dom/unstable-new-scheduler build, so the extra internals
are currently missing. This commit adds them.
Verified that a variant of this test fails as follows when the
`context.withAsyncDispatching` function is excluded (i.e., reproduces the
issue).
Expected value to equal:
["press", "longpress", "longpresschange"]
Received:
["press", "longpress", "longpress", "longpresschange"]
* Rewrite ReactFiberScheduler
Adds a new implementation of ReactFiberScheduler behind a feature flag.
We will maintain both implementations in parallel until the new one
is proven stable enough to replace the old one.
The main difference between the implementations is that the new one is
integrated with the Scheduler package's priority levels.
* Conditionally add fields to FiberRoot
Some fields only used by the old scheduler, and some by the new.
* Add separate build that enables new scheduler
* Re-enable skipped test
If synchronous updates are scheduled by a passive effect, that work
should be flushed synchronously, even if flushPassiveEffects is
called inside batchedUpdates.
* Passive effects have same priority as render
* Revert ability to cancel the current callback
React doesn't need this anyway because it never schedules callbacks if
it's already rendering.
* Revert change to FiberDebugPerf
Turns out this isn't neccessary.
* Fix ReactFiberScheduler dead code elimination
Should initialize to nothing, then assign the exports conditionally,
instead of initializing to the old exports and then reassigning to the
new ones.
* Don't yield before commit during sync error retry
* Call Scheduler.flushAll unconditionally in tests
Instead of wrapping in enableNewScheduler flag.
This took a while, but I'm happy I went through it. Some key moments - recursively flushing effects, flushing microtasks on each async turn, and my team's uncompromising philosophy on code reuse. Really happy with this. I still want to expand test coverage, and I have some more small related todos, but this is good to land. On to the next one.
Soundtrack to landing this - https://open.spotify.com/track/0MF8I8OUo8kytiOo8aSHYq?si=gSWqUheKQbiQDXzptCXHTg
* hacked up act(async () => {...})
* move stuff around
* merge changes
* abstract .act warnings and stuff. all renderers. pass all tests.
* move testutils.act back into testutils
* move into scheduler, rename some bits
* smaller bundle
* a comment for why we don't do typeof === 'function'
* fix test
* pass tests - fire, prod
* lose actContainerElement
* tighter
* write a test for TestRenderer
it's an odd one, because not only does sync act not flush effects correctly, but the async one does (wut). verified it's fine with the dom version.
* lint
* rewrote to move flushing logic closer to the renderer
the scheduler's `flushPassiveEffects` didn't work as expected for the test renderer, so I decided to go back to the hack (rendering a dumb container) This also makes reactdom not as heavy (by a few bytes, but still).
* move it around so the delta isn't too bad
* cleanups
fix promise chaining
propagate errors correctly
test for thenable the 'right' way
more tests!
tidier!
ponies!
* Stray comment
* recursively flush effects
* fixed tests
* lint, move noop.act into react-reconciler
* microtasks when checking if called, s/called/calledLog, cleanup
* pass fb lint
we could have globally changed our eslint config to assume Promise is available, but that means we expect a promise polyfill on the page, and we don't yet. this code is triggered only in jest anyway, and we're fairly certain Promise will be available there. hence, the once-off disable for the check
* shorter timers, fix a test, test for Promise
* use global.Promise for existence check
* flush microtasks
* a version that works in browsers (that support postMessage)
I also added a sanity fixture inside fixtures/dom/ mostly for me.
* hoist flushEffectsAndMicroTasks
* pull out tick logic from ReactFiberScheduler
* fix await act (...sync) hanging
- fix a hang when awaiting sync logic
- a better async/await test for test renderer
* feedback changes
- use node's setImmediate if available
- a warning if MessageChannel isn't available
- rename some functions
* pass lint/flow checks (without requiring a Promise polyfill/exclusion)
* prettier
the prettiest, even.
* use globalPromise for the missed await warning
* __DEV__ check for didWarnAboutMessageChannel
* thenables and callbacks instead of promises, pass flow/lint
* tinier. better.
- pulled most bits out of FiberScheduler
- actedUpdates uses callbacks now
* pass build validation
* augh prettier
* golfing 7 more chars
* Test that effects are not flushed without also flushing microtasks
* export doesHavePendingPassiveEffects, nits
* createAct()
* dead code
* missed in merge?
* lose the preflushing bits
* ugh prettier
* removed `actedUpdates()`, created shared/actingUpdatesScopeDepth
* rearrange imports so builds work, remove the hack versions of flushPassiveEffects
* represent actingUpdatesScopeDepth as a tuple [number]
* use a shared flag on React.__SECRET...
* remove createAct, setup act for all relevant renderers
* review feedback
shared/enqueueTask
import ReactSharedInternals from 'shared/ReactSharedInternals';
simpler act() internals
ReactSharedInternals.ReactShouldWarnActingUpdates
* move act() implementation into createReactNoop
* warnIfNotCurrentlyActingUpdatesInDev condition check order
* Add Press responder event tests
Behavior being tested takes cues from React Native's Pressability.
A couple of these tests fail and require the Press implementation to be patched.
* Add PressProps type to event module
* Move default Press event delays to constants
* Fix right-click press check for Safari
* Prettier and Linter
* Use event.key in press responder
event.keyCode is a deprecated API
* Remove unused props from Press event module
Note: this is for an experimental event API that we're testing out internally at Facebook.
* onPressIn -> onPressStart
* onPressOut -> onPressEnd
* longPressCancelsPress -> onLongPressShouldCancelPress
* ReactNative's ref.measureLayout now takes a ref
* Use Object as the additional param type
* Remove unnecessary whitespace
* Not supporting ref in mixin or subclass
Make sure that `onPressChange` is only called if `longPressCancelsPress` is `false`.
And make sure that `onLongPressChange` is called when a long press ends.
The 'longpress' event is dispatched during a press interaction, rather than
after it has ended.
The 'longPressCancelsPress' prop can be used to prevent 'press' being
dispatched if 'longpress' has already been dispatched.
I inline it into performAsyncWork instead.
Code that was only relevant to the async callback had leaked into the
performWork call which is an indication that this was a bad abstraction
and therefore the wrong place to DRY.
By inlining I also discovered that minExpirationTime is actually irrelevant
in the yieldy case so we can clean that up.
* Isolate ReactUpdates-test cases
This ensures their behavior is consistent when run in isolation, and that they actually test the cases they're describing.
* Add coverage for cases where we reset nestedUpdateCounter
These cases explicitly verify that we reset the counter in right places.
* Add a mutually recursive test case
* Add test coverage for useLayoutEffect loop
Adds a feature flag `enableNewScheduler` that toggles between two
implementations of ReactFiberScheduler. This will let us land changes in
master while preserving the ability to quickly rollback.
Ideally this will be a short-lived fork. Once we've tested the new
scheduler for a week or so without issues, we will get rid of it. Until
then, we'll need to maintain two parallel implementations and run tests
against both of them. We rarely land changes to ReactFiberScheduler, so
I don't expect this will be a huge burden.
This commit does not implement anything new. The flag is still off and
tests run against the existing implementation.
Use `yarn test-new-scheduler` to run tests against the new one.
MDN has a list of methods for obtaining the window reference of an
iframe:
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage#Syntax
fix(react-dom): check if iframe belongs to the same origin
Accessing the contentDocument of a HTMLIframeElement can cause the browser
to throw, e.g. if it has a cross-origin src attribute.
Safari will show an error in the console when the access results in "Blocked a frame with origin". e.g:
```javascript
try {
$0.contentDocument.defaultView
} catch (err) {
console.log('err', err)
}
> Blocked a frame with origin X from accessing a frame with origin Y. Protocols, domains, and ports must match.
> err – TypeError: null is not an object (evaluating '$0.contentDocument.defaultView')
```
A safety way is to access one of the cross origin properties: Window or Location
Which might result in "SecurityError" DOM Exception and it is compatible to Safari.
```javascript
try {
$0.contentWindow.location.href
} catch (err) {
console.log('err', err)
}
> err – SecurityError: Blocked a frame with origin "http://localhost:3001" from accessing a cross-origin frame. Protocols, domains, and ports must match.
```
https://html.spec.whatwg.org/multipage/browsers.html#integration-with-idl
* Transform invariant to custom error type
This transforms calls to the invariant module:
```js
invariant(condition, 'A %s message that contains %s', adj, noun);
```
Into throw statements:
```js
if (!condition) {
if (__DEV__) {
throw ReactError(`A ${adj} message that contains ${noun}`);
} else {
throw ReactErrorProd(ERR_CODE, adj, noun);
}
}
```
The only thing ReactError does is return an error whose name is set
to "Invariant Violation" to match the existing behavior.
ReactErrorProd is a special version used in production that throws
a minified error code, with a link to see to expanded form. This
replaces the reactProdInvariant module.
As a next step, I would like to replace our use of the invariant module
for user facing errors by transforming normal Error constructors to
ReactError and ReactErrorProd. (We can continue using invariant for
internal React errors that are meant to be unreachable, which was the
original purpose of invariant.)
* Use numbers instead of strings for error codes
* Use arguments instead of an array
I wasn't sure about this part so I asked Sebastian, and his rationale
was that using arguments will make ReactErrorProd slightly slower, but
using an array will likely make all the functions that throw slightly
slower to compile, so it's hard to say which way is better. But since
ReactErrorProd is in an error path, and fewer bytes is generally better,
no array is good.
* Casing nit
* Add more info to invalid hook call error message
* Update other renderers + change call to action
* Update related tests for new hooks error message
* Fix lint errors
* Eager bailout optimization should always compare to latest reducer
* queue.eagerReducer -> queue.lastRenderedReducer
This name is a bit more descriptive.
* Add test case that uses preceding render phase update
* Throw away old shallow renderer state on type change
This worked in function components but was broken for classes. It incorrectly retained the old instance even if the type was different.
* Remove _previousComponentIdentity
We only needed this because we didn't correctly reset based on type. Now we do so this can go away.
* Use _reset when unmounting
* Use arbitrary componentIdentity
There was no particular reason it was set to element.type. We just wanted to check if something is a render phase update.
* Support Hook state updates in shallow renderer
* Support React.memo in ReactShallowRenderer
ReactShallowRenderer uses element.type frequently, but with React.memo
elements the actual type is element.type.type. This updates
ReactShallowRenderer so it uses the correct element type for Memo
components and also validates the inner props for the wrapped
components.
* Allow Rect.memo to prevent re-renders
* Support memo(forwardRef())
* Dont call memo comparison function on initial render
* Fix test
* Small tweaks
* Set 'size' attribute to select tag if it occurs before appending options
* Add comment about why size is assigned on select create. Tests
I added some more clarification for why size must be set on select
element creation:
- In the source code
- In the DOM test fixture
- In a unit test
* Use let, not const in select tag stub assignment
* Hydration Fixture: Only load ReactDOMServer if it exists
Fixes an issue where the hydration fixture would try to load in
ReactDOMServer below version 14. In version 13, string markup methods
exist on the React namespace.
* DOM Fixtures: Use class component for App.js
This was breaking React 0.13.0.
* Hydration Fixture: better findDOMNode compatibility
This commit fixes an issue where the Hydration DOM fixture was
unusable in React 0.13.0 or lower because of newer API usage.
It fixes that by avoiding the use of refs to get the textarea
reference in the code editor component, using various versions of
findDOMNode as required.
* Hydration Fixture: Do not show dropdown for single-line errors
If an error showed for the hydration fixture, a detail element was
used even if no additional lines could display. In that case, this
commit changes the component such that it returns a div.
* Deeper React version support for hydration fixture
This commit adds support for versions 0.4.0 of React and higher for
the hydration fixture.
The DOM test fixtures themselves do not support down to React 0.4.0,
which would be exhaustive. Instead, the Hydration fixture can pick a
version to use for its own purposes. By default, this is the version
of React used by the fixtures.
In the process of doing this, I had to make some updates to the
renderer.html document associated with the hydration fixture, and I've
added some comments to better document the history of API changes.
* Prevent javascript protocol URLs
* Just warn when disableJavaScriptURLs is false
This avoids a breaking change.
* Allow framesets
* Allow <html> to be used in integration tests
Full document renders requires server rendering so the client path
just uses the hydration path in this case to simplify writing these tests.
* Detect leading and intermediate characters and test mixed case
These are considered valid javascript urls by browser so they must be
included in the filter.
This is an exact match according to the spec but maybe we should include
a super set to be safer?
* Test updates to ensure we have coverage there too
* Fix toString invocation and Flow types
Right now we invoke toString twice when we hydrate (three times
with the flag off). Ideally we should only do it once even in this case
but the code structure doesn't really allow for that right now.
* s/itRejects/itRejectsRendering
* Dedupe warning and add the unsafe URL to the warning message
* Add test that fails if g is added to the sanitizer
This only affects the prod version since the warning is deduped anyway.
* Fix prod test
* Split props changing from permanent fallback state
These will need different logic. In this commit, no logic has changed,
only moved.
* Delete terminal fallback content in first pass
If the dehydrated suspense boundary's fallback content is terminal there
is nothing to show. We need to get actual content on the screen soon.
If we deprioritize that work to offscreen, then the timeout heuristics will
be wrong.
Therefore, if we have no current and we're already at terminal fallback
state we'll immediately schedule a deletion and upgrade to real suspense.
* Show failing case when there is another wrapper boundary
* Revert "Delete terminal fallback content in first pass"
This reverts commit ad67ba8928c23f5d9ba22d7e5c202bf27d0e49d3.
* Use the new approach of leaving work at normal pri to replace fallback
* Add command to run tests in persistent mode
* Convert Suspense fuzz tester to use noop renderer
So we can run it in persistent mode, too.
* Don't mutate stateNode in appendAllChildren
We can't mutate the stateNode in appendAllChildren because the children
could be current.
This is a bit weird because now the child that we append is different
from the one on the fiber stateNode. I think this makes conceptual
sense, but I suspect this likely breaks an assumption in Fabric.
With this approach, we no longer need to clone to unhide the children,
so I removed those host config methods.
Fixes bug surfaced by fuzz tester. (The test case that failed was the
one that's already hard coded.)
* In persistent mode, disable test that reads a ref
Refs behave differently in persistent mode. I added a TODO to write
a persistent mode version of this test.
* Run persistent mode tests in CI
* test-persistent should skip files without noop
If a file doesn't reference react-noop-renderer, we shouldn't bother
running it in persistent mode, since the results will be identical to
the normal test run.
* Remove module constructor from placeholder tests
We don't need this now that we have the ability to run any test file in
either mutation or persistent mode.
* Revert "test-persistent should skip files without noop"
Seb objected to adding shelljs as a dep and I'm too lazy to worry about
Windows support so whatever I'll just revert this.
* Delete duplicate file
* Convert ReactSuspensePlaceholder tests to use noop
Instead of the test renderer, since test renderer does not support
running in persistent mode.
* Run Placeholder tests in persistent mode, too
* Fix Flow and lint
* Hidden text instances should have correct host context
Adds a test for a subtle edge case that only occurs in persistent mode.
* createHiddenTextInstance -> cloneHiddenTextInstance
This sidesteps the problem where createHiddenTextInstance needs access
to the host context.
* A clearer message for props destructuring where applicable
* Add line number to the "move function" message
* Add a hint for how to fix callbacks from props
* Simplify code and harden tests
* Collect all dependency references for better warnings
* Suggest updater or reducer where appropriate
* Import Scheduler directly, not via host config
We currently schedule asynchronous tasks via the host config. (The host
config is a static/build-time dependency injection system that varies
across different renderers — DOM, native, test, and so on.) Instead of
calling platform APIs like `requestIdleCallback` directly, each renderer
implements a method called `scheduleDeferredCallback`.
We've since discovered that when scheduling tasks, it's crucial that
React work is placed in the same queue as other, non-React work on the
main thread. Otherwise, you easily end up in a starvation scenario where
rendering is constantly interrupted by less important tasks. You need a
centralized coordinator that is used both by React and by other
frameworks and application code. This coordinator must also have a
consistent API across all the different host environments, for
convention's sake and so product code is portable — e.g. so the same
component can work in both React Native and React Native Web.
This turned into the Scheduler package. We will have different builds of
Scheduler for each of our target platforms. With this approach, we treat
Scheduler like a built-in platform primitive that exists wherever React
is supported.
Now that we have this consistent interface, the indirection of the host
config no longer makes sense for the purpose of scheduling tasks. In
fact, we explicitly do not want renderers to scheduled task via any
system except the Scheduler package.
So, this PR removes `scheduleDeferredCallback` and its associated
methods from the host config in favor of directly importing Scheduler.
* Missed an extraneous export
* Warn on mount when deps are not an array
* Check other Hooks
* I can't figure out how to fix error/warning nesting lint
But it doesn't really matter much because we test other cases in the other test.
* Revert #14756 changes to ReactFiberScheduler
This PR introduced some bugs in concurrent mode during internal testing.
Until we figure out a proper solution, I'm going to try reverting it.
Not totally certain this is sufficient to unbreak the bugs we found, but
I'm using this branch to determine that.
* Add back commented out Scheduler import
With a note not to use named imports next time we import Scheduler
in this module.
This required a bit of unusual CSS but seems to work well for Firefox and Chrome. We can remove it and revisit other approaches (like PR#24) in the future if needed.
* ReactDebugHooks identifies State and Reducer hooks as editable
* Inject overrideHookState() method to DevTools to support editing in DEV builds
* Added an integration test for React DevTools, react-debug-tools, and overrideHookState
* Swap expect(ReactNoop) for expect(Scheduler)
In the previous commits, I upgraded our custom Jest matchers for the
noop and test renderers to use Scheduler under the hood.
Now that all these matchers are using Scheduler, we can drop
support for passing ReactNoop and test roots and always pass
Scheduler directly.
* Externalize Scheduler in noop and test bundles
I also noticed we don't need to regenerator runtime in noop anymore.
* Replace test renderer's fake Scheduler implementation with mock build
The test renderer has its own mock implementation of the Scheduler
interface, with the ability to partially render work in tests. Now that
this functionality has been lifted into a proper mock Scheduler build,
we can use that instead.
* Fix Profiler tests in prod
* Replace noop's fake Scheduler implementation with mock Scheduler build
The noop renderer has its own mock implementation of the Scheduler
interface, with the ability to partially render work in tests. Now that
this functionality has been lifted into a proper mock Scheduler build,
we can use that instead.
Most of the existing noop tests were unaffected, but I did have to make
some changes. The biggest one involved passive effects: previously, they
were scheduled on a separate queue from the queue that handles
rendering. After this change, both rendering and effects are scheduled
in the Scheduler queue. I think this is a better approach because tests
no longer have to worry about the difference; if you call `flushAll`,
all the work is flushed, both rendering and effects. But for those few
tests that do care to flush the rendering without the effects, that's
still possible using the `yieldValue` API.
Follow-up: Do the same for test renderer.
* Fix import to scheduler/unstable_mock
* Add new mock build of Scheduler with flush, yield API
Test environments need a way to take control of the Scheduler queue and
incrementally flush work. Our current tests accomplish this either using
dynamic injection, or by using Jest's fake timers feature. Both of these
options are fragile and rely too much on implementation details.
In this new approach, we have a separate build of Scheduler that is
specifically designed for test environments. We mock the default
implementation like we would any other module; in our case, via Jest.
This special build has methods like `flushAll` and `yieldValue` that
control when work is flushed. These methods are based on equivalent
methods we've been using to write incremental React tests. Eventually
we may want to migrate the React tests to interact with the mock
Scheduler directly, instead of going through the host config like we
currently do.
For now, I'm using our custom static injection infrastructure to create
the two builds of Scheduler — a default build for DOM (which falls back
to a naive timer based implementation), and the new mock build. I did it
this way because it allows me to share most of the implementation, which
isn't specific to a host environment — e.g. everything related to the
priority queue. It may be better to duplicate the shared code instead,
especially considering that future environments (like React Native) may
have entirely forked implementations. I'd prefer to wait until the
implementation stabilizes before worrying about that, but I'm open to
changing this now if we decide it's important enough.
* Mock Scheduler in bundle tests, too
* Remove special case by making regex more restrictive
* Refactor hook ordering check to use DEV-only data structure. This enables us to warn about more cases (e.g. useContext, useDebugValue) withou the need to add any overhead to production bundles.
* Throw in tests if work is done before emptying log
Test renderer already does this. Makes it harder to miss unexpected
behavior by forcing you to assert on every logged value.
* Convert ReactNoop tests to use jest matchers
The matchers warn if work is flushed while the log is empty. This is
the pattern we already follow for test renderer. I've used the same APIs
as test renderer, so it should be easy to switch between the two.
* Deprecate ref.setNativeProps in favor of ReactNative.setNativeProps
* Using a feature flag for the setNativeProps warning
* Removing extra line breaks
* Set the FB native feature flag to true
* Prettier
* Remove ReactNoop.flushDeferredPri and flushUnitsOfWork
Some of our older tests worked by counting how many times React checked
whether it should yield to the main thread, instead of something
publicly observable like how many times a component is rendered.
Our newer tests have converged on a style where we push into a log and
make assertions on the log. This pattern is less coupled to the
implementation while still being sufficient to test performance
optimizations, like resuming (whenever we add that back).
This commit removes flushDeferredPri and flushUnitsOfWork and upgrades
the affected tests.
* Remove shouldYieldToRenderer indirection
This wrapper is no longer necessary.
As I prepare to refactor the Fiber scheduler, I've noticed some quirks
in our implementation. This PR addressed one of them.
---
There's no reason for a timed out Scheduler callback to check
`shouldYield`, because the value will always be false until the work
has completed. The `didTimeout` argument provides this information to
the callback so it can avoid the redundant checks.
React's existing check for whether a callback has timed out didn't make
any sense, but happened to work anyway. I don't think the wrongness of
the old implementation is observable via React APIs but it's
incoherent regardless.
* Adding ReactNative.setNativeProps that takes a ref
* Adding test for components rendered with Fabric with Paper's setNativeProps
* Fixing flow types
* Fix prettier
* Rename ReactNativeSetNativeProps.js to be more general
* Add ESLint rule for useEffect/useCallback/useMemo Hook dependencies
* Fix ReactiveDependencies rule
* fix lint errors
* Support useLayoutEffect
* Add some failing tests and comments
* Gather dependencies in child scopes too
* If we don't find foo.bar.baz in deps, try foo.bar, then foo
* foo is enough for both foo.bar and foo.baz
* Shorter rule name
* Add fixable meta
* Remove a bunch of code and start from scratch
* [WIP] Only report errors from dependency array
This results in nicer editing experience. Also has autofix.
* Fix typo
* [Temp] Skip all tests
* Fix the first test
* Revamp the test suite
* Fix [foo] to include foo.bar
* Don't suggest call expressions
* Special case 'current' for refs
* Don't complain about known static deps
* Support useImperativeHandle
* Better punctuation and formatting
* More uniform message format
* Treat React.useRef/useState/useReducer as static too
* Add special message for ref.current
* Add a TODO case
* Alphabetize the autofix
* Only alphabetize if it already was
* Don't add static deps by default
* Add an undefined variable case
* Tweak wording
* Rename to exhaustive-deps
* Clean up / refactor a little bit
* Replace SSR fallback content with new suspense content
* The three states of a Dehydrated Suspense
This introduces three states for dehydrated suspense boundaries
Pending - This means that the tree is still waiting for additional data or
to be populated with its final content.
Fallback - This means that the tree has entered a permanent fallback state
and no more data from the server is to be expected. This means that the
client should take over and try to render instead. The fallback nodes will
be deleted.
Normal - The node has entered its final content and is now ready to be
hydrated.
* Rename retryTimedOutBoundary to resolveRetryThenable
This doesn't just retry. It assumes that resolving a thenable means that
it is ok to clear it from the thenable cache.
We'll reuse the retryTimedOutBoundary logic separately.
* Register a callback to be fired when a boundary changes away from pending
It's now possible to switch from a pending state to either hydrating
or replacing the content.
* Improve release script process documentation
* Improved pre-publish instructions/message based on feedback
* Added reminder to attach build artifacts to GitHub release
* Basic partial hydration test
* Render comments around Suspense components
We need this to be able to identify how far to skip ahead if we're not
going to hydrate this subtree yet.
* Add DehydratedSuspenseComponent type of work
Will be used for Suspense boundaries that are left with their server
rendered content intact.
* Add comment node as hydratable instance type as placeholder for suspense
* Skip past nodes within the Suspense boundary
This lets us continue hydrating sibling nodes.
* A dehydrated suspense boundary comment should be considered a sibling
* Retry hydrating at offscreen pri or after ping if suspended
* Enter hydration state when retrying dehydrated suspense boundary
* Delete all children within a dehydrated suspense boundary when it's deleted
* Delete server rendered content when props change before hydration completes
* Make test internal
* Wrap in act
* Change SSR Fixture to use Partial Hydration
This requires the enableSuspenseServerRenderer flag to be manually enabled
for the build to work.
* Changes to any parent Context forces clearing dehydrated content
We mark dehydrated boundaries as having child work, since they might have
components that read from the changed context.
We check this in beginWork and if it does we treat it as if the input
has changed (same as if props changes).
* Wrap in feature flag
* Treat Suspense boundaries without fallbacks as if not-boundaries
These don't come into play for purposes of hydration.
* Fix clearing of nested suspense boundaries
* ping -> retry
Co-Authored-By: sebmarkbage <sebastian@calyptus.eu>
* Typo
Co-Authored-By: sebmarkbage <sebastian@calyptus.eu>
* Use didReceiveUpdate instead of manually comparing props
* Leave comment for why it's ok to ignore the timeout
* Add 16.8.0 changelog
* Mention ESLint plugin
* Remove experimental notices from the ESLint plugin README
* Update CHANGELOG.md
* Add more details for Hooks
* fix
* Set a date
* Update CHANGELOG.md
Co-Authored-By: gaearon <dan.abramov@gmail.com>
* Update CHANGELOG.md
* useReducer in changelog
* Add to changelog
* Update date
* Add #14119 to changelog
* Add #14744 to changelog
* Fix PR links
* act() method was added to test utils, too
* Updated release date to February 6th
* Add Scheduler.unstable_next
* Use Scheduler to prioritize updates
Changes the implementation of syncUpdates, deferredUpdates, and
interactiveUpdates to use runWithPriority, so
This is the minimum integration between Scheduler and React needed to
unblock use of the Scheduler.next API.
* Add Scheduler.unstable_next
* Use Scheduler to prioritize updates
Changes the implementation of syncUpdates, deferredUpdates, and
interactiveUpdates to use runWithPriority, so
This is the minimum integration between Scheduler and React needed to
unblock use of the Scheduler.next API.
* Add 16.8.0 changelog
* Mention ESLint plugin
* Remove experimental notices from the ESLint plugin README
* Update CHANGELOG.md
* Add more details for Hooks
* fix
* Set a date
* Update CHANGELOG.md
Co-Authored-By: gaearon <dan.abramov@gmail.com>
* Update CHANGELOG.md
* useReducer in changelog
* Add to changelog
* Update date
* Add #14119 to changelog
* Add #14744 to changelog
* Fix PR links
* act() method was added to test utils, too
* Updated release date to February 6th
* Add 16.8.0 changelog
* Mention ESLint plugin
* Remove experimental notices from the ESLint plugin README
* Update CHANGELOG.md
* Add more details for Hooks
* fix
* Set a date
* Update CHANGELOG.md
Co-Authored-By: gaearon <dan.abramov@gmail.com>
* Update CHANGELOG.md
* useReducer in changelog
* Add to changelog
* Update date
* Add #14119 to changelog
* Add #14744 to changelog
* Fix PR links
* act() method was added to test utils, too
* Updated release date to February 6th
* expose unstable_interact for batching actions in tests
* move to TestUtils
* move it all into testutils
* s/interact/act
* warn when calling hook-like setState outside batching mode
* pass tests
* merge-temp
* move jsdom test to callsite
* mark failing tests
* pass most tests (except one)
* augh IE
* pass fuzz tests
* better warning, expose the right batchedUpdates on TestRenderer for www
* move it into hooks, test for dom
* expose a flag on the host config, move stuff around
* rename, pass flow
* pass flow... again
* tweak .act() type
* enable for all jest environments/renderers; pass (most) tests.
* pass all tests
* expose just the warning from the scheduler
* don't return values
* a bunch of changes.
can't return values from .act
don't try to await .act calls
pass tests
* fixes and nits
* "fire events that udpates state"
* nit
* 🙄
* my bad
* hi andrew
(prettier fix)
* Avoid importing Scheduler directly
The reconciler should not depend directly on Scheduler. This adds it to
the host config for the renderer instead.
(Except for `scheduler/tracing` imports, which are used only by the
profiling build. I've left those imports as-is, though I'm open to
directing those through the host config, too.)
* Make throwaway root id longer to appease Brian
* Restrict effect return type to a function or nothing
We already warn in dev if the wrong type is returned. This updates the
Flow type.
* Restrict return type further
* Assume Effect hook returns either a function or undefined
* Tweak warning message
* Improve Reducer Hook's lazy init API
* Use generic type for initilizer input
Still requires an `any` cast in the case where `init` function is
not provided.
* Move DEV-only function right above where it's used
I don't like looking at this top-level function #petty
* Use different dispatchers for functions & classes
Classes support readContext, but not any of the other dispatcher
methods. Function support all methods.
This is a more robust version of our previous strategy of checking
whether `currentlyRenderingFiber` is null.
As a next step, we can use a separate dispatcher for each phase of the
render cycle (mount versus update).
* Use separate dispatchers for mount and update
* Remove mount code from update path
Deletes mount-specific code from the update path, since it should be
unreachable. To continue supporting progressive enhancement (mounting
new hooks at the end of the list), we detect when there are no more
current hooks and switch back to the mount dispatcher. Progressive
enhancement isn't officially supported yet, so it will continue to warn.
* Factoring nits
* Fix Flow
Had to cheat more than I would like
* More Flow nits
* Switch back to using a special dispatcher for nested hooks in DEV
In order for this strategy to work, I had to revert progressive
enhancement support (appending hooks to the end). It was previously a
warning but now it results in an error. We'll reconsider later.
* Always pass args to updateState and updateReducer
Even though the extra args are only used on mount, to ensure
type consistency.
* Make readContext() in Hooks DEV-only warning
* Warn about readContext() during class render-phase setState()
* Warn on readContext() in SSR inside useMemo and useReducer
* Make all Hooks-in-Hooks warnings DEV-only
* Rename stashContextDependencies
* Clean up warning state on errors
* Turned enableHooks feature flag on everywhere
* Removed useHooks feature flag from tests (now that it's on by default)
* Remove useHooks feature flag entirely
* Revert "Revert "Double-render function components with Hooks in DEV in StrictMode" (#14652)"
This reverts commit 3fbebb2a0b.
* Revert "Revert "Disallow reading context during useMemo etc" (#14651)"
This reverts commit 5fce6488ce.
* Add extra passing test for an edge case
Mentioned by @acdlite to watch out for
* More convoluted test
* Don't rely on expirationTime
Addresses @acdlite's concerns
* Edge case: forbid readContext() during eager reducer
* 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.
* Memoize promise listeners to prevent exponential growth
Previously, React would attach a new listener every time a promise is
thrown, regardless of whether the same listener was already attached
during a previous render. Because React attempts to render every time
a promise resolves, the number of listeners grows quickly.
This was especially bad in synchronous mode because the renders that
happen when the promise pings are not batched together. So if a single
promise has multiple listeners for the same root, there will be multiple
renders, which in turn results in more listeners being added to the
remaining unresolved promises. This results in exponential growth in
the number of listeners with respect to the number of IO-bound
components in a single render.
Fixes#14220
* Memoize on the root and Suspense fiber instead of on the promise
* Add TODO to fix persistent mode tests
* Inject overrideProps() fn to DevTools
This function will enable editing props for function components, host nodes, and special types like memo and forwardRef.
* [Fizz] Add Flow/Jest/Rollup build infra
Add a new package for react-stream which allows for custom server renderer
outputs. I picked the name because it's a reasonable name but also
because the npm name is currently owned by a friend of the project.
The react-dom build has its own inlined server renderer under the
name `react-dom/fizz`.
There is also a noop renderer to be used for testing. At some point
we might add a public one to test-renderer but for now I don't want to have
to think about public API design for the tests.
* Add FormatConfig too
We need to separate the format (DOM, React Native, etc) from the host
running the server (Node, Browser, etc).
* Basic wiring between Node, Noop and DOM configs
The Node DOM API is pipeToNodeStream which accepts a writable stream.
* Merge host and format config in dynamic react-stream entry point
Simpler API this way but also avoids having to fork the wrapper config.
Fixes noop builds.
* Add setImmediate/Buffer globals to lint config
Used by the server renderer
* Properly include fizz.node.js
Also use forwarding to it from fizz.js in builds so that tests covers
this.
* Make react-stream private since we're not ready to publish
or even name it yet
* Rename Renderer -> Streamer
* Prefix react-dom/fizz with react-dom/unstable-fizz
* Add Fizz Browser host config
This lets Fizz render to WHATWG streams. E.g. for rendering in a
Service Worker.
I added react-dom/unstable-fizz.browser as the entry point for this.
Since we now have two configurations of DOM. I had to add another
inlinedHostConfigs configuration called `dom-browser`. The reconciler
treats this configuration the same as `dom`. For stream it checks
against the ReactFizzHostConfigBrowser instead of the Node one.
* Add Fizz Browser Fixture
This is for testing server rendering - on the client.
* Lower version number to detach it from react-reconciler version
* Fixes#14360 and adds a test for mixed priority dispatches.
It was broken because `cloneHook` assigned `memoizedState` instead of
`baseState` from the original hook to `baseState` of the clone.
* tweak comments
* Add a test for current defaultProps behavior in lazy
* Add a warning against definining defaultProps on the outer wrapper
* Warn about setting propTypes too
* Remove redundant async
* Validate propTypes for resolved lazy types
Note this only works for elements created after resolving. So it's not ideal. But it provides the best stack trace for those cases.
* Add a test for lazy(forwardRef()) propTypes check
* Validate memo() inner propTypes and warn about shadowing
* Add test verifying nested lazy is unsupported
* Change error wording to remove "Promise elements"
* Improve error message for nested lazy() and add tests
* Validate propTypes for memo in the reconciler when necessary
* Add comments for why we're calling checkPropTypes
* Fix Flow and lint
* Undo unintentional formatting changes
* Remove unnecessary case (it is handled by function code path)
* Add test coverage for memo(fn.defaultProps).propTypes
* Test should be agnostic of where resolving happens
That's an implementation detail and we might want to change it later. Let's keep it easy by making tests just check that validation happened, not at which stage.
* Unify traversal logic in createElement
This moves all type traversal into createElement. When lazy resolves, we call createElement once to re-check.
* Match prod behavior for propTypes/defaultProps shims closer
* Revert "Unify traversal logic in createElement"
This reverts commit 2e77ca47fe80ebe6595333542a8c5c138c68643f.
See https://github.com/facebook/react/pull/14298#issuecomment-442687775
* Undo unnecessary change to getComponentName
useMutationEffect has problems (namely, refs aren't attached at the time that it runs) and we're not positive it's necessary. useLayoutEffect runs at the same time as componentDidMount/Update so it's sufficient for all existing use cases; it can be used in any case that useEffect happens too late. Until we figure out what we want to do, let's delete it.
Regression introduced in #14182 resulted in errors no longer being emitted on streams, breaking many consumers.
Co-authored-by: Elliot Jalgard <elliot.j@live.se>
* Add failing test for defaultProps between lazy() and memo()
* Add another regression test for defaultProps resolution order
* Resolve outer props for MemoComponent
Whenever we do this, Rollup needs to materialize this as an object.
This causes it to also add the Babel compatibility property which is
unnecessary bloat. However, since when we use these, we leak the object
this often also deopts any compiler optimizations.
If we really need an object we should export default an object.
Currently there is an exception for DOMTopLevelEventTypes since
listing out the imports is a PITA and it doesn't escape so it should
get properly inlined. We should probably move to a different pattern
to avoid this for consistency though.
In the process of switching to MessageChannel, it seems the postMessage call was modified to pass `"*"` (originally the target origin value from `window.postMessage`). This actually ends up triggering serialization, whereas passing `undefined` bypasses.
To save some investigation, passing a Number like `0` still incurs serialization overhead - `undefined` has special behavior.
Disables the recently introduced (#14181) warning for shorthand
CSS property collisions by wrapping in a feature flag. Let's hold off
shipping this until at least the next minor.
* Add a checkbox to fixtures UI to choose React production build
* Assign header__label class name to label directly, instead of using a separate span
* center the production checkbox vertically
Scheduler needs to schedule a task that fires after paint. To do this,
it currently posts a message event to `window`. This happens on every
frame until the queue is empty. An unfortunate consequence is that every
other message event handler also gets called on every frame; even if
they exit immediately, this adds up to significant per-frame overhead.
Instead, we'll create a MessageChannel and post to that, with a
fallback to the old behavior if MessageChannel does not exist.
I figured out a simpler way to do #14181. It does allocate some but I think that's OK. Time complexity might even be better since we avoid the nested loops the old one had.
* BUG: ReactPartialRenderer / New Context polutes mutable global state
The new context API stores the provided values on the shared context instance. When used in a synchronous context, this is not an issue. However when used in an concurrent context this can cause a "push provider" from one react render to have an effect on an unrelated concurrent react render.
I've encountered this bug in production when using renderToNodeStream, which asks ReactPartialRenderer for bytes up to a high water mark before yielding. If two Node Streams are created and read from in parallel, the state of one can polute the other.
I wrote a failing test to illustrate the conditions under which this happens.
I'm also concerned that the experimental concurrent/async React rendering on the client could suffer from the same issue.
* Use unique thread ID for each partial render to access Context
This first adds an allocator that keeps track of a unique ThreadID index
for each currently executing partial renderer. IDs are not just growing
but are reused as streams are destroyed.
This ensures that IDs are kept nice and compact.
This lets us use an "array" for each Context object to store the current
values. The look up for these are fast because they're just looking up
an offset in a tightly packed "array".
I don't use an actual Array object to store the values. Instead, I rely
on that VMs (notably V8) treat storage of numeric index property access
as a separate "elements" allocation.
This lets us avoid an extra indirection.
However, we must ensure that these arrays are not holey to preserve this
feature.
To do that I store the _threadCount on each context (effectively it takes
the place of the .length property on an array).
This lets us first validate that the context has enough slots before we
access the slot. If not, we fill in the slots with the default value.
This is one of the most insidious quirks of React DOM that people run into. Now we warn when we think an update is dangerous.
We still allow rendering `{background, backgroundSize}` with unchanging values, for example. But once you remove either one or change `background` (without changing `backgroundSize` at the same time), that's bad news. So we warn.
Fixes#6348.
Oopsie!
This could have been avoided if our types were modeled correctly with
Flow (using a disjoint union).
Fuzz tester didn't catch it because it does not generate cases where
a Suspense component mounts with no children. I'll update it.
* Don't warn if an unmounted component is pinged
* Suspense fuzz tester
The fuzzer works by generating a random tree of React elements. The tree
two types of custom components:
- A Text component suspends rendering on initial mount for a fuzzy
duration of time. It may update a fuzzy number of times; each update
supsends for a fuzzy duration of time.
- A Container component wraps some children. It may remount its children
a fuzzy number of times, by updating its key.
The tree may also include nested Suspense components.
After this tree is generated, the tester sets a flag to temporarily
disable Text components from suspending. The tree is rendered
synchronously. The output of this render is the expected output.
Then the tester flips the flag back to enable suspending. It renders the
tree again. This time the Text components will suspend for the amount of
time configured by the props. The tester waits until everything has
resolved. The resolved output is then compared to the expected output
generated in the previous step.
Finally, we render once more, but this time in concurrent mode. Once
again, the resolved output is compared to the expected output.
I tested by commenting out various parts of the Suspense implementation
to see if broke in the expected way. I also confirmed that it would have
caught #14133, a recent bug related to deletions.
* When a generated test case fails, log its input
* Moar fuzziness
Adds more fuzziness to the generated tests. Specifcally, introduces
nested Suspense cases, where the fallback of a Suspense component
also suspends.
This flushed out a bug (yay!) whose test case I've hard coded.
* Use seeded random number generator
So if there's a failure, we can bisect.
* Add failing test for ping on unmounted component
We had a test for this, but not outside of concurrent mode :)
* Don't warn if an unmounted component is pinged
* Parse build script type and package names
This ensures that `yarn build core dom` includes DOM.
It also ensures that spaces like `yarn build "core, dom"` doesn't build EVERYTHING.
* Get rid of label in bundles config
Instead we just use the name from entry using fuzzy search.
There is one special case. If you put in `/index` or `/index.js`.
That allows to build things like `react/index` to only build isomorphic
where as `react` would build everything. Or `react-dom/index` to exclude
the server renderers.
* Instead of matching `/index.js` just append it to the search string
That way things like `yarn build react/` works too.
* Fixed `treeBaseDuration` by propagating its value from the suspended tree to the Fragment React temporarily wraps around it when showing the fallback UI.
* Fixed `actualDuration` by recording elapsed profiler time in the event of an error.
* Fixed `actualDuration` in concurrent mode by propagating the time spent rendering the suspending component to its parent.
Also updated ReactSuspensePlaceholder-test.internal to cover these new cases.
Fixes a bug where deletion effects in the primary tree were dropped
before entering the second render pass.
Because we no longer reset the effect list after the first render pass,
I've also moved the deletion of the fallback children to the complete
phase, after the tree successfully renders without suspending.
Will need to revisit this heuristic when we implement resuming.
* Recover from errors with a boundary in completion phase
* Use a separate field for completing unit of work
* Use a simpler fix with one boolean
* Reoder conditions
* Clarify which paths are DEV-only
* Move duplicated line out
* Make it clearer this code is DEV-only
Adds a check to the existing fuzz tester to confirm that the props are
set to the latest values in the commit phase. Only checks
componentDidUpdate; we already have unit tests for the other lifecycles,
so I think this is good enough. This is only a redundancy.
* Resolve defaultProps for Lazy components
* Make test fail again
* Undo the partial fix
* Make test output more compact
* Add a separate failing test for sync mode
* Clean up tests
* Add another update to both tests
* Resolve props for commit phase lifecycles
* Resolve prevProps for begin phase lifecycles
* Resolve prevProps for pre-commit lifecycles
* Only resolve props if element type differs
* Fix Flow
* Don't set instance.props/state during commit phase
This is an optimization. I'm not sure it's entirely safe. It's probably worth running internal tests and see if we can ever trigger a case where they're different.
This can mess with resuming.
* Keep setting instance.props/state before unmounting
This reverts part of the previous commit. It broke a test that verifies we use current props in componentWillUnmount if the fiber unmounts due to an error.
Setting to null isn't correct; setting to '' is. I opted to use dangerousStyleValue for consistency with the main path that we set things.
Fixes#14114.
Test Plan:
Verified setting to '' works in Chrome and IE11. (Setting to null works in Chrome but not in IE11.)
The `enableHooks` feature flag used to only control whether the API
was exposed on the React package. But now it also determines if the
dispatcher and implementation are included in the bundle.
We're using hooks in www, so I've switched the feature flag to `true`
in the www build.
(Alternatively, we could have two feature flags: one for the
implementation and dispatcher, and one for exposing the API on the
React package.)
* Avoid double commit by re-rendering immediately and reusing children
To support Suspense outside of concurrent mode, any component that
starts rendering must commit synchronously without being interrupted.
This means normal path, where we unwind the stack and try again from the
nearest Suspense boundary, won't work.
We used to have a special case where we commit the suspended tree in an
incomplete state. Then, in a subsequent commit, we re-render using the
fallback.
The first part — committing an incomplete tree — hasn't changed with
this PR. But I've changed the second part — now we render the fallback
children immediately, within the same commit.
* Add a failing test for remounting fallback in sync mode
* Add failing test for stuck Suspense fallback
* Toggle visibility of Suspense children in mutation phase, not layout
If parent reads visibility of children in a lifecycle, they should have
already updated.
This is required to use lazy.
Test Plan:
* Verified lazy works on a real world use case (shows spinner, shows real content).
* Verified that if I change the primary content's styles to have `display: 'none'` then it never appears (i.e., the code in `unhide` reads the styles successfully)
* Add debug tools package
* Add basic implementation
* Implement inspection of the current state of hooks using the fiber tree
* Support useContext hooks inspection by backtracking from the Fiber
I'm not sure this is safe because the return fibers may not be current
but close enough and it's fast.
We use this to set up the current values of the providers.
* rm copypasta
* Use lastIndexOf
Just in case. I don't know of any scenario where this can happen.
* Support ForwardRef
* Add test for memo and custom hooks
* Support defaultProps resolution
Check for existence of `setTimeout` and `clearTimeout` in the runtime
before using them, to ensure runtimes without them (like .NET ClearScript)
do not crash just by importing `react-dom`.
Mostly to catch this:
```js
useEffect(async () => {
// ...
return cleanup;
});
```
Is this too restrictive? Not sure if you would want to do like
```js
useEffect(() => ref.current.style.color = 'red');
```
which would give a false positive here. We can always relax it to only warn on Promises if people complain.
* Simplify imports in ReactChildFiber
* Import type first in ReactCurrentFiber
* Simplify imports in ReactFiberBeginWork
* Simplify imports in ReactFiberScheduler
* Simplify import in ReactFiberTreeReflection
* Simplify import in ReactFiberUnwindWork
* Remove repeated import
* Fix imports from ReactFiberExpirationTime
* Master imports in ReactFiberBeginWork
Removes the `enableDispatchCallback` feature flag and deletes the
associated code. An earlier version of the Hooks proposal included this
feature but we've since decided to remove it.
* [scheduler] Deadline object -> shouldYield
Instead of using a requestIdleCallback-style deadline object, expose a
method Scheduler.shouldYield that returns true if there's a higher
priority event in the queue.
* Nits
Even though we commit the fiber in an incomplete state, we shouldn't
fire any lifecycles or effects.
We already did this for classes, but now with useEffect, the same is
needed for other types of work, too.
Before the fix, the passive effect in the test is never executed.
We were previously waiting until the next commit phase to run effects. Now, we run them before scheduling work.
Effects scheduled by useEffect should not fire until after the browser
has had a chance to paint. However, they should be fired before any
subsequent mutations.
Also adds useMutationEffect and useLayoutEffect. useMutationEffect fires
during the host update phase. useLayoutEffect fires during the post-
update phase (the same phase as componentDidMount
and componentDidUpdate).
* [react-cache] Remove `cache` as argument to `read`
Updated is API is `Resource.read(key)` instead of
`Resource.read(cache, key)`.
The cache is read from context using `readContext`.
This also removes cache invalidation entirely (other than the default
LRU mechanism), as well as the ability to have multiple caches. We'll
add it back once `Context.write` lands and we can implement it the
right way.
Since there's now only a single cache (the global one), we don't
actually need to use context yet, but I've added a dummy context
anyway so the user gets an error if they attempt to read outside the
render phase.
* nits
* Add test for thenables that resolve multiple times
* [Synchronous Suspense] Suspending a class outside concurrent mode
When a class component suspends during mount outside concurrent mode,
change the tag so it's not mistaken for a completed component. For
example, we should not call componentWillUnmount if it is deleted.
* PR nits
We are using it with lazy and the combination Suspense + lazy seems pretty
stable. maxDuration is not but that's only enabled when you're in
ConcurrentMode which is still unstable.
Found a bug related to suspending inside an already mounted tree. While
investigating this I noticed we really don't have much coverage of
suspended updates. I think this would greatly benefit from some fuzz
testing; still haven't thought of a good test case, though.
* Add support for React.pure in ReactDOMServer
* Unwrap pure wrappers by creating an additional element as a single child
This is very slow but meh. We're rewriting this whole thing anyway.
* Allow arbitrary types to be wrapped in pure
This creates an outer fiber that container the pure check and an inner
fiber that represents which ever type of component.
* Add optimized fast path for simple pure function components
Special cased when there are no defaultProps and it's a simple function
component instead of class. This doesn't require an extra fiber.
We could make it so that this also works with custom comparer but that
means we have to go through one extra indirection to get to it.
Maybe it's worth it, donno.
* Introduce elementType field
This will be used to store the wrapped type of an element. E.g. pure and
lazy.
The existing type field will be used for the unwrapped type within them.
* Store the unwrapped type on the type field of lazy components
* Use the raw tags for lazy components
Instead, we check if the elementType and type are equal to test if
we need to resolve props. This is slightly slower in the normal case
but will yield less code and branching.
* Clean up lazy branches
* Collapse work tag numbering
* Split IndeterminateComponent out from Lazy
This way we don't have to check the type in a hacky way in the
indeterminate path. Also, lets us deal with lazy that resolves to
indeterminate and such.
* Missing clean up in rebase
* Always bail out timed out children even if they receive an update
The fragment that wraps timed-out children should always have an
expiration time of NoWork.
* Don't need to set expirationTime, only childExpirationTime
* Move memoizedProps to after beginWork remove memoizeProps helper
We always call this at the end. This is now enforced to line up since
we do the equality check in the beginning of beginWork. So we can't
have special cases.
* Inline the one caller of memoizeState
Outside of concurrent mode, schedules a force update on a suspended
class component to force it to prevent it from bailing out and
reusing the current fiber, which we know to be inconsistent.
Removes support for using arbitrary promises as the type of a React
element. Instead, promises must be wrapped in React.lazy. This gives us
flexibility later if we need to change the protocol.
The reason is that promises do not provide a way to call their
constructor multiple times. For example:
const promiseForA = new Promise(resolve => {
fetchA(a => resolve(a));
});
Given a reference to `promiseForA`, there's no way to call `fetchA`
again. Calling `then` on the promise doesn't run the constructor again;
it only attaches another listener.
In the future we will likely introduce an API like `React.eager` that
is similar to `lazy` but eagerly calls the constructor. That gives us
the ability to call the constructor multiple times. E.g. to increase
the priority, or to retry if the first operation failed.
* Suspense component does not capture if `fallback` is not defined
A missing fallback prop means the exception should propagate to the next
parent (like a rethrow). That way a Suspense component can specify other
props like maxDuration without needing to provide a fallback, too.
Closes#13864
* Change order of checks
This was the original, lower-level API before we landed on `fallback`
instead. (We might add a different lower-level API in the future, likely
alongside a new API for catching errors).
In the default mode, Suspense has special semantics where, in
addition to timing out immediately, we don't unwind the stack before
rendering the fallback. Instead, we commit the tree in an inconsistent
state, then synchronous render *again* to switch to the fallback. This
is slower but is less likely to cause issues with older components that
perform side effects in the render phase (e.g. componentWillMount,
componentWillUpdate, and componentWillReceiveProps).
We should do this in strict mode, too, so that there are no semantic
differences (in prod, at least) between default mode and strict mode.
The rationale is that it makes it easier to wrap a tree in strict mode
and start migrating components incrementally without worrying about new
bugs in production.
* Store the start time on `updateQueue` instead of `stateNode`
Originally I did this to free the `stateNode` field to store a second
set of children. I don't we'll need this anymore, since we use fragment
fibers instead. But I still think using `updateQueue` makes more sense
so I'll leave this in.
* Use fragment fibers to keep the primary and fallback children separate
If the children timeout, we switch to showing the fallback children in
place of the "primary" children. However, we don't want to delete the
primary children because then their state will be lost (both the React
state and the host state, e.g. uncontrolled form inputs). Instead we
keep them mounted and hide them. Both the fallback children AND the
primary children are rendered at the same time. Once the primary
children are un-suspended, we can delete the fallback children — don't
need to preserve their state.
The two sets of children are siblings in the host environment, but
semantically, for purposes of reconciliation, they are two separate
sets. So we store them using two fragment fibers.
However, we want to avoid allocating extra fibers for every placeholder.
They're only necessary when the children time out, because that's the
only time when both sets are mounted.
So, the extra fragment fibers are only used if the children time out.
Otherwise, we render the primary children directly. This requires some
custom reconciliation logic to preserve the state of the primary
children. It's essentially a very basic form of re-parenting.
* Use `memoizedState` to store various pieces of SuspenseComponent's state
SuspenseComponent has three pieces of state:
- alreadyCaptured: Whether a component in the child subtree already
suspended. If true, subsequent suspends should bubble up to the
next boundary.
- didTimeout: Whether the boundary renders the primary or fallback
children. This is separate from `alreadyCaptured` because outside of
strict mode, when a boundary times out, the first commit renders the
primary children in an incomplete state, then performs a second commit
to switch the fallback. In that first commit, `alreadyCaptured` is
false and `didTimeout` is true.
- timedOutAt: The time at which the boundary timed out. This is separate
from `didTimeout` because it's not set unless the boundary
actually commits.
These were previously spread across several fields.
This happens to make the non-strict case a bit less hacky; the logic for
that special case is now mostly localized to the UnwindWork module.
* Hide timed-out Suspense children
When a subtree takes too long to load, we swap its contents out for
a fallback to unblock the rest of the tree. Because we don't want
to lose the state of the timed out view, we shouldn't actually delete
the nodes from the tree. Instead, we'll keep them mounted and hide
them visually. When the subtree is unblocked, we un-hide it, having
preserved the existing state.
Adds additional host config methods. For mutation mode:
- hideInstance
- hideTextInstance
- unhideInstance
- unhideTextInstance
For persistent mode:
- cloneHiddenInstance
- cloneUnhiddenInstance
- createHiddenTextInstance
I've only implemented the new methods in the noop and test renderers.
I'll implement them in the other renderers in subsequent commits.
* Include `hidden` prop in noop renderer's output
This will be used in subsequent commits to test that timed-out children
are properly hidden.
Also adds getChildrenAsJSX() method as an alternative to using
getChildren(). (Ideally all our tests would use test renderer #oneday.)
* Implement hide/unhide host config methods for DOM renderer
For DOM nodes, we hide using `el.style.display = 'none'`.
Text nodes don't have style, so we hide using `text.textContent = ''`.
* Implement hide/unhide host config methods for Art renderer
* Create DOM fixture that tests state preservation of timed out content
* Account for class components that suspend outside concurrent mode
Need to distinguish mount from update. An unfortunate edge case :(
* Fork appendAllChildren between persistent and mutation mode
* Remove redundant check for existence of el.style
* Schedule placement effect on indeterminate components
In non-concurrent mode, indeterminate fibers may commit in an
inconsistent state. But when they update, we should throw out the
old fiber and start fresh. Which means the new fiber needs a
placement effect.
* Pass null instead of current everywhere in mountIndeterminateComponent
* Deprecate findDOMNode in StrictMode
There are two scenarios. One is that we pass a component instance that is
already in strict mode or the node that we find is in strict mode if
an outer component renders into strict mode.
I use a separate method findHostInstanceWithWarning for this so that
a) I can pass the method name (findDOMNode/findNodeHandle).
b) Can ignore this warning in React Native mixins/NativeComponent that use this helper.
I don't want to expose the fiber to the renderers themselves.
- "Interactive" -> "user-blocking"
- "Whenever" -> "Idle"
These are the terms used by @spanicker in their main-thread scheduling
proposal: https://github.com/spanicker/main-thread-scheduling#api-sketch
That proposal also uses "microtask" instead of "immediate" and "default"
instead of "normal." Not sure about "microtask" because I don't think
most people know what that is. And our implementation isn't a proper
microtask, though you could use it to implement microtasks if you made
sure to wrap every entry point. I don't really have a preference between
"default" and "normal."
These aren't necessarily the final names. Still prefixed by `unstable_`.
We're not planning to encourage legacy context, and without this change, it's difficult to use pure+forwardRef together. We could special-case `pure(forwardRef(...))` but this is hopefully simpler.
```js
React.pure(function(props, ref) {
// ...
});
```
Fixes#13777
As part of #11927 we introduced a regression by adding onclick handler
to the React root. This causes the whole React tree to flash when tapped
on iOS devices (for reasons I outlined in
https://github.com/facebook/react/issues/12989#issuecomment-414266839).
To fix this, we should only apply onclick listeners to portal roots. I
verified that my proposed fix indeed works by checking out our DOM
fixtures and adding regression tests.
Strangely, I had to make changes to the DOM fixtures to see the behavior
in the first place. This seems to be caused by our normal sites (and
thus their React root) being bigger than the viewport:
An alternative approach to finding out if we're appending to a React
root would be to add a third parameter to `appendChildToContainer` based
on the tag of the parent fiber.
* [scheduler] Eagerly schedule rAF at beginning of frame
Eagerly schedule the next animation callback at the beginning of the
frame. If the scheduler queue is not empty at the end of the frame, it
will continue flushing inside that callback. If the queue *is* empty,
then it will exit immediately. Posting the callback at the start of the
frame ensures it's fired within the earliest possible frame. If we
waited until the end of the frame to post the callback, we risk the
browser skipping a frame and not firing the callback until the frame
after that.
* Re-name scheduledCallback -> scheduledHostCallback
Previously, we were emptying root.pendingInteractionMap and permanently losing those interactions when applying an unrelated update to a tree that has no scheduled work that is waiting on promise resolution. (That is, one that is showing a fallback and waiting for the suspended content to resolve.)
The logic I'm leaving untouched with `nextRenderIncludesTimedOutPlaceholder` is *not* correct -- what we want is instead to know if *any* placeholder anywhere in the tree is showing its fallback -- but we don't currently have a better replacement, and this should unblock tracing with suspense again.
This package uses `process.env.NODE_ENV` but does not transform its usage during bundling like the rest of the React libraries do. This causes issues when `process` is not defined globally.
* Jest + test renderer helpers for concurrent mode
Most of our concurrent React tests use the noop renderer. But most
of those tests don't test the renderer API, and could instead be
written with the test renderer. We should switch to using the test
renderer whenever possible, because that's what we expect product devs
and library authors to do. If test renderer is sufficient for writing
most React core tests, it should be sufficient for others, too. (The
converse isn't true but we should aim to dogfood test renderer as much
as possible.)
This PR adds a new package, jest-react (thanks @cpojer). I've moved
our existing Jest matchers into that package and added some new ones.
I'm not expecting to figure out the final API in this PR. My goal is
to land something good enough that we can start dogfooding in www.
TODO: Continue migrating Suspense tests, decide on better API names
* Add additional invariants to prevent common errors
- Errors if user attempts to flush when log of yields is not empty
- Throws if argument passed to toClearYields is not ReactTestRenderer
* Better method names
- toFlushAll -> toFlushAndYield
- toFlushAndYieldThrough ->
- toClearYields -> toHaveYielded
Also added toFlushWithoutYielding
* Fix jest-react exports
* Tweak README
`--save` is on by default as of [npm 5](https://blog.npmjs.org/post/161081169345/v500), and `npm install aphrodite` is functionally equivalent to `npm install --save aphrodite` now
* Removed the enableGetDerivedStateFromCatch feature flag (aka permanently enabled the feature)
* Forked/copied ReactErrorBoundaries to ReactLegacyErrorBoundaries for testing componentDidCatch
* Updated error boundaries tests to apply to getDerivedStateFromCatch
* Renamed getDerivedStateFromCatch -> getDerivedStateFromError
* Warn if boundary with only componentDidCatch swallows error
* Fixed a subtle reconciliation bug with render phase error boundary
* pure
A higher-order component version of the `React.PureComponent` class.
During an update, the previous props are compared to the new props. If
they are the same, React will skip rendering the component and
its children.
Unlike userspace implementations, `pure` will not add an additional
fiber to the tree.
The first argument must be a functional component; it does not work
with classes.
`pure` uses shallow comparison by default, like `React.PureComponent`.
A custom comparison can be passed as the second argument.
Co-authored-by: Andrew Clark <acdlite@fb.com>
Co-authored-by: Sophie Alpert <sophiebits@fb.com>
* Warn if first argument is not a functional component
Added some tests for the non-DOM version of Scheduler that is used
as a fallback, e.g. Jest. The tests use Jest's fake timers API:
- `jest.runAllTimers(ms)` flushes all scheduled work, as expected
- `jest.advanceTimersByTime(ms)` flushes only callbacks that expire
within the given milliseconds.
These capabilities should be sufficient for most product tests. Because
jest's fake timers do not override performance.now or Date.now, we
assume time is constant. This means Scheduler's internal time will not
be aligned with other code that reads from `performance.now`. For finer
control, the user can override `window._sched` like we do in our tests.
We will likely publish a Jest package that has this built in.
All of these features are based on features of React's internal
scheduler. The eventual goal is to lift as much as possible out of the
React internals into the Scheduler package.
Includes some renaming of existing methods.
- `scheduleWork` is now `scheduleCallback`
- `cancelScheduledWork` is now `cancelCallback`
Priority levels
---------------
Adds the ability to schedule callbacks at different priority levels.
The current levels are (final names TBD):
- Immediate priority. Fires at the end of the outermost currently
executing (similar to a microtask).
- Interactive priority. Fires within a few hundred milliseconds. This
should only be used to provide quick feedback to the user as a result
of an interaction.
- Normal priority. This is the default. Fires within several seconds.
- "Maybe" priority. Only fires if there's nothing else to do. Used for
prerendering or warming a cache.
The priority is changed using `runWithPriority`:
```js
runWithPriority(InteractivePriority, () => {
scheduleCallback(callback);
});
```
Continuations
-------------
Adds the ability for a callback to yield without losing its place
in the queue, by returning a continuation. The continuation will have
the same expiration as the callback that yielded.
Wrapped callbacks
-----------------
Adds the ability to wrap a callback so that, when it is called, it
receives the priority of the current execution context.
* fix updateWrapper causing re-render textarea, even though their data has not changed
* fix updateWrapper causing re-render textarea, even though their data, prettier-all
* minor changes to updateWrapper, add test
* Do not bind topLevelType to dispatch
A previous change made it such that all top level event types
correspond to their associated native event string values. This commit
eliminates the .bind attached to dispatch and fixes a related flow
type.
* Add note about why casting event.type to a topLevelType is safe
* Move interactiveUpdates comment to point of assignment
* Refactor Schedule, remove React-isms
Once the API stabilizes, we will move Schedule this into a separate
repo. To promote adoption, especially by projects outside the React
ecosystem, we'll remove all React-isms from the source and keep it as
simple as possible:
- No build step.
- No static types.
- Everything is in a single file.
If we end up needing to support multiple targets, like CommonJS and ESM,
we can still avoid a build step by maintaining two copies of the same
file, but with different exports.
This commit also refactors the implementation to split out the DOM-
specific parts (essentially a requestIdleCallback polyfill). Aside from
the architectural benefits, this also makes it possible to write host-
agnostic tests. If/when we publish a version of Schedule that targets
other environments, like React Native, we can run these same tests
across all implementations.
* Edits in response to Dan's PR feedback
* Added UMD_PROFILING type to react-dom and scheduling package. Added UMD shim to schedule package.
* Added new schedule umd prod+prof bundle to API test
* Enhance dev warnings for forwardRef render function
- For 0 parameters: Do not warn because it may be due to usage of the
arguments object.
- For 1 parameter: Warn about missing the 'ref' parameter.
- For 2 parameters: This is the ideal. Do not warn.
- For more than 2 parameters: Warn about undefined parameters.
* Make test cases for forwardRef warnings more realistic
* Add period to warning sentence
* 🔥 Stop syncing the value attribute on inputs
* Eliminate some additional checks
* Remove initialValue and initialWrapper from wrapperState flow type
* Update tests with new sync logic, reduce some operations
* Update tests, add some caveats for SSR mismatches
* Revert newline change
* Remove unused type
* Call toString to safely type string values
* Add disableInputAttributeSyncing feature flag
Reverts tests to original state, adds attribute sync feature flag,
then moves all affected tests to ReactFire-test.js.
* Revert position of types in toStringValues
* Invert flag on number input blur
* Add clarification why double blur is necessary
* Update ReactFire number cases to be more explicite about blur
* Move comments to reduce diff size
* Add comments to clarify behavior in each branch
* There is no need to assign a different checked behavior in Fire
* Use checked reference
* Format
* Avoid precomputing stringable values
* Revert getToStringValue comment
* Revert placement of undefined in getToStringValue
* Do not eagerly stringify value
* Unify Fire test cases with normal ones
* Revert toString change. Only assign unsynced values when not nully
* Fix warning without stack for ie9
Where console methods like log, error etc. don't have 'apply' method.
Because of the lot of tests already expect that exactly console['method']
will be called - had to reapply references for console.error method
https://github.com/facebook/react/issues/13610
* pass parameters explicitly to avoid using .apply
which is not supported for console methods in ie9
* Minor tweaks
* add failing test
* honor displayName set on ForwardRef if available
Since React.forwardRef returns a component object, some users
(including styled-components and react-native) are starting to
decorate them with various statics including displayName.
This adjusts React's various name-getters to honor this if set and
surface the name in warnings and hopefully DevTools.
* fix typing
* Refine later
* Add home component. Async load fixtures.
This commit adds a homepage to the DOM fixtures that includes browser
testing information and asynchronously loads fixtures.
This should make it easier to find DOM testing information and keep
the payload size in check as we add more components to the fixtures.
* Adds experimental hydration fixture
This commit adds a first pass at a fixture that makes it easier to
debug the process of hydrating static markup. This is not complete:
1. It needs to be verified across multiple browsers
2. It needs to render with the current version of react
Still, it at least demonstrates the idea. A fixture like this will
also be helpful for debugging change events for hydrated inputs, which
presently do not fire if the user changes an input's text before
hydration.
* Tweak select width
* Manually join extra attributes in warning
This prevents a bug where Chrome reports `Array(n)` where `n` is the
size of the array.
* Transform with buble
* Eliminate dependencies
* Pull in react-live for better editing
* Handle encoding errors, pass react version
* Load the correct version of React
* Tweaks
* Revert style change
* Revert warning update
* Properly handle script errors. Fix dom-server CDN loading
* Fix 15.x releases
* Use postMessage to reduce latency, support older browsers
This commit makes a few tweaks to support older browsers and updates
the code transition process to use window.postMessage. This avoids
loading React on every single change.
* Fix fixture renamespacing bug
* Gracefully fallback to textarea in React 14
* Replace buble with babel, react-live with codemirror
* Simplify layout to resolve production code-mirror issues
* Tweak height rules for code-mirror
* Update theme to paraiso
* Format Code.js
* Adjust viewport to fix CodeMirror resize issue in production build
* Eliminate react-code-mirror
* Improve error state. Make full stack collapsable
* Add link to license in codemirror stylesheet
* Make code example more concise
* Replace "Hydrate" with "Auto-hydrate" for clarity
* Remove border below hydration header
* Rename query function in render.js
* Use Function(code) to evaluate hydration fixture
For clarity, and so that the Fixture component does not need to be
assigned to the window, this commit changes the way code is executed
such that it evaluates using a Function constructor.
* Extend hydration fixture to fill width. Design adjustments
This commit extends the hydration fixture such that it takes up the
full screen view. To accomplish this, the container that wraps all
fixtures has been moved to the FixtureSet component, utilized by all
other fixtures.
* Improve error scroll state
* Lazy load CodeMirror together before executing
This commit fixes an issue where CodeMirror wouldn't layout correctly
in production builds because the editor executes before the stylesheet
loaded. CodeMirror needs layout information, and was rendering
off-screen without correct CSS layout measurements.
* Fix indentation on error message
* Do not highlight errors from Babel. Add setPrototypeOf polyfill
This commit fixes an error in Safari 7.1 where Chalk highlighted Babel
errors caused a crash when setPrototypeOf was called within the
library.
This is also an issue on IE9, however this fix does not resolve issues
in that browser.
* Increase resilience to bad errors in Hydration fixture
- Reverts highlighting change. Polyfilling Safari 7.1 is sufficient
- Do not render a details tag in IE9
* Add regression test for persistent bailout bug
* Fork more logic into updateHostComponent
This is mostly copy paste. But I added a bailout only to mutation mode. Persistent mode doesn't have that props equality bailout anymore, so the Fabric test now passes.
* Add failing test for persistence host minimalism
* Add bailouts to the persistent host updates
* Added blessed production+profiling entry point for schedule/tracking
* Add invariant when profiling renderer is used with non-profiling schedule/tracking
* Remove injectComponentTree from unstable-native-dependencies, add
EventPluginHub
injectComponentTree was exposed for react-native-web, but wasn't
actually being used by the project. They were using EventPluginHub
through ReactDOM's secret internals, but that was removed in https://github.com/facebook/react/pull/13539
This removes the unused injectComponentTree export, refactors the
ResponderEventPlugin test so it doesn't depend on it, and also adds
EventPluginHub to the exports to unbreak react-native-web
* Re-export injectEventPluginsByName from ReactDOM internals
In https://github.com/facebook/react/pull/13394, I encountered an
issue where the ReactDOMServerIntegrationForm test suite consumed
sufficient memory to crash CircleCI. Breaking up this test suite by
form element type resolved the issue.
This commit performs that change separate from the Symbol/Function
stringification changes in #13394.
* Removed 'private' ref methods from UMD forwarding API
* Replaced getters with exported constants since they were no longer referenced for UMD forwarding
IE 11 parses & normalizes the style attribute as opposed to other
browsers. It adds spaces and sorts the properties in some
non-alphabetical order. Handling that would require sorting CSS
properties in the client & server versions or applying
`expectedStyle` to a temporary DOM node to read its `style` attribute
normalized. Since it only affects IE, we're skipping style warnings
in that browser completely in favor of doing all that work.
Fixes#11807
This is documenting the current order in which events are dispatched
when interacting with native document listeners and other React apps.
For more context, check out #12919.
* Merged interaction-tracking package into react-scheduler
* Add tracking API to FB+www builds
* Added Rollup plugin to strip no-side-effect imports from Rollup bundles
* Re-bundle tracking and scheduling APIs on SECRET_INTERNALS object for UMD build (and provide lazy forwarding methods)
* Added some additional tests and fixtures
* Fixed broken UMD fixture in master (#13512)
* Updated suspense fixture to use new interaction-tracking API
* Integrated Profiler API with interaction-tracking API (and added tests)
* Pass interaction Set (rather than Array) to Profiler onRender callback
* Removed some :any casts for enableInteractionTracking fields in FiberRoot type
* Refactored threadID calculation into a helper method
* Errors thrown by interaction tracking hooks use unhandledError to rethrow more safely.
Reverted try/finally change to ReactTestRendererScheduling
* Added a $FlowFixMe above the FiberRoot :any cast
* Reduce overhead from calling work-started hook
* Remove interaction-tracking wrap() references from unwind work in favor of managing suspense/interaction continuations in the scheduler
* Moved the logic for calling work-started hook from performWorkOnRoot() to renderRoot()
* Add interaction-tracking to bundle externals. Set feature flag to __PROFILE__
* Renamed the freezeInteractionCount flag and replaced one use-case with a method param
* let -> const
* Updated suspense fixture to handle recent API changes
* Add a failing test for deferredUpdates not being respected
* Don't consider deferred updates interactive
* Remove now-unnecessary setTimeout hack in the fixture
* Remove unstable_deferredUpdates
* Remove addEventListener check in isEventSupported
All browsers we support also support addEventListener, so this check is
unncessary
* Remove capture argument from isEventSupported
There's no good reason for this to be an object. This refactors it so
that we just use three variables instead. We can avoid the property reads/writes and also minify better, since property names don't get mangled but variables do.
* Do not toLowerCase lists of lowercase words
* Add notes about downcasing to DOMProperty.js
* Use consistent comment breakout
* Make toLowerCase more obvious
* Removed enableInteractionTrackingObserver as a separate flag; only enableInteractionTracking is used now
* Added interaction-tracking/subscriptions bundle and split tests
* Added multi-subscriber support
* Moved subscriptions behind feature flag
* Fixed bug with wrap() parameters and added test
* Replaced wrap arrow function
* Replace some namespace imports
* Simplify the controlled component injection
* Simplify the batching injection
* Simplify the component tree injection
* Add a regression test for 12643#issuecomment-413727104
* Don't diff memoized host components
* Add regression tests for noop renderer
* No early return
* Strengthen the test for host siblings
* Flow types
Lazily starts loading a component the first time it's rendered. The
implementation is fairly simple and could be left to userspace, but since
this is an important use case, there's value in standardization.
* Accept promise as element type
On the initial render, the element will suspend as if a promise were
thrown from inside the body of the unresolved component. Siblings should
continue rendering and if the parent is a Placeholder, the promise
should be captured by that Placeholder.
When the promise resolves, rendering resumes. If the resolved value
has a `default` property, it is assumed to be the default export of
an ES module, and we use that as the component type. If it does not have
a `default` property, we use the resolved value itself.
The resolved value is stored as an expando on the promise/thenable.
* Use special types of work for lazy components
Because reconciliation is a hot path, this adds ClassComponentLazy,
FunctionalComponentLazy, and ForwardRefLazy as special types of work.
The other types are not supported, but wouldn't be placed into a
separate module regardless.
* Resolve defaultProps for lazy types
* Remove some calls to isContextProvider
isContextProvider checks the fiber tag, but it's typically called after
we've already refined the type of work. We should get rid of it. I
removed some of them in the previous commit, and deleted a few more
in this one. I left a few behind because the remaining ones would
require additional refactoring that feels outside the scope of this PR.
* Remove getLazyComponentTypeIfResolved
* Return baseProps instead of null
The caller compares the result to baseProps to see if anything changed.
* Avoid redundant checks by inlining getFiberTagFromObjectType
* Move tag resolution to ReactFiber module
* Pass next props to update* functions
We should do this with all types of work in the future.
* Refine component type before pushing/popping context
Removes unnecessary checks.
* Replace all occurrences of _reactResult with helper
* Move shared thenable logic to `shared` package
* Check type of wrapper object before resolving to `default` export
* Return resolved tag instead of reassigning
* fix: do not reconcile children that are iterable functions
* fix: remove fit
* Refactor comparison to exclude anything that isnt an object
* Remove redundant undefined check
* Don't stop context traversal at matching consumers
Originally, the idea was to time slice the traversal. This worked when
there was only a single context type per consumer.
Now that each fiber may have a list of context dependencies, including
duplicate entries, that optimization no longer makes sense – we could
end up scanning the same subtree multiple times.
* Remove changedBits from context object and stack
Don't need it anymore, yay
Before this change in development window.event was overridden
in invokeGuardedCallback.
After this change window.event is preserved in the browsers that
support it.
* Warn when the string "false" is the value of a boolean DOM prop
* Only warn on exact case match for "false" in DOM boolean props
* Warn on string "true" as well as "false" in DOM boolean props
* Clarify warnings on "true" / "false" values in DOM boolean props
`flow-coverage-report` stopped working after Flow was set to run for each renderer separately (#12846). As discussed in #13393, this is hard to fix without adding complexity to `.flowconfig`'s generation.
* wip: ignore symbols and functions in select tag
* fix: Use ToStringValue as a maybe type
* refactor: remove unnecessary test
* refactor: remove implicit return from tests
* Add home component. Async load fixtures.
This commit adds a homepage to the DOM fixtures that includes browser
testing information and asynchronously loads fixtures.
This should make it easier to find DOM testing information and keep
the payload size in check as we add more components to the fixtures.
* Update browser support fields
* Tweak select width
* Fix typo
* Report actual error when fixture fails to load
* Update browser information
* Update browserstack subscription info
* English
* Switch let for const in fixture loader
* refactor: move getSafeValue to separate file
* fix(?): ReactDOMFiberTextarea sanitization for symbols and functions
* tests: add TODOs for warnings
* fix: restore accidentally removed test
* fix: remove redundant logic for initialValue
* refactor: integrate SafeValue typings into textarea
* fix: restore stringified newValue for equality check
* fix: remove getSafeValue from hostProps
* refactor: SafeValue -> ToStringValue
* refactor: update TODO comment in test file
* refactor: no need to convert children to ToStringValue
* Manually join extra attributes in warning
This prevents a bug where Chrome reports `Array(n)` where `n` is the
size of the array.
* Prettier
* Stringify all %s replaced symbols in warning
* Eliminate extra string coercion
* Pass args through with spread, convert all arguments to strings
* Rename strings to stringArgs
* Remove e.suppressReactErrorLogging check before last resort throw
It's unnecessary here. It was here because this method called console.error().
But we now rethrow with a clean stack, and that's worth doing regardless of whether the logging is silenced.
* Don't print error addendum if 'error' event got preventDefault()
* Add fixtures
* Use an expando property instead of a WeakSet
* Make it a bit less fragile
* Clarify comments
Following up on the changes I made in #13367, @gaearon suggest that
"safe" could be read as necessary for security. To avoid misleading a
reader, I'm changing the name.
A few names where discussed in the previous PR. I think `ToStringValue`
makes sense since the value itself is not a string yet but an opaque
type that can be cast to a string. For the actual string concatenation,
I've used `toString` now to avoid confusion: `toStringValueToString`
is super weird and it's namespaced anyhow.
Definitely open for suggestions here. :) I'll wait until we wrap up
#13362 and take care of rebase afterwards.
* Improve soundness of ReactDOMFiberInput typings
This is an attempt in improving the soundness for the safe value cast
that was added in #11741. We want this to avoid situations like [this
one](https://github.com/facebook/react/pull/13362#discussion_r209380079)
where we need to remember why we have certain type casts. Additionally
we can be sure that we only cast safe values to string.
The problem was `getSafeValue()`. It used the (deprecated) `*` type to
infer the type which resulted in a passing-through of the implicit `any`
of the props `Object`. So `getSafeValue()` was effectively returning
`any`.
Once I fixed this, I found out that Flow does not allow concatenating
all possible types to a string (e.g `"" + false` fails in Flow). To
fix this as well, I've opted into making the SafeValue type opaque and
added a function that can be used to get the string value. This is sound
because we know that SafeValue is already checked.
I've verified that the interim function is inlined by the compiler and
also looked at a diff of the compiled react-dom bundles to see if I've
regressed anything. Seems like we're good.
* Fix typo
* Bring back onSubmit bubble test
I found a test that was written more than 5 years ago and probably never
run until now. The behavior still works, although the API changed quite
a bit over the years.
Seems like this was part of the initial public release already:
75897c2dcd (diff-1bf5126edab96f3b7fea034cd3b0c742R31)
* Rely on bubbling for submit and reset events
* Update dom fixture lockfile
* Revet rollup results
Whoopsie.
* Simplified profiler actualDuration timing
While testing the new DevTools profiler, I noticed that sometimes– in larger, more complicated applications– the actualDuration value was incorrect (either too large, or sometimes negative). I was not able to reproduce this in a smaller application or test (which sucks) but I assume it has something to do with the way I was tracking render times across priorities/roots. So this PR replaces the previous approach with a simpler one.
* Changed bubbling logic after chatting out of band with Andrew
* Replaced __PROFILE__ with feature-flag conditionals in test
* Updated test comment
Remove 'async', 'bundle-collapser', 'del', 'derequire', 'escape-string-regexp', 'git-branch', 'gzip-js',
'merge-stream', 'platform', 'run-sequence' & 'yargs'.
Most of them were used in the old Grunt build system.
This ends up removing 32 packages, according to yarn.lock.
* Add support for auxclick event
* Add to simpleEventPLugin
* Add auxclick as interactive event type in SimpleEventPlugin
* Update ReactTestUtils fixture to include auxClick
* fix selectedIndex in postMountWrapper in ReactDOMFiberSelected
* comment in ReactDomFiberSelect in postMountWrapper for selectedIndex fix
* test for selectedIndex fix
* set boolean value for multiple
* Revert the fix which has been fixed on master
* Make sure that `select` has `multiple` attribute set to appropriate state before appending options
fixes#13222
* Add dom test fixture to test long multiple select scrolling to the first selected option
fixes#13222
* typo fix
* update comment
remove redundant conversion to bool type
* change a way of assigning property to domElement
* Remove unused ref on select fixture form
* Prefer node’s window and document over globals
* Support active elements in nested browsing contexts
* Avoid invoking defaultView getter unnecessarily
* Prefer node’s window and document over globals
* Support active elements in nested browsing contexts
* Avoid invoking defaultView getter unnecessarily
* Implement selection event fixtures
* Prefer node’s window and document over globals
* Avoid invoking defaultView getter unnecessarily
* Fix react-scripts to work with alphas after 16.0.0
The current logic just checks if the version is an alpha with a major version of 16 to account for weirdness with the 16 RC releases, but now we have alphas for newer minor releases that don't have weirdness
* Run prettier on new selection events fixtures
* Add fixture for onSelect in iframes, remove DraftJS fixture
The DraftJs fixture wasn't really working in all supported browsers anyways, so just drop it and try to cover our bases without using it directly
* Purge remnants of draft.js from fixtures
* Use prop-types import instead of window global
* Make fixtures’ Iframe component Firefox-compatible
* Fix switch case for SelectionEventsFixture
* Remove draft.js / immutable.js dependencies
* Cache owner doc as var to avoid reading it twice
* Add documentation for getActiveElementDeep to explain try/catch
Add documentation for getActiveElementDeep to explain try/catch
* Ensure getActiveElement always returns DOM element
* Tighten up isNode and isTextNode
* Remove ie8 compatibility
* Specify cross-origin example in getActiveElementDeep
* Revert back to returning null if document is not defined
* Add a regression test for #13188
* Replace console.error() with a throw in setTimeout() as last resort
* Fix lint and comment
* Fix tests to check we throw after all
* Fix build tests
* Inject react-art renderer into react-devtools
This commit makes react-art renderer to be injected to react-devtools,
so that component tree of the renderer is presented on debug panel of browser.
* Update ReactART.js
* [#13130] Add a more helpful message when passing an element to createElement()
* better conditional flow
* update after review
* move last condition inside last else clause
* Added test case
* compare 25132typeof to REACT_ELEMENT_TYPE
* runs prettier
* remove unrelated changes
* Tweak the message
* Make option children a text content by default
fix#11911
* Apply requested changes
- Remove meaningless comments
- revert scripts/rollup/results.json
* remove empty row
* Update comment
* Add a simple unit-test
* [WIP: no flow] Pass through hostContext
* [WIP: no flow] Give better description for test
* Fixes
* Don't pass hostContext through
It ended up being more complicated than I thought.
* Also warn on hydration
* Remove 'warning' module from the JS scheduler
**what is the change?:**
See title
**why make this change?:**
Internally the 'warning' module has some dependencies which we want to
avoid pulling in during the very early stages of initial pageload. It is
creating a cyclical dependency.
And we wanted to remove this dependency anyway, because this module
should be kept small and decoupled.
**test plan:**
- Tested the exact same change internally in Facebook.com
- Ran unit tests
- Tried out the fixture
**issue:**
Internal task T31831021
* check for console existence before calling console.error
* Move DEV check into separate block
This is likely the common case because individual component authors
will casually call read on common contexts like the cache, or cache
provider.
Where as libraries like Relay only call read once per fragment and pass
all observed bits at once.
* Store list of contexts on the fiber
Currently, context can only be read by a special type of component,
ContextConsumer. We want to add support to all fibers, including
classes and functional components.
Each fiber may read from one or more contexts. To enable quick, mono-
morphic access of this list, we'll store them on a fiber property.
* Context.unstable_read
unstable_read can be called anywhere within the render phase. That
includes the render method, getDerivedStateFromProps, constructors,
functional components, and context consumer render props.
If it's called outside the render phase, an error is thrown.
* Remove vestigial context cursor
Wasn't being used.
* Split fiber.expirationTime into two separate fields
Currently, the `expirationTime` field represents the pending work of
both the fiber itself — including new props, state, and context — and of
any updates in that fiber's subtree.
This commit adds a second field called `childExpirationTime`. Now
`expirationTime` only represents the pending work of the fiber itself.
The subtree's pending work is represented by `childExpirationTime`.
The biggest advantage is it requires fewer checks to bailout on already
finished work. For most types of work, if the `expirationTime` does not
match the render expiration time, we can bailout immediately without
any further checks. This won't work for fibers that have
`shouldComponentUpdate` semantics (class components), for which we still
need to check for props and state changes explicitly.
* Performance nits
Optimize `readContext` for most common case
* Add a test that StrictMode shows up in the component stack
The SSR test passes. The client one doesn't.
* Include Modes in component stack
* Update other tests to include modes
Adds custom Jest matchers that help with writing async tests:
- `toFlushThrough`
- `toFlushAll`
- `toFlushAndThrow`
- `toClearYields`
Each one accepts an array of expected yielded values, to prevent
false negatives.
Eventually I imagine we'll want to publish this on npm.
* Add a repro case for profiler unwinding
This currently fails the tests due to an unexpected warning.
* Add a regression test for context stack
* Simplify the first test case
* Update nextUnitOfWork inside completeUnitOfWork()
The bug was caused by a structure like this:
</Provider>
</div>
</errorInCompletePhase>
We forgot to update nextUnitOfWork so it was still pointing at Provider when errorInCompletePhase threw. As a result, we would try to unwind from Provider (rather than from errorInCompletePhase), and thus pop the Provider twice.
The `yield` method isn't tied to any specific root. Putting this
on the main export enables test components that are not within scope
to yield even if they don't have access to the currently rendering
root instance. This follows the pattern established by ReactNoop.
Added a `clearYields` method, too, for reading values that were yielded
out of band. This is also based on ReactNoop.
* Revert #5947 and disable the test
* Fix isDefaultPrevented and isPropagationStopped to not get nulled
This was a bug introduced by #5947. It's very confusing that they become nulled while stopPropagation/preventDefault don't.
* Add a comment
* Run Prettier
* Fix grammar
* Fix Portal unmount
Before that change, currentParent is not set as a container even if it should so it break on react-native and probably other custom renderers
* Assert that *ToContainer() methods receive containers
* Add regression tests
* Add comments
This is a leftover from #13161 that I forgot to include.
It ensures we don't accidentally write code in the old way and end up passing the stack twice.
* Use %s in the console calls
* Add shared/warningWithStack
* Convert some warning callsites to warningWithStack
* Use warningInStack in shared utilities and remove unnecessary checks
* Replace more warning() calls with warningWithStack()
* Fixes after rebase + use warningWithStack in react
* Make warning have stack by default; warningWithoutStack opts out
* Forbid builds that may not use internals
* Revert newly added stacks
I changed my mind and want to keep this PR without functional changes. So we won't "fix" any warnings that are already missing stacks. We'll do it in follow-ups instead.
* Fix silly find/replace mistake
* Reorder imports
* Add protection against warning argument count mismatches
* Address review
* Suspending inside a constructor outside of strict mode
Outside of strict mode, suspended components commit in an incomplete
state, then are synchronously deleted in a subsequent commit. If a
component suspends inside the constructor, it mounts without
an instance.
This breaks at least one invariant: during deletion, we assume that
every mounted component has an instance, and check the instance for
the existence of `componentWillUnmount`.
Rather than add a redundant check to the deletion of every class
component, components that suspend inside their constructor and outside
of strict mode are turned into empty functional components before they
are mounted. This is a bit weird, but it's an edge case, and the empty
component will be synchronously unmounted regardless.
* Do not fire lifecycles of a suspended component
In non-strict mode, suspended components commit, but their lifecycles
should not fire.
Instead of wrapping ReactDebugCurrentFrame.getStackAddendum() call into a custom wrapper inside ReactElementValidator, "teach" the main ReactDebugCurrentFrame.getStackAddendum() to take currently validating element into account.
* Fix getComponentName() for types with nested $$typeof
* Temporarily remove Profiler ID from messages
* Change getComponentName() signature to take just type
It doesn't actually need the whole Fiber.
* Remove getComponentName() forks in isomorphic and SSR
* Remove unnecessary .type access where we already have a type
* Remove unused type
* Remove event simulation of onChange events
It’s time to get rid of even more `ReactTestUtils.Simulate`s. In this PR
we remove the event simulation from all onChange tests. To do this, we
have to get a setter to the untracked value/checked props.
All remaining `ReactTestUtils.Simulate` calls are either testing
ReactTestUtils or assert that they do/don't throw.
* Use input instead of change event for all but checkbox, radio, and select
`React$ElementRef<T>` is the type of the ref _instance_ for a component of type T, whereas `React$Ref<T>` is the type of the ref _prop_ for a component of type T, which seems to be the intended type here.
* Refactor ReactDebugCurrentFiber to use named exports
This makes the difference between it and ReactFiberCurrentFrame a bit clearer.
ReactDebugCurrentFiber is Fiber's own implementation.
ReactFiberCurrentFrame is the thing that holds a reference to the current implementation and delegates to it.
* Unify ReactFiberComponentTreeHook and ReactDebugCurrentFiber
Conceptually they're very related.
ReactFiberComponentTreeHook contains implementation details of reading Fiber's stack (both in DEV and PROD).
ReactDebugCurrentFiber contained a reference to the current fiber, and used the above utility.
It was confusing when to use which one. Colocating them makes it clearer what you could do with each method.
In the future, the plan is to stop using these methods explicitly in most places, and instead delegate to a warning system that includes stacks automatically. This change makes future refactorings simpler by colocating related logic.
* Rename methods to better reflect their meanings
Clarify which are DEV or PROD-only.
Clarify which can return null.
I believe the "work in progress only" was a mistake. I introduced it because I wasn't sure what guarantees we have around .return. But we know for sure that following a .return chain gives us an accurate stack even if we get into WIP trees because we don't have reparenting. So it's fine to relax that naming.
* Rename ReactDebugCurrentFiber -> ReactCurrentFiber
It's not completely DEV-only anymore.
Individual methods already specify whether they work in DEV or PROD in their names.
An infinite update loop can occur when an update is scheduled inside a
lifecycle method, which causes a re-render, which schedules another
update, and so on. Before the Fiber rewrite, this scenario resulted in a
stack overflow.
Because Fiber does not use the JavaScript stack, we maintain our own
counter to track the number of nested, synchronous updates. We throw an
error if the limit is exceeded.
The nested update limit is currently 1000. I chose this number
arbitrarily, certain that there was no valid reason for a component to
schedule so many synchronous re-renders.
I think we can go much lower. This commit decreases the limit to 50. I
believe this is still comfortably above the reasonable number of
synchronous re-renders a component may perform.
This will make it easier for developers to debug infinite update bugs
when they occur.
A recent change to the scheduler caused a regression when scheduling
many updates within a single batch. Added a test case that would
have caught this.
This is an unobservable change to all but the (under development) DevTools Profiler plugin. It is being done so that the plugin can safely feature detect a version of React that supports it. The profiler API has existed since the 16.4.0 release, but it did not support the DevTools plugin prior to PR #13058.
Side note: I am not a big fan of the term "base duration". Both it and "actual duration" are kind of awkward and vague. If anyone has suggestions for better names– this is the best time to bikeshed about them.
* Reset ReactProfilerTimer's DEV-only Fiber stack after an error
* Added ReactNoop functionality to error during "complete" phase
* Added failing profiler stack unwinding test
* Potential fix for unwinding time bug
* Renamed test
* Don't record time until complete phase succeeds. Simplifies unwinding.
* Expanded ReactProfilerDevToolsIntegration-test coverage a bit
* Added unstable_flushWithoutCommitting method to noop renderer
* Added failing multi-root/batch test to ReactProfiler-test
* Beefed up tests a bit and added some TODOs
* Profiler timer differentiates between batched commits and in-progress async work
This was a two-part change:
1) Don't count time spent working on a batched commit against yielded async work.
2) Don't assert an empty stack after processing a batched commit (because there may be yielded async work)
This is kind of a hacky solution, and may have problems that I haven't thought of yet. I need to commit this so I can mentally clock out for a bit without worrying about it. I will think about it more when I'm back from PTO. In the meanwhile, input is welcome.
* Removed TODO
* Replaced FiberRoot map with boolean
* Removed unnecessary whitespace edit
Changed the API to match what we've been using in our latest discussions.
Our tentative plans are for <Placeholder> to automatically hide the timed-out
children, instead of removing them, so their state is not lost. This part is
not yet implemented. We'll likely have a lower level API that does not include
the hiding behavior. This is also not yet implemented.
We can support components that suspend outside of an async mode tree
by immediately committing their placeholders.
In strict mode, the Timeout acts effectively like an error boundary.
Within a single render pass, we unwind to the nearest Timeout and
re-render the placeholder view.
Outside of strict mode, it's not safe to unwind and re-render the
siblings without committing. (Technically, this is true of error
boundaries, too, though probably not a huge deal, since we don't support
using error boundaries for control flow (yet, at least)). We need to be
clever. What we do is pretend the suspended component rendered null.*
There's no unwinding. The siblings commit like normal.
Then, in the commit phase, schedule an update on the Timeout to
synchronously re-render the placeholder. Although this requires an extra
commit, it will not be observable. And because the siblings were not
blocked from committing, they don't have to be strict mode compatible.
Another caveat is that if a component suspends during an async render,
but it's captured by a non-async Timeout, we need to revert to sync
mode. In other words, if any non-async component renders, the entire
tree must complete and commit without yielding.
* The downside of rendering null is that the existing children will be
deleted. We should hide them instead. I'll work on this in a follow-up.
* Prepare placeholders before timing out
While a tree is suspended, prepare for the timeout by pre-rendering the
placeholder state.
This simplifies the implementation a bit because every render now
results in a completed tree.
* Suspend inside an already timed out Placeholder
A component should be able to suspend inside an already timed out
placeholder. The time at which the placeholder committed is used as
the start time for a subsequent suspend.
So, if a placeholder times out after 3 seconds, and an inner
placeholder has a threshold of 2 seconds, the inner placeholder will
not time out until 5 seconds total have elapsed.
* Fix crash during server render.
setTimeout and clearTimeout may not be available in some server-render environments (such as ChakraCore in React.NET), and loading ReactScheduler.js will cause a crash unless the existence of the variables are checked via a typeof comparison.
https://github.com/reactjs/React.NET/issues/555
The crash did not occur in 16.4.0, and the change appears to have been introduced here: https://github.com/facebook/react/pull/12931/files#diff-bbebc3357e1fb99ab13ad796e04b69a6L47
I tested this by using yarn link and running it with a local copy of React.NET. I am unsure the best way to unit test this change, since assigning null to `setTimeout` causes an immediate crash within the Node REPL.
* Fix flow errors and log warning if setTimeout / clearTimeout are
not defined / not a function.
* Use invariant to assert setTimeout / clearTimeout are functions
* Remove use of invariant
* Explain
* Add fixture test for schedule running when tab is backgrounded
**what is the change?:**
Just adding a test to the fixture, where we can easily see whether
scheduled callbacks are called after switching away from the fixture
tab.
**why make this change?:**
We are about to fix the schedule module so that it still runs even when
the tab is in the backround.
**test plan:**
Manually tested the fixture, verified that it works as expected and
right now callbacks are not called when the tab is in the background.
**issue:**
Internal task T30754186
* Fall back to 'setTimeout' when 'requestAnimationFrame' is not called
**what is the change?:**
If 'requestAnimationFrame' is not called for 100ms we fall back to
'setTimeout' to schedule the postmessage.
**why make this change?:**
When you start loading a page, and then switch tabs,
'requestAnimationFrame' is throttled or not called until you come back
to that tab. That means React's rendering, any any other scheduled work,
are paused.
Users expect the page to continue loading, and rendering is part of the
page load in a React app. So we need to continue calling callbacks.
**test plan:**
Manually tested using the new fixture test, observed that the callbacks
were called while switched to another tab. They were called more
slowly, but that seems like a reasonable thing.
**issue:**
Internal task T30754186
* make arguments more explicit
* Fixes children when using dangerouslySetInnerHtml in a selected <option>
This fixes an inadvertent cast of undefined children to an empty string when creating an option tag that will be selected:
```
<select defaultValue="test">
<option value='test' dangerouslySetInnerHTML={{ __html: '‏ test'}} />
</select>
```
This causes an invariant error because both children and dangerouslySetInnerHTML are set.
* PR fix and new ReactDOMServerIntegrationForms test
* Account for null case
* Combine test cases into single test
* Add tests for failure cases
* Fix lint
* react-test-renderer injects itself into DevTools if present
* Fibers are always opted into ProfileMode if DevTools is present
* Added simple test for DevTools + always profiling behavior
* Do not add additional work to a batch that is already rendering.
Otherwise, the part of the tree that hasn't rendered yet will receive
the latest state, but the already rendered part will show the state
as it was before the intervening update.
* Reduce non-helpfulness of comments
Expiration times are computed by adding to the current time (the start
time). However, if two updates are scheduled within the same event, we
should treat their start times as simultaneous, even if the actual clock
time has advanced between the first and second call.
In other words, because expiration times determine how updates are
batched, we want all updates of like priority that occur within the same
event to receive the same expiration time. Otherwise we get tearing.
We keep track of two separate times: the current "renderer" time and the
current "scheduler" time. The renderer time can be updated whenever; it
only exists to minimize the calls performance.now.
But the scheduler time can only be updated if there's no pending work,
or if we know for certain that we're not in the middle of an event.
* Inline fbjs/lib/emptyObject
* Explicit naming
* Compare to undefined
* Another approach for detecting whether we can mutate
Each renderer would have its own local LegacyRefsObject function.
While in general we don't want `instanceof`, here it lets us do a simple check: did *we* create the refs object?
Then we can mutate it.
If the check didn't pass, either we're attaching ref for the first time (so we know to use the constructor),
or (unlikely) we're attaching a ref to a component owned by another renderer. In this case, to avoid "losing"
refs, we assign them onto the new object. Even in that case it shouldn't "hop" between renderers anymore.
* Clearer naming
* Add test case for strings refs across renderers
* Use a shared empty object for refs by reading it from React
* Remove string refs from ReactART test
It's not currently possible to resetModules() between several renderers
without also resetting the `React` module. However, that leads to losing
the referential identity of the empty ref object, and thus subsequent
checks in the renderers for whether it is pooled fail (and cause assignments
to a frozen object).
This has always been the case, but we used to work around it by shimming
fbjs/lib/emptyObject in tests and preserving its referential identity.
This won't work anymore because we've inlined it. And preserving referential
identity of React itself wouldn't be great because it could be confusing during
testing (although we might want to revisit this in the future by moving its
stateful parts into a separate package).
For now, I'm removing string ref usage from this test because only this is
the only place in our tests where we hit this problem, and it's only
related to string refs, and not just ref mechanism in general.
* Simplify the condition
In async mode, events are interleaved with rendering. If one of those
events mutates state that is later accessed during render, it can lead
to inconsistencies/tearing.
Restarting the render from the root is often sufficient to fix the
inconsistency. We'll flush the restart synchronously to prevent yet
another mutation from happening during an interleaved event.
We'll only restart during an async render. Sync renders are already
sync, so there's no benefit in restarting. (Unless a mutation happens
during the render phase, but we don't support that.)
* onFatal, onComplete, onSuspend, onYield
For every call to renderRoot, one of onFatal, onComplete, onSuspend,
and onYield is called upon exiting. We use these in lieu of returning a
tuple. I've also chosen not to inline them into renderRoot because these
will eventually be lifted into the renderer.
* Suspended high pri work forces lower priority work to expire early
If an error is thrown, and there is lower priority pending work, we
retry at the lower priority. The lower priority work should expire
at the same time at which the high priority work would have expired.
Effectively, this increases the priority of the low priority work.
Simple example: If an error is thrown during a synchronous render, and
there's an async update, the async update should flush synchronously in
case it's able to fix the error. I've added a unit test for
this scenario.
User provided timeouts should have the same behavior, but I'll leave
that for a future PR.
* Add isUsingKoreanIME function to check if a composition event was triggered by Korean IME
* Add Korean IME check alongside useFallbackCompositionData and disable fallback mode with Korean IME
We need a different "component tree" thingy for Fabric.
A lot of this doesn't really make much sense in a persistent world but
currently we can't dispatch events to memoizedProps on a Fiber since
they're pooled. Also, it's unclear what the semantics should be when we
dispatch an event that happened when the old props were in effect but now
we have new props already.
This implementation tries to use the last committed props but also fails
at that because we don't have a commit hook in the persistent mode.
However, at least it doesn't crash when dispatching. :)
* Remove rAF fork
**what is the change?:**
Undid https://github.com/facebook/react/pull/12837
**why make this change?:**
We originally forked rAF because we needed to pull in a particular
version of rAF internally at Facebook, to avoid grabbing the default
polyfilled version.
The longer term solution, until we can get rid of the global polyfill
behavior, is to initialize 'schedule' before the polyfilling happens.
Now that we have landed and synced
https://github.com/facebook/react/pull/12900 successfully, we can
initialize 'schedule' before the polyfill runs.
So we can remove the rAF fork. Here is how it will work:
1. Land this PR on Github.
2. Flarnie will quickly run a sync getting this change into www.
3. We delete the internal forked version of
'requestAnimationFrameForReact'.
4. We require 'schedule' in the polyfill file itself, before the
polyfilling happens.
**test plan:**
Flarnie will manually try the above steps locally and verify that things
work.
**issue:**
Internal task T29442940
* fix nits
* fix tests, fix changes from rebasing
* fix lint
* Remove enableSuspense flag from PendingPriority module
We're going to use this for suspending on error, too.
* Retry on error if there's lower priority pending work
If an error is thrown, and there's lower priority work, it's possible
the lower priority work will fix the error. Retry at the lower priority.
If an error is thrown and there's no more work to try, handle the error
like we normally do (trigger the nearest error boundary).
* Use native event dispatching instead of Simulate or SimulateNative
In #12629 @gaearon suggested that it would be better to drop usage of
`ReactTestUtils.Simulate` and `ReactTestUtils.SimulateNative`. In this
PR I’m attempting at removing it from a lot of places with only a few
leftovers.
Those leftovers can be categorized into three groups:
1. Anything that tests that `SimulateNative` throws. This is a property
that native event dispatching doesn’t have so I can’t convert that
easily. Affected test suites: `EventPluginHub-test`,
`ReactBrowserEventEmitter-test`.
2. Anything that tests `ReactTestUtils` directly. Affected test suites:
`ReactBrowserEventEmitter-test` (this file has one test that reads
"should have mouse enter simulated by test utils"),
`ReactTestUtils-test`.
3. Anything that dispatches a `change` event. The reason here goes a bit
deeper and is rooted in the way we shim onChange. Usually when using
native event dispatching, you would set the node’s `.value` and then
dispatch the event. However inside [`inputValueTracking.js`][] we
install a setter on the node’s `.value` that will ignore the next
`change` event (I found [this][near-perfect-oninput-shim] article
from Sophie that explains that this is to avoid onChange when
updating the value via JavaScript).
All remaining usages of `Simulate` or `SimulateNative` can be avoided
by mounting the containers inside the `document` and dispatching native
events.
Here some remarks:
1. I’m using `Element#click()` instead of `dispatchEvent`. In the jsdom
changelog I read that `click()` now properly sets the correct values
(you can also verify it does the same thing by looking at the
[source][jsdom-source]).
2. I had to update jsdom in order to get `TouchEvent` constructors
working (and while doing so also updated jest). There was one
unexpected surprise: `ReactScheduler-test` was relying on not having
`window.performance` available. I’ve recreated the previous
environment by deleting this property from the global object.
3. I was a bit confused that `ReactTestUtils.renderIntoDocument()` does
not render into the document 🤷
[`inputValueTracking.js`]: 392530104c/packages/react-dom/src/client/inputValueTracking.js (L79)
[near-perfect-oninput-shim]: https://sophiebits.com/2013/06/18/a-near-perfect-oninput-shim-for-ie-8-and-9.html
[jsdom-source]: 45b77f5d21/lib/jsdom/living/nodes/HTMLElement-impl.js (L43-L76)
* Make sure contains are unlinked from the document even if the test fails
* Remove unnecessary findDOMNode calls
**what is the change?:**
Basically undoes 4b2e65d32e (diff-904ceabd8a1e9a07ab1d876d843d62e1)
**why make this change?:**
We rolled out this fix internally and in open source weeks ago, and now
we're cleaning up.
**test plan:**
Ran tests and lint, and really we have been testing this because the
flag is open internally as of last week or so.
**issue:**
Internal task T29948812 has some info.
* Don’t error when returning an empty Fragment
When a fragment is reconciled, we directly move onto it’s children.
Since an empty `<React.Fragment/>` will have children of `undefined`,
this would always throw.
To fix this, we bail out in those cases.
* Test the update path as well
* Reuse existing code path
* An even more explicit solution that also fixes Flow
It looks like we accidentally removed a fallback condition for the
event target in IE9 when we dropped some support for IE8. This commit
adds the event target specific support code back to getEventTarget.js
Fixes#12506
* Fixed an issue with nested contexts unwinding when server rendering. GitHub issue #12984
* Fixed an issue with search direction and stricter false checking
* Use decrement infix operator
* Streamlined existence checks
* Streamlined assignment. Removed redundant comment. Use null for array values
* Made prettier
* Relaxed type checking and improved comment
* Improve test coverage
This commit removes a reference to inst._wrapperState, which was the
old way of tracking input state in the stack renderer.
This means we no longer need to pass the instance into the associated
function, allowing us to eliminate an exception for IE (and a TODO).
* Fix react-dom ReferenceError requestAnimationFrame in non-browser env (#13000)
The https://github.com/facebook/react/pull/12931 ( 79a740c6e3 ) broke the server-side rendering: in the `fixtures/ssr` the following error appeared from the server-side when `localhost:3000` is requested:
```
ReferenceError: requestAnimationFrame is not defined
at /__CENSORED__/react/build/node_modules/react-dom/cjs/react-dom.development.js:5232:34
at Object.<anonymous> (/__CENSORED__/react/build/node_modules/react-dom/cjs/react-dom.development.js:17632:5)
at Module._compile (module.js:624:30)
at Module._extensions..js (module.js:635:10)
at Object.require.extensions.(anonymous function) [as .js] (/__CENSORED__/react/fixtures/ssr/node_modules/babel-register/lib/node.js:152:7)
at Module.load (module.js:545:32)
at tryModuleLoad (module.js:508:12)
at Function.Module._load (module.js:500:3)
at Module.require (module.js:568:17)
at require (internal/module.js:11:18)
```
The exception pointed to this line:
```js
// We capture a local reference to any global, in case it gets polyfilled after
// this module is initially evaluated.
// We want to be using a consistent implementation.
const localRequestAnimationFrame = requestAnimationFrame;
```
**Test plan**
1. In `react` repo root, `yarn && yarn build`.
2. In `fixtures/ssr`, `yarn && yarn start`,
3. In browser, go to `http://localhost:3000`.
4. Observe the fixture page, not the exception message.
* Move the requestAnimationFrameForReact check and warning to callsites (#13000)
According to the comment by @gaearon: https://github.com/facebook/react/pull/13001#issuecomment-395803076
* Use `invariant` instead of `throw new Error`, use the same message (#13000)
According to the comment by @gaearon: https://github.com/facebook/react/pull/13001#discussion_r194133355
* Set the correct initial value on input range
* Add description and update value diff check for input range
* add isHydrating argument and tests
* update node value according to isHydrating
* Initial failing unit test for error handling in schedule
**what is the change?:**
see title
**why make this change?:**
Adding tests for the error handling behavior we are about to add. This
test is failing, which gives us the chance to make it pass.
Wrote skeletons of some other tests to add.
Unit testing this way is really hacky, and I'm also adding to the
fixture to test this in the real browser environment.
**test plan:**
Ran new test, saw it fail!
* Add fixture for testing error handling in scheduler
**what is the change?:**
Added a fixture which does the following -
logs in the console to show what happens when you use
`requestAnimationFrame` to schedule a series of callbacks and some of
them throw errors.
Then does the same actions with the `scheduler` and verifies that it
behaves in a similar way.
Hard to really verify the errors get thrown at the proper time without
looking at the console.
**why make this change?:**
We want the most authentic, accurate test of how errors are handled in
the scheduler. That's what this fixture should be.
**test plan:**
Manually verified that this test does what I expect - right now it's
failing but follow up commits will fix that.
* Handle errors in scheduler
**what is the change?:**
We set a flag before calling any callback, and then use a 'try/finally'
block to wrap it. Note that we *do not* catch the error, if one is
thrown. But, we only unset the flag after the callback successfully
finishes.
If we reach the 'finally' block and the flag was not unset, then it
means an error was thrown.
In that case we start a new postMessage callback, to finish calling any
other pending callbacks if there is time.
**why make this change?:**
We need to make sure that an error thrown from one callback doesn't stop
other callbacks from firing, but we also don't want to catch or swallow
the error because we want engineers to still be able to log and debug
errors.
**test plan:**
New tests added are passing, and we verified that they fail without this
change.
* Add more tests for error handling in scheduler
**what is the change?:**
Added tests for more situations where error handling may come up.
**why make this change?:**
To get additional protection against this being broken in the future.
**test plan:**
Ran new tests and verified that they fail when error handling fails.
* callSafely -> callUnsafely
* Fix bugs with error handling in schedule
**what is the change?:**
- ensure that we properly remove the callback from the linked list, even
if it throws an error and is timed out.
- ensure that you can call 'cancelScheduledWork' more than once and it
is idempotent.
**why make this change?:**
To fix bugs :)
**test plan:**
Existing tests pass, and we'll add more tests in a follow up commit.
* Unit tests for error handling with timed out callbacks
**what is the change?:**
More unit tests, to cover behavior which we missed; error handling of
timed out callbacks.
**why make this change?:**
To protect the future!~
**test plan:**
Run the new tests.
* Adds fixture to test timed out callbacks with scheduler
**what is the change?:**
See title
In the other error handling fixture we compare 'scheduleWork' error
handling to 'requestAnimationFrame' and try to get as close as possible.
There is no 'timing out' feature with 'requestAnimationFrame' but
effectively the 'timing out' feature changes the order in which things
are called. So we just changed the order in the 'requestAnimationFrame'
version and that works well for illustrating the behavior we expect in
the 'scheduleWork' test.
**why make this change?:**
We need more test coverage of timed out callbacks.
**test plan:**
Executed the fixture manually in Firefox and Chrome. Results looked
good.
* fix rebase problems
* make fixture compensate for chrome JS speed
* ran prettier
* Remove 'cancelled' flag on callbackConfig in scheduler, add test
**what is the change?:**
- Instead of using a 'cancelled' flag on the callbackConfig, it's easier
to just check the state of the callbackConfig inside
'cancelScheduledWork' to determine if it's already been cancelled. That
way we don't have to remember to set the 'cancelled' flag every time we
call a callback or cancel it. One less thing to remember.
- We added a test for calling 'cancelScheduledWork' more than once,
which would have failed before.
Thanks @acdlite for suggesting this in code review. :)
**why make this change?:**
To increase stability of the schedule module, increase test coverage.
**test plan:**
Existing tests pass and we added a new test to cover this behavior.
* fix typo
* Fix for Flow issues in SimpleCacheProvider
**what is the change?:**
- Fixed some flow errors which were somehow swallowed when CI
originally
- Loosen flow types to avoid issue with recursive loop in Flow; https://github.com/facebook/flow/issues/5870
**why make this change?:**
To unbreak master and unblock other changes we want to make.
**test plan:**
Flow passes!
**issue:**
https://github.com/facebook/react/issues/12941
* Fix lints
* [simple-cache-provider] Use LRU cache eviction
Max size is hard-coded to 500. In the future, we should make this
configurable per resource.
* Evict PAGE_SIZE records from cache when max limit is reached
* Do not set selection when prior selection is undefined (#12062)
`restoreSelection` did not account for input elements that have changed
type after the commit phase. The new `text` input supported selection
but the old `email` did not and `setSelection` was incorrectly trying to
restore `null` selection state.
We also extend input type check in selection capabilities to cover cases
where input type is `search`, `tel`, `url`, or `password`.
* Add link to HTML spec for element types and selection
* Add reset button to ReplaceEmailInput
This commit adds a button to restore the original state of the
ReplaceEmailInput fixture so that it can be run multiple times without
refreshing the page.
**what is the change?:**
In a recent PR we were referencing some global variables and storing
local references to them.
To make things more natural, we co-opted the original name of the global
for our local reference. To make this work with Flow, we get the
original reference from 'window.requestAnimationFrame' and assign it to
'const requestAnimationFrame'.
Sometimes React is used in an environment where 'window' is not defined
- in that case we need to use something else, or hide the 'window'
reference somewhere.
We opted to use 'global' thinking that Babel transforms would fill that
in with the proper thing.
But for some of our fixtures we are not doing that transform on the
bundle.
**why make this change?:**
I want to unbreak this on master and then investigate more about what we
should do to fix this.
**test plan:**
run `yarn build` and open the fixtures.
**issue:**
https://github.com/facebook/react/issues/12930
* Use local references to global things inside 'scheduler'
**what is the change?:**
See title
**why make this change?:**
We want to avoid initially calling one version of an API and then later
accessing a polyfilled version.
**test plan:**
Run existing tests.
* Shim ReactScheduler for www
**what is the change?:**
In 'www' we want to reference the separate build of ReactScheduler,
which allows treating it as a separate module internally.
**why make this change?:**
We need to require the ReactScheduler before our rAF polyfill activates,
in order to customize which custom behaviors we want.
This is also a step towards being able to experiment with using it
outside of React.
**test plan:**
Ran tests, ran the build, and ran `test-build`.
* Generate a bundle for fb-www
**what is the change?:**
See title
**why make this change?:**
Splitting out the 'schedule' module allows us to load it before
polyfills kick in for rAF and other APIs.
And long term we want to split this into a separate module anyway, this
is a step towards that.
**test plan:**
I'll run the sync next week and verify that this all works. :)
* ran prettier
* fix rebase issues
* Change names of variables used for holding globals
This commit fixes an issue where assigning an empty string to required
text inputs triggers the invalid state in Firefox (~60.0.1).
It does this by first comparing the initial state value to the current
value property on the text element. This:
1. Prevents the validation issue
2. Avoids an extra DOM Mutation in some cases
CI builds should always use the `--frozen-lockfile` option. It will fail the build if the lockfile is out-of-date:
> If you need reproducible dependencies, which is usually the case with the continuous integration systems, you should pass --frozen-lockfile flag.
(https://yarnpkg.com/en/docs/cli/install/)
* [schedule] Use linked list instead of queue and map for storing cbs
NOTE: This PR depends on https://github.com/facebook/react/pull/12880
and https://github.com/facebook/react/pull/12884
Please review those first, and after they land Flarnie will rebase on
top of them.
---
**what is the change?:**
See title
**why make this change?:**
This seems to make the code simpler, and potentially saves space of
having an array and object around holding references to the callbacks.
**test plan:**
Run existing tests
* minor style improvements
* refactor conditionals in cancelScheduledWork for increased clarity
* Remove 'canUseDOM' condition and fix some flow issues w/callbackID type
**what is the change?:**
- Removed conditional which fell back to 'setTimeout' when the
environment doesn't have DOM. This appears to be an old polyfill used
for test environments and we don't use it any more.
- Fixed type definitions around the callbackID to be more accurate in
the scheduler itself, and more loose in the React code.
**why make this change?:**
To get Flow passing, simplify the scheduler code, make things accurate.
**test plan:**
Run tests and flow.
* Rewrite 'cancelScheduledWork' so that Flow accepts it
**what is the change?:**
Adding verification that 'previousCallbackConfig' and
'nextCallbackConfig' are not null before accessing properties on them.
Slightly concerned because this implementation relies on these
properties being untouched and correct on the config which is passed to
'cancelScheduledWork' but I guess we already rely heavily on that for
this whole approach. :\
**why make this change?:**
To get Flow passing.
Not sure why it passed earlier and in CI, but now it's not.
**test plan:**
`yarn flow dom` and other flow tests, lint, tests, etc.
* ran prettier
* Put back the fallback implementation of scheduler for node environment
**what is the change?:**
We had tried removing the fallback implementation of `scheduler` but
tests reminded us that this is important for supporting isomorphic uses
of React.
Long term we will move this out of the `schedule` module but for now
let's keep things simple.
**why make this change?:**
Keep things working!
**test plan:**
Ran tests and flow
* Shorten properties stored in objects by sheduler
**what is the change?:**
`previousScheduledCallback` -> `prev`
`nextScheduledCallback` -> `next`
**why make this change?:**
We want this package to be smaller, and less letters means less code
means smaller!
**test plan:**
ran existing tests
* further remove extra lines in scheduler
* Moved actual time fields from Profiler stateNode to Fiber
* Record actual time for all Fibers within a ProfileMode tree
* Changed how profiler accumulates time
This change gives up on accumulating time across renders of different priority, but in exchange- simplifies how the commit phase (reset) code works, and perhaps also makes the profiling code more compatible with future resuming behavior
* Adding 'schedule' fixture
**what is the change?:**
We need to test the `schedule` module against real live browser APIs. As
a quick solution we're writing a fixture for using in manual testing.
Later we plan on adding automated browser testing, using this or a
similar fixture as the test page.
**why make this change?:**
To further solidify test coverage for `schedule` before making further
improvements/refactors to the module.
**test plan:**
`open fixtures/schedule/index.html` and inspect the results. It should
be clear that things pass.
We also temporarily broke the scheduler and verified that this fixture
demonstrates the problems.
**issue:**
Internal task T29442940
* Made fixture tests display red or green border depending on pass/fail
**what is the change?:**
Added red/green solid/dashed border for test results when using the
schedule fixture.
We also tweaked the timing of the last test because it was on the line
in terms of whether it passed or failed.
**why make this change?:**
To make it faster to use the fixture - it takes more time to read
through the results line by line and check that they match what is
expected.
**test plan:**
Looked at the fixture, and also tried modifying a test to show what it
looks like when something fails.
**what is the change?:**
Renamed some methods, and made a method to advance a frame in the test
environment.
**why make this change?:**
We often need to simulate a frame passing with some amount of idle time
or lack of idle time, and the new method makes it easier to write that
out.
**test plan:**
Run the updated tests.
Also temporarily tried breaking the scheduler and verified that the
tests will fail.
**issue:**
See internal task T29442940
* add legacy context APIs warning in strict mode
* refactor if statement and the warning message
* add other flags for type check
* add component stack tree and refactor wording
* fix the nits
* Rewrite to a switch
I find it a bit easier to follow than many comparison conditions.
* Remove unnecessary assignments
They are being assigned below anyway. This is likely a copypasta from the FOCUS/BLUR special case (which *does* need those assignments).
* Unify "cancel" and "close" cases
Their logic is identical.
* Don't listen to media events at the top
* Add a unit test for double-invoking form events
* Remove an unused case and document it in a test
The case I added was wrong (just like including this event in the top level list was always wrong).
In fact it never bubbles, even for <img>. And since we don't special case it in the <img> event
attachment logic when we create it, we never supported <img onLoadStart> at all.
We could fix it. But Chrome doesn't support it either: https://bugs.chromium.org/p/chromium/issues/detail?id=458851.
Nobody asked us for it yet. And supporting it would require attaching an extra listener to every <img>.
So maybe we don't need it? Let's document the existing state of things.
* Add a test verifying we don't attach unnecessary listeners
* Add a comment
* Add a test for submit (bubbles: false)
**what is the change?:**
Test coverage checking that callbacks are called when they time out.
This test surfaced a bug and this commit includes the fix.
I want to refine this approach, but basically we can simulate time outs
by controlling the return value of 'now()' and the argument passed to
the rAF callback.
Next we will write a browser fixture to further test this against real
browser APIs.
**why make this change?:**
Better tests will keep this module working smoothly while we continue
refactoring and improving it.
**test plan:**
Run the new tests, see that it fails without the bug fix.
We were adding a listener at the root when we weren't meant to. Blames to e96dc14059.
This now alerts once (at FORM) instead of twice (at FORM, #document):
```
var Hello = class extends React.Component {
render() {
return (
<form onSubmit={(e) => {e.preventDefault(); alert('hi ' + e.nativeEvent.currentTarget.nodeName);}}>
<button>hi</button>
</form>
);
}
};
```
* Added start time parameter to Profiler onRender callback
* Profiler also captures commit time
* Only init Profiler stateNode if enableProfilerTimer feature flag enabled
* Extract base Jest config
This makes it easier to change the source config without affecting the build test config.
* Statically import the host config
This changes react-reconciler to import HostConfig instead of getting it through a function argument.
Rather than start with packages like ReactDOM that want to inline it, I started with React Noop and ensured that *custom* renderers using react-reconciler package still work. To do this, I'm making HostConfig module in the reconciler look at a global variable by default (which, in case of the react-reconciler npm package, ends up being the host config argument in the top-level scope).
This is still very broken.
* Add scaffolding for importing an inlined renderer
* Fix the build
* ES exports for renderer methods
* ES modules for host configs
* Remove closures from the reconciler
* Check each renderer's config with Flow
* Fix uncovered Flow issue
We know nextHydratableInstance doesn't get mutated inside this function, but Flow doesn't so it thinks it may be null.
Help Flow.
* Prettier
* Get rid of enable*Reconciler flags
They are not as useful anymore because for almost all cases (except third party renderers) we *know* whether it supports mutation or persistence.
This refactoring means react-reconciler and react-reconciler/persistent third-party packages now ship the same thing.
Not ideal, but this seems worth how simpler the code becomes. We can later look into addressing it by having a single toggle instead.
* Prettier again
* Fix Flow config creation issue
* Fix imprecise Flow typing
* Revert accidental changes
**what is the change?:**
Fix a typo which caused timed out callbacks to not be called.
**why make this change?:**
This is a bug caught by tests I'm in the process of writing, and we
should fix it asap.
**test plan:**
Tests in a WIP PR - will push and share the WIP test in comments on this
PR.
* Generate Flow config on install
We'll need to do pre-renderer Flow passes with different configs.
This is the first step to get it working. We only want the original version checked in.
* Create multiple Flow configs from a template
* Run Flow per renderer
* Lint
* Revert the environment consolidation
I thought this would be a bit cleaner at first because we now have non-environment files in this directory.
But Sebastian is changing these files at the same time so I want to avoid conflicts and keep the PR more tightly scoped. Undo.
* Misc
* Lint for untyped imports and enable Flow typing in ReactFiber
* Re-enable Flow for ReactFiber and fix Flow issues
* Avoid an invariant in DEV-only code
I just introduced it, but on a second thought, it's better to keep it as a warning.
* Address review
* Temporary fix for grabbing wrong rAF polyfill in ReactScheduler
**what is the change?:**
For now...
We need to grab a slightly different implementation of rAF internally at
FB than in Open Source. Making rAF a dependency of the ReactScheduler
module allows us to fork the dependency at FB.
NOTE: After this lands we have an alternative plan to make this module
separate from React and require it before our Facebook timer polyfills
are applied. But want to land this now to keep master in a working state
and fix bugs folks are seeing at Facebook.
Thanks @sebmarkbage @acdlite and @sophiebits for discussing the options
and trade-offs for solving this issue.
**why make this change?:**
This fixes a problem we're running into when experimenting with
ReactScheduler internally at Facebook, **and* it's part of our long term
plan to use dependency injection with the scheduler to make it easier to
test and adjust.
**test plan:**
Ran tests, lint, flow, and will manually test when syncing into
Facebook's codebase.
**issue:**
See internal task T29442940
* ran prettier
**what is the change?:**
We were setting a flag after some early returns, should have set it
right away.
To be fair, it's not clear how you can hit a problem with the current
state of things. Even if a callback is cancelled, it's still in the
'pendingCallbacks' queue until the rAF runs, and we only schedule a rAF
when there are pendingCallbacks in the queue.
But since this is obviously wrong, going to fix it.
We will be adding a regression test in a follow-up PR.
**why make this change?:**
To fix a random bug which was popping up.
**test plan:**
Adding a regression unit test in a follow-up PR.
**what is the change?:**
In some cases we had defined the 'callback' as taking two arguments,
when really we meant to indicate the second argument passed to
'scheduleWork'.
**why make this change?:**
For correctness and to unblock something @gaearon is working on. A bit
surprised Flow didn't catch this in the first place.
**test plan:**
Ran tests, flow, lint.
* Rename Scheduler methods more accurately
**what is the change?:**
```
rIC -> scheduleCallback
```
We will later expose a second method for different priority level, name
TBD. Since we only have one priority right now we can delay the
bikeshedding about the priority names.
cIC -> cancelScheduledCallback
This method can be used to cancel callbacks scheduled at any priority
level, and will remain named this way.
why make this change?:
Originally this module contained a polyfill for requestIdleCallback
and cancelIdleCallback but we are changing the behavior so it's no
longer just a polyfill. The new names are more semantic and distinguish
this from the original polyfill functionality.
**test plan:**
Ran the tests
**why make this change?:**
Getting this out of the way so things are more clear.
**Coming Up Next:**
- Switching from a Map of ids and an array to a linked list for storing
callbacks.
- Error handling
* callback -> work
* update callsites in new places after rebase
* fix typo
* Add TopLevelEventTypes
* Fix `ReactBrowserEventEmitter`
* Fix EventPluginUtils
* Fix TapEventPlugin
* Fix ResponderEventPlugin
* Update ReactDOMFiberComponent
* Fix BeforeInputEventPlugin
* Fix ChangeEventPlugin
* Fix EnterLeaveEventPlugin
* Add missing non top event type used in ChangeEventPlugin
* Fix SelectEventPlugin
* Fix SimpleEventPlugin
* Fix outstanding Flow issues and move TopLevelEventTypes
* Inline a list of all events in `ReactTestUtils`
* Fix tests
* Make it pretty
* Fix completly unrelated typo
* Don’t use map constructor because of IE11
* Update typings, revert changes to native code
* Make topLevelTypes in ResponderEventPlugin injectable and create DOM and ReactNative variant
* Set proper dependencies for DOMResponderEventPlugin
* Prettify
* Make some react dom tests no longer depend on internal API
* Use factories to create top level speific generic event modules
* Remove unused dependency
* Revert exposed module renaming, hide store creation, and inline dependency decleration
* Add Flow types to createResponderEventPlugin and its consumers
* Remove unused dependency
* Use opaque flow type for TopLevelType
* Add missing semis
* Use raw event names as top level identifer
* Upgrade baylon
This is required for parsing opaque flow types in our CI tests.
* Clean up flow types
* Revert Map changes of ReactBrowserEventEmitter
* Upgrade babel-* packages
Apparently local unit tests also have issues with parsing JavaScript
modules that contain opaque types (not sure why I didn't notice
earlier!?).
* Revert Map changes of SimpleEventPlugin
* Clean up ReactTestUtils
* Add missing semi
* Fix Flow issue
* Make TopLevelType clearer
* Favor for loops
* Explain the new DOMTopLevelEventTypes concept
* Use static injection for Responder plugin types
* Remove null check and rely on flow checks
* Add missing ResponderEventPlugin dependencies
* Use global state for `hasForceUpdate` instead of persisting to queue
Fixes a bug where `hasForceUpdate` was not reset on commit.
Ideally we'd use a tuple and return `hasForceUpdate` from
`processUpdateQueue`.
* Remove underscore and add comment
* Remove temporary variables
Fixes an oversight from #12600. getDerivedStateFromProps should fire
if either props *or* state have changed, but not if *neither* have
changed. This prevents a parent from re-rendering if a deep child
receives an update.
Previously, _owner would be null if you create an element inside forwardRef or inside a context consumer. This is used by ReactNativeFiberInspector when traversing the hierarchy and also to give more info in some warning texts. This also means you'll now correctly get a warning if you call setState inside one of these.
Test Plan: Tim tried it in the RN inspector.
* makes closure compiler threaded
* Dans PR with a closure compiler java version
* Remove unused dep
* Pin GCC
* Prettier
* Nit rename
* Fix error handling
* Name plugins consistently
* Fix lint
* Maybe this works?
* or this
* AppVeyor
* Fix lint
* Support concurrent primary and secondary renderers.
As a workaround to support multiple concurrent renderers, we categorize
some renderers as primary and others as secondary. We only expect
there to be two concurrent renderers at most: React Native (primary) and
Fabric (secondary); React DOM (primary) and React ART (secondary).
Secondary renderers store their context values on separate fields.
* Add back concurrent renderer warning
Only warn for two concurrent primary or two concurrent secondary renderers.
* Change "_secondary" suffix to "2"
#EveryBitCounts
* Timeout component
Adds Timeout component. If a promise is thrown from inside a Timeout component,
React will suspend the in-progress render from committing. When the promise
resolves, React will retry. If the render is suspended for longer than the
maximum threshold, the Timeout switches to a placeholder state.
The timeout threshold is defined as the minimum of:
- The expiration time of the current render
- The `ms` prop given to each Timeout component in the ancestor path of the
thrown promise.
* Add a test for nested fallbacks
Co-authored-by: Andrew Clark <acdlite@fb.com>
* Resume on promise rejection
React should resume rendering regardless of whether it resolves
or rejects.
* Wrap Suspense code in feature flag
* Children of a Timeout must be strict mode compatible
Async is not required for Suspense, but strict mode is.
* Simplify list of pending work
Some of this was added with "soft expiration" in mind, but now with our revised
model for how soft expiration will work, this isn't necessary.
It would be nice to remove more of this, but I think the list itself is inherent
because we need a way to track the start times, for <Timeout ms={ms} />.
* Only use the Timeout update queue to store promises, not for state
It already worked this way in practice.
* Wrap more Suspense-only paths in the feature flag
* Attach promise listener immediately on suspend
Instead of waiting for commit phase.
* Infer approximate start time using expiration time
* Remove list of pending priority levels
We can replicate almost all the functionality by tracking just five
separate levels: the highest/lowest priority pending levels, the
highest/lowest priority suspended levels, and the lowest pinged level.
We lose a bit of granularity, in that if there are multiple levels of
pending updates, only the first and last ones are known. But in practice
this likely isn't a big deal.
These heuristics are almost entirely isolated to a single module and
can be adjusted later, without API changes, if necessary.
Non-IO-bound work is not affected at all.
* ReactFiberPendingWork -> ReactFiberPendingPriority
* Renaming method names from "pending work" to "pending priority"
* Get rid of SuspenseThenable module
Idk why I thought this was neccessary
* Nits based on Sebastian's feedback
* More naming nits + comments
* Add test for hiding a suspended tree to unblock
* Revert change to expiration time rounding
This means you have to account for the start time approximation
heuristic when writing Suspense tests, but that's going to be
true regardless.
When updating the tests, I also made a fix related to offscreen
priority. We should never timeout inside a hidden tree.
* palceholder -> placeholder
Add a new component type, Profiler, that can be used to collect new render time metrics. Since this is a new, experimental API, it will be exported as React.unstable_Profiler initially.
Most of the functionality for this component has been added behind a feature flag, enableProfileModeMetrics. When the feature flag is disabled, the component will just render its children with no additional behavior. When the flag is enabled, React will also collect timing information and pass it to the onRender function (as described below).
* Support using id to cancel scheduled callback
**what is the change?:**
see title
**why make this change?:**
Once we support multiple callbacks you will need to use the id to
specify which callback you mean.
**test plan:**
Added a test, ran all tests, lint, etc.
* ran prettier
* fix lint
* Use object for storing callback info in scheduler
* Wrap initial test in a describe block
* Support multiple callbacks in `ReactScheduler`
**what is the change?:**
We keep a queue of callbacks instead of just one at a time, and call
them in order first by their timeoutTime and then by the order which
they were scheduled in.
**why make this change?:**
We plan on using this module to coordinate JS outside of React, so we
will need to schedule more than one callback at a time.
**test plan:**
Added a boatload of shiny new tests. :)
Plus ran all the old ones.
NOTE: The tests do not yet cover the vital logic of callbacks timing
out, and later commits will add the missing test coverage.
* Heuristic to avoid looking for timed out callbacks when none timed out
**what is the change?:**
Tracks the current soonest timeOut time for all scheduled callbacks.
**why make this change?:**
We were checking every scheduled callback to see if it timed out on
every tick. It's more efficient to skip that O(n) check if we know that
none have timed out.
**test plan:**
Ran existing tests.
Will write new tests to cover timeout behavior in more detail soon.
* Put multiple callback support under a disabled feature flag
**what is the change?:**
See title
**why make this change?:**
We don't have error handling in place yet, so should maintain the old
behavior until that is in place.
But want to get this far to continue making incremental changes.
**test plan:**
Updated and ran tests.
* Hide support for multiple callbacks under a feature flag
**what is the change?:**
see title
**why make this change?:**
We haven't added error handling yet, so should not expose this feature.
**test plan:**
Ran all tests, temporarily split out the tests for multiple callbacks
into separate file. Will recombine once we remove the flag.
* Fix nits from code review
See comments on https://github.com/facebook/react/pull/12743
* update checklist in comments
* Remove nested loop which calls additional timed out callbacks
**what is the change?:**
We used to re-run any callbacks which time out whilst other callbacks
are running, but now we will only check once for timed out callbacks
then then run them.
**why make this change?:**
To simplify the code and the behavior of this module.
**test plan:**
Ran all existing tests.
* Remove feature flag
**what is the change?:**
see title
**why make this change?:**
Because only React is using this, and it sounds like async. rendering
won't hit any different behavior due to these changes.
**test plan:**
Existing tests pass, and this allowed us to recombine all tests to run
in both 'test' and 'test-build' modes.
* remove outdated file
* fix typo
* Mark new component types with PerformedWork effect
* Don't do it for ForwardRef
Since this has some overhead and ForwardRef is likely going to be used around context, let's skip it.
We don't highlight ForwardRef alone in DevTools anyway.
```
$ jest
FAIL scripts/jest/dont-run-jest-directly.js
● Test suite failed to run
Don't run `jest` directly. Run `yarn test` instead.
> 1 | throw new Error("Don't run `jest` directly. Run `yarn test` instead.");
2 |
at Object.<anonymous> (scripts/jest/dont-run-jest-directly.js:1:96)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 0.866s
Ran all test suites.
```
* Add a failing test for forwardRef memoization
* Memoize forwardRef props and bail out on strict equality
* Bail out only when ref matches the current ref
**what is the change?:**
We had a condition to set either 'performance.now' or 'Date.now' as the
'now' function.
Then later we had another conditional checking again if
'performance.now' was supported, and using it if so, otherwise falling
back to 'Date.now'.
More efficient to just use the 'now' shortcut defined above.
**why make this change?:**
Fewer lines, clearer code.
**test plan:**
Now that we have tests we can run them :)
* Remove the 'alwaysUseRequestIdleCallbackPolyfill' feature flag
**what is the change?:**
Removes the feature flag 'alwaysUseRequestIdleCallbackPolyfill', such
that we **always** use the polyfill for requestIdleCallback.
**why make this change?:**
We have been testing this feature flag at 100% for some time internally,
and determined it works better for React than the native implementation.
Looks like RN was overriding the flag to use the native when possible,
but since no RN products are using 'async' mode it should be safe to
switch this flag over for RN as well.
**test plan:**
We have already been testing this internally for some time.
**issue:**
internal task t28128480
* fix mistaken conditional
* Add mocking of rAF, postMessage, and initial test for ReactScheduler
**what is the change?:**
- In all tests where we previously mocked rIC or relied on native
mocking which no longer works, we are now mocking rAF and postMessage.
- Also adds a basic initial test for ReactScheduler.
NOTE -> we do plan to write headless browser tests for ReactScheduler!
This is just an initial test, to verify that it works with the mocked
out browser APIs as expected.
**why make this change?:**
We need to mock out the browser APIs more completely for the new
'ReactScheduler' to work in our tests. Many tests are depending on it,
since it's used at a low level.
By mocking the browser APIs rather than the 'react-scheduler' module, we
enable testing the production bundles. This approach is trading
isolation for accuracy. These tests will be closer to a real use.
**test plan:**
run the tests :)
**issue:**
internal task T28128480
* Decouple update queue from Fiber type
The update queue is in need of a refactor. Recent bugfixes (#12528) have
exposed some flaws in how it's modeled. Upcoming features like Suspense
and [redacted] also rely on the update queue in ways that weren't
anticipated in the original design.
Major changes:
- Instead of boolean flags for `isReplace` and `isForceUpdate`, updates
have a `tag` field (like Fiber). This lowers the cost for adding new
types of updates.
- Render phase updates are special cased. Updates scheduled during
the render phase are dropped if the work-in-progress does not commit.
This is used for `getDerivedStateFrom{Props,Catch}`.
- `callbackList` has been replaced with a generic effect list. Aside
from callbacks, this is also used for `componentDidCatch`.
* Remove first class UpdateQueue types and use closures instead
I tried to avoid this at first, since we avoid it everywhere else in the Fiber
codebase, but since updates are not in a hot path, the trade off with file size
seems worth it.
* Store captured errors on a separate part of the update queue
This way they can be reused independently of updates like
getDerivedStateFromProps. This will be important for resuming.
* Revert back to storing hasForceUpdate on the update queue
Instead of using the effect tag. Ideally, this would be part of the
return type of processUpdateQueue.
* Rename UpdateQueue effect type back to Callback
I don't love this name either, but it's less confusing than UpdateQueue
I suppose. Conceptually, this is usually a callback: setState callbacks,
componentDidCatch. The only case that feels a bit weird is Timeouts,
which use this effect to attach a promise listener. I guess that kinda
fits, too.
* Call getDerivedStateFromProps every render, even if props did not change
Rather than enqueue a new setState updater for every props change, we
can skip the update queue entirely and merge the result into state at
the end. This makes more sense, since "receiving props" is not an event
that should be observed. It's still a bit weird, since eventually we do
persist the derived state (in other words, it accumulates).
* Store captured effects on separate list from "own" effects (callbacks)
For resuming, we need the ability to discard the "own" effects while
reusing the captured effects.
* Optimize for class components
Change `process` and `callback` to match the expected payload types
for class components. I had intended for the update queue to be reusable
for both class components and a future React API, but we'll likely have
to fork anyway.
* Only double-invoke render phase lifecycles functions in DEV
* Use global state to track currently processing queue in DEV
* checkPropTypes in updateContextProvider
* invalid “prop”
* `type not `types` .. :l
* test
* don’t need extra check with no spelling mistake (:
* change error message to specifically address provider
* don’t need class, add extra render to make sure good props go through
* nitpicky rename
* prettier
* switch to `Context.Provider`
* add stack to warning, add extra undefined check
* separate dev check
* add stack to test
* more efficient
* remove unused function
* prettier
* const to top
This is the first step - pulling the ReactDOMFrameScheduling module out
into a separate package.
Co-authored-by: Brandon Dail <aweary@users.noreply.github.com>
* Installed 3.x release of react-lifecycles-compat
* Updated ReactComponentLifeCycle-test and ReactDOMServerLifecycles-test to cover both polyfilled lifecycles in StrictMode
* Updated StrictMode warnings to not warn about polyfilled getSnapshotBeforeUpdate
* Added new "native-fb" and "native-fabric-fb" bundles.
* Split RN_DEV and RN_PROD bundle types into RN_OSS_DEV, RN_OSS_PROD, RN_FB_DEV, and RN_FB_PROD. (This is a bit redundant but it seemed the least intrusive way of supporting a forked feature flags file for these bundles.)
* Renamed FB_DEV and FB_PROD bundle types to be more explicitly for www (FB_WWW_DEV and FB_WWW_PROD)
* Removed Haste @providesModule headers from the RB-specific RN renderer bundles to avoid a duplicate name conflicts.
* Remove dynamic values from OSS RN feature flags. (Leave them in FB RN feature flags.)
* Updated the sync script(s) to account for new renderer type.
* Move ReactFeatureFlags.js shim to FB bundle only (since OSS bundle no longer needs dynamic values).
* Added new debug performance tests for AsyncMode, StrictMode, forwardRef, and context provider/consumer components.
* Updated performance labels to exclude AsyncMode and StrictMode.
* Added labels for forwardRef (and inner function) that mirror DevTools labels.
* Don't download bundle stats from master on CI
This was temporarily necessary in the past because we didn't have the logic that downloads actual *merge base* stats.
We do have that now as part of the Danger script. So we can remove this.
* Use absolute threshold for whether to show a change
* Download master stats, but only for other master builds
* Rewrite sizes
* Bump expiration for interactive updates to 150ms in production
**what is the change?:**
Changes the expiration deadline from 500ms to 150ms, only in production.
In development it will still be 500ms.
I'm thinking we may want to change the 'bucket size' too, will look into
that a bit.
**why make this change?:**
We need to ensure interactions are responsive enough in order to gather
more test data on async. mode.
**test plan:**
No tests failed - where shall we add a test for this?
* Add comments
* Move findNodeHandle into the renderers and use instantiation
This is just like ReactDOM does it. This also lets us get rid of injection
for findNodeHandle. Instead I move NativeMethodsMixin and ReactNativeComponent
to use instantiation.
* Refactor findHostInstance
The reconciler shouldn't expose the Fiber data structure. We should pass
the component instance to the reconciler, since the reconciler is the
thing that is supposed to be instancemap aware.
* Fix devtools injection
* Move view config registry to shims
This ensures that both Fabric and RN renderers share the same view config
registry since it is stateful.
I had to duplicate in the mocks for testing.
* Move createReactNativeComponentClass to shims and delete internal usage
Since createReactNativeComponentClass is just an alias for the register
there's no need to bundle it. This file should probably just move back
to RN too.
We already have one stateful module that contains all the view config.
We might as well store the event types there too. That way the shared
state is compartmentalized (and I can move it out in a follow up PR).
The view config registry also already has an appropriate place to call
processEventTypes so now we no longer have to do it in RN.
Will follow up with a PR to RN to remove that call.
These don't make much sense in Fabric, since Fabric will be async by default only.
And unmount+remove container is a sketchy API we should remove so we might
as well make sure modern containers enforce that.
This doesn't actually need to share any state because it goes through
the instance to the fiber structure. Since Fabric is on the same version
as RN, calling it on either renderer works.
There are no plans to enable async in the old renderer. In the new renderer
it only really makes sense to do from the main thread and probably from
native since it'll have to yield to native first.
This is not safe in general and therefore shouldn't be exposed to anything
other than React Native internals.
It will also need a different version in Fabric that will not have the
reactTag exposed.
* Don't render consumers that bailed out with bitmask even if there's a deeper matching child
* Use a render prop in the test
Without it, <Indirection> doesn't do anything because we bail out on constant element anyway.
That's not what we're testing, and could be confusing.
Based on a bug found in UFI2.
There have been several bugs related to the update queue (and
specifically baseState) recently, so I'm going to follow-up with some
refactoring to clean it up. This is a quick fix so we can ship a
patch release.
* Add regression tests for error boundary replay bugs
* Ensure the context stack is aligned if renderer throws
* Always throw when replaying a failed unit of work
Replaying a failed unit of work should always throw, because the render
phase is meant to be idempotent, If it doesn't throw, rethrow the
original error, so React's internal stack is not misaligned.
* Reset originalReplayError after replaying
* Typo fix
* Update user timing to record when we are about to commit
**what is the change?:**
After repeatedly logging '(React Tree Reconciliation)' we vary the
message slightly for the last reconciliation, which happens right before
we commit.
**why make this change?:**
When debugging performance in the devtools it will be helpful if we can
quickly see where the 'commit' happens in a potentially long list of
sliced '(React Tree Reconciliation)' logs.
**test plan:**
Built and ran one of the fixtures. Also ran the unit test.
(Flarnie will insert a screenshot)
* Ran prettier
* Fixes in response to code review
* Update snapshot tests
* Move isWorking assignment out of branches to top
* Stricter type for stopWorkLoopTimer args
* Fix DEV performance regression by avoiding Object.assign on Fibers
* Reduce allocations in hot path by reusing the stash
Since performUnitOfWork() is not reentrant, it should be safe to reuse the same stash every time instead of creating a new object.
* Add React.isValidElementType()
Per the conversation on #12453, there are a number of third-party
libraries (particularly those that generate higher-order components)
that are performing suboptimal validation of element types.
This commit exposes a function that can perform the desired check
without depending upon React internals.
* Move isValidElementType to shared/
* Update user timing to record the timeout deadline with 'waiting' events
**what is the change?:**
When we are processing work during reconciliation, we have a "timeout"
deadline to finish the work. It's a safety measure that forces things to
finish up synchronously if they are taking too long.
The "timeout" is different depending on the type of interaction which
triggered the reconciliation. We currently have a shorter "timeout" for
"interactive updates", meaning we will try to finish work faster if the
reconciliation was triggered by a click or other user interaction.
For collecting more data in our logs we want to differentiate the
'waiting for async callback...' events based on the "timeout" so I'm
adding that to the logging.
One interesting note - in one of the snapshot tests the "timeout" was
super high. Going to look into that.
**why make this change?:**
Right now we are debugging cases where an interaction triggers a
reconciliation and the "waiting for async callback...' events are too
long, getting blocked because the main thread is too busy. We are
keeping logs of these user timing events and want to filter to focus on
the reconciliation triggered by interaction.
**test plan:**
Manually tested and also updated snapshot tests.
(Flarnie will insert a screenshot)
* Improve wording of message
* ran prettier
* Test case for React Context bailing out unexpectedly
* This is 💯% definitely not the correct fix at all
* Revert "This is 💯% definitely not the correct fix at all"
This reverts commit 8686c0f6bdc1cba3056fb2212f3f7740c749d33a.
* Formatting + minor tweaks to the test
* Don't bail out on consumer child equality
* Tweak the comment
* Pretty lint
* Silly Dan
* Add a failing test for setState in cDM during batch.commit()
* Copy pasta
* Flush all follow-up Sync work on the committed batch
* Nit: Use performSyncWork
Call performSyncWork right after flushing the batch. Does effectively
the same thing by reusing the existing function.
Also added some comments.
* Delete accidentally duplicated test
These are based on the ReactNoop renderer, which we use to test React
itself. This gives library authors (Relay, Apollo, Redux, et al.) a way
to test their components for async compatibility.
- Pass `unstable_isAsync` to `TestRenderer.create` to create an async
renderer instance. This causes updates to be lazily flushed.
- `renderer.unstable_yield` tells React to yield execution after the
currently rendering component.
- `renderer.unstable_flushAll` flushes all pending async work, and
returns an array of yielded values.
- `renderer.unstable_flushThrough` receives an array of expected values,
begins rendering, and stops once those values have been yielded. It
returns the array of values that are actually yielded. The user should
assert that they are equal.
Although we've used this pattern successfully in our own tests, I'm not
sure if these are the final APIs we'll make public.
* Call getSnapshotBeforeUpdate in separate traversal, before mutation (aka revert db84b9a) and add unit test.
* Added a new timer to ReactDebugFiberPerf for Snapshot effects
* Implemented new getSnapshotBeforeUpdate lifecycle
* Store snapshot value from Fiber to instance (__reactInternalSnapshotBeforeUpdate)
* Use commitAllHostEffects() traversal for getSnapshotBeforeUpdate()
* Added DEV warnings and tests for new lifecycle
* Don't invoke legacy lifecycles if getSnapshotBeforeUpdate() is defined. DEV warn about this.
* Converted did-warn objects to Sets in ReactFiberClassComponent
* Replaced redundant new lifecycle checks in a few methods
* Check for polyfill suppress flag on cWU as well before warning
* Added Snapshot bit to HostEffectMask
Is this necessary? I'd like to use the package in enzyme to avoid having to recopy/paste the symbols for better debugging names, but at hard dep in enzyme proper on a version of react isn't gonna work. This seems safe since nothing explicitly depends on React in here?
* Add a failing test verifying componentInfo is missing
* Pass componentInfo to componentDidCatch and getDerivedStateFromCatch
* Only expect stack in DEV
* Don't pass the stack to getDerivedStateFromCatch()
FiberNode stateNode could be null
So I get TypeError:
```
at performWorkOnRoot (/tmp/my-project/node_modules/react-dom/cjs/react-dom.development.js:11014:24) TypeError: Cannot read property '_warnedAboutRefsInRender' of null
at findDOMNode (/tmp/my-project/node_modules/react-dom/cjs/react-dom.development.js:15264:55)
```
* Add a regression test for the context infinite loop
* Fix the bug
We set .return pointer inside the loop, but the top-level parent-child relationship happens outside.
This ensures the top-level parent's child points to the right copy of the parent.
Otherwise we may end up in a situation where (workInProgress === nextFiber) is never true and we loop forever.
* Support ForwardRef type of work in TestRenderer and ShallowRenderer.
* Release script now updates inter-package dependencies too (e.g. react-test-renderer depends on react-is).
We'll use this in www to test whether the polyfill is better at
scheduling high-pri async work than the native one. My preliminary tests
suggest "yes" but it's hard to say for certain, given how difficult it
is to consistently reproduce the starvation issues we've been seeing.
* Use module pattern so context stack is isolated per renderer
* Unify context implementations
Implements the new context API on top of the existing ReactStack that we
already use for host context and legacy context. Now there is a single
array that we push and pop from.
This makes the interrupt path slightly slower, since when we reset the
unit of work pointer, we have to iterate over the stack (like before)
*and* switch on the type of work (not like before). On the other hand,
this unifies all of the unwinding behavior in the UnwindWork module.
* Add DEV only warning if stack is not reset properly
We have other tests that would have caught this if resuming were enabled
in all cases, but since it's currently only enabled for error
boundaries, the test I've added to prevent a regression is a
bit contrived.
* Context providers and consumers should bail-out on already finished work
Fixes bug where a consumer would re-render even if its props and context
had not changed.
* Encode output as JSON string
* Add weights to random action generator
* Add context to triangle fuzz tester
* Move bailouts to as early as possible
* Bailout if neither context value nor children haven't changed (sCU)
* Change prop type invariant to a DEV-only warning
Using `new Map(iterable)` isn't supported in IE11, so it ends up trying to iterate through an empty map and these attributes don't get defined in properties. Since this is only run once on startup inlining the attributeName array is probably fine.
Changes `createResource` to return an object with `read` and `preload`
methods. Future methods may include `set`, `subscribe`, `invalidate`,
and so on.
* Don't expose ReactGlobalSharedState on React Native renderer
We should just go through the "react" package if need access to this one.
Removed the dependencies in React Native.
* No longer used by InspectorUtils
`oldProps` was null. This went uncaught by the unit tests because
ReactNoop did not use `oldProps` in either `prepareUpdate` or
`completeUpdate`. I added some invariants so we don't regress in
the future.
* Revert "Replace danger token with a refreshed facebook-open-source-bot token (#12295)"
This reverts commit 2d511479c4.
* Revert "Temporarily disable Danger in CI (#12291)"
This reverts commit 925fc93389.
* Add stack unwinding phase for handling errors
A rewrite of error handling, with semantics that more closely match
stack unwinding.
Errors that are thrown during the render phase unwind to the nearest
error boundary, like before. But rather than synchronously unmount the
children before retrying, we restart the failed subtree within the same
render phase. The failed children are still unmounted (as if all their
keys changed) but without an extra commit.
Commit phase errors are different. They work by scheduling an error on
the update queue of the error boundary. When we enter the render phase,
the error is popped off the queue. The rest of the algorithm is
the same.
This approach is designed to work for throwing non-errors, too, though
that feature is not implemented yet.
* Add experimental getDerivedStateFromCatch lifecycle
Fires during the render phase, so you can recover from an error within the same
pass. This aligns error boundaries more closely with try-catch semantics.
Let's keep this behind a feature flag until a future release. For now, the
recommendation is to keep using componentDidCatch. Eventually, the advice will
be to use getDerivedStateFromCatch for handling errors and componentDidCatch
only for logging.
* Reconcile twice to remount failed children, instead of using a boolean
* Handle effect immediately after its thrown
This way we don't have to store the thrown values on the effect list.
* ReactFiberIncompleteWork -> ReactFiberUnwindWork
* Remove startTime
* Remove TypeOfException
We don't need it yet. We'll reconsider once we add another exception type.
* Move replay to outer catch block
This moves it out of the hot path.
* Add test exercising public API to test BeforeInputEventPlugin + FallbackCompositionState
- I've adopted a similar approach to the existing test for BeforeInputEventPlugin
- I've simulated events and then assert the event handler for onBeforeInput is fired or not fired based on the test conditions
- The scenarios are tested against IE11, Webkite and Presto environment simulations
- I've encorporated what I understand to be the functionality in the FallbackCompositionState test
* Prettier
* Linting fixes
* Remove test for contenteditable in Presto - the contenteditable type is not supported in Presto powered browsers (Opera).
* Remove mention of Presto as this explicit condition is no longer handled in BeforeInputEventPlugin.
We still need to exercise usage of FallbackCompositionState though so let's keep a test where the env does not support Composition and Text events.
* Add tests for envs with only CompositionEvent support
* Remove internal tests no longer needed
* Shorten test case names to satisfy lint rules
* Add tests for onCompositionStart and onCompositionUpdte events
The BeforeInputEventPlugin is responsible for emitting these events so we need to add tests for this. This also ensure we exercise the code path that, L207, that was not previously exercised with the public tests.
If we have multiple RN renderers running simultaneously, we should be able to send a single event to all of them and only if it recognizes the event will it do anything with it. Crucially, this avoids the 'Unsupported top level event type "%s" dispatched' invariant in those cases.
* [experimental] simple-cache-provider
Pushing an early version of this for testing and demonstration purposes.
* Change invariant to DEV-only warning
* Use function overloading for createResource type
Expresses that primitive keys do not require a hash function, but
non-primitive keys do.
* More tests
* Use export *
* Make Record type a disjoint union
* Pass miss argument separate from key to avoid a closure
* Additional release script options for publishing canary versions
- `branch` specifies a branch other than master
- `local` skips pulling from the remote branch and checking CircleCI
- `tag` specifies an npm dist tag other than `latest` or `next`
We may add a higher-level `canary` option in the future.
* Address Brian's feedback:
- Updated description of `local` option
- Throws if the `latest` tag is specified for a prerelease version
* Disable DEV-only warnings for RN NativeMethodsMixin/create-react-class
* Tiny bit of cleanup
* Make strict-mode suppression check a little more robust
* [Danger] Use the PR's mergebase for a branch in the dangerfile instead of
the root commit's parent.
* [Danger] Get the full history to find the merge base
When a ref is removed from a class component, React now calls the previous ref-setter (if there was one) with null. Previously this was the case only for host component refs.
A new test has been added.
* add failed tests for <unstable_AsyncMode> with server rendering
* Fix server render with <unstable_AsyncMode> component
* Merge StrictMode and AsyncMode tests into Modes file
* Invoke both legacy and UNSAFE_ lifecycles when both are present
This is to support edge cases with eg create-react-class where a mixin defines a legacy lifecycle but the component being created defines an UNSAFE one (or vice versa).
I did not warn about this case because the warning would be a bit redundant with the deprecation warning which we will soon be enabling. I could be convinced to change my stance here though.
* Added explicit function-type check to SS ReactPartialRenderer
Accounts for the case where an event is dispatched synchronously from
inside another event, like `el.focus`. I've added a test, but in general
we need more coverage around this area.
* Switch to JSX API for context
80% sure this will be the final API. Merging this now so we can get this
into the next www sync in preparation for 16.3.
* Promote context to a stable API
* Updates inside controlled events (onChange) are sync even in async mode
This guarantees the DOM is in a consistent state before we yield back
to the browser.
We'll need to figure out a separate strategy for other
interactive events.
* Don't rely on flushing behavior of public batchedUpdates implementation
Flush work as an explicit step at the end of the event, right before
restoring controlled state.
* Interactive updates
At the beginning of an interactive browser event (events that fire as
the result of a user interaction, like a click), check for pending
updates that were scheduled in a previous interactive event. Flush the
pending updates synchronously so that the event handlers are up-to-date
before responding to the current event.
We now have three classes of events:
- Controlled events. Updates are always flushed synchronously.
- Interactive events. Updates are async, unless another a subsequent
event is fired before it can complete, as described above. They are
also slightly higher priority than a normal async update.
- Non-interactive events. These are treated as normal, low-priority
async updates.
* Flush lowest pending interactive update time
Accounts for case when multiple interactive updates are scheduled at
different priorities. This can happen when an interactive event is
dispatched inside an async subtree, and there's an event handler on
an ancestor that is outside the subtree.
* Update comment about restoring controlled components
* ReactDOM.flushControlled
New API for wrapping event handlers that need to fire before React
yields to the browser. Previously we thought that flushSync was
sufficient for this use case, but it turns out that flushSync is only
safe if you're guaranteed to be at the top of the stack; that is, if
you know for sure that your event handler is not nested inside another
React event handler or lifecycle. This isn't true for cases like
el.focus, el.click, or dispatchEvent, where an event handler can be
invoked synchronously from inside an existing stack.
flushControlled has similar semantics to batchedUpdates, where if you
nest multiple batches, the work is not flushed until the end of the
outermost batch. The work is not guaranteed to synchronously flush, as
with flushSync, but it is guaranteed to flush before React yields to
the browser.
flushSync is still the preferred API in most cases, such as inside
a requestAnimationFrame callback.
* Test that flushControlled does not flush inside batchedUpdates
* Make flushControlled a void function
In the future, we may want to return a thenable work object. For now,
we'll return nothing.
* flushControlled -> unstable_flushControlled
* Replace unstable_AsyncComponent with Unstable_AsyncMode
Mirrors the StrictMode API and uses the new Mode type of work.
* internalContextTag -> mode
Change this now that we have a better name
* Unstable_ -> unstable_
* Suppress unsafe/deprecation warnings for polyfilled components.
* Don't invoke deprecated lifecycles if static gDSFP exists.
* Applied recent changes to server rendering also
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.
While writing tests for unsafe async warnings, I noticed that in certain cases, errors were swallowed by the toWarnDev matcher and resulted in confusing test failures. For example, if an error prevented the code being tested from logging an expected warning- the test would fail saying that the warning hadn't been logged rather than reporting the unexpected error. I think a better approach for this is to always treat caught errors as the highest-priority reason for failing a test.
I reran all of the test cases for this matcher that I originally ran with PR #11786 and ensured they all still pass.
* 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
* Adds danger_js with an initial rule for warning about large PRs
Signed-off-by: Anandaroop Roy <roop@artsymail.com>
* [WIP] Get the before and after for the build results
* [Dev] More work on the Dangerfile
* [Danger] Split the reports into sections based on their package
* Remove the --extract-errors on the circle build
* [Danger] Improve the lookup for previous -> current build to also include the environment
* Fix rebase
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.
We want to start refactoring some of the event constants, but we don't
have a great way to confirm media events work as intended. This commit
adds a new DOM test fixture to verify that media events bubble.
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
* Added 'flow-coverage-report' package for discussion
* Aded flow-coverage command and configuration file
* Moved FLow coverage config file to scripts/flow/coverage-config
* Moved Flow coverage config back to root as dotfile
* Runs a lint rule on tests only that errors if it sees `fdescribe` or `fit` calls.
* Changes `file:` to `link:` for our custom, internal rules (just to simplify updating these in the future).
* Updates `eslint` from 3.10 -> 4.1 and `babel-eslint` from 7.1 -> 8.0 so that we can run this new rule only against tests.
* 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
* Move build/packages/* to build/node_modules/*
This fixes Node resolution in that folder and lets us require() packages in it in Node shell for manual testing.
* Link fixtures to packages/node_modules
This updates the location and also uses link: instead of file: to avoid Yarn caching the folder contents.
* 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
I'm running out of ideas to keep these commit messages entertaining. Thankfully this should keep the CI green and we can forget any of it ever happened.
We added this to Flow in v0.25 (about 2 years ago), but never actually
deprecated the legacy `declare var exports` syntax. Hoping to do that
soon, so clearing up uses that I can find.
Test Plan: flow
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
* Harden tests around init/addition/update/removal of aliased attributes
I noticed some patterns weren't being tested.
* Call setValueForProperty() for null and undefined
The branching before the call is unnecessary because setValueForProperty() already
has an internal branch that delegates to deleteValueForProperty() for null and
undefined through the shouldIgnoreValue() check.
The goal is to start unifying these methods because their separation doesn't
reflect the current behavior (e.g. for unknown properties) anymore, and obscures
what actually happens with different inputs.
* Inline deleteValueForProperty() into setValueForProperty()
Now we don't read propertyInfo twice in this case.
I also dropped a few early returns. I added them a while ago when we had
Stack-only tracking of DOM operations, and some operations were being
counted twice because of how this code is structured. This isn't a problem
anymore (both because we don't track operations, and because I've just
inlined this method call).
* Inline deleteValueForAttribute() into setValueForAttribute()
The special cases for null and undefined already exist in setValueForAttribute().
* Delete some dead code
* Make setValueForAttribute() a branch of setValueForProperty()
Their naming is pretty confusing by now. For example setValueForProperty()
calls setValueForAttribute() when shouldSetAttribute() is false (!). I want
to refactor (as in, inline and then maybe factor it out differently) the relation
between them. For now, I'm consolidating the callers to use setValueForProperty().
* Make it more obvious where we skip and when we reset attributes
The naming of these methods is still very vague and conflicting in some cases.
Will need further work.
* Rewrite setValueForProperty() with early exits
This makes the flow clearer in my opinion.
* Move shouldIgnoreValue() into DOMProperty
It was previously duplicated.
It's also suspiciously similar in purpose to shouldTreatAttributeValueAsNull()
so I want to see if there is a way to unify them.
* Use more specific methods for testing validity
* Unify shouldTreatAttributeValueAsNull() and shouldIgnoreValue()
* Remove shouldSetAttribute()
Its naming was confusing and it was used all over the place instead of more specific checks.
Now that we only have one call site, we might as well inline and get rid of it.
* Remove unnecessary condition
* Remove another unnecessary condition
* Add Flow coverage
* Oops
* Fix lint (ESLint complains about Flow suppression)
* Fix treatment of Symbol/Function values on boolean attributes
They weren't being properly skipped because of the early return.
I added tests for this case.
* Avoid getPropertyInfo() calls
I think this PR looks worse on benchmarks because we have to read propertyInfo in different places.
Originally I tried to get rid of propertyInfo, but looks like it's important for performance after all.
So now I'm going into the opposite direction, and precompute propertyInfo as early as possible, and then just pass it around.
This way we can avoid extra lookups but keep functions nice and modular.
* Pass propertyInfo as argument to getValueForProperty()
It always exists because this function is only called for known properties.
* Make it clearer this branch is boolean-specific
I wrote this and then got confused myself.
* Memoize whether propertyInfo accepts boolean value
Since we run these checks for all booleans, might as well remember it.
* Fix a crash when numeric property is given a Symbol
* Record attribute table
The changes reflect that SSR doesn't crash with symbols anymore (and just warns, consistently with the client).
* Refactor attribute initialization
Instead of using flags, explicitly group similar attributes/properties.
* Optimization: we know built-in attributes are never invalid
* Use strict comparison
* Rename methods for clarity
* Lint nit
* Minor tweaks
* Document all the different attribute types
* Deduplication of warn selected on option
- Wrote a failing test
- Deduplication when selected is set on option
* Ran yarn preitter
* Fixed PR request
- Moved dedupe test to above
- Moved && case to seperate if to seperate static and dynamic things
- Render'd component twice
* Actually check for deduplication
* Minor nits
* Harden tests around init/addition/update/removal of aliased attributes
I noticed some patterns weren't being tested.
* Call setValueForProperty() for null and undefined
The branching before the call is unnecessary because setValueForProperty() already
has an internal branch that delegates to deleteValueForProperty() for null and
undefined through the shouldIgnoreValue() check.
The goal is to start unifying these methods because their separation doesn't
reflect the current behavior (e.g. for unknown properties) anymore, and obscures
what actually happens with different inputs.
* Inline deleteValueForProperty() into setValueForProperty()
Now we don't read propertyInfo twice in this case.
I also dropped a few early returns. I added them a while ago when we had
Stack-only tracking of DOM operations, and some operations were being
counted twice because of how this code is structured. This isn't a problem
anymore (both because we don't track operations, and because I've just
inlined this method call).
* Inline deleteValueForAttribute() into setValueForAttribute()
The special cases for null and undefined already exist in setValueForAttribute().
* Delete some dead code
* Make setValueForAttribute() a branch of setValueForProperty()
Their naming is pretty confusing by now. For example setValueForProperty()
calls setValueForAttribute() when shouldSetAttribute() is false (!). I want
to refactor (as in, inline and then maybe factor it out differently) the relation
between them. For now, I'm consolidating the callers to use setValueForProperty().
* Make it more obvious where we skip and when we reset attributes
The naming of these methods is still very vague and conflicting in some cases.
Will need further work.
* Rewrite setValueForProperty() with early exits
This makes the flow clearer in my opinion.
* Move shouldIgnoreValue() into DOMProperty
It was previously duplicated.
It's also suspiciously similar in purpose to shouldTreatAttributeValueAsNull()
so I want to see if there is a way to unify them.
* Use more specific methods for testing validity
* Unify shouldTreatAttributeValueAsNull() and shouldIgnoreValue()
* Remove shouldSetAttribute()
Its naming was confusing and it was used all over the place instead of more specific checks.
Now that we only have one call site, we might as well inline and get rid of it.
* Remove unnecessary condition
* Remove another unnecessary condition
* Add Flow coverage
* Oops
* Fix lint (ESLint complains about Flow suppression)
* Remove EventListener fbjs utility
EventListener normalizes event subscription for <= IE8. This is no
longer necessary. element.addEventListener is sufficient.
* Remove an extra allocation for open source bundles
* Split into two functions to avoid extra runtime checks
* Revert unrelated changes
* Add a test-only transform to catch infinite loops
* Only track iteration count, not time
This makes the detection dramatically faster, and is okay in our case because we don't have tests that iterate so much.
* Use clearer naming
* Set different limits for tests
* Fail tests with infinite loops even if the error was caught
* Add a test
* ValidateDOMNesting tests(#11299)
* Rewrite tests using only public API.
* Modified the tests to prevent duplication of code.
* Code review changes implemented.
* Removed the .internal from the test file name as
its now written using public APIs.
* Remove mutation
* Remove unnecessary argument
Now that we pass warnings, we don't need to pass a boolean.
* Move things around a bit, and add component stack assertions
* Rewrite the build scripts
* Don't crash when doing FB-only builds
* Group sync imports under Sync.*
* Don't print known errors twice
* Use an exclamation that aligns vertically
* Fix autoFocus for hydration content when it is mismatched
* Add a test for mismatched content
* Fix a test for production
* Fix a spec description and verify console.error output
* Run prettier
* finalizeInitialChildren always returns `true`
* Revert "finalizeInitialChildren always returns `true`"
This reverts commit 58edd228046bcafcbcd04a70cb5e78520b50a07e.
* Add a TODO comment
* Update ReactServerRendering-test.js
* Update ReactServerRendering-test.js
* Rewrite the comment
* Change build process to include npm pack and unpacking generated packages to corresponding build directories.
* Update function name, change to use os's default temp directory
* appending uuid to temp npm packaging directory.
* Ensure value and defaultValue do not assign functions and symbols
* Eliminate assignProperty method from ReactDOMInput
* Restore original placement of defaultValue reservedProp
* Reduce branching. Make assignment more consistent
* Control for warnings in symbol/function tests
* Add boolean to readOnly assignments
* Tweak the tests
* Invalid value attributes should convert to an empty string
* Revert ChangeEventPlugin update. See #11746
* Format
* Replace shouldSetAttribute call with value specific type check
DOMProperty.shouldSetAttribute runs a few other checks that aren't
appropriate for determining if a value or defaultValue should be
assigned on an input. This commit replaces that call with an input
specific check.
* Remove unused import
* Eliminate unnecessary numeric equality checks (#11751)
* Eliminate unnecessary numeric equality checks
This commit changes the way numeric equality for number inputs works
such that it compares against `input.valueAsNumber`. This eliminates
quite a bit of branching around numeric equality.
* There is no need to compare valueAsNumber
* Add test cases for empty string to 0.
* Avoid implicit boolean JSX props
* Split up numeric equality test to isolate eslint disable command
* Fix typo in ReactDOMInput test
* Add todos
* Update the attribute table
I updated ReactDOMInput.synchronizeDefaultValue such that it assignes
the defaultValue property instead of the value attribute. I never
followed up on the ChangeEventPlugin's on blur behavior.
* Inline HTML and SVG configs into DOMProperty
* Replace invariants with warnings
These invariants can only happen if *we* mess up, and happen during init time.
So it's safe to make these warnings, as they would fail the tests anyway.
* Clearer variable naming
* Use defaultValue instead of setAttribute('value')
This commit replaces the method of synchronizing an input's value
attribute from using setAttribute to assigning defaultValue. This has
several benefits:
- Fixes issue where IE10+ and Edge password icon disappears (#7328)
- Fixes issue where toggling input types hides display value on dates
in Safari (unreported)
- Removes mutationMethod behaviors from DOMPropertyOperations
* initialValue in Input wrapperState is always a string
* The value property is assigned before the value attribute. Fix related tests.
* Remove initial value tests in ReactDOMInput
I added these tests after removing the `value` mutation
method. However they do not add any additional value over existing
tests.
* Improve clarity of value checks in ReactDOMInput.postMountWrapper
* Remove value and defaultValue from InputWithWrapperState type
They are already included in the type definition for HTMLInputElement
* Inline stringification of value in ReactDOMInput
Avoids eagier stringification and makes usage more consistent.
* Use consistent value/defaultValue presence in postMountHook
Other methods in ReactDOMInput check for null instead of
hasOwnProperty.
* Add missing semicolon
* Remove unused value argument in ReactDOMInput test
* Address cases where a value switches to undefined
When a controlled input value switches to undefined, it reverts back
to the initial state of the controlled input.
We didn't have test coverage for this case, so I've added two describe
blocks to cover both null and undefined.
* Test: create TapEventPlugin-test
* move TapEventPlugin to TapEventPlugin-test.internal.js from ReactBrowserEventEmitter-test.internal.js
* Prittier: run prittier
* run prittier
* Fix: fix CI test error
fix CI test error by lint
* Test: remove TapEventPlugin test code
* remove TapEventPlugin test code from ReactBrowserEventEmitter-test.internal.js
* Use `this` inside invokeGuardedCallback
It's slightly odd but that's exactly how our www fork works.
Might as well do it in the open source version to make it clear we rely on context here.
* Move invokeGuardedCallback into a separate file
This lets us introduce forks for it.
* Add a www fork for invokeGuardedCallback
* Fix Flow
* WIP:use public API
* ReactPortal shifted to shared:all passed
* wrote createPortal method for ReactNoop.(#11299)
* imported ReactNodeList type into ReactNoop.(#11299)
* createPortal method implemented.(#11299)
* exec yarn prettier-all.(#11299)
* Unify the way we fork modules
* Replace rollup-plugin-alias with our own plugin
This does exactly what we need and doesn't suffer from https://github.com/rollup/rollup-plugin-alias/issues/34.
* Move the new plugin to its own file
* Rename variable for consistency
I settled on calling them "forks" since we already have a different concept of "shims".
* Move fork config into its own file
* Rewrite SelectEventPlugin-test to test behavior using Public API
* Minor refactor
* Make sure that we test that "focus" event is ignored
Use newer API when creating events
* Rewrote the other test to use Public API as well
* Tweak the test
* Remove -internal suffix
* Oops
* Warn if `document` is missing by the time invokeGuardedCallback runs in DEV
* Typo
* Add a comment
* Use invariant() instead
* Create event immediately for clarity
* rewrite two phase traversal tests with public APIs
* rewrite enter/leave tests
* lift render into beforeEach, organise variables
* move getLowestCommonAncestor test
* remove internal tree traversal test
* fix linter errors
* move creation of outer nodes into {before,after}Each
* explain why getLowestCommonAncestor test was moved
* remove unnessecary ARG and ARG2 token
these were used for testing the internal API to simulate synthetic
events passed to traverseEnterLeave. since we're now dealing with
actual synthetic events we can remove them.
* run prettier
In the current implementation, pendingProps is null if there are no new
props since the last commit. When that happens, we bail out and reuse
the current props.
But it makes more sense to always set pendingProps to whatever the next
props will be. In other words, pendingProps is never null: it points to
either new props, or to the current props. Modeling it this way lets us
delete lots of code branches and is easier to reason about bail outs:
just compare the pending props to the current props.
API for batching top-level updates and deferring the commit.
- `root.createBatch` creates a batch with an async expiration time
associated with it.
- `batch.render` updates the children that the batch renders.
- `batch.then` resolves when the root has completed.
- `batch.commit` synchronously flushes any remaining work and commits.
No two batches can have the same expiration time. The only way to
commit a batch is by calling its `commit` method. E.g. flushing one
batch will not cause a different batch to also flush.
* Move ReactFiberTreeReflection to react-reconciler/reflection #11659
* Use * for react-reconciler
We don't know the latest local version, and release script currently doesn't bump deps automatically.
* Remove unused field
* Use CommonJS in entry point for consistency
* Undo the CommonJS change
I didn't realize it would break the build.
* Record sizes
* Remove reconciler fixtures
They're unnecessary now that we run real tests on reconciler bundles.
* Add rule to ignore default handling of not linting hidden files
* Undo changes
* Add function to validate warnings
* Use validateWarnings when reporting linc command
* Restore files
* Contain code to line file
* Add bundle linting and tests to the release script
- add yarn lint-build
- use yarn lint-build in circle ci build.sh
- add yarn lint-build, yarn test-prod, yarn test-build, and yarn test-build-prod to the realse script
* Improve readability of release test messages
* Run prettier
* Updating package versions for release 16.2.0
* Seperate bundle specific tests
- Moved the runYarnTask into utils since its being used two files now
- Uncomment out checks I mistakenly committed
* Revert a bunch of version bump changes
Mistakenly commited by release script
* .js for consistency
* KeyboardEvent interface-keypress
* Pass first 6 tests
* Roll getEventCharCode-test into SyntheticKeyboardEvent-test
* Run SyntheticKeyboardEvent-test on bundles
* Remove unused code
* Use only public API for ChangeEventPlugin-test.js
* precommit commands complete
* Removed comments
* Improving event dispatchers
* Updated tests
* Fixed for revisions
* Prettified
* Add more details and fixes to tests
* Not internal anymore
* Remove unused code
* added verification check for misspelled propTypes
* added flag to check if misspelled warning was shown to developer before
* added the condition to else if and improved the warning message
* moved variable under dev section & initialized it to false
* added test to confirm the missmatch prop type warning in both and tests files
* removed eslint disable and split error into 2 lines
* changed expectDev to expect in tests
* added __DEV__ condition before both tests
* Rename escapeText util. Test quoteAttributeValueForBrowser through ReactDOMServer API
* Fix lint errors
* Prettier reformatting
* Change syntax to prevent prettier escape doble quote
* Name and description gardening. Add tests for escapeTextForBrowser. Add missing tests
* Improve script tag as text content test
* Update escapeTextForBrowser-test.js
* Update quoteAttributeValueForBrowser-test.js
* Simplify tests
* Move utilities to server folder
* Extract Jest config into a separate file
* Refactor Jest scripts directory structure
Introduces a more consistent naming scheme.
* Add yarn test-bundles and yarn test-prod-bundles
Only files ending with -test.public.js are opted in (so far we don't have any).
* Fix error decoding for production bundles
GCC seems to remove `new` from `new Error()` which broke our proxy.
* Build production version of react-noop-renderer
This lets us test more bundles.
* Switch to blacklist (exclude .private.js tests)
* Rename tests that are currently broken against bundles to *-test.internal.js
Some of these are using private APIs. Some have other issues.
* Add bundle tests to CI
* Split private and public ReactJSXElementValidator tests
* Remove internal deps from ReactServerRendering-test and make it public
* Only run tests directly in __tests__
This lets us share code between test files by placing them in __tests__/utils.
* Remove ExecutionEnvironment dependency from DOMServerIntegrationTest
It's not necessary since Stack.
* Split up ReactDOMServerIntegration into test suite and utilities
This enables us to further split it down. Good both for parallelization and extracting public parts.
* Split Fragment tests from other DOMServerIntegration tests
This enables them to opt other DOMServerIntegration tests into bundle testing.
* Split ReactDOMServerIntegration into different test files
It was way too slow to run all these in sequence.
* Don't reset the cache twice in DOMServerIntegration tests
We used to do this to simulate testing separate bundles.
But now we actually *do* test bundles. So there is no need for this, as it makes tests slower.
* Rename test-bundles* commands to test-build*
Also add test-prod-build as alias for test-build-prod because I keep messing them up.
* Use regenerator polyfill for react-noop
This fixes other issues and finally lets us run ReactNoop tests against a prod bundle.
* Run most Incremental tests against bundles
Now that GCC generator issue is fixed, we can do this.
I split ErrorLogging test separately because it does mocking. Other error handling tests don't need it.
* Update sizes
* Fix ReactMount test
* Enable ReactDOMComponent test
* Fix a warning issue uncovered by flat bundle testing
With flat bundles, we couldn't produce a good warning for <div onclick={}> on SSR
because it doesn't use the event system. However the issue was not visible in normal
Jest runs because the event plugins have been injected by the time the test ran.
To solve this, I am explicitly passing whether event system is available as an argument
to the hook. This makes the behavior consistent between source and bundle tests. Then
I change the tests to document the actual logic and _attempt_ to show a nice message
(e.g. we know for sure `onclick` is a bad event but we don't know the right name for it
on the server so we just say a generic message about camelCase naming convention).
* Remove global mocks
They are making it harder to test compiled bundles.
One of them (FeatureFlags) is not used. It is mocked in some specific test files (and that's fine).
The other (FiberErrorLogger) is mocked to silence its output. I'll look if there's some other way to achieve this.
* Add error.suppressReactErrorLogging and use it in tests
This adds an escape hatch to *not* log errors that go through React to the console.
We will enable it for our own tests.
* Create test to verify ReactShallowRenderer bug (#11496)
* Fix ReactShallowRenderer callback bug on componentWillMount (#11496)
* Improve fnction naming and clean up queued callback before call
* Run prettier on ReactShallowRenderer.js
* Consolidate callback call on ReactShallowRenderer.js
* Ensure callback behavior is similar between ReactDOM and ReactShallowRenderer
* Fix Code Review requests (#11507)
* Move test to ReactCompositeComponent
* Verify the callback gets called
* Ensure multiple callbacks are correctly handled on ReactShallowRenderer
* Ensure the setState callback is called inside componentWillMount (ReactDOM)
* Clear ReactShallowRenderer callback queue before actually calling the callbacks
* Add test for multiple callbacks on ReactShallowRenderer
* Ensure the ReactShallowRenderer callback queue is cleared after invoking callbacks
* Remove references to internal fields on ReactShallowRenderer test
* Move Jest setup files to /dev/ subdirectory
* Clone Jest /dev/ files into /prod/
* Move shared code into scripts/jest
* Move Jest config into the scripts folder
* Fix the equivalence test
It fails because the config is now passed to Jest explicitly.
But the test doesn't know about the config.
To fix this, we just run it via `yarn test` (which includes the config).
We already depend on Yarn for development anyway.
* Add yarn test-prod to run Jest with production environment
* Actually flip the production tests to run in prod environment
This produces a bunch of errors:
Test Suites: 64 failed, 58 passed, 122 total
Tests: 740 failed, 26 skipped, 1809 passed, 2575 total
Snapshots: 16 failed, 4 passed, 20 total
* Ignore expectDev() calls in production
Down from 740 to 175 failed.
Test Suites: 44 failed, 78 passed, 122 total
Tests: 175 failed, 26 skipped, 2374 passed, 2575 total
Snapshots: 16 failed, 4 passed, 20 total
* Decode errors so tests can assert on their messages
Down from 175 to 129.
Test Suites: 33 failed, 89 passed, 122 total
Tests: 129 failed, 1029 skipped, 1417 passed, 2575 total
Snapshots: 16 failed, 4 passed, 20 total
* Remove ReactDOMProduction-test
There is no need for it now. The only test that was special is moved into ReactDOM-test.
* Remove production switches from ReactErrorUtils
The tests now run in production in a separate pass.
* Add and use spyOnDev() for warnings
This ensures that by default we expect no warnings in production bundles.
If the warning *is* expected, use the regular spyOn() method.
This currently breaks all expectDev() assertions without __DEV__ blocks so we go back to:
Test Suites: 56 failed, 65 passed, 121 total
Tests: 379 failed, 1029 skipped, 1148 passed, 2556 total
Snapshots: 16 failed, 4 passed, 20 total
* Replace expectDev() with expect() in __DEV__ blocks
We started using spyOnDev() for console warnings to ensure we don't *expect* them to occur in production. As a consequence, expectDev() assertions on console.error.calls fail because console.error.calls doesn't exist. This is actually good because it would help catch accidental warnings in production.
To solve this, we are getting rid of expectDev() altogether, and instead introduce explicit expectation branches. We'd need them anyway for testing intentional behavior differences.
This commit replaces all expectDev() calls with expect() calls in __DEV__ blocks. It also removes a few unnecessary expect() checks that no warnings were produced (by also removing the corresponding spyOnDev() calls).
Some DEV-only assertions used plain expect(). Those were also moved into __DEV__ blocks.
ReactFiberErrorLogger was special because it console.error()'s in production too. So in that case I intentionally used spyOn() instead of spyOnDev(), and added extra assertions.
This gets us down to:
Test Suites: 21 failed, 100 passed, 121 total
Tests: 72 failed, 26 skipped, 2458 passed, 2556 total
Snapshots: 16 failed, 4 passed, 20 total
* Enable User Timing API for production testing
We could've disabled it, but seems like a good idea to test since we use it at FB.
* Test for explicit Object.freeze() differences between PROD and DEV
This is one of the few places where DEV and PROD behavior differs for performance reasons.
Now we explicitly test both branches.
* Run Jest via "yarn test" on CI
* Remove unused variable
* Assert different error messages
* Fix error handling tests
This logic is really complicated because of the global ReactFiberErrorLogger mock.
I understand it now, so I added TODOs for later.
It can be much simpler if we change the rest of the tests that assert uncaught errors to also assert they are logged as warnings.
Which mirrors what happens in practice anyway.
* Fix more assertions
* Change tests to document the DEV/PROD difference for state invariant
It is very likely unintentional but I don't want to change behavior in this PR.
Filed a follow up as https://github.com/facebook/react/issues/11618.
* Remove unnecessary split between DEV/PROD ref tests
* Fix more test message assertions
* Make validateDOMNesting tests DEV-only
* Fix error message assertions
* Document existing DEV/PROD message difference (possible bug)
* Change mocking assertions to be DEV-only
* Fix the error code test
* Fix more error message assertions
* Fix the last failing test due to known issue
* Run production tests on CI
* Unify configuration
* Fix coverage script
* Remove expectDev from eslintrc
* Run everything in band
We used to before, too. I just forgot to add the arguments after deleting the script.
* support Call and Return components in React.Children calls
* make tests more verbose
* fix ordering of React component types
* cleanup conditional detection of children type
* directly inline callback invocation
* reduce callback invocation code re-use
* Forked ReactFeatureFlags for React Native to enable debugRenderPhaseSideEffects GK
* Changed debugRenderPhaseSideEffects in www feature flags to be runtime as well
* generate synthetics events using public API
* rewritten createEvent to use public APIs
* removed all references SyntheticEvent.release
In order to test under realistic circumstances I had to move
the expectations into a callback in mosts tests to overcome
the effects of event pooling.
* run prettier
* remove empty line
* don't use ReactTestUtils
* run prettier and fix linter issues
* remove duplicate test
* remove invalid calls to expect
The removed `expect` calls verified the correct behaviour based on
missing `preventDefault` and `stopPropagation` methods.
The was correct as we used plain objects to simulate events.
Since we switched to the public API we're using native events which
do have these methods.
* set event.defaultPrevented to undefined
This was missed when the test was first migrated.
When emulating IE8 not only has returnValue to be false.
In addition defaultPrevented must not be defined.
* run all tests and format code
* rename instance variable to node
* remove backtick
* only simulate IE in normalisation test
* include assignment in definition
* add missing `persist` test
* use method instead of field to prevent default
* expect properties to be unchanged on persisted event
* optimise tests that deal with event persitence
* declare and assign `event` on the same line if not reassigned later
The `wheel` event has not always been supported in every browser. React would fall back to `mousewheel` and `DOMMouseScroll` when the `wheel` event was not available. All supported browsers provide the `wheel` event. This code is no longer necessary.
Fixes a case where changing the name and checked value of a radio button in the same update would lead to checking the wrong radio input. Also adds a DOM test fixture for related issue.
Related issues:
https://github.com/facebook/react/issues/7630
* Use const/let in more places (#11467)
* Convert ReactDOMFiberTextarea to const/let
* Convert ReactDOMSelection to const/let
* Convert setTextContent to const/let
* Convert validateDOMNesting to const/let
* Replace Object.assign by Object Spread
* Convert ReactDOMFiberOption to Object Spread
* Convert ReactDOMFiberTextarea to Object Spread
* Convert validateDOMNesting to Object Spread
* Improve formatting of errors when building
* Remove undefined from the header when error.plugin is undefined
* Add babel-code-frame and syntax highlighting in error message
* Run yarn prettier and fix code format
* Rewrite ReactDOMComponentTree-test to test behavior using Public API
- Part of #11299
- I've tried to identify cases where code within ReactDOMComponentTree is exercised and have updated accordingly but I'm not entirely sure whether I'm on the right track. I thought I'd PR to get feedback from the community. Looking forward to comments.
* Prettier and lint changes
* Remove testing of internals and add test cases for testing behavior exhibited after use of getInstanceFromNode
* [RFC] Update testing approach to verify exhibited behavior dependent upon methods in ReactDOMComponentTree
* Remove tests from event handlers and use sync tests
* Prettier changes
* Rename variables to be more semantic
* Prettier updates
* Update test following review
- Use beforeEach and afterEach to set up and tear down container element for use in each test
- Move any functions specific to one test to within test body (improves readability imo)
* Add coverage for getNodeFromInstance and implementation of getFiberCurrentPropsFromNode
- After researching usage of getNodeFromInstance we can test getNodeFromInstance dispatching some events and asserting the id of the currentTarget
- After checking git blame for getFiberCurrentPropsFromNode and reading through #8607 I found a test that we can simplify to assert behavior of the function by ensuring event handler props are updated from the fiber props. Swapping out the implementation of this function with `return node[internalInstanceKey].memoizedProps` results in a failure.
When we're rendering work at a specific level, and a higher priority
update comes in, we interrupt the current work and restart at the
higher priority. The rationale is that the high priority update is
likely cheaper to render that the lower one, so it's usually worth
throwing out the current work to get the high pri update on the screen
as soon as possible.
Currently, we also interrupt the current work if an update of *equal*
priority is scheduled. The rationale here is less clear: the only reason
to do this is if both updates are expected to flush at the same time,
to prevent tearing. But this usually isn't the case. Separate setStates
are usually distinct updates that can be flushed separately, especially
if the components that are being updated are in separate subtrees.
An exception is in Flux-like systems where multiple setStates are the
result of a single conceptual update/event/dispatch. We can add an
explicit API for batching in the future; in fact, we'd likely need one
anyway to account for expiration accidentally causing consecutive
updates to fall into separate buckets.
* Don't call idle callback unless there's time remaining
* Expiration fixture
Fixture that demonstrates how async work expires after a certain interval.
The fixture clogs the main thread with animation work, so it only works if the
`timeout` option is provided to `requestIdleCallback`.
* Pass timeout option to requestIdleCallback
Forces `requestIdleCallback` to fire if too much time has elapsed, even if the
main thread is busy. Required to make expiration times work properly. Otherwise,
async work can expire, but React never has a chance to flush it because the
browser never calls into React.
Fixes an issue where performWorkOnRoot was called, but nextFlushedRoot
was not set. This happened in a special branch where we synchronously
flush newly mounted DOM trees outside the normal work loop.
Arguably, performWorkOnRoot should read from the globally assigned root
and expiration time instead of accepting arguments, since those
arguments are expected to be the same as the global values, anyway. I
decided against that since the global values could be null, so reading
from them would require extra null checks.
* Unfreeze the react-dom/server interface
this allows stubbing of the exposed named functions, as was possible before v16.1
fixes#11526
* Fix missing version export
* Fix missing version export
* Whitespace
* Update Flow
* Fix createElement() issue
The * type was too ambiguous. It's always a string so what's the point?
Suppression for missing Flow support for {is: ''} web component argument to createElement() didn't work for some reason.
I don't understand what the regex is testing for anyway (a task number?) so I just removed that, and suppression got fixed.
* Remove deleted $Abstract<> feature
* Expand the unsound isAsync check
Flow now errors earlier because it can't find .type on a portal.
* Add an unsafe cast for the null State in UpdateQueue
* Introduce "hydratable instance" type
The Flow error here highlighted a quirk in our typing of hydration.
React only really knows about a subset of all possible nodes that can
exist in a hydrated tree. Currently we assume that the host renderer
filters them out to be either Instance or TextInstance. We also assume
that those are different things which they might not be. E.g. it could
be fine for a renderer to render "text" as the same type as one of the
instances, with some default props.
We don't really know what it will be narrowed down to until we call
canHydrateInstance or canHydrateTextInstance. That's when the type is
truly refined.
So to solve this I use a different type for hydratable instance that is
used in that temporary stage between us reading it from the DOM and until
it gets refined by canHydrate(Text)Instance.
* Have the renderer refine Hydratable Instance to Instance or Text Instance
Currently we assume that if canHydrateInstance or canHydrateTextInstance
returns true, then the types also match up. But we don't tell that to Flow.
It just happens to work because `fiber.stateNode` is still `any`.
We could potentially use some kind of predicate typing but instead
of that I can just return null or instance from the "can" tests.
This ensures that the renderer has to do the refinement properly.
* Use dispatchEvent() directly
Don't fear repetition in tests. It is clearer what's going on.
* Clean up the container after tests
* Add a comment to container code
* Update SyntheticWheelEvent tests to use public API
* Replace: ReactTestUtils.SimulateNative to native Events()
* Update: Replaced WheelEvent() interface to document.createEvent
* Fix: Lint SyntheticWheelEvent file
* Update: Custom WheelEvent function to a generic MouseEvent function
* Update: Prettier SyntheticWheelEvent-test.js
* Verify the `button` property is set on synthetic event
* Use MouseEvent constructor over custom helper
* Rewrite to test React rather than jsdom
* Force the .srcElement code path to execute
* Style tweaks and slight code reorganization
* Refactor SyntheticClipboardEvent tests to only use the public API
* Replace local document creation by document body reset on each test case execution
* Set up and tear down container separately
* Tweak test assertion logic for clarity
* Remove simulate abstraction and create events directly
* Ensure the test covers IE8 behavior
* Verify that persistence works
**what is the change?:**
Adding a document linking to the Facebook Open Source Code of Conduct,
for visibility and to meet Github community standards.
**why make this change?:**
Facebook Open Source provides a Code of Conduct statement for all
projects to follow.
React already links to this Code of Conduct in the README, which is
great!
Exposing the COC via a separate markdown file is a standard being
promoted by Github via the Community Profile in order to meet their Open
Source Guide's recommended community standards.
As you can see, adding this file will complete [React's Community Profile](https://github.com/facebook/react/community)
checklist and increase the visibility of our COC.
**test plan:**
Viewing it on my branch -
(Flarnie will insert screenshot)
**issue:**
internal task t23481323
* Measure time between scheduling an async callback and flushing it
Helps detect starvation issues.
* Debug comments should print directly above the next measure
* Better warning message
Most users won't know what "expires" means
* Remove inputValueTracking from ReactDOMComponent-test dependency
* prettier
* use node._valueTracker and add some test cases to make sure that value being tracked
* using Object.getOwnPropertyDescriptor to get the tracked value
* move getValueTracker to each test case and use its corresponding prototype
* remove tests and move the value tracker definition before React is imported
* Delete these tests completely
* Added missing params object to execUnlessDry call
* Public package names are no longer hard-coded
* Added "v" prefix to git tag
* Show more accurate in-progress duration
* Properly bucket-bridage params
* Prettier
* Publish command logs stack with error
* Consolidate build process with GCC
* Record sizes
* Refactor header and footer wrapping
It is easier to understand if we just explicitly type them out.
* Add a timeout before querying npm right after publish
* Conditionally log some post publish steps
* Print ready-to-paste 'yarn add' instructions for CRA prerelease testing
* Add a failing test for createFactory in production
* Fix createFactory() in production
* Add more prod-only tests
* Fix prettier
* Run prettier 1.8.1
* Enable User Timing API integration with a feature flag
* Expose a way to toggle user timing flag in www
* Update ReactNativeCSFeatureFlags.js
* Update ReactFeatureFlags.js
* Fix dead code elimination for feature flags
Turning flags into named exports fixes dead code elimination.
This required some restructuring of how we verify that flag types match up. I used the Check<> trick combined with import typeof, as suggested by @calebmer.
For www, we can no longer re-export `require('ReactFeatureFlags')` directly, and instead destructure it. This means flags have to be known at init time. This is already the case so it's not a problem. In fact it may be better since it removes extra property access in tight paths.
For things that we *want* to be dynamic on www (currently, only performance flag) we can export a function to toggle it, and then put it on the secret exports. In fact this is better than just letting everyone mutate the flag at arbitrary times since we can provide, e.g., a ref counting interface to it.
* Record sizes
* Convert ReactDOM to const/let
* Convert ReactDOMComponentTree to const/let
* Convert ReactDOMComponentTree to const/let
* Convert getNodeForCharacterOffset to const/let
* Convert getTextContentAccessor to const/let
* Convert inputValueTracking to const/let
* Convert setInnerHTML to const/let
* Convert setTextContent to const/let
* Convert validateDOMNesting to const/let
* Convert EventPlugin{Hub,Registry} to named exports
* Convert EventPluginUtils to named exports
* Convert EventPropagators to named exports
* Convert ReactControlledComponent to named exports
* Convert ReactGenericBatching to named exports
* Convert ReactDOMComponentTree to named exports
* Convert ReactNativeComponentTree to named exports
* Convert ReactNativeRTComponentTree to named exports
* Convert FallbackCompositionState to named exports
* Convert ReactEventEmitterMixin to named exports
* Convert ReactBrowserEventEmitter to named exports
* Convert ReactNativeEventEmitter to named exports
* Convert ReactDOMEventListener to named exports
* Convert DOMMarkupOperations to named exports
* Convert DOMProperty to named exports
* Add suppression for existing Flow violation
Flow didn't see it before.
* Update sizes
* Rewrite setInnerHTML tests to use Public API.
* Rename variables and drop unnecessary variable assignments.
* Rename testfile to dangerouslySetInnerHTML-test.js
* Properly prettify test file.
* Rewrite SVG tests to verify we recover from missing innerHTML
* Use only public api for ReactDOMEventListener-test.js
* Use less confusing naming
There was no need to extract React elements into separate variables.
* Replace the "disappearance" test
I could not get it to fail on master so it was probably testing something specific to Stack implementation details. It was also already broken because it didn't look at the right argument and never actually called `unmountComponentAtNode`.
Instead I replaced it with original repro case from https://github.com/facebook/react/issues/1105 which is when it was introduced.
* Tweak naming and add comments
* Missed this one
* Use only public API for EnterLeaveEventPlugin Tests (#11299)
* Trigger native event to test EnterLeaveEventPlugin (#11299)
* Rewrite EnterLeaveEventPlugin tests to use dispatchEvent
* Update EnterLeaveEventPlugin test to use OnMouseLeave event
* Add coverage for onMouseEnter too
* Update transforms to handle ES modules
* Update Jest to handle ES modules
* Convert react package to ES modules
* Convert react-art package to ES Modules
* Convert react-call-return package to ES Modules
* Convert react-test-renderer package to ES Modules
* Convert react-cs-renderer package to ES Modules
* Convert react-rt-renderer package to ES Modules
* Convert react-noop-renderer package to ES Modules
* Convert react-dom/server to ES modules
* Convert react-dom/{client,events,test-utils} to ES modules
* Convert react-dom/shared to ES modules
* Convert react-native-renderer to ES modules
* Convert react-reconciler to ES modules
* Convert events to ES modules
* Convert shared to ES modules
* Remove CommonJS support from transforms
* Move ReactDOMFB entry point code into react-dom/src
This is clearer because we can use ES imports in it.
* Fix Rollup shim configuration to work with ESM
* Fix incorrect comment
* Exclude external imports without side effects
* Fix ReactDOM FB build
* Remove TODOs I don’t intend to fix yet
* Constructor test and fix complete
* Linters and prettier run
* Remove unnecessary checks
* Update error message
* Updat unit test
* prettier
* Tweak the check to be more specific
* Move tests to ReactCompositeComponent-test
* add error call count and remove line
* Remove prop-types/checkPropTypes reimplementation
* Remove renderer dependency on top-level PropTypes
This annotation is unnecessary because we already warn for bad event listener types.
* Record sizes
* Drop fbjs/lib/EventListener from tests
Assert on the underlying native event listener instead.
This test file still needs to be rewritten in terms of public APIs.
* Inline fbjs/lib/EventListener dependency
We explicitly don't want to shim this and we don't use the return value.
We can probably even drop the IE path now since we don't support it.
Not sure if that'll be a true breaking change though.
* Wrap event listeners and the callback passed to requestIdleCallback
This is a FBism.
This uses the injection model in ReactErrorUtils. This isn't technically
going to used for errors but close enough.
This really wants to be eager but we can't because of dynamic injection.
* move to pendingProps to args
* update userFiber in ReactChildFiber
* prettier it
* prettier it
* move expirationTime to the last
* move expirationTime to the last on userFiber
* Move assignment
* Deduplicated many warnings (#11140)
* Deduplicated the following warnings:
1. Can only update a mounted or mounting component.
This usually means you called setState, replaceState,
or forceUpdate on an unmounted component. This is a no-op
2. %s.componentWillReceiveProps(): Assigning directly to
this.state is deprecated (except inside a component's
constructor). Use setState instead.'
3. An update (setState, replaceState, or forceUpdate) was scheduled
from inside an update function. Update functions should be pure,
with zero side-effects. Consider using componentDidUpdate or a
callback.
4. setState(...): Cannot call setState() inside getChildContext()
* Code review changes made for #11140
* Minor style fix
* Test deduplication for noop updates in server renderer
* Test deduplication for cWRP warning
* Test deduplication for cWM setState warning
* Test deduplication for unnmounted setState warning
* Fix existing Flow typing
* Test deduplication for invalid updates
* Test deduplication of update-in-updater warning
* Corrects error message for select with props.multiple set to true and a null value.
* Don't bother deduplicating based on type
* Make the code a bit simpler (and more verbose)
* Add Fragment as a named export to React
* Remove extra tests for Fragment
* Change React.Fragment export to be a string '#fragment'
* Fix fragment special case to work with 1 child
* Add single child test for fragment export
* Move fragment definition to ReactEntry.js and render components for key warning tests
* Inline createFiberFromElementType into createFiberFromElement
* Update reconciliation to special case fragments
* Use same semantics as implicit childsets for ReactFragment
* Add more fragment state preservation tests
* Export symbol instead of string for fragments
* Fix rebase breakages
* Re-apply prettier at 1.2.2
* Merge branches in updateElement
* Remove unnecessary check
* Re-use createFiberFromFragment for fragment case
* Simplyify branches by adding type field to fragment fiber
* Move branching logic for fragments to broader methods when possible.
* Add more tests for fragments
* Address Dan's feedback
* Move REACT_FRAGMENT_TYPE into __DEV__ block for DCE
* Change hex representation of REACT_FRAGMENT_TYPE to follow convention
* Remove unnecessary branching and isArray checks
* Update test for preserving children state when keys are same
* Fix updateSlot bug and add more tests
* Make fragment tests more robust by using ops pattern
* Update jsx element validator to allow numbers and symbols
* Remove type field from fragment fiber
* Fork reconcileChildFibers instead of recursing
* Use ternary if condition
* Revamp fragment test suite:
- Add more coverage to fragment tests
- Use better names
- Remove useless Fragment component inside tests
- Remove useless tests so that tests are more concise
* Check output of renderer in fragment tests to ensure no silly business despite states being preserved
* Finish implementation of fragment reconciliation with desired behavior
* Add reverse render direction for fragment tests
* Remove unneeded fragment branch in updateElement
* Add more test cases for ReactFragment
* Handle childless fragment in reconciler
* Support fragment flattening in SSR
* Clean up ReactPartialRenderer
* Warn when non-key and children props are passed to fragments
* Add non-null key check back to updateSlot's array's case
* Add test for positional reconciliation in fragments
* Add warning for refs in fragments with stack trace
* Implement CS first take
This is using a pure JS API. This should probably switch to native hooks
at some later point but I'll start ironing out issues at this level first.
* Use async scheduling by default
The scheduled callback gets called immediately in render with infinite
time for now. Later this will be per root and abortable.
* Fix up the type signature of the ReactNativeCSType export
* Add escape hatch for special cased children
Working around the fact that we can't map arbitrary children slots. Just
the "children" prop.
* Readd providesModule for ReactNativeCSTypes
* Fix lint
* Fix ReactNativeTypes providesModule and CI check
* Special case a parent instance that doesn't have a props object
CSCustom can be anything here. Ugly but whatevs.
* Don't forget to store stateUpdater so that we can trigger updates
* Fix test
* Rewrite tests depending on internal API
* Remove focus being called when there was no blur event function before
* Remove triggering function and just let ReactTestUtils take care
* Use native events
* Remove duplicate
* Simulate native event when changing value on reentrant
* Change wasn't being called
* Use Simulate only
* Use React event handlers on test
* Move commentary
* Lint commit
* Use native event
* Comment native event dispatching
* Prettier
* add setUntrackedValue
* Prettier-all
* Use dispatchEvent instead of ReactTestUtils Simulates;
* Prettier
* Fix lint
* Remove useless arg
* Wrap event dispatcher into function
* Remove deprecated Event
* Remove unused change event dispatcher
* Fix merge
* Prettier
* Add missing focus/blur calls
They are necessary to cover for the fix in #8240.
While refactoring root scheduler, I noticed we have few tests that
cover updates across multiple roots. To address, I've added multiple
root cases to the fuzz tester.
Includes a hard-coded test case that was failing before #11307 landed.
* Update Jest
* Remove hacks for Jest + Workspace integration
They were fixed by https://github.com/facebook/jest/pull/4761.
* Use relative requires in tests relying on private APIs
I changed them to absolute to work around a Jest bug.
The bug has been fixed so I can revert my past changes now.
* Remove Task priority
The concept of Task priority was originally added as a way to avoid
reentrancy. Sync priority is for work that flushes synchronously, and
Task is for work that flushes at the end of the event loop.
But it turns out that in most cases, it's simpler to model Task and
Sync as the same priority level. For example, it's never correct to
flush Sync work from the update queue without flushing Task. Doing so
can lead to infinite update loops.
And using a separate priority level is not necessary to avoid
reentrancy. We already track when work is being rendered, and exit
before entering the render cycle again. That alone is sufficient.
This commit removes Task priority from the codebase. Now we use the
same level for both truly synchronous work and work that is deferred
until the end of the event loop.
This also enables us to remove DOM-specific legacy cases from the
reconciler and lift them to the renderer.
* Remove isUnbatched from FiberRoot
Simpler to render unbatched roots immediately.
* Use a cyclic linked list for root schedule
Avoids the need for a separate `isScheduled` field.
* Added an automated test that would have caught the recent error code transform bug
* Renamed dev-expression-with-codes test to replace-invariant-error-codes
* Formatting nit
* Use relative paths in packages/react
* Use relative paths in packages/react-art
* Use relative paths in packages/react-cs
* Use relative paths in other packages
* Fix as many issues as I can
This uncovered an interesting problem where ./b from package/src/a would resolve to a different instantiation of package/src/b in Jest.
Either this is a showstopper or we can solve it by completely fobbidding remaining /src/.
* Fix all tests
It seems we can't use relative requires in tests anymore. Otherwise Jest becomes confused between real file and symlink.
https://github.com/facebook/jest/issues/3830
This seems bad... Except that we already *don't* want people to create tests that import individual source files.
All existing cases of us doing so are actually TODOs waiting to be fixed.
So perhaps this requirement isn't too bad because it makes bad code looks bad.
Of course, if we go with this, we'll have to lint against relative requires in tests.
It also makes moving things more painful.
* Prettier
* Remove @providesModule
* Fix remaining Haste imports I missed earlier
* Fix up paths to reflect new flat structure
* Fix Flow
* Fix CJS and UMD builds
* Fix FB bundles
* Fix RN bundles
* Prettier
* Fix lint
* Fix warning printing and error codes
* Fix buggy return
* Fix lint and Flow
* Use Yarn on CI
* Unbreak Jest
* Fix lint
* Fix aliased originals getting included in DEV
Shouldn't affect correctness (they were ignored) but fixes DEV size regression.
* Record sizes
* Fix weird version in package.json
* Tweak bundle labels
* Get rid of output option by introducing react-dom/server.node
* Reconciler should depend on prop-types
* Update sizes last time
* Split performWork into renderRoot and commitRoot
It turns out that the scheduler is too coupled to how the DOM renderer
works. Specifically, the requestIdleCallback model, and how roots are
committed immediately after completing. Other renderers have different
constraints for when to yield and when to commit work.
We're moving towards a model where the scheduler only works on a single
root at a time, and the render phase and commit phase are split into
distinct entry points. This gives the renderer more control over when
roots are committed, coordinating multiple roots, deferring the commit
phase, batching updates, when to yield execution, and so on.
In this initial commit, I've left the renderers alone and only changed
the scheduler. Mostly, this involved extracting logic related to
multiple roots and moving it into its own section at the bottom of the
file. The idea is that this section can be lifted pretty much as-is
into the renderers. I'll do that next.
* Remove FiberRoot scheduleAt
Isn't actually used anywhere
* Make the root schedule a linked list again
Since this still lives inside the renderer, let's just use the
FiberRoot type. The FiberRoot concept will likely be lifted out
eventually, anyway.
* commitRoot should accept a HostRoot
This way it's less reliant on the alternate model
* Unify branches
* Remove dead branch
onUncaughtError is only called while we're working on a root.
* remainingWork -> remainingExpirationTime
I was wary of leaking NoWork but mixing numbers and null is worse so
let's just do it until we think of something better.
* Rename stuff
While testing some changes to RN, I noticed that the '--sync-fbsource' flag had been broken recently by things being moved around and the newly-added CS renderer. Fixed it up.
* react-dom/src/syntheticEvents => events, and put plugins into it
* Flatten react-dom/src/shared
* Split react-dom/src/client/utils into event/ and root client folder
Makes it clearer what is used by what.
* Strictly separate modules that can be imported by client and server
* shared/src -> shared
It's not a real package and doesn't even have package.json.
This will also make importing less weird if we drop Haste.
* Get rid of shared/utils
Moved event-specific into shared/event.
Moved rest to the root since distinction has always been pretty arbitrary.
* Fix references to old shared/src paths
* Move files and tests to more meaningful places
* Fix the build
Now that we import reconciler via react-reconciler, I needed to make a few tweaks.
* Update sizes
* Move @preventMunge directive to FB header
* Revert unintentional change
* Fix Flow coverage
I forgot to @flow-ify those files. This uncovered some issues.
* Prettier, I love you but you're bringing me down
Prettier, I love you but you're bringing me down
Like a rat in a cage
Pulling minimum wage
Prettier, I love you but you're bringing me down
Prettier, you're safer and you're wasting my time
Our records all show you were filthy but fine
But they shuttered your stores
When you opened the doors
To the cops who were bored once they'd run out of crime
Prettier, you're perfect, oh, please don't change a thing
Your mild billionaire mayor's now convinced he's a king
So the boring collect
I mean all disrespect
In the neighborhood bars I'd once dreamt I would drink
Prettier, I love you but you're freaking me out
There's a ton of the twist but we're fresh out of shout
Like a death in the hall
That you hear through your wall
Prettier, I love you but you're freaking me out
Prettier, I love you but you're bringing me down
Prettier, I love you but you're bringing me down
Like a death of the heart
Jesus, where do I start?
But you're still the one pool where I'd happily drown
And oh! Take me off your mailing list
For kids who think it still exists
Yes, for those who think it still exists
Maybe I'm wrong and maybe you're right
Maybe I'm wrong and maybe you're right
Maybe you're right, maybe I'm wrong
And just maybe you're right
And oh! Maybe mother told you true
And there'll always be somebody there for you
And you'll never be alone
But maybe she's wrong and maybe I'm right
And just maybe she's wrong
Maybe she's wrong and maybe I'm right
And if so, here's this song!
* Include component stack in more places, including SSR
* Forbid including reconciler code into the server bundle
* Tighten up the Flow annotation
* Fix lint
* Gosh Prettier
* Only renderers should depend on reconciler code
* Remove react-art dependency on react-dom modules
They share ReactDOMFrameScheduling so I moved it to shared.
* Update build size
* [CS] Clone container instead of new root concept
The extra "root" concept is kind of unnecessary. Instead of having a
mutable container even in the persistent mode, I'll instead make the
container be immutable too and be cloned. Then the "commit" just becomes
swapping the previous container for the new one.
* Change the signature or persistence again
We may need to clone without any updates, e.g. when the children are changed.
Passing in the previous node is not enough to recycle since it won't have the
up-to-date props and children. It's really only useful to for allocation pooling.
* Implement persistent updates
This forks the update path for host fibers. For mutation mode we mark
them as having an effect. For persistence mode, we clone the stateNode with
new props/children.
Next I'll do HostRoot and HostPortal.
* Refine protocol into a complete and commit phase
finalizeContainerChildren will get called at the complete phase.
replaceContainer will get called at commit.
Also, drop the keepChildren flag. We'll never keep children as we'll never
update a container if none of the children has changed.
* Implement persistent updates of roots and portals
These are both "containers". Normally we rely on placement/deletion effects
to deal with insertions into the containers. In the persistent mode we need
to clone the container and append all the changed children to it.
I needed somewhere to store these new containers before they're committed
so I added another field.
* Commit persistent work at the end by swapping out the container
* Unify cloneOrRecycle
Originally I tried to make the recyclable instance nullable but Flow didn't
like that and it's kind of sketchy since the instance type might not be
nullable.
However, the real difference which one we call is depending on whether they
are equal. We can just offload that to the renderer. Most of them won't
need to know about this at all since they'll always clone or just create
new.
The ones that do know now have to be careful to compare them so they don't
reuse an existing instance but that's probably fine to simplify the
implementation and API.
* Add persistent noop renderer for testing
* Add basic persistent tree test
* Test bail out
This adds a test for bailouts. This revealed a subtle bug. We don't set the
return pointer when stepping into newly created fibers because there
can only be one. However, since I'm reusing this mechanism for persistent
updates, I'll need to set the return pointer because a bailed out tree
won't have the right return pointer.
* Test persistent text nodes
Found another bug.
* Add persistent portal test
This creates a bit of an unfortunate feature testing in the unmount
branch.
That's because we want to trigger nested host deletions in portals in the
mutation mode.
* Don't consider container when determining portal identity
Basically, we can't use the container to determine if we should keep
identity and update an existing portal instead of recreate it. Because
for persistent containers, there is no permanent identity.
This makes it kind of strange to even use portals in this mode. It's
probably more ideal to have another concept that has permanent identity
rather than trying to swap out containers.
* Clear portals when the portal is deleted
When a portal gets deleted we need to create a new empty container and
replace the current one with the empty one.
* Add renderer mode flags for dead code elimination
* Simplify ReactNoop fix
* Add new type to the host config for persistent configs
We need container to stay as the persistent identity of the root atom.
So that we can refer to portals over time.
Instead, I'll introduce a new type just to temporarily hold the children
of a container until they're ready to be committed into the permanent
container. Essentially, this is just a fancy array that is not an array
so that the host can choose data structure/allocation for it.
* Implement new hooks
Now containers are singletons and instead their children swap. That way
portals can use the container as part of their identity again.
* Update build size and error codes
* Address comment
* Move new files to new location
* Enable Yarn workspaces for packages/*
* Move src/isomorphic/* into packages/react/src/*
* Create index.js stubs for all packages in packages/*
This makes the test pass again, but breaks the build because npm/ folders aren't used yet.
I'm not sure if we'll keep this structure--I'll just keep working and fix the build after it settles down.
* Put FB entry point for react-dom into packages/*
* Move src/renderers/testing/* into packages/react-test-renderer/src/*
Note that this is currently broken because Jest ignores node_modules,
and so Yarn linking makes Jest skip React source when transforming.
* Remove src/node_modules
It is now unnecessary. Some tests fail though.
* Add a hacky workaround for Jest/Workspaces issue
Jest sees node_modules and thinks it's third party code.
This is a hacky way to teach Jest to still transform anything in node_modules/react*
if it resolves outside of node_modules (such as to our packages/*) folder.
I'm not very happy with this and we should revisit.
* Add a fake react-native package
* Move src/renderers/art/* into packages/react-art/src/*
* Move src/renderers/noop/* into packages/react-noop-renderer/src/*
* Move src/renderers/dom/* into packages/react-dom/src/*
* Move src/renderers/shared/fiber/* into packages/react-reconciler/src/*
* Move DOM/reconciler tests I previously forgot to move
* Move src/renderers/native-*/* into packages/react-native-*/src/*
* Move shared code into packages/shared
It's not super clear how to organize this properly yet.
* Add back files that somehow got lost
* Fix the build
* Prettier
* Add missing license headers
* Fix an issue that caused mocks to get included into build
* Update other references to src/
* Re-run Prettier
* Fix lint
* Fix weird Flow violation
I didn't change this file but Flow started complaining.
Caleb said this annotation was unnecessarily using $Abstract though so I removed it.
* Update sizes
* Fix stats script
* Fix packaging fixtures
Use file: instead of NODE_PATH since NODE_PATH.
NODE_PATH trick only worked because we had no react/react-dom in root node_modules, but now we do.
file: dependency only works as I expect in Yarn, so I moved the packaging fixtures to use Yarn and committed lockfiles.
Verified that the page shows up.
* Fix art fixture
* Fix reconciler fixture
* Fix SSR fixture
* Rename native packages
Fixes a bug surfaced by www unit test.
I'm not yet sure the best way to test this; in the interest of landing
this fix quickly, I'll save the test for a follow-up.
* Add note to 'unreleased' CHANGELOG about deprecating Bower
**what is the change?:**
We will no longer release new versions of React to Bower, and we should
announce that as part of our CHANGELOG.
**why make this change?:**
We decided on this as a team.
**test plan:**
Visual inspection and spell check. :)
**issue:**
Just follow-up for https://github.com/facebook/react/pull/11223
* Improve messaging/formatting
* Move bower deprecation notice to top of changelog
* Delete tests that only mattered during createElement transition
They were added after #2576, but were only important when React.createElement was introduced as a migration path.
Now that elements are used consistently, these tests shouldn't be necessary.
I created a separate test specifically for scryRenderedComponentsWithType() though because that was the only one.
* Simplify mocking test setup
Today, the only remaining special behavior for Jest mocks is we let them render undefined.
We don't plan to introduce any other special behavior for them in the future.
(In fact, we already decided against replicating this special behavior for functional components.)
Therefore, we can remove dependency on Jest automocking mechanism in these tests completely,
and just explicitly mock the render method which is the only one for which we have special behavior.
For clarity, we add an explicit test for mockComponent() API (whose naming is a bit of a lie).
* Inline getTestDocument into test cases
* Remove mention of mock file we do not use
* Remove unused configuration entries
* Move eslint-rules package into the scripts/ folder
* ReactDOM.createRoot
Introduce new API for creating roots. Only root.render and root.unmount
are implemented. Later we'll add root.prerender, and support for lazy
roots (roots with DOM containers that resolve lazily).
* Add hydrate option to createRoot
* Deterministic updates
High priority updates typically require less work to render than
low priority ones. It's beneficial to flush those first, in their own
batch, before working on more expensive low priority ones. We do this
even if a high priority is scheduled after a low priority one.
However, we don't want this reordering of updates to affect the terminal
state. State should be deterministic: once all work has been flushed,
the final state should be the same regardless of how they were
scheduled.
To get both properties, we store updates on the queue in insertion
order instead of priority order (always append). Then, when processing
the queue, we skip over updates with insufficient priority. Instead of
removing updates from the queue right after processing them, we only
remove them if there are no unprocessed updates before it in the list.
This means that updates may be processed more than once.
As a bonus, the new implementation is simpler and requires less code.
* Fix ceiling function
Mixed up the operators.
* Remove addUpdate, addReplaceState, et al
These functions don't really do anything. Simpler to use a single
insertUpdateIntoFiber function.
Also splits scheduleUpdate into two functions:
- scheduleWork traverses a fiber's ancestor path and updates their
expiration times.
- scheduleUpdate inserts an update into a fiber's update queue, then
calls scheduleWork.
* Remove getExpirationTime
The last remaining use for getExpirationTime was for top-level async
updates. I moved that check to scheduleUpdate instead.
* Move UpdateQueue insertions back to class module
Moves UpdateQueue related functions out of the scheduler and back into
the class component module. It's a bit awkward that now we need to pass
around createUpdateExpirationForFiber, too. But we can still do without
addUpdate, replaceUpdate, et al.
* Store callbacks as an array of Updates
Simpler this way.
Also moves commitCallbacks back to UpdateQueue module.
* beginUpdateQueue -> processUpdateQueue
* Updates should never have an expiration of NoWork
* Rename expiration related functions
* Fix update queue Flow types
Gets rid of an unneccessary null check
* CS renderer
Because we didn't have enough RN experiments. I want to add one more.
* Split out hydration from the host config object
This makes it easier to do feature detection on the configuration.
* Move mutation host config to separate optional object
* Refs and life-cycles should happen even in immutable mode
* Unmount components even in non-mutation mode
This is the same as committing deletions but instead of finding host
components to delete, it only invokes componentWillUnmount and detaching
of refs.
* Add persistent updates API
This mode will use a clone based API instead of mutating host instances.
Needs implementation still.
It's awkward that there can be more than one child inserted into the root.
So we need a new API to create a "root" instance so that we can update it
atomically. Alternatively we could keep the mutable API for containers
and assume that most use cases would only have a single root.
* Package up CS renderer
* Fix reconciler package fixture
In sync mode, we downgrade sync priority work to task work when we're in
the commit phase, but not in the render phase. That means if you
schedule updates in both phases, the render phase update will flush
first, and the commit phase update will flush after that. What should
really happen is that both updates flush at the same time.
To solve this, updates in the commit phase are now given sync priority.
The distinction between task and sync really only exists to account for
a historical quirk in the behavior of top-level mounts. (Refer to the
test case titled "initial mount is sync inside batchedUpdates".)
Ideally, there would only be one priority for both sync and task. This
gets us closer to that model, while still accounting for
top-level mounts.
* chore(syntheticEvent): remove IE8 code
Since IE8 has been deprecated for a while, I thought it might be useful to remove some IE8-only code
If this is not something you want to focus on yet, or is too much work to test, feel free to close this PR
* Update SyntheticUIEvent.js
* Update SyntheticUIEvent.js
* remove unused require
* completely remove UIEvent
* augment with noop
everything breaks otherwise
* comment back
* spacing
Coalescing is the only feature that depends on PriorityLevel. Since
we're not sure if coalescing is even valuable, we'll remove it for
now. If it turns out we need it, we can add it back later.
* Initial commit of react-reconciler bundle
* I think it’s working 🙀
* React reconciler: slightly better description and README
* Drop react-reconciler version to an unstable release number
* Convert to moduleType enum and fix packaging
* eslint
* s/Renderer/Reconciler in docs
* yarn prettier
* change names of things in the react-reconciler readme
* change predicate
* rollup: flip object-assign shimming check
* copy noop renderer into react-reconciler fixture
* Change reconciler fixture test
* prettier
* Remove a bunch of Noop test renderer
* Delete a bunch of stuff we don’t care about for reconciler teesting. Add flow pragmas for future flow pragma testing
* Remove PATENTS
* Update Reconciler fixture docs
* ReactDOMUnstableNativeDependencies should be ISOMORPHIC
* Inline fixture renderer
* Make it "RENDERER"
* There is no UMD build. It also doesn't need propTypes.
* Tweak how the reconciler is built
* Record sizes
* Update README.md
* Keep autoFocus attribute in the DOM
* Don't emit autoFocus attribute on the client
* Test that hydration doesn't call focus
* Add autoFocus to SSR fixture
* Add <noscript> with HTML in it to SSR fixture
* Wrap <noscript> into a <div> to get its "client HTML"
* Revert "Wrap <noscript> into a <div> to get its "client HTML""
This reverts commit 27a42503e2790a0d5cf0b90451a664fc6ab9d862.
* Always use parent.ownerDocument
* Add failing iframe test
* Possible fix by returning null ownerName in SSR
* prettier
* eslolint
* gah c’mon really?
* emptyFunction.thatReturnsNull
* One less property access
* [Work-in-progress] Assign expiration times to updates
An expiration time represents a time in the future by which an update
should flush. The priority of the update is related to the difference
between the current clock time and the expiration time. This has the
effect of increasing the priority of updates as time progresses, to
prevent starvation.
This lays the initial groundwork for expiration times without changing
any behavior. Future commits will replace work priority with
expiration times.
* Replace pendingWorkPriority with expiration times
Instead of a priority, a fiber has an expiration time that represents
a point in the future by which it should render.
Pending updates still have priorities so that they can be coalesced.
We use a host config method to read the current time. This commit
implements everything except that method, which currently returns a
constant value. So this just proves that expiration times work the same
as priorities when time is frozen. Subsequent commits will show the
effect of advancing time.
* Triangle Demo should use a class
shouldComponentUpdate was removed from functional components.
Running the demo shows, now that expiration is enabled, the demo does
not starve. (Still won't run smoothly until we add back the ability to
resume interrupted work.)
* Use a magic value for task expiration time
There are a few cases related to sync mode where we need to distinguish
between work that is scheduled as task and work that is treated like
task because it expires. For example, batchedUpdates. We don't want to
perform any work until the end of the batch, regardless of how much
time has elapsed.
* Use current time to calculate expiration time
* Add unit tests for expiration and coalescing
* Delete unnecessary abstraction
* Move performance.now polyfill to ReactDOMFrameScheduling
* Add expiration to fuzz tester
* Expiration nits
- Rename Done -> NoWork
- Use max int32 instead of max safe int
- Use bitwise operations instead of Math functions
* Allow single `on` property for custom elements
* Remove test from ReactDOMComponent-test
* Allow custom attribute named 'on' to be passed
* Check property length instead of comparing strings
* Add a regression test for #10906
* Turn while conditions into breaks without changing the logic
This will be easier to follow when we add more code there.
* var => const/let
So that I can add a block scoped variable.
* Check alternates when comparing to the common ancestor
This is the actual bugfix.
* Pass parent type and props to insert/delete hydration warning hooks
For this to work, we need to split the API into a container and normal
version. Since the root doesn't have a type nor props.
* Ignore SSR warning using explicit suppressHydrationWarning option
This lets you ignore the warning on a single element and its direct child
content. This is useful for simple fields that you're expecting to fail
such as time stamps.
Note that this still won't patch up such content so it'll remain
inconsistent. It's also not suitable for nested complex content that may
change.
* Suppress warning of inserted/deleted direct children
* Add fixture testing hydration warning
Also fixing the render->hydrate API change in the fixture
* Add hooks when text hydration doesn't match up
The purpose of these hooks is to pass the parent context to them. I don't
want to do that in the normal hydrateTextInstance hooks since this is
only used in DEV. This is also in line with what happens if there is no
text instance at all and we invoke didNotFindHydratableTextInstance.
* Move mismatch text hydration warning to the new hooks
This lets us ignore this call when we have parent props available and
the suppression flag is set.
* Inject the right event emitter
Previously this was injecting the ReactNativeEventEmitter even though
we want the ReactNativeRTEventEmitter.
RCTEventEmitter is also just an abstraction around BatchedBridge that
registers a single name. We can't register more than one with it. Removed
that abstraction for now so we don't have to add it back into the RN repo.
* Unify appendChildToDetachedParent and appendChild, separate root
Merge appendChildToDetachedParent and appendChild. We don't need the distinction.
We do however need a separate notion for the root container.
Calling this `appendChildToContext` since Context has a meaning here.
* Add a simple shallow comparison so that we don't send updates for equal props
This still sends all props if any differs. Not sure we'll want that but I
think so.
* Add BatchedBridge to bundle externals
* Lint
* Added check to deduplicate function type warning calls on each component type
* Added test to check that 'function type as React child' warning is deduplicated correctly by component type
* Ran prettier on added code
* Modified test checking deduplication of 'Functions are not valid as a React child' warning so it will check against rerendering component now
* Deleted docs folder
* Deleted www folder
* Remove Netlify website build command
* Removed refs to docs and www from ESlint config
* Removed refs to www/docs from Flow config
* Removed unnecessary .gitignore config
* Updated license check to remove refs to docs
* Removed gh-pages specific portions of Circle build scripts
There may be more that we can remove (eg set_up_github_keys.sh) but I'm not positive
* Removed docs specific license
When testing range input change events, clicking the knob would cause
it to move if the click region wasn't precisely on the center of the
knob.
This is annoying! This commit adds a button to focus the range input
knob and takes a small pass at styling buttons.
A label would work here too, however it does not generate a focus ring
in all browsers.
* Rename rootNodeID -> tag
* Process RT props before forwarding them along
This is needed because the children prop can't be serialized.
Also, some minor placeholder for events.
* Add regression test for CR-insensitive hydration
* Normalize CR when comparing server HTML to DOM
* Move tests in the file
* Add a failing test for comparing attributes
* Normalize CR for attributes too
* Add a test case for CR in dangerouslySetInnerHTML
* Undo the fix per feedback
* Change the fix to be DEV-only and still patch up LF -> CR
* Remove the dangerouslySetInnerHTML test
It's always going to "pass" because we normalize HTML anyway.
Except that it won't pass because we intentionally don't patch up dangerouslyInnerHTML.
* Fix issue that Flow failed to catch
* Add null character tests
* Normalize both client and server value for the warning
* Fix the bug
* Normalize replacement character away as well
* Fix outdated comment
* Add a failing test for text nodes within components
* Reset the text node flag only when emitting tags
This ensures we don't reset it when we exit components that return strings.
* Add a failing test for a more complex tree
* Also reset text flag when emitting a footer
This fixes the {'a'}</div>{'b'} case and prevents an unnecessary comment before 'b'.
We heard from Chrome engineers that creating too many Range objects slows down Chrome because it needs to keep track of all of them for the case that anchor/focus nodes get removed from the document. We can just implement this calculation without ranges anyway.
jsdom doesn't support Range objects, but I copied the fuzz test code into my browser and manually compared it against our old implementation https://gist.github.com/sophiebits/2e6d571f4f10f33b62ea138a6e9c265c; with 200,000 trials no differences were found.
This is an experimental new protocol for some experiments we want to play
with. To make that easier, I'm just going to fork it.
This experiment won't use the event system so I by-pass it and just invoke
functions on the props object for now.
I also fork the UIManager into a new RTManager.
* style(docsearch): add cursor + logo
fixes#10965
Not completely convinced about the cursor colour, but I couldn't really find a better one, cc @joecritch
* fix margin
* style(docsearch): add cursor + logo
fixes#10965
Not completely convinced about the cursor colour, but I couldn't really find a better one, cc @joecritch
* padding
* [Website] Add titles and labels to iframes and images on Community pages
**what is the change?:**
- add titles to all iframes
- add alt tags to images
- add `aria-label` to some links which only have images as contents.
**why make this change?:**
Based on warnings thrown by aXe a11y audit of those pages
**test plan:**
Manual testing
**issue:**
None
* remove redundant alt tags
These were broken after 16 was tagged as `latest` on npm. This fixes that problem, and also adds two template options: one for React 16 and one for React 15. I figure we should provide both for now, since there's still a lot of 15.x users.
This documentation change clarifies how the method `tick()` relates to the example given in the State and Lifecycle documentation. Why this change is necessary is because it may be confusing for beginners who may mistake `tick()` to be a lifecycle API hook. To clarify, the verbiage is changed so that it becomes more clear that the method is specific to the component and not the API.
* Use ES6 module instead of commonJS
As far as I know, we're using ES6 modules throughout the docs. For the sake of consistency :)
* Convert all CommonJS requires to ES6 module
removing the old mention of license for examples. since there is no examples in the repository and also the license for them was deleted [here](#10890)
* [Gatsby docs a11y] Add `aria-label` to search input
**what is the change?:**
See title.
**why make this change?:**
There was no label on this input, and screen readers might not have been
able to identify it's purpose.
[The `placeholder` doesn't count as a label.](http://a11yproject.com/posts/placeholder-input-elements/)
**test plan:**
Manually inspected the HTML in the devtools, and ran the aXe a11y audit
tool, and the warning generated by aXe was gone.
**issue:**
Checklist item on list of docs a11y issues -
https://github.com/bvaughn/react/wiki/Gatsby-A11y-Fixes
* [Gatsby Docs a11y] Increase contrast of 'installation' page tabs
**what is the change?:**
Change the dark blue used for the text/background of the tabs on the
'installation' page to a slightly darker blue, which we were already
using for the 'focus' style of the tabs. It looked a bit weird before,
imo, when the 'focus' was darker.
Now the 'focus' style just lightens the border to the new signature
blue.
**why make this change?:**
To add enough contrast that folks who see colors differently can still
decipher the writing on the tabs on this page.
We plan to refactor this page and remove the tabs soon, so not too
worried about making this fix perfect.
**test plan:**
Manual testing - loaded the page and it looks ok, and ran aXe a11y
audit, no more warnings about contrast. :)
(Flarnie will insert a screenshot)
**issue:**
checklist item on https://github.com/bvaughn/react/wiki/Gatsby-A11y-Fixes
* Add a failing test that prints "null" in the warning instead of the stack
* Don't reset the current fiber during reconciliation
It should only be reset when we stop doing work.
Otherwise, any warnings after the reset will lose the component stack.
The reset in getMaskedContext() was completely unnecessary.
It is always called with the same fiber as the current work in progress.
Therefore, I add a DEV-only warning assertion to ensure we don't regress, and remove the reset.
The reset in processChildContext() is necessary because it can be called outside of reconciliation.
Unfortunately, we have to keep this hack in until we can remove unstable_renderSubtreeIntoContainer().
To work around it, I restore the previous fiber instead of resetting.
* Decouple setting the current fiber and phase
These are two distinct actions.
This helps make it clearer when we're actually changing the current pointer.
I'm also removing an overengineered hack I previously added for unstable_renderSubtreeIntoContainer. It's not necessary now that we don't null the pointer all the time.
This makes the code more straightforward.
* Centralize the pointer updates in the scheduler
* Fix for createHTMLDocument API specific to IE11
The createHTMLDocument API title parameter is not optional in IE while other browsers don't care IE11 will throw if an argument is not passed. This only impacts react.dom.development not react.dom.production.
* Tweak
Adds a new docs website, built with Gatsby JS, to replace the old Jekyll site. Source code for the new site lives in /www (although markdown and YML data still comes from the legacy /docs folder).
Changes to either markdown or website source code can be previewed on Netlify. The react-js bot should automatically add comments to each PR with preview links. (This preview is generated by running the newly-added yarn build:docs command in the root package.json.)
The majority of the changes in this PR are contained within the new /www directory. However some minor modifications have been made to existing content in the /docs directory:
* Modified frontmatter author block to always be an array
* Small markdown formatting tweaks
* Remove allowTransparency attribute
`allowtransparency` is an Internet Explorer-only attribute that
controls the background transparency of an iFrame. When set to true,
it respects the background color of the iFrame. When set to false, it
sets the background color to that of the document.
This feature was removed in IE9 - falling out of React's support
commitment.
Developers that have somehow figured out how to get IE8 to work with
React 16.x can still use `allowtransparency="true"`, since React now
supports unrecognized attributes.
* Use correct attribute script location
* Use new UMD bundles in attribute fixtures
* Update attribute snapshot
* Blank for CI
* Add link to React community on Hashnode
React community on Hashnode has more than 10K followers. It'd be nice if we can point developers to this place.
* Consistency in heading + remove the sales pitch-y bit
* Update portals docs "child" language
This commit changes the portals docs so that the language of the Parent
no longer feels like it is missing a word with "is not a child the div
with onClick handler" and replaces that with "is not a direct child of
the div with the onClick handler".
closes#10868
* Update portals.md
* "Write Code in Your Editor": Split step 5 into 2 steps
To me it wasn't clear (enough) that I had to copy the file's content from [here](https://codepen.io/gaearon/pen/oWWQNa?editors=0010) *and* add the three lines to the top.
* Update tutorial.md
* Update Portals Documentation
Correct some grammar to be more explicit and clear. Update example CodePen to better match code found in documentation. Update code example styles to match other code examples (ie. 'State and Lifecycle', 'Handling Events').
* Clean up comment to be accurate to example
There was a small comment overlooked when reviewing the documentation. This fixes it to be accurate to the example as well as grammatically correct.
* Update portals.md
* More fixes
* Add ReactTestRenderer documentations
* Add TestRenderer documentations
* TestRenderer is not experiment
* Add a link for jsdom
* Use ES Modules syntax
* Twaek
* Add a Link component
* Use Jest assertions
* Move a documentation for createNodeMock to Idea section
* Renamed
* Tweak
* Rename
* More explicit
* Add a usecase for createNodeMock
Did find and replace in TextMate.
```
find: (?:( \*)( ))?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+(?:this source tree|the same directory)\.$
replace: $1$2Copyright (c) $3-present, Facebook, Inc.\n$1\n$1$2This source code is licensed under the MIT license found in the\n$1$2LICENSE file in the root directory of this source tree.
```
* First shot at updating changelog for 16.0
**what is the change?:**
Added an 'unreleased' section to the changelog with info from https://github.com/facebook/react/issues/10294
**why make this change?:**
To get things set for the 16.0 release.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/8854
* Fix typos and formatting errors in changelog
* Add requestAnimationFrame and remove "New helpful warnings"
**what is the change?:**
In response to helpful code review -
- Add mention of dependency on `requestAnimationFrame` and need to
polyfill that as well as `Map` and `Set`
- Remove "New helpful warnings" section; it was incomplete, and there
are so many new and updated warnings that it might not be reasonable
to cover them in the changelog.
**why make this change?:**
Accuracy
**test plan:**
Visual inspection
**issue:**
issue #8854
* Improve wording
* Improve wording and fix missing links
* Add backticks to file names & code; wording tweak
* Break "Major Changes" into "New Feature" and "Breaking Changes"
* Add server side render changes to 16.0 changelog
* Change gist link from mine to gaearons
* Add note about returning fragments
* fix misc nits
* Misc. formatting/wording fixes to changelog
**what is the change?:**
Thanks to the kind code review comments of @gaearon and @nhunzaker we
have
- removed the non-deterministic bold styling on some bullet points
- improved wording of the bullet points for portals, attribute whitelist
changes, and server rendering changes
- Add note about error boundaries including a breaking change to error
handling behavior.
- punctuation and capitalization fixes
**why make this change?:**
Clarity and correctness
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/8854
* fix broken link
Prevents a push/pop mismatch when bailing out on HostRoots. This is
currently unobservable, because HostRoots never bail out on low
priority, but this does happen with prerendering.
I found this when rebasing #10624 on top of master.
* ReactNativeBridgeEventPlugin supports lazily-registered event types
This accompanies changes on the native side to now specify which event types each view manager supports as part of its view config. Ultimately the goal is to lazily initialize view managers on the native side as well.
* Bubbling and direct attributes are optional on view config
This should help ease transition for pre-existing JS-only components.
* Freeze bundle configs before the build
This ensures we don't accidentally mutate it.
* Fix config mutation during the build uncovered by freeze
* Fix FB isomorphic build by marking object-assign as an external
* Bye bye redundant check
The tutorial hints that a change can be made that allows you to go back
in time then click in the board to create a new entry, but the change is
already present in the example code.
This fix removes the hint and re-words the explanation of the change the
example code is making.
After realizing this was the second time I've visited this exact page within a year and second guessing myself that the `textInput` ref isn't actually the `<input />` element. I decided to attempt to make this a little more explicit; you are actually accessing the method on the child class and not the `focus` method on the dom input element. Having them named the same caused some confusion.
* Improve displayName documentation
* displayName docs: higher-order component lowercased to stay consistent with the rest of the docs
* Rephrase displayName reference docs
NOTE: This commit is not exactly what went out as RC2 because I forgot to push. See tag v16.0.0-rc.2 (d06680ea9e) instead. Bumping the version here so we're at the right place though.
* Add license headers on build bundles
* Add the filename IMO to header
* Preserve headers in production bundles
* Use ECMASCRIPT5_STRICT to preserve "use strict"
* Add missing dependencies in `art` fixture, update `yarn.lock`
**what is the change?:**
See title
**why make this change?:**
We want the `art` fixture to be working so that we can test the latest
version of `react-art`.
**test plan:**
Built and inspected the fixture manually
**issue:**
Prepping for 16.0RC release - https://github.com/facebook/react/issues/10623
* ran prettier
* Added invariant check for native dispatching an unsupported event type
This prevents a case of a silent failure when native dispatches an event that JavaScript does not know how to handle.
* Added iOS direct event type 'onSnapshotReady'
This is used for snapshot testing.
* Import react-art/lib/{Circle,Rectangle,Wedge}.art
Copied from react-art@0.15.1 built files.
* Changes to built files to make ART shapes work
Test Plan: Opened the fixture. React logo shows up with its normal dot, now rendered by a `<Circle />`.
**what is the change?:**
Updates to the latest allowed versions for two dependencies.
`yarn upgrade 'fbjs@^0.8.9'`
and
`yarn upgrade 'prop-types@^15.5.8'`
**why make this change?:**
Prepping for the 16.0 RC, we want to have a reproducible build that is
as close as possible to what new users will get when installing React.
**test plan:**
`yarn && yarn build && yarn test`
**issue:**
https://github.com/facebook/react/issues/10623
* Add AgentConf 2018
We are having another edition of the AgentConf in 2018, which has again a strong focus on react, and we'll be skiing again 😎 Last year's PR for reference: https://github.com/facebook/react/pull/8196
* Update conferences.md
* WIP
* WIP Add the rest of the tests for what we expect re: unknown attributes
**what is the change?:**
Adds tests for the following behavior -
- Numbers and booleans should be converted to strings, and not warn
- NaN, Symbols, functions, and objects should be converted to strings,
and *should* warn
Going to add tests for the not-warning behavior in a follow-up.
These tests are not entirely passing - we either need to change what we
expect or change the behavior.
**why make this change?:**
Gets everyone on the same page about expected behavior, and codifies it
in a maintainable way
**test plan:**
`yarn test src/renderers/dom/shared/__tests__/ReactDOMAttribute-test.js`
**issue:**
https://github.com/facebook/react/issues/10399
* WIP Add check that we *don't* warn when handling some unknown attributes
**what is the change?:**
We are testing the behavior of unknown attributes, which has changed
since React 15.
We want to *not* warn for the following cases -
- null
- undefined
- missing
- strings
- numbers
- booleans
**why make this change?:**
We want to verify that warnings don't get fired at the wrong time.
**test plan:**
`yarn test src/renderers/dom/shared/__tests__/ReactDOMAttribute-test.js`
**issue:**
https://github.com/facebook/react/issues/10399
* ran prettier
* Symbols and functions passed to unknown attributes should remove and warn
* Abstract tests a bit to make them easier to read
* Remove Markdown from test names
I don't think we use this convention anywhere.
* Add an assertion for NaN warning message
* Update ReactDOMAttribute test based on attribute fixture
**what is the change?:**
- booleans don't get stringified
- some warnings have changed since we originally wrote this
**why make this change?:**
The attribute behavior is finalized and now we can test it :D
I also found it handy to have a row with a truly unknown attribute, so
added "imaginaryFriend".
**test plan:**
`yarn test src/renderers/dom/shared/__tests__/ReactDOMAttribute-test.js`
and comparing the tests to the attribute table
**issue:**
https://github.com/facebook/react/issues/10399
* remove imaginaryFriend to resolve conflict
* ran prettier
* Default to first non-disabled option for select
Instead of defaulting to the first option for a select element, which could be a disabled option, we find the first non-disabled option available while we looping through the options. If no option matches, set the first non-disabled option as selected.
* Add ReactDOMSelect test for defaulting to non-disabled options
* Add test fixtures to cover disabled selected options
* Fix bad merge
* Adding Crowdin config file to master repo
* Updated to include additional files while ignoring localized community files stored on github
* Additional files ignored
* Included additional files in root docs directory
* ReactNative doesn't query UIManager for native event types
This is a pre-req to unblock Prepack optimiations for ReactNative apps
* Replaced mock ReactNativeEventTypes with mock Platform
* Added Platform.OS to RN host hooks Flow types
* ReactNative supports lazy view registration
Don't react viewConfig from UIManager when a view is registered, but only when it is used for the first time. This will help unblock Prepack optimizations for RN views.
* Added new lazy-creation method for native views
Also exposed the native view config registry to allow invalid/unsupported host components to fall back to RCTView
* Removed ReactNativeViewConfigRegistry from RN __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED
After discussion with Spencer Ahrens and Andy Street, it seems the early fallback behavior was mostly for the early days of Ads Manager when Android didn't yet support a lot of the view types. It should be okay now to use an invarient/redbox instead for unsupported views.
* Removed non-lazy createReactNativeComponentClass impl
There are only a handful of components with JavaScript-defined view configs. It's probably worth making them use the new lazy/async interface as well to be more consistent.
* Remove HTMLPropertyConfig entries for non-boolean values
When we originally removed attributes from the whitelist, we assumed a
few attributes were string booleans, but they are not:
Autocomplete ("on", "off")
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#autocomplete
Autocapitalize ("none", "sentence", "words", ...)
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#autocapitalize
Autocorrect ("on", "off")
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#autocorrect
Autosave (string)
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#autosave
* Only HAS_BOOLEAN_VALUE attribute flag can assign booleans
* Use a non-boolean attribute in object assignment tests
* Add HAS_STRING_BOOLEAN_VALUE attribute flag
* Fix boolean tests, add boolean warning.
* Reserved props should allow booleans
* Remove outdated comments
* Style tweaks
* Don't treat dashed SVG tags as custom elements
* SVG elements like font-face are not custom attributes
- Adds exceptions to isCustomAttribute for dashed SVG elements
- Use consistent custom element check across all modules
* Move namespace check to isCustomAttribute. Add caveat for stack.
* Remove unused namespace variable assignment
* Fix the DEV-only whitelist
* Don't read property twice
* Ignore and warn about non-string `is` attribute
* Blacklist "aria" and "data" attributes
* Don't pass unknown on* attributes through
* Remove dead code
* Avoid accessing namespace when possible
* Drop .only in ReactDOMComponent-test
* Make isCustomComponent logic more solid
* Do attribute name check earlier
* Fix fbjs import
* Revert unintentional edit
* Re-allow "data" attribute
We intentionally allowed it.
* Use stricter check when attaching events
* Pass SVG boolean attributes with correct casing
* Fix the test
* Undo the SVG dashed-name fix
Per conversation with @sebmarkbage we decided that the fix is too complicated, and it's unfortunate it depends on the DOM element.
It's only relevant for super rare tags that aren't even working consistently across browsers so we'll leave it unfixed for now.
* Prettier
* Fix lint
* Fix flow
* Pass "aria" through but still warn
* Remove special cases for onfocusin, onfocusout
They're covered by event handler code now.
* Add a more specific warning for unknown events
* Pass badly cased React attributes through with warning
We track nested updates to simulate a stack overflow error and prevent
infinite loops. Every time we commit a tree, we increment a counter.
This works if you only have one tree, but if you update many separate
trees, it creates a false negative.
The fix is to reset the counter whenever we switch trees.
* Load ReactDOMServer into attribute table
* Highlight differences between DOM and server renderer
* Use SSR behavior when comparing behavior across renderers
* Use less severe color if SSR differences are only due to warnings
* Ensure result node's tagName matches what's expected
* Throw on unexpected HTMLUnknownElement
* Add ability to "complete" rows and store state in localStorage
* Sort groups based on size
Also: include tagName and containerTagName in info object.
* Tweak sort order
* Update flow-bin to 0.53.1
* Ran flow-upgrade utility
Manually corrected a few over-eager cases where it tried to replace our ReactElement sub-type.
* Replaced a couple of React.Element types with React
* Removed temporary ReactComponent/ReactComponent Flow types
* Prettier
* Replaced React with React based on Dan's PR feedback
Also canonicalize object results (since these SVG properties are objects).
The canonicalized format is what we compare against.
(This will cause unknown objects to show up as unchanged.)
* Add alphabetical and rev-alphabetical sorting
This is just an initial convenient way to jump to the top or bottom of
the list.
Next we will add a sorting which groups rows together if their behavior
pattern is the same.
* Add sorting to group the rows by behavior pattern
**what is the change?:**
Another sorting option - if the content of a row is the same, it takes
those rows and groups them together.
**why make this change?:**
This will help us find groups of attributes that behave similarly.
**test plan:**
manual testing
* rename variable to be more clear
* [WIP] Table of attribute behavior
* getAttribute helper
* add getters for attributes V-Z
* More special cases
* Add getters for more attributes
* Add tagName to attribute config
* Switch default accessor to getProperty instead of getAttribute
* Add containerTagName and tagName config
* Compare result to default value
* Add overrideStringValue config option
* add section for Sebastian and update a couple more attributes
* 'array with string' should use string override, too
* Add additional value types
Strings on, off, true, false
* more attribute updates
* More attributes
* Remove old directory
* add more attribute configs
* More attributes
* just a couple more attribute updates
* More attributes
* Fix the seb parts
* Fix the seb parts
# Conflicts:
# scripts/attribute-behavior/src/App.js
* More attributes
* Prettier
* More attributes
* More attributes
* Fix some bugs in seb's set
* Fix the rest of flarnie's section
* More attributes
* Prettier
* Finish my section (Andrew)
* Compare against UMD build of master
Once we get past MVP stage we can hook this up to the build system so
these files are automatically copied over.
* Fix attributes that don't have compatible properties
Avoid all undefined reads.
* Test multiple input types
Tests different input types and valueAsNumber property. This value is often
NaN. To compare that we also need to switch to Object.is.
* Ignore checked in copies of React 15 bundles in attribute fixture
**what is the change?:**
We checked in bundles of React v15 to run comparisons of attribute
behavior on DOM elements between 15 and 16.
This commit tells prettier and eslint to ignore those files, and fixes a
prettier lint in one other file from that fixture.
**why make this change?:**
To get CI passing.
**test plan:**
`yarn prettier` doesn't change anything, eslint passes
**issue:**
* update README for attribute table fixture
* run prettier again
When the feature flag enableAsyncSubtreeAPI is true,
React.unstable_AsyncComponent creates an async subtree. When it's false,
it behaves like a normal, sync React component. We use this flag in www
as a fail safe so that if we ship an async bug, we can set the flag to
false and revert back to sync mode.
For open source, we should enable the feature flag.
* Add early warning for non-functional event listeners
* Use functional listeners in ReactDOMComponent test
To avoid triggering the non-functional event listener component
* spy on console.error in non-function EventPluginHub test
This should warn from ReactDOMFiberComponent, but we just ignore it here
* Remove redundant check for listener
* Add expectation for non-functional listener warning in EventPluginHub
* Hoist listener typeof check in hot paths
* Include stack addendum in non-functional listener warning
* Make it pretty
* Remove it.onnly from ReactDOMFiber test
* Fix message
* Update expected message
* Change invariant message to match the new style
* Fix remaining warning
This reverts the meaningful (src, non-test) part of commit 3bc64327f0 since we've reverted the commit it depended on in 18083a8a73. I don't fully understand the negative implications of leaving this unreverted but it sounds like consensus is that it's safer to revert.
I left the new fixture and verified it works correctly in Chrome 62 Mac, as well as the jest tests passing.
* Add missing single-word attributes to property warning list
* Alphabetize svg and html configs in possible names
* Add basic test coverage for known single word attributes
* Add note about including whitelist properites in `possibleStandardNames
* Also add attribute sync comment to possibleStandardNames
* add renderer id to react-devtools injection
* rename renderer id to rendererPackageName in react-dom injection
* add rendererPackageName to react-native entries
**what is the change?:**
This reverts 0b220d0f04
Which was part of https://github.com/facebook/react/pull/10238
**why make this change?:**
When trying to sync the latest React with FB's codebase, we had failing
integration tests.
It looks like they are running with an old version of Chrome and there
is something related to file upload that fails when these polyfills are
missing.
For now we'd like to revert this to unblock syncing, but it's worth
revisiting this change to try and add some polyfill for FB and remove it
from React, or to fix whatever the specific issue was with our file
upload error.
**test plan:**
`yarn test` and also built and played with the `dom` and `packaging`
fixtures
* Add invariant check for composite components to event simulation test utils
* Change simulate variable names from domComponentOrNode to domNode, language for new simulate invariant, and add space in existing invariant
* Update test name
* Update test for invariant with shallow rendering
* Update text for existing invariant and change comments to reflect change to only domNode usage
* Update text for existing invariant to reflect syntax with new invariant
* Update ReactTestUtilsEntry.js
* Update React element invariant to reflect usage with shallow rendering
* Move Simulate-related tests into Simulate block
* Run prettier
* Add babel transform for object getters
**what is the change?:**
We were not transforming object getters[1], and our new TestRenderer
uses one.[2]
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get
[2]: https://github.com/facebook/react/blob/master/src/renderers/testing/ReactTestRendererFiberEntry.js#L569
**why make this change?:**
Our internal build system was not supporting object getters.
**test plan:**
`yarn build && yarn test`
Also built and opened the 'packaging' fixture.
Honestly I'm not sure what else to test, this seems pretty low risk.
**issue:**
None opened yet
* Replace object getter with `Object.defineProperty` in TestRenderer
**what is the change?:**
Replaces an Object Getter [1] with `Object.defineProperty`.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get
**why make this change?:**
Our internal build system does not support object getters.
**test plan:**
We should do follow-up work to ensure that this doesn't come up again -
we can't commit code which uses object getters.
**issue:**
No issue opened yet
* Tweak the Object.defineProperty call in test renderer to make flow pass
**what is the change?:**
- switched from `Object.defineProperties` to `Object.defineProperty`
- set some undefined properties to get flow to pass
**why make this change?:**
- Flow doesn't seem to play nicely with `Object.defineProperty/ies`
calls, specifically when you implement `get` and `set` methods.
See https://github.com/facebook/flow/issues/1336
- Switched from `properties` to `property` because it seems more
conventional in our codebase to use `property`, and I'm only setting
one anyway.
**test plan:**
`flow`
**issue:**
no issue
* More flow type tweaking
**what is the change?:**
Forced the typing of an argument to 'Object.defineProperty' to be
'Object' to avoid an issue with Flow.
**why make this change?:**
To get tests passing and flow passing.
**test plan:**
`flow && yarn test`
**issue:**
* Throw error to warn of mistaken loading of prod + dev React bundles
**what is the change?:**
Credit to @gaearon for coming up with a clever way to check for this. :)
I mainly just did the manual testing and fixed a couple of typos in his
idea.
I'd like to do a follow-up PR to add a link and a page explaining this
issue more and suggesting how to fix it.
**why make this change?:**
We want to warn for an unfortunate gotcha for
the following situation -
1. Wanting to shrink their JS bundle, an engineer runs it through
'uglifyjs' or some other minifier. They assume this will also do
dead-code-elimination, but the 'prod' and 'dev' checks are not
envified yet and dev-only code does not get removed.
2. Then they run it through browserify's 'envify' or some other tool to
change all calls to 'process.env.NODE_ENV' to "production". This
makes their code ready to ship, except the 'dev' only dead code is
still in the bundle. Their bundle is twice as large as it needs to
be, due to the dead code.
This was a problem with the old build system before, but with our new
build system output it's possible to detect and throw an informative
error in this case.
**test plan:**
1. run the build in react as usual; `yarn build`
2. manually run 'uglifyjs -mt' on 'build/packages/react/index.js' to
simulate mistakenly minifying React before env variables are
resolved, which skips dead code elimination.
3. run the fixtures build - `cd fixtures/packaging && node
./build-all.js && serve ../..`
4. Visit just the production browserify fixture -
http://localhost:5000/fixtures/packaging/browserify/prod/
5. You should see the error thrown indicating this problem has occurred.
(Flarnie will insert a screenshot)
6. Do the above steps with NO uglifyjs step, and verify that no error is
thrown. When there is no minification applied, we don't assume that
this mix-up has occurred.
(Flarnie will insert a screenshot)
**issue:**
fixes#9589
* Remove extra 'prod' env. check and add link to docs in error message
**what is the change?:**
Based on helpful feedback from @gaearon
- removed outer check that `process.env.NODE_ENV` is "production" since
we are only calling the `testMinification` method inside of another
check for "production" environment.
- Added an fburl that points to [our current docs on using the production version of React](https://facebook.github.io/react/docs/optimizing-performance.html#use-the-production-build)
**why make this change?:**
To save an extra layer of conditionals and to make the error message
more clear.
**test plan:**
Same test plan as earlier -
1. run the build in react as usual; yarn build
2. manually run 'uglifyjs -mt' on 'build/packages/react/index.js' to
simulate mistakenly minifying React before env variables are
resolved, which skips dead code elimination.
3. run the fixtures build - cd fixtures/packaging && node ./build-all.js && serve ../..
4. Visit just the production browserify fixture -
http://localhost:5000/fixtures/packaging/browserify/prod/
You should see the error thrown indicating this problem has occurred.
(Flarnie will insert a screenshot in comments on the PR)
6. Do the above steps with NO uglifyjs step, and verify that no error is thrown. When there is no minification applied, we don't assume that this mix-up has occurred.
(Flarnie will insert a screenshot in the comments on the PR.)
**issue:**
https://github.com/facebook/react/issues/9589
* WIP fix and test 'testMinificationUsedDCE' method
**what is the change?:**
- Instead of looking for one match when having the method inspect it's
own source, we look for two matches, because the search itself will be
a match.
- WIP moving this method into another file and testing it.
Next steps:
- Figure out why the babel.transform call is not actually minifying the
code
- Add tests for uglifyjs
- Update build process so that this file can be accessed from
`packages/react/index.js`
**why make this change?:**
- We had a bug in the 'testMinification' method, and I thought the name
could be more clear. I fixed the code and also changed the name.
- In order to avoid other bugs and keep this code working in the future
we'd like to add a unit test for this method. Using the npm modules
for 'uglifyjs' and 'babel'/'babili' we should be able to actually test
how this method will work when minified with different configurations.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/9589
* Add babeli and uglifyjs as dev-only dependencies
**what is the change?:**
See commit title
**why make this change?:**
In order to test that we are correctly detecting different minification
situations, we are using these modules in a test.
**test plan:**
NA
**issue:**
https://github.com/facebook/react/issues/9589
* Fix typo and add 'uglifyjs' tests
**what is the change?:**
There was a mix-up in the conditional in 'testMinificationUsedDCE' and
this fixes it.
The great new tests we added caught the typo. :)
Next steps:
- get the tests for 'babili' working
- update build scripts so that this the 'testMinificationUsedDCE'
module is available from 'packages/react/index.js'
**why make this change?:**
We want to modularize 'testMinificationUsedDCE' and test it.
This verifies that the method warns when `uglifyjs` is used to minify
but dead code elimination is not done, in a production environment.
Generally this is a 'gotcha' which we want to warn folks aboug.
**test plan:**
`yarn test src/shared/utils/__tests__/testMinificationUsedDCE-test.js`
**issue:**
https://github.com/facebook/react/issues/9589
* Run prettier
* var -> const/let
* Require specific version of `uglify-js`
**what is the change?:**
Removed the '^' from the npm package requirement
**why make this change?:**
I am seeing failures in CI that show `uglify-js` is returning different
output there from my local environment. To further debug this I'd like
to run CI with the exact same version of `uglify-js` that I am using
locally.
**test plan:**
push and see what CI does
**issue:**
https://github.com/facebook/react/issues/9589
* Add build step copying testMinificationUsedDCE into build/packages/react/cj
**what is the change?:**
This is a first step - we still need (I think) to process this file to
get it's contents wrapped in an 'iffe'.
Added a step to the build script which copies the source file for the
'testMinificationUsedDCE' module into the 'cjs' directory of our react
package build.
**why make this change?:**
We want this module to be available to the 'index.js' module in this
build.
**test plan:**
Will do manual testing once the build stuff is fully set up.
**issue:**
* Inline 'testMinificationUsedDCE' and remove unit test for now
What:
- Inlines the 'testMinificationUsedDCE' method into
'packages/react/index.js'
- Removes unit test for 'testMinififcationUsedDCE'
- Puts dependencies back the way that they were; should remove extra
dependencies that were added for the unit test.
Why:
- It would add complexity to the build process to add another file to
the 'build/packages/react/cjs' folder, and that is the only way to
pull this out and test it. So instead we are inlining this.
* Revert unintentional changes to dependency versions, variable placing
**what is the change?:**
- We had updated and added some dependencies, but ended up reverting
this in a previous commit. The `yarn.lock` and `package.json` needed
updated still though.
- There is a call to `Function.toString` which we wanted to wrap in a
`try/catch` block.
**why make this change?:**
To remove unrelated dependency changes and increase the safety of the
`Function.toString` call.
**test plan:**
Manual testing again
**issue:**
https://github.com/facebook/react/issues/9589
* Allow custom attributes. Add flag to toggle custom attribute behavior
* Update custom attribute logic
- Only allow string attributes
- Remove custom attribute feature flag
- Add additional tests for data, aria, and custom attributes
* Allow numbers and booleans custom attributes. Cut isCustomAttribute
* Cover objects with custom attributes in warning test
* Rename DOMProperty.isWriteable to shouldSetAttribute
* Rework conditions in shouldSetProperty to avoid edge cases
* Update unknown property warning to include custom attribute information
* Remove ref and key from reserved props
* Ensure SSR test coverage for DOMProperty injections
* Add ajaxify attribute for internal FB support
* Ajaxify is a stringifiable object attribute
* Remove non-case sensitive standard attributes. Make ARIA hook dev only.
* Update test name for custom attributes on custom elements
* Remove SSR custom injection test
* Remove case sensitive props
* Remove onAfterResetModules hooks in SSR render tests
* Add back a few attributes and explain why they are needed
* Remove possibleStandardNames from DOMProperty.js
* Fix typo in HTMLPropertyConfig comment
* Remove duplicative comment
* Add back loop boolean property
* Do not allow assignment of attributes that are aliased
* Update custom attribute test to check value, not just presence
* Address case where class is assigned as an attribute on custom elements. Improve SSR tests
* Cover cases where className and for are given to custom elements
* Remove unnecessary spys on console.error. Reduce extra space in tests
* Cover cased custom attributes in SSR tests
* Custom attributes are case sensitive
* Allow uppercase letters in custom attributes. Address associated edge cases
* Allow improperly cased aliased attributes. Add additional tests
* Handle special properties like onFocusOut
* Add some comments to document where casing matters. Remove DOMPropertyNames
* Fix spelling mistake in ajaxify HTML property comment
* Make ARIA enforcement dev-only
* Remove alias test that covers multiple aliases for one property
* Fix typo in comment
* Build SVG aliases dynamically
* Remove unused DOMPropertyNames reference
* Do not translate bad casings of aliased attributes
- classname writes to the DOM as classname
- class does not write to the DOM
- cLASS does not write to the DOM
- arabic-form does not write to the DOM
* Revise the way custom booleans are treated
- Custom attributes can not have boolean values unless they are aria
or data attributes
- Attributes with boolean values have been added back to the whitelist
- Warnings now exclude booleans from supported types
- Associated test coverage
* Add developer warnings for NaN and ARIA hooks
* Use string comparison instead of regex to check for data and aria attributes.
* Warn about unsupported properties without case sensitivity
* Remove attributes that are updated to invalid values
* Support object property values with toString methods. Allow boolean props to coerce objects
* Add back ajaxify test
* Address bad references in ReactDOMComponent-test. Format.
* Revert changes to the docs
We'll update them separately
* Allow all objects and pass incorrect aliases
The prior message was a bit wordy and didn't cover all cases (like the one we discovered while researching #10441).
We can use the new URL to explain background info on the DEV-mode technique we're using in addition to common fixes (eg crossorigin attribute for CDN scripts and Webpack devtools settings). Putting this information behind a link will allow us to more easily edit it in the future as common causes for this issue change.
Resolves#10441
* Add test for nested controlled selects
The failure repros only when two events are fired sequentially, where the second
event is what updates the value.
* Add failure case to DOM select fixture
* Use virtual event target for change event instead of native target
Ensures that we use the same node to make decisions instead of two like
we do now.
This will cause restore to be called or not called consistently.
* Pass native event target to the event
We normally pass the native event target to the event object. This ensures
that we do the same thing here.
We still want to schedule a "restore" on the virtual target though since
those are the only nodes known to React.
* Find callsites that would call toString() if we pass attributes through
* Warn for all object unknown props, not just 'toString' ones
fixing this as per Sebastian's feedback, because we want to find all
objects and not just ones with 'toString' defined. Because there may be
other corner cases and issues that are revealed.
* Wrap warning() calls in a DEV check for RN_* builds too.
* Wrapped several warning() imports and calls in if-DEV checks.
* Removed a useless variable (allTypesByEventName) and loop from ReactNativeBridgeEventPlugin.
* Use GCC instead of Uglify for UMD/NODE bundles
* Prettier run
* Fixes fixtures that were alterated by Pretter and trailing function commas
* prettier on prettier
* updated prettier config
* altered prettier config slightly
* Reverted prettier changes
* updated results.json
* made createFiber create a constructed FiberNode object
* updated comment
* satisfying flow and prettier
* better comments :)
* fixes flow error
* updates comment
* converted function constructor to a ES2015 class
* Revert "converted function constructor to a ES2015 class"
This reverts commit c020982c5fe62446667f6f933c834366c3f009b3.
* fixed some merge conflict issues
* Flow....
* removed exact types to make flow pass
* opted for $FlowFixMe instead
* removed exact types to make flow pass
* opted for $FlowFixMe instead
* run prettier
* Don't warn about setState on unmounted when scheduling error recovery
We shouldn't schedule an update on unmounted error boundaries, but we
don't know if a boundary is unmounted until we traverse its parents.
Added an additional argument to scheduleUpdate so we know not to warn
about setState on unmounted components.
* Should be able to unmount an error boundary before it is handled
Fixes the case where an error boundary captures an error, but its
parent is unmounted before we can re-render it. componentDidCatch is
never called, and we don't remove the boundary from our set of
unhandled error boundaries.
We should not assume that if capturedErrors is non-null that we still
have unhandled errors.
* Rewrite DOMPropertyOperations-test in terms of public API
* Add more assertions
I don't understand what the jsdom comments are about since they pass.
* Address review feedback
* Remove PooledClass from FallbackCompositionState
The only module that uses FallbackCompositonState is BeforeInputEventPlugin. The way its structured means there can only be a single instance of FallbackCompositionState at any given time (stored in a local variable at the top-level) so we don't really need pooling here at all. Instead, a single object is now stored in FallbackCompositionState, and access (initializing, reseting, getting data) is gaurded by the exported helper object.
* Use new FallbackCompositionState API in BeforeInputEventPlugin
* Implement event-specific pooling in SyntheticEvent
* Remove PooledClass from TopLevelCallbackBookKeeping
* Update results.json
* Add pooled event test fixtures (#1)
* Fix fixture lint
This prevents the captured error from becoming separated from the component stack if other errors (or console.error calls) are made between them, eg a component errors during unmount.
* Add DOM fixture for cross-origin errors
* Use a custom error object in place of cross-origin errors
Cross-origin errors aren't accessible by React in DEV mode because we
catch errors using a global error handler, in order to preserve the
"Pause on exceptions" behavior of the DevTools. When this happens, we
should use a custom error object that explains what happened.
For uncaught errors, the actual error message is logged to the console
by the browser, so React should skip logging the message again.
* Add test case that demonstrates errors are logged even if they're caught
* Don't double log error messages in DEV
In DEV, the browser always logs errors thrown inside React components,
even if the originating update is wrapped in a try-catch, because of the
dispatchEvent trick used by invokeGuardedCallback. So the error logger
should not log the message again.
* Fix tests
* Change how error is printed in DEV and PROD
In DEV, we don't want to print the stack trace because the browser already always prints it.
We'll just print the component stack now.
In PROD, we used to omit the JS error message. However we *do* want to show it because
if the application swallows the error, the browser will *not* print it. In DEV it works
only because of the fake event trick. So in PROD we will always print the underlying error
by logging the error object directly. This will show both the message and the JS stack.
* Make the wording tighter and emphasize the real error is above
There's a few goals in the rewording:
* Make it tighter using line breaks between sentences.
* Make it slightly less patronizing ("You should fix it" => "You can find its details in an earlier log")
* ^^ This also helps highlight that the real error message and stack is above
* Group subsections: intro (there's an error), component stack, and final addendum about error boundaries
* ^^ Otherwise people might think error boundaries are part of the reason they have an error
* Make it clear "located at" is not the stacktrace. Otherwise it feels confusing. This makes it clearer you should still look for stack trace (with other details) above and introduces the concept of component stack.
* Make the message shorter
* Unused variables
* Fix an error caused by fixing lint
* One more bikeshed
* Fix fixture
* Remove unused file
* Concise wording
* Unused variables
* Upgrade DOM Fixtures
Upgrade to react-scripts v1 and include required polyfills for older
browsers
* Remove ChangeEvent polyfills for unsupported browsers
* Use single entry point for SSR via browser field
* Add server.browser entry point and smoke tests
* Tweak bundle naming
* Fix import
* Re-record
* Fix the robot nits
* Add resetModules for some extra isolation
This avoids strict mode conflicts for certain browsers wrt functions being defined within an if-block.
Also re-added the if-DEV condition for the ReactNative renderer since it was removed for this reason.
FB bundles wrap warning() calls in __DEV__
Split dev-mode transforms into separate parts:
1) umd+cjs+fb: Wrap warning calls with process.env checks
2) umd+cjs: Replace error messages with minified codes
Also updated transforms to use __DEV__ since it transforms to smaller code after stripEnvVariables is run.
Also renamed 'scripts/error-codes/dev-expression-with-codes.js' -> 'scripts/error-codes/replace-invariant-error-codes.js'
This parameter was accidentally omitted before. Leland reported it because it impacts Enzyme.
I also added a basic lifecycle parameter test for shallow renderer.
Fiber doesn't schedule animation callbacks anymore (though it does use
the browser's requestAnimationFrame to polyfill requestIdleCallback).
This removes the rAF export from ReactDOMFrameScheduling, since it's not
being used.
* Remove hydrate() warning about empty container
It used to have false positives for cases where we legitimately don't render anything.
* Use existing constant
* Test empty string case using its parent
* Add ReactDOM.hydrate()
* Deprecate ReactDOM.render() hydration in favor of ReactDOM.hydrate()
* Downgrade the warning level to console.warn()
* Warn when hydrate() is called with empty container
* Don't catch the assertion about missing errors
Previously, even if an error was not thrown, the assertion about this was ignored.
This fix exposes two failing cases in new SSR that weren't failing in Stack.
* Add child context validation to new SSR
This fixes the error cases that were silently failing before but are now exposed.
* fix(*): fix renderToString fails with array type children when react-dom/server render
* Add an integration test that verify renderToString with array type children
* Add integration test to renderToString with array type child
* Update integration test to renderToString with array type child
* fix renderToString fails with array type children when react-dom/server render
* Update integration test to renderToString with array type child
* Add to iterate that are not arrays
* Add the validation react element
* Improve an integration test of server renderToString with array type
* prettier
* prettier
* Make SSR can handle a single array element and nested array
* prettier
* Change integeration test description
* modified: src/renderers/dom/ReactDOMNodeStreamRenderer.js
* Make invariants consistent
* Gate outdated test itself by feature flag
* Change test to make sense both with old and new code
* Test more cases
* Add date time test fixtures
This commit adds a new section for the DOM test fixtures specifically
for date inputs. Additionally, it adds a test case to verify that
correct transference of dates between the `"date"` and
`"datetime-locale"` input types.
* Adjust date parsing to be clearer
The critical semantics are resilient to browser flakiness, so we don't
need this feature test.
Also added comments explaining how invokeGuardedCallback dev works.
* Deduplicate unknown DOM tag warning
* Don't warn about <time> because it is widely used
Other browsers implement it, and Chrome will ship it soon too.
* Use hasOwnProperty
* Fix corner case: hasOwnProperty as a tag
* Update comments to be more correct factually
invokeGuardedCallback is a function we use in place of try-catch
statement. It accepts a function, and if the function throws, it
captures the error. In production, the implementation is a normal try-
catch. In development, we swap out the prod implementation for a special
version designed to preserve "Pause on all exceptions" behavior of the
browser DevTools.
invokeGuardedCallbackDev works by dispatching an event to a dummy DOM
node and calling the provided function inside a handler for that event.
We also attach an error event handler to the window object. If the
function throws, the global event handler is called and we can access
the error.
The global event handler is added and removed right before and after the
fake event is dispatched. But if invokeGuardedCallbackDev is nested --
that is, if it's invoked inside the body of another
invokeGuardedCallbackDev -- multiple error event handlers will attached
simultaneously. We only want the handler that corresponds to the deepest
level to handle the error. So we keep track of a depth counter, and
within the event handler, we only handle the error if the current depth
matches the depth at the time the function was invoked.
The problem that we discovered, and that this PR fixes, is that the
depth counter is local to each renderer. So if you nest separate copies
of invokeGuardedCallback from separate renderers, each renderer will
have its own depth counter, and multiple error handlers will fire for a
single, nested error.
* Reset modules between importing client and server modules in the test
Client and server renderers still share some modules, including injections.
This means they have shared state in this test, potentially missing issues that would occur in real world.
After this change, the client and server modules are completely isolated in the test.
This makes the tests fail due to https://github.com/facebook/react/issues/10265 (a real issue that was missed).
* Don't validate events if no plugins are injected
* Ran prettier over non-modified files to change them
* Fixed output of failing Prettier message to show invalid files
* Failing Prettier command now suggests 'yarn prettier-all'
* Support throwing null
In JavaScript, you can throw values of any type, not just errors. That
includes null. We currently rely on null checks to determine if a user-
provided function has thrown. This refactors our error handling code to
keep track of an explicit boolean flag instead.
* Add DOM fixture test case for break on exception behavior
* preventDefault error events during feature test
We call invokeGuardedCallbackDev at startup as part of a feature test.
But we don't want those errors to log to the console.
* Add throwing null test case
* Use ReactFeatureFlags instead of ReactDOMFeatureFlags
React ART uses this, too.
* Non-errors in error logger
If a non-error is thrown, we'll coerce the value to a string and use
that as the message.
* RFC Add warning for rendering into container that was updated manually
RFC because we still need to tidy this up and verify that all tests
pass.
**what is the change?:**
We want to warn when users render into a container which was manually
emptied or updated outside of React. This can lead to the cryptic error
about not being able to remove a node, or just lead to silent failures
of render. This warning should make things more clear.
Note that this covers the case where the contents of the root container
are manually updated, but does not cover the case where something was
manually updated deeper in the tree.
**why make this change?:**
To maintain parity and increase clarity before releasing v16.0 beta.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
last item under the '16 beta' checklist.
* Add test and tweak check for rendering into manually updated container
STILL TODO: figure out how to skip this warning when the component
renders to a portal.
Unfortunately 'ReactPortal.isPortal(children)' returns false, even in
the failing test where we are rendering to a portal.
**what is the change?:**
- added a test for the case where we call 'ReactDOM.render' with a new
container, using a key or a different type, after the contents of the
first container were messed with outside of React. This case throws,
and now at least there will be an informative warning along with the
error.
- We updated the check to compare the parent of the 'hostInstance' to
the container; this seems less fragile
- tweaked some comments
**why make this change?:**
Continue improving this to make it more final.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Stub our `console.error` in one of the portal tests
**what is the change?:**
See title
**why make this change?:**
See comment in the code
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Skip warning in 'ReactDOMFiberEntry' when mounting to Comment node
**what is the change?:**
We have a warning for cases when the container doesn't match the parent
which we remembered the previously rendered content being rendered into.
We are skipping that warning when you render into a 'comment' node.
**why make this change?:**
Basically, if you render into a 'comment' node, then the parent of the
comment node is the container for your rendered content. We could check
for similarity there but rendering into a comment node seems like a
corner case and I'd rather skip the warning without knowing more about
what could happen in that case.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Improve warning message, remove dedup check, and unmock console.error
**what is the change?:**
Various changes to get this closer to being finished;
- Improved warning message (thanks @spicyj!!!)
- Removed dedup check on warning
- Remove mocking of 'console.error' in portals test
**why make this change?:**
- warning message improvement: communicates better with users
- Remove dedup check: it wasn't important in this case
- Remove mocking of 'console.error'; we don't want to ignore an
inaccurate warning, even for an "unstable" feature.
**test plan:**
`yarn test` -> follow-up commits will fix the remaining tests
**issue:**
issue #8854
* Possible fix for issue of incorrect warning for portal re-render
**what is the change?:**
Add a property to a container which was rendered into using
`ReactDOM.unstable_createPortal`.
**why make this change?:**
We don't want to warn for mismatching container nodes in this case - the
user intentionally rendered into the portal container instead of the
original container.
concerns;
- will this affect React Native badly?
- will this add bloat to the portal code? seems small enough but not
sure.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Fix logic for checking if the host instance container is a portal
**what is the change?:**
When focusing on fixing the warning to not check when we are using
portals, I missed checking for the existence of the host instance parent
before checking if it was a portal. This adds the missing null checks.
**why make this change?:**
To fix a bug that the previous commit introduced.
**test plan:**
`yarn test`
-> follow-up commits fix more of the test failures
**issue:**
https://github.com/facebook/react/issues/8854
* Clean up new tests in ReactDOMFiber-test
**what is the change?:**
- removed extra single quotes, downgrade double quotes to single
- update expected warning message to match latest warning message
- fix indentation
**why make this change?:**
- get tests passing
- code maintainability/readability
**test plan:**
`yarn test`
follow up commits will fix the remaining tests
**issue:**
https://github.com/facebook/react/issues/8854
* Add 'unmountComponentAtNode' call in test for reconciling pre-rendered markup
**what is the change?:**
We have a test that verifies React can reconcile text from pre-rendered
mark-up. It tests React doing this for three strings and three empty
strings.
This adds a call to 'unmountComponentAtNode' between the two
expectations for strings and empty strings.
**why make this change?:**
We now warn when someone messes with the DOM inside of a node in such a
way that removes the React-rendered content. This test was doing that. I
can't think of a situation where this would happen with server-side
rendering without the need to call 'unmountComponentAtNode' before
inserting the server-side rendered content.
**test plan:**
`yarn test`
Only one more failing test, will fix that in the next commit.
**issue:**
https://github.com/facebook/react/issues/8854
* ran prettier
* remove unused variable
* run scripts/fiber/record-tests
* Fix type error and improve name of portal container flag
**NOTE:** I am still looking for a good place to move this flag
assignment to, or a better approach. This does some intermediate fixes.
**what is the change?:**
- fixed flow error by allowing optional flag on a DOMContainer that
indicates it was used as a portal container.
- renamed the flag to something which makes more sense
**why make this change?:**
- get Flow passing
- make this change make more sense
We are still not sure about adding this flag; a follow-up diff may move
it or take a different approach.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Add flag to portalContainer on mount instead of in `createPortal`
**what is the change?:**
We add a flag to the container of a 'portal' in the 'commit work' phase
in Fiber. This is right before we call `appendChildToContainer`.
**why make this change?:**
- Sometimes people call `ReactDOM.render(... container)`, then manually
clear the content of the `container`, and then try to call another
`ReactDOM.render(... container)`.
- This leads to cryptic errors or silent failure because we hold a
reference to the node that was rendered the first time, and expect it
to still be inside the container.
- We added a warning for this issue in `renderSubtreeIntoContainer`, but
when a component renders something returned by
`ReactDOM.unstable_createPortal(<Component />, portalContainer);`,
then the child is inside the `portalContainer` and not the `container,
but that is valid and we want to skip warning in that case.
Inside `renderSubtreeIntoContainer` we don't have the info to determine
if a child was rendered into a `portalContainer` or a `container`, and
adding this flag lets us figure that out and skip the warning.
We originally added the flag in the call to
`ReactDOM.unstable_createPortal` but that seemed like a method that
should be "pure" and free of side-effects. This commit moves the
flag-adding to happen when we mount the portal component.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Force an 'any' type for the `hostInstance.parentNode` in warning check
**what is the change?:**
This is awful. :(
I'm not sure how else to let Flow know that we expect that this might be
a sort of `DOMContainer` type and not just a normal `Node` type.
To at least make the type information clear we added a comment.
**why make this change?:**
To get `flow` passing. Looks like we have `any` types sprinkled
throughout this file. phooey. :(
**test plan:**
`yarn flow`
**issue:**
https://github.com/facebook/react/issues/8854
* Ignore portals in `DOMRenderer.findHostInstance`
**what is the change?:**
We want to ignore portals when firing a certain warning.
This allows us to get the host instance and ignore portals.
Also added a new snapshot recording while fixing things.
**why make this change?:**
Originally we had added a flag to the DOM node which was used for
rendering the portal, and then could notice and ignore children rendered
into those nodes.
However, it's better to just ignore portals in
`DOMRenderer.findHostInstance` because
- we will not ignore a non-portal second child with this approach
- we meant to ignore portals in this method anyway (according to a
'TODO' comment)
- this change only affects the DOM renderer, instead of changing code
which is shared with RN and other renderers
- we avoid adding unneeded expandos
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Ran prettier
* Remove error snapshot test
I think there is a bug where an empty snapshot is treated as an 'outdated snapshot'.
If I delete the obsolute snapshot, and run ReactDOMFiber-test.js it generates a new snapshot.
But then when I run the test with the newly generated snapshot, it says "1 obsolete snapshot found",
At some point I will file an issue with Jest. For now going to skip the snapshot generation for the error message in the new test.
* Remove expando that we were adding to portal container
**what is the change?:**
see title
**why make this change?:**
this is part of an old approach to detecting portals, and we have
instead added a check in the `findHostInstance` method to filter out
portals.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
* Fork `findHostInstance` to make `findHostInstanceWithNoPortals`
**what is the change?:**
We need to get host instances, but filter out portals. There is not
currently a method for that.
**why make this change?:**
Rather than change the existing `findHostInstance` method, which would
affect the behavior of the public `findDOMNode` method, we are forking.
**test plan:**
`yarn test`
**issue:**
https://github.com/facebook/react/issues/8854
Alternative to using the static class property unstable_asyncUpdates.
Everything inside <AsyncComponent /> has async updates by default. You
can also extend it like PureComponent or Component.
* Delete flattenChildren
* Stop exporting mapIntoWithKeyPrefixInternal
* Remove unescapeInDev()
flattenChildren() was the only traverseAllChildren() caller that relied on it.
In DEV mode this keeps an additional sub-stack within the stack of the
server renderer. This substack keeps track of all the elements that we
resolved to get to to the next processing frame.
This lets us recreate the full composite component stack for warnings.
Normally the stack only contains host components.
We reset this every time we're going to resolve another sibling.
* Disable Fiber specific test run in CI
This disables the comparison against previously recorded test. Instead,
we'll rely on jest failures to fail tests.
* Extract jest config into two separate projects for Fiber and Stack
Allows us to run both in the same jest run. The setupMocks file is forked into
specific environment configuration for each project. This replaces the
environment variable.
I used copy pasta here to make it clear. We can abstract this later. It's clear
to me that simply extracting shared stuff is not the best way to abstract this.
setupMocks for example didn't need all the code in both branches.
I think that some of the stuff that is shared such as error message extracting
etc. should probably be lifted out into a stand-alone jest project instead of
being shared.
* Fix class equivalence test
There's a behavior change when projects are used which makes
setupTestFrameworkScriptFile not override the normal config.
This test should probably just move to a separate CI script or something
less hacky.
* Only run Fiber tests with scripts/fiber/record-tests
* Move input valueTracker to DOM nodes
This moves the storage of the input value tracker to the DOM node
instead of the wrapperState. This makes it easier to support both Stack
and Fiber without out a lot of ugly type casting and logic branches.
related: #10207
* run prettier
* remove instance accepting methods
* rm unused trst method
* address feedback
* fix naming
* fix lint
* Replace SSR unit test with integration test
* Remove unit test that is already covered by integration suite
* Replace unit tests for boolean attrs with integration tests
* Replace unit test for aria attrs with integration test
* Replace unit tests for numeric 0 with integration tests
* Remove unit test covered by integration tests
* Replace unit test for injection with integration test
It still touches internals but it tests both renderers.
* Fork DOMPropertyOperations into DOMMarkupOperations
* Trim down DOMPropertyOperations and DOMMarkupOperations
* Record SSR sizes
* Record them tests
* Fix false positive warning for overloaded booleans when passing numbers
* Remove stray import
* Replace CSS markup tests with public API tests
Some of these are handy as integration tests so I moved them there.
But some test markup specifically so I changed them to use DOMServer.
* Make CSSPropertyOperations client-only
I forked createMarkupForStyles() into ReactDOMComponent and ReactPartialRenderer. Duplication is fine because one of them will soon be gone (guess which one!)
The warnInvalidStyle helper is used by both server and client, unlike other client-only stuff in CSSPropertyOperations, so I moved it to a separately module used in both.
* Record server bundle size
* Add an early exit to validation
* Clarify what is being duplicated
* Upgrade jest to 20.1.0-delta.1
This includes multi-project support.
* Use isSpy polyfill that is not available in jest 20
* Remove use of jasmine.createSpyObj
We don't really need this and it's not in jest 20.
* Upgrade record-tests script to use the new jest 20 APIs
* Use performFailedUnitOfWork
instead of beginFailedWork and completeUnitOfWork separately. Also, we
unwind the context stack *before* beginning work again.
* Only use error loop directly after a commit
We have a special, forked version of work loop that checks if a fiber is
in a failed state (needs to be unmounted). This is only relevant right
after a commit -- begin phase errors are handled differently, by
unwinding the stack.
Also renamed findNextUnitOfWork to resetNextUnitOfWork and made it a
void function to signal that it's impure.
* Reset nextUnitOfWork after every commit
* Include the error boundary when unwinding a failed subtree
Also added a warning to the error boundary to show that it failed.
* Push context providers in beginFailedWork to avoid push/pop mismatch
Added a test that demonstrates how an error boundary that is also a
context provider could pop its context too many times if you neglect
to push it in beginFailedWork. This happens because we've already
popped the context once in unwindContext.
The solution is a code smell. I don't like how we push/pop context in
so many places. Shouldn't they all happen in the same location?
* Refactor work loop
- Optimizes the normal, non-error path by reducing the number of checks
needed to begin performing work.
- Prevents control flow from oscillating between fast normal loop and
slower error loop.
* Improve context unwinding test
Tests that we correctly unwind an error boundary that is also a
context provider.
* Triangle tester should assert the tree is consistent after every action
...not just at the end.
* Better implementation of infinite loop error
Infinite loops should only be possible if a while loop never terminates.
Now that we've refactored to avoid oscillation between different
work loops, we can count updates local to each loop.
The two loops that could infinite loop are the sync work loop and the
loop that surrounds the body of the render phase catch block. The
async loop could also fall into an infinite loop if the deadline never
terminates, but we'll assume that it always eventually does.
This change also creates better error stack traces because the error is
thrown from inside the first setState that exceeds the limit.
Added a test case for an error boundary whose parent remounts it
on recovery.
* Use invokeGuardedCallback in DEV
* Add a regression test that passes in Stack but fails in Fiber
The failure happens because trackValueOnNode() can exit early if it detects an existing descriptor on node, or if it sees a "broken" Safari descriptor (which is how we encountered this bug in the wild).
As a result, the tracker field was not set, and subsequent updateValueIfChanged() call went into the branch that initializes the tracker lazily. That branch has a bug in Fiber mode where it passes the wrong type.
We did not see this issue before because that branch is relatively hard to hit (you have to either run it in Safari or define a custom DOM value descriptor which is what I did in the test).
In the future, we will likely remove the lazy branch altogether since if we bailed out of setting up the tracker once, we will likely bail out every time. But for now I'm just focused on a minimal fix to unbreak master.
* Fix updateValueIfChanged() lazy path to work with DOM argument
* Slightly reorder lines for clarity and record tests
* Also test the change event code path
This makes it go through the Fiber argument code path.
* Extract the top element frame from ReactDebugCurrentFrame
This is part of a larger refactor to decouple stack addendums. All
renderers have their own way of getting the stack of the currently
executing components.
There is one special case in Element Validator that adds an additional line
for the element being validated. This commit moves that special case in
into the validator.
There is another case where it looked like this was used in shallow
renderer but this is actually something different. It is part of the
component stack. It just happens to be that shallow renderer has a simpler
implementation of the component stack that just happens to be a single
element.
This will let us decouple the implementation to get a stack from
ReactDebugCurrentFrame and put that in each renderer.
* Stop using ReactComponentTreeHook for Fiber
Currently we fall back to ReactCurrentOwner in ReactComponentTreeHook for
stack addendums. We shouldn't need to because we should use
ReactDebugCurrrentFiber.
Ensure we always set both ReactDebugCurrentFiber and ReactDebugCurrentFrame
so that we can rely on these for all stacks.
* Make ReactDebugCurrentFrame implementation independent
Introduced ReactDebugCurrentStack for the Stack renderer which does the
same thing as ReactDebugCurrentFiber.
ReactDebugCurrentFrame no longer keeps track of the current fiber/debug id.
That's handled by the individual renderers.
Instead, it is now used to keep track of the current *implementation* of
the current stack frame. That way it is decoupled from the specifics of
the renderers. There can be multiple renderers in a context. What matters
is which one is currently executing a debuggable context (such as a render
function).
* Add debug frames to ReactPartialRenderer (ssr)
Basic functionality.
* Add shared modules to shallow renderer
This is now needed because we share describeComponentFrame.
* Limit the number of nested synchronous updates
In Stack, an infinite update loop would result in a stack overflow. This
gives the same behavior to Fiber.
Conceptually, I think this check belongs in findNextUnitOfWork, since
that is what we call right before starting a new stack. I've put it
in scheduleUpdate for now so I have access to the component that
triggered the nested update. But we could track that explicitly instead.
I've chosen 1000 as the limit rather arbitrarily. Most legit use cases
should really have a much smaller limit, but a smaller limit could break
existing code. For now I'm only concerned with preventing an infinite
loop. We could add a warning that fires at the smaller limit.
* Move check to findNextUnitOfWork
Including the name of the component in the message probably isn't
necessary. The JS stack will include either componentDidUpdate or
componentWillUpdate. And the component that's updating won't
necessarily be the component whose lifecycle triggered it.
So let's move the infinite loop check to findNextUnitWork as I
originally wanted to.
* Remove unnecessary injection guard
* Remove inject() indirection for global injections
It was necessary when they shared global state. But now these are flat bundles so we can inject as side effect.
This feels a bit less convoluted to me.
Ideally we can get rid of this somehow soon.
* WIP Improve error message thrown in Fiber with multiple copies of React
**what is the change?:**
Adding an 'invariant' with detailed error message for the problem that
occurs when you load two copies of React with the Fiber reconciler.
WIP:
- Is there any other likely cause for this error besides two copies of
React?
- How can we make the message more clear?
Still TODO:
- Write a unit test
- Write a documentation page and create the link to the page, similar
to https://facebook.github.io/react/warnings/refs-must-have-owner.html
It would also be nice to have a page with instructions on how to fix
common cases of accidental double-loading of React, but we can open a
separate issue on that and let the community do it.
**why make this change?:**
This error comes up relatively often and we want to make things clear
when it happens in v16.0+
**test plan:**
WIP
**issue:**
Fixes#9962
* Add improved warning and docs for 'refs must have owner' in Fiber
**what is the change?:**
- Added warning in the place where this error is thrown in Fiber, to
get parity with older versions of React.
- Updated docs to mention new error message as well as old one.
I started to write a new docs page for the new error, and realized the
content was the same as the old one. So then I just updated the existing
error page.
**why make this change?:**
We want to avoid confusion when this error is thrown from React v16.
**test plan:**
- manually inspected docs page
- manually tested in a CRA to trigger the error message
(Flarnie will insert screenshots)
**issue:**
Fixes#9962
Related to #8854
* Add test for the informative warning around multiple react copies
@gaearon debugged the test for this and now it works!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!! :)
**what is the change?:**
We now test for the warning that the previous commits add in Fiber, and
also test for the old warning in the stack reconciler.
**why make this change?:**
This is an especially important warning, and we want to know that it
will fire correctly.
**test plan:**
`yarn test src/renderers/__tests__/multiple-copies-of-react-test.js`
`REACT_DOM_JEST_USE_FIBER=1 yarn test src/renderers/__tests__/multiple-copies-of-react-test.js`
* Fix up test for 'multiple copies of react'
**what is the change?:**
refactor test for 'multiple copies of React' to be simpler and remove
some copypasta
* run prettier
* Fix conditionals in 'multiple copies of react' test
**what is the change?:**
When moving the 'fiber' and 'non-fiber' conditions from two assertions
into one, we copy pasted the wrong message into the 'fiber' condition.
This wasn't caught because we were using an outdated name for the
'fiber' constant when running the tests locally with fiber enabled.
This fixes the copy-paste error and we now are actually running the
tests with fiber enabled locally.
* Run scripts/fiber/record-tests
* Reword duplicate key warning
**what is the change?:**
- Removes the now-inaccurate description of behavior around duplicate
keys
- Adds link to 'key' docs page
- Changes tone to be more casual and friendly
Alternative wording idea;
'Encountered two children with the same key, ${key}
Child keys must be unique; using duplicate keys is not supported and
will cause unexpected behavior in some versions of React.
See https://fb.me/react-warning-keys for more information on how to
fix this.'
**why make this change?:**
Mainly this change was needed because in React 16, duplicate keys will
not cause omission of items with duplicate keys. All items will be
rendered. It could happen that in future versions of React we will have
different behavior though.
**test plan:**
`yarn test`
**issue:**
Wishlist item on https://github.com/facebook/react/issues/8854
* Further improve wording of duplicate key error
**what is the change?:**
Another tweak to the wording of this error to make it more clear and
accurate.
**why make this change?:**
The previous tweak was too casual in tone and still not clear enough.
**test plan:**
`yarn test` and `REACT_DOM_JEST_USE_FIBER=1 yarn run test`
**issue:**
Wishlist item on https://github.com/facebook/react/issues/8854
* Run prettier
* Fix typo in error message for duplicate keys
**what is the change?:**
Fixed a typo in the updated message
* Fix two more typo spots
* change the argument passed to CallbackQueue.getPooled
* remove undefined from function call
* add test for ReactNativeReconcileTransaction
* update log of tests
* change test to one that operates on setState
* added new tests and fixed another instance of the bug
* run prettier
* update names of tests and minor clean up
* remove arg from CallbackQueue and update tests
* Add react-dom-unstable-native-dependencies
react-native-web and react-primitives currently access a few internals
for shimming DOM events into native ones. Changes in react@16 packaging
hide these internals completely. This change adds a submodule to react-dom,
unstable-native-dependencies that includes the necessary modules to
continue enabling that method of dom-native event injection.
* Update ResponderEventPlugin to use "public" interfaces for test
In order to get some sort of smoke testing on
react-dom-unstable-native-dependencies, update ResponderEventPlugin-test
to use the "public" interfaces provided by react-dom and the new
react-dom/unstable-native dependencies
Also adds the missing references in package.json as well as missing
files required for unittests to do imports correctrly
Also exports injectComponentTree() which is required for the unittests
to re-set the shared component state between runs.
* Tweak bundle comment
* Bundle content updates from exporting injectComponentTree
* Added FB_DEV, FB_PROD to bundle types
* Run yarn prettier for -unstable-native-dependencies updates
* Add failing test to show that shallow test renderer doesn't call setState's callback arg
* Record tests
* Fix shallow renderer's setState/replaceState/forceUpdate to execute any callbacks passed. (#10089)
* Ensure shallow renderer callbacks are called with the correct binding.
This fixes a snapshot test regression introduced by #10008. I had
noticed this change and believe the new behavior was correct, but upon
further investigation I was wrong. This reverts the snapshot test and
fixes it accordingly.
To make sure we don't reset the priority of a down-prioritized fiber,
we compare the priority we're currently rendering at to the fiber's
work priority. If the work priority is lower, then we know not to reset
the work priority.
When an error in thrown in the begin phase, we begin work on the
error boundary a second time to unmount the children. This is a special
case of "resuming" work that we need to account for. The children are
set to the current children so that we can delete them.
The current implementation of resuming work is buggy. The underlying
model is also flawed. Rather than attempt to fix a flawed model, we'll
scrap the feature entirely and add it back later.
* Warn for text content
* Warn for different attributes/properties values
Warns if there are unknown extra attributes in the hydrated node.
It also tries to compare the existing property or attribute against the
expected value. It does this by reading the property and comparing it to
the prop. Except it's not that simple because multiple prop values can
yield the same output. For this we pass an extra expected value that is
a hint as to which one was used. This is a bit weird but I'm not sure the
alternatives were much better.
* Warn when there is an insertion or deletion during hydration
This warns if there is ever an insertion or deletion due to hydration
failing to find a match.
Currently we can't warn for insertions required into the root because
that's how we do all non-hydrating renders atm. Left a todo.
This strategy is a bit unfortunate that it leads to so much plumbing code.
And we have to add three extra methods to the HostConfig that are only used
in DEV and not for anything else. I don't really have a better idea.
* Don't try to delete children of a textarea
Textareas are special cases. The initial mount inserts children
as the default value, but we should leave that untouched. This is the same
as the special case where we set text content of children so I'll use that
mechanism.
* Change expected format for text differences
In Stack this is presented as HTML which needs to have normalized escaping
rules. In Fiber it is currently not presented as HTML but a raw string
so we don't escape it.
* Unmount component in between tests
In Fiber, the second warning isn't issued because it's considered an update
not a new initial render and we don't fire the warning for those.
* Change expectation of white space text behavior in Fiber
In Fiber we don't expect empty strings to be different from rendering null.
In fact, in a follow up I plan on formalizing this by never creating text
Fibers for empty strings.
* Warn for different dangerouslySetInnerHTML
We can't just compare the raw innerHTML value because it will have been
normalized. Instead, we'll create another element, set its innerHTML and
read it back.
Since there can be custom elements registered with this document, we want
to avoid any side-effects they might cause. So I do this in a fresh new
document.
I'm not sure how this would affect controlled components and other stuff
that could have changed after runtime. I think for those cases maybe we
just need a general way of opting out of the diff.
* Warn if unmounting a non-container
* Warn if the 2nd+ child is a "root" element but not first
This triggers our non-reuse mode. This is covered by ReactMount already but
the test doesn't pass yet without also landing #10026.
Simplifies markup generation by only inserting a simple comments between
consecutive text nodes.
I also skip past comments and other nodes while hydrating. This leaves them
in place instead of being removed by the hydration mechanism. This is more
efficient but will also be needed by hydration validator.
There's a special case for empty strings. We probably shouldn't have nodes
for those at all. For now I special case it by assuming there won't be one
so if we need one, we'll insert an empty text node.
I also dropped the ID from the react ID.
This covers up errors that are thrown in Fiber, because callback gets
fired *and* an error is thrown. Created a follow up #10049 to reevaluate
these semantics.
# Conflicts:
# scripts/fiber/tests-passing-except-dev.txt
# scripts/fiber/tests-passing.txt
This ensures that custom properties that are required by Facebook's error tooling (eg 'framesToPop') don't get dropped.
I also improved the handling/messaging of thrown strings.
There's no advantage to scheduling updates with animation priority
versus scheduling sync work inside requestAnimationCallback. So we can
remove all the animation-specific code. Now there's only one type of
callback.
Allows us to make assertions on the values that are yielded when
performing work. In our existing tests, we do this manually by pushing
into an array.
ReactNoop.flushThrough extends this concept. It accepts an array of
expected values and flushes until those values are yielded.
When a user types an emoji via Touch keyboard in IE, React's fallback logic
creates the `BeforeInput` event based on the `keypress`. However, the length
of an emoji character (e.g. `\uD83D\uDE0A`) is two, so the `which` property
does not represent an emoji correctly.
Because IE's KeyboardEvent has the `char` property holding an entire emoji,
we can use it directly instead of converting from the `which`.
This makes it so you don't need to pattern-match manually to build a renderer where the container and instance types are not the same. Prerequisite to #9835.
* Prevents adding units to css custom properties
* Fix code style
* Optimize custom property checking
* Prevents adding units to css custom properties in markup creation
* Update passing tests
* Fix argument name and reuse check in DEV
* Remove internal forwarding modules for /lib/
* Add *Entry suffix to all entry points
* Don't bundle ReactNativeFeatureFlags since it's shimmed
* Delete TestRendererStack
* Switch tests at forwarding modules rather than via Jest
* Share mocks between regular and equivalence fixtures
* Rename environment flag to be more generic
* Remove accidental variable name change
* Minor naming changes for consistency
Files that have two versions get the engine in variable name.
* Add ReactNoop.yield, ReactNoop.flushAndYield, ReactNoop.flushUnitsOfWork
Incremental tests often rely on yielding at a specific point. Using an
explicit API should make our tests more resilient to changes
in implementation.
* Fuzz tester that simulates Sierpinski Triangle demo
The tests only assert that the output of the tree is consistent after
each action, and that the final result after all work has flushed is
the expected value. It does not assert how work is reused, which means
it can't detect starvation issues. However, this also means that it
is fairly resilient to changes in our incremental algorithm.
* Blog post for 15.6.0
**what is the change?:**
A short and sweet summary of 15.6.0 changes
**why make this change?:**
To thank community contributors and call out important changes.
**test plan:**
Visual inspection.
I also looked it over in a markdown viewer - http://dillinger.io/
**issue:**
https://github.com/facebook/react/issues/9398
* Add 'Installation' and 'Changelog' to 15.6.0 blog post
**what is the change?:**
Added the 'Installation' section we have on most release blog posts,
customized for the 15.6.0 version of React.
Added the 'Changelog' from master to the blog post.
**why make this change?:**
To show folks how to install React and what changes are in this release.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Improvements to blog post, and add self to `authors.yml`
**what is the change?:**
- Add self to contributors so my name turns into a link
- Use backticks for code-ish things
- Second header to ##, not #
- Change production mode link to the new address per @bvaughn's comment
- Update changelog with fixes from https://github.com/facebook/react/pull/9951
**why make this change?:**
Make things more clear and accurate.
**test plan:**
Visual inspect - @flarnie will paste an image of how it appears in the
actual docs.
**issue:**
https://github.com/facebook/react/issues/9398
* Further improvements to 15.6 blog post
**what is the change?:**
- Reword heading about deprecation warning changes
- add 'br' s to the list of installation options
- add some stray missing backticks
**why make this change?:**
Clarity and readability
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Make ReactControlledValuePropTypes DEV-only
* Remove canDefineProperty
This breaks IE8. We don't support it.
* Remove getNextDebugID
It was added temporarily to avoid Stack shared state issues across renderers.
Not a problem anymore.
* Make KeyEscapeUtils.unescape() DEV-only
* Remove unused deprecated() module
It's unlikely we'll deprecate anything else on React.* object soon.
* Inline getIteratorFn at the call sites
* Inline ReactElementSymbol
* Inline KeyEscapeUtils into Children and move the file into Stack
It's only used in one place in isomorphic.
It's used more broadly in Stack so we move it there to die.
* Update artifacts
* Reorder declarations for consistency
* Fix Flow
React Riot is the first online worldwide hackathon for React! No cost to enter and teams can win some cool prizes. It's a community event to build the best React app in 48 hours.
* Add check for string and null 'rootElement' in ReactDOMFiber
**what is the change?:**
Before we call 'rootElement.getAttribute' we check that the method is
defined.
**why make this change?:**
There is an internal use case I found where 'rootElement' is a string
and null at different points as the page is rendered.
It looks like this method was added as part of support for re-hydration
of server-side rendered content. I can't imagine we would want to reuse
content if the rootnode is a string or null. Not sure if we want an
earlier check that it's an element before this point.
**test plan:**
`yarn test`
and I manually tested this fix in the internal case where it was
breaking
* Add test and improve check for non-element rootElement
**what is the change?:**
We use the nodeType to check that we have the correct type of
rootElement, and we added a unit test.
**why make this change?:**
Improve this solution to the problem.
**test plan:**
`yarn test`
* run ./scripts/fiber/record-tests
* Don't hydrate any properties other than event listeners and text content
This strategy assumes that the rendered HTML is correct if the tree lines
up. Therefore we don't diff any attributes of the rendered HTML.
However, as a precaution I ensure that textContent *is* updated. This
ensures that if something goes wrong with keys lining up etc. at least
there is some feedback that the event handlers might not line up. With
what you expect. This might not be what you want e.g. for date formatting
where it can different between server and client.
It is expected that content will line up. To ensure that I will in a follow
up ensure that the warning is issued if it doesn't line up so that in
development this can be addressed.
The text content updates are now moved to the commit phase so if the tree
is asynchronously hydrated it doesn't start partially swapping out. I use
the regular update side-effect with payload if the content doesn't match up.
Since we no longer guarantee that attributes is correct I changed the
bad mark up SSR integration tests to only assert on the textContent
instead.
* Hydrate text node if possible
Currently we're never matching text nodes so we need to properly branch.
* Tweak syntax in rollup build script
@bvaughn and I already discussed this.
**test plan:**
`yarn build`
* Remove JSDoc comments
**what is the change?:**
removing some comments
**why make this change?:**
The code is basically self explanatory and these comments could get out
of sync.
**test plan:**
Visual inspection, `yarn build` and `yarn test`
**issue:**
https://github.com/facebook/react/issues/9398
According to #9836 we're intentionally chosing to not support this until
we have better proof of this being a big need. E.g. to protect against
extensions. In a way that it's not better to push extensions to be fixed.
* Avoid adding trailing semicolons to inline styles.
* Prettify.
* For sake of performance, avoid messing around with arrays.
* Change approach to avoid calling .substring.
While reading the page, the "chain of thought" is broken by stating that the `tempertature` and `onTemperatureChange` don't have any special meaning. Making this a blockquote makes that note look more like a comment and keep the "chain of thought" intact.
* bump flow to 0.47
* Fix variadic function flow issues in fiber
* Fix variadic function flow issues in ReactFiberNative
* fix ReactDOM type issues with flow 0.47
* getChildHostContext *does* take an `instance` argument
* change recently added anys to mixedies
* HydrationContext needs a handle on the rootContainerInstance
* prettier
This was mostly used for timing of initial mounts. However, we haven't
implemented that in Fiber and yet nobody has complained despite running
without it. Further more the update tracks any update within the tree,
not just updates to the props of the top level. This is much less useful
due to the variation.
I could make this track initial mounts too but it's a bit awkward so I'd
rather just delete it if possible. We can run the full profiling mode if
we want more coverage.
* Update CHANGELOG for unreleased 15.6 branch
**what is the change?:**
Added entries for the latest changes.
**why make this change?:**
We are about to do an RC release and folks can look at these notes to
see what is in the planned release.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Update changelog regarding `createClass` dep. warning
**what is the change?:**
We decided to strike through the previous changelog item and add it to
the more recent changelog section, since this is the release where the
deprecation warning will actually go out.
**why make this change?:**
To make things clear for everyone using 15.6
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
This creates `ReactNativeComponent`, the modern replacement for `NativeMethodsMixin`.
This class is going to allow us to start migrating React Native off `React.createClass(...)` into a typesafe, class-based brave new world.
This also introduces `IReactNativeComponent`, an interface that enforces consistency between `ReactNativeComponent` and `ReactNativeFiberHostComponent`.
This is a follow-up on
https://github.com/facebook/react/pull/9584#discussion_r115642293. There
is no need to assign the value property of an input if the value
property of the React component changes types, but stringifies to the
same value. For example:
```javascript
DOM.render(<input value="true" />, el)
DOM.render(<input value={true} />, el)
```
In this case, the assignment to `input.value` will always be
cast to the string "true". There is no need to perform this
assignment. Particularly when we already cast the value to a string
later:
```javascript
// Cast `value` to a string to ensure the value is set correctly. While
// browsers typically do this as necessary, jsdom doesn't.
node.value = '' + value;
```
This isn't necessarily what we want long-term especially with more async, but currently we crash in jsdom in some cases when an img load event gets dispatched synchronously. (Needed for FB-internal D5060180.)
**what is the change?:**
- Add two more special cases for 'lowPriorityWarning' in 'modules.js',
treating it the same as 'ReactCurrentOwner'.
**why make this change?:**
Without this, the build was including 'lowPriorityWarning' seemingly both as an external module and as part of the bundle.
**test plan:**
Ran `yarn build` and inspected the `React-dev` build. `lowPriorityWarning` did not get bundled in this time.
**issue:**
None yet - @gaearon flagged this for me directly.
* Add back caught error and other checks to 'lowPriorityWarning'
**what is the change?:**
This change makes 'lowPriorityWarning' an exact copy of 'warning.js' from
e66ba20ad5/packages/fbjs/src/__forks__/warning.js
where before we had skipped some checks from that module.
- Adds an error which we catch, in order to let people find the error and resulting stack trace when using devtools with 'pause on caught errors' checked.
- Adds check that 'format' argument is passed
**why make this change?:**
- To maintain a closer fork to 'warning.js'
- To allow easier debugging using 'pause on caught errors'
- To validate inputs to 'lowPriorityWarning'
**test plan:**
`yarn test`
**issue:**
* Update 'print-warnings' script to include 'lowPriorityWarning' output
**what is the change?:**
We print the logs from 'lowPriorityWarning' as well as 'warning' from the 'print-warnings' script.
NOTE: This PR is branching off of https://github.com/facebook/react/pull/9754
**why make this change?:**
We want to use the same process of white/blacklisting warnings with 'lowPriorityWarning' that we do with 'warning'.
**test plan:**
This is not super easy to test unless we are doing a sync with FB afaik. I plan on running a sync in the next few days, or next week at latest, for the sake of not landing big things on a Friday. That will be the actual test of this.
**issue:**
https://github.com/facebook/react/issues/9398
* Add 'Test Utils' docs back to main navigation
**why make this change?:**
We accidentally removed this - still supporting the use of Test Utilities, so we should have them in the docs.
**test plan:**
Manually tested the website - will insert a screenshot.
**issue:**
https://github.com/facebook/react/issues/9651
* Move test-utils docs to reference section
**what is the change?:**
Moved from 'advanced guides' to 'reference'
**why make this change?:**
It makes more sense as a reference
**test plan:**
Visual inspection (flarnie may add a screenshot)
**issue:**
* Add back the shallow renderer docs and remove outdated docs
**what is the change?:**
- Remove outdated 'shallow renderer' docs on 'test utils' page, and point to the updated 'shallow renderer' docs.
- Re-add a link to the updated 'shallow renderer' docs on the main navigation.
**why make this change?:**
This was already approved in https://github.com/facebook/react/pull/9331 which was then cherry-picked to https://github.com/facebook/react/pull/9359/commits and landed on master.
I'm not sure why some of these changes didn't persist. For now just adding back the changes we need.
**test plan:**
Manually inspected website - will insert screenshots.
**issue:**
* Further improvements to 'shallow rendering' and 'test utils' docs
Thanks @gaearon for the improvements!
**what is the change?:**
- Remove <hr/> from end of 'shallow rendering' docs
- 'documents' -> 'documentation'
- Move 'shallow rendering' redirection section to top of 'test utils' docs
- Add intro sentence about testing to 'shallow rendering' docs
**why make this change?:**
Documentation helps people learn.
**test plan:**
Visual inspection
* Update 2015-12-16-ismounted-antipattern.md
In case anybody else stumbles across this old blog post, I wanted to submit a patch to help with unhandled rejections.
`#then` and `#catch` each return new Promise instances, so here we actually create two new promises (that aren't assigned). If the argument promise to `#makeCancelable` rejects, the promise created by `#then` will be an unhandled rejection, which in Node 7 will be an uncaught error.
By using the second argument of `#then` to handle rejections instead, we don't need to worry about the runtime finding any unhandled rejections here.
* Style updates
* Add update notice
* Don't double validate the DOM container
The warnings need to check a valid container but that should happen in
unstable_renderSubtreeIntoContainer too so might as well move it in.
* Hydrating DOM
Hydrates a server-rendered DOM tree by traversing it and connecting up the nodes if they match. Attributes are not diffed. They're assumed to be accurate on matching nodes.
* Remove meta data filtering from test
Because the current server renderer includes the meta data, it remains in a revived tree.
* Annotate because Flow
* Don't track insertion effects if we're going to hydrate
During initial mount, we should not track Placement
* Fix up test cases to ignore errors that we no longer throw
TODO make these warnings instead.
* Correctly track hydration state inside a newly inserted tree
When we don't match the first hydration node, we'll do an insertion.
Currently we keep the next hydratable sibling so that we know where to
pick up once we're done with the insertion. Unfortunately this makes the
nodes inside the insertion think that there's a node to hydrate.
I used to check for the direct parent but that doesn't work on nested host components.
We need to instead keep track of that we're in an hydration context but
we're not currently hydrating. Once we pop passed the inserted node can
we resume hydrating.
* Hacky fix to isMounted
isMounted checks whether a component is inside a Placement. During
hydration we ideally don't do any Placements if hydration matches the tree.
To work around this I use the Placement flag on the root, which isn't used
for anything else. But only temporarily while we're hydrating. Then reset
it before committing.
* Record tests
* Comments
Since stripEnvVariables was used to replace __DEV__ references, I assumed it (and other plugins) we run before requires statements were processed. Obviously I was wrong 😬 and as a result, the RN Stack and Fiber builds were way too large. This is an attempt to mimic the approach taken with DOM renderer and stub out modules that we explicitly don't want to include.
The alternative to this would have been to fork findNodeHandle, NativeMethodsMixin, ReactNativeBaseComponent, etc. and essentially avoid using the feature flag. That didn't seem tenable. The previous injection approach also doesn't work here because the circular references it resulted in caused Rollup to choke when creating the modules.
This regressed with the recent addition of RN_* bundles. I was accidentally stripping comments from FB_PROD when I meant to do the opposite. This corrects that mistake.
No significant bundle size change occurs when re-running this build against the version prior to the RN_* bundles.
* Split ReactNativeFiber into separate ReactNativeFiberRenderer module
Hopefully this is sufficient to work around Rollup circular dependency problems. (To be seen in subsequent commits...)
* Split findNodeHandle into findNodeHandleFiber + findNodeHandleStack
This allowed me to remove the ReactNative -> findNodeHandle injections, which should in turn allow me to require a fully-functional findNodeHandle without going through ReactNative. This will hopefully allow ReactNativeBaseomponent to avoid a circular dependency.
* Un-forked findNodeHandle in favor of just inlining the findNode function impl
* takeSnapshot no longer requires/depends-on ReactNative for findNodeHandle
Instead it uses the new, renderer-specific wrappers (eg findNodeHandleFiberWrapper and findNodeHandleStackWrapper) to ensure the returned value is numeric (or null). This avoids a circular dependency that would trip up Rollup.
* NativeMethodsMixin requires findNodeHandler wrapper(s) directly rather than ReactNative
This works around a potential circular dependency that would break the Rollup build
* Add RN_* build targets to hash-finle-name check
* Strip @providesModule annotations from headers for RN_* builds
* Added process.env.REACT_NATIVE_USE_FIBER to ReactNativeFeatureFlags
This is kind of a hacky solution, but it is temporary. It works around the fact that ReactNativeFeatureFlag values need to be set at build time in order to avoid a mismatch between runtime flag values. DOM avoids the need to do this by using injection but Native is not able to use this same approach due to circular dependency issues.
* Moved a couple of SECRET exports to dev-only. Removed SyntheticEvent and PooledClass from SECRET exports. Converted Rollup helper function to use named params.
* Split NativeMethodsMixins interface and object-type
* Add @noflow header to flat-bundle template to avoid triggering Flow problems
When Flow tries to infer such a large file, it consumes massive amounts of CPU/RAM and can often lead to programs crashing. It is better for such large files to use .flow.js types instead.
* NativeMethodsMixin and ReactNativeFiberHostComponent now share the same Flow type
* Collocated (externally exposed) ReactTypes and ReactNativeTypes into single files to be synced to fbsource. ReactNativeFiber and ReactNativeStack use ReactNativeType Flow type
* Build script syncs RN types and PooledClass automatically
* Added optional sync-RN step to Rollup build script
* Added results.json for new RN bundles
* Add back caught error and other checks to 'lowPriorityWarning'
**what is the change?:**
This change makes 'lowPriorityWarning' an exact copy of 'warning.js' from
e66ba20ad5/packages/fbjs/src/__forks__/warning.js
where before we had skipped some checks from that module.
- Adds an error which we catch, in order to let people find the error and resulting stack trace when using devtools with 'pause on caught errors' checked.
- Adds check that 'format' argument is passed
**why make this change?:**
- To maintain a closer fork to 'warning.js'
- To allow easier debugging using 'pause on caught errors'
- To validate inputs to 'lowPriorityWarning'
**test plan:**
`yarn test`
**issue:**
* Update results.json
* Run prettier
* fixed conflicts with master
* splits fiber and stack implementations
* prettier run
* updated fiber implementation based on feedback
* updated fiber implementation for selecting inspector hierarchy
* run of prettier
* fixed flow issues
* updated stack implementation
* fixes an implementation difference where before it wasnt properly understoof
* addresses comments in PR feedback
* updated stack inspector to use emptyObject
* Update ReactNativeFiberInspector.js
Fixes a flow error
* fixes last flow error
* prettier
* applied changes to how viewConfig works for fibers and extracted measure out
* fixed bad paste
* fixes flow errors
* prettyify
* revmoed getComponentName changes
* updated logic for getHostProps and addressed other PR feedback
* improved throwing to invariant and update stack implemenation based on feedback
* prettier
* Initial regeneration of results.json
**what is the change?:**
We ran `yarn build` and updated the perf. stats record.
**why make this change?:**
Some commits have landed without updating this. By getting an initial update, I can run the build script again after my changes and see any size regressions.
* Downgrade deprecation warnings from errors to warnings
**what is the change?:**
Swapping out `warning` module for a fork that uses `console.warn`.
It looks like we were using the `warning` module for deprecation notices, *but* there is also a 'deprecated' module designed specifically for deprecation notices.
However, we could not find any place that it was currently used.
Since React's build process is not 100% clear to me, I assume it could still be used somewhere by something and just updated it along with other deprecation notices.
We might consider a follow-up diff that does some clean up here;
- remove 'deprecated' module if it's unused, OR
- use 'deprecated' module for all our current deprecation warnings
**why make this change?:**
- We have had complaints about noisy warnings, in particular after introducing new deprecations
- They potentially cause CI failures
- Deprecations are not really time-sensitive, can ship without breaking your app, etc.
For more context - https://github.com/facebook/react/issues/9395
**test plan:**
`npm run test`
and unit tests for the new modules
and manual testing (WIP)
**issue:**
https://github.com/facebook/react/issues/9395
* Add 'lowPriorityWarning' to ReactExternals
**what is the change?:**
We won't bundle 'lowPriorityWarning' with the rest of React when building for Facebook.
NOTE: A parallel commit will introduce an internal implementation of 'lowPriorityWarning' in Facebook's codebase, to compensate. Will post a comment with the diff number once that is up.
**why make this change?:**
So that the sync between github and Facebook can go more smoothly!
**test plan:**
We will see when I run the sync! But this is a reasonable first step imo.
**issue:**
https://github.com/facebook/react/issues/9398
* Make state mutations an error, not low-pri warning
**what is the change?:**
Even though this is a "deprecation" warning, we still want to use 'console.error' for it.
**why make this change?:**
- It's not likely to come up now, hopefully, because this warning has been present for some time
- This will cause real issues in production if ignored
**test plan:**
`yarn test` - we did fix one test which failed bc of this change
**issue:**
https://github.com/facebook/react/issues/9398
* Fix test of assigning to this.state that was only passing in fiber
**what is the change?:**
updated a unit test for assigning directly to state; it once again raises an error and not a warning.
**why make this change?:**
So that tests pass
**test plan:**
REACT_DOM_JEST_USE_FIBER=1 yarn run test
**issue:**
* Update results.json
As of Chrome 58, the Timeline tab is now called the Performance tab, this updates the "Optimizing Performance > Profiling Components with Chrome Performance" section of the docs to reflect that.
The example explaining how redux's connect works doesn't use the same component name. Line 264 references (Comment) while 274 referenced (CommentList). Changed 264 to match 274.
* Adjust some expectations of the server markup format of Fiber
Currently this case is using the stack renderer.
* Ensure debug hooks are injected into the Stack server renderer
In our tests this normally happens because ReactDOM.js injects them into
the shared module, but when Fiber is enabled or this is its own flat
bundle, that doesn't happen.
* Add package builds for new server renderer and enable tests
ReactServer -> ReactDOMServerStream
This file is going to be the replacement for ReactDOMServer.
I mock ReactDOMServer and user ReactDOMServerStream when we have
the fiber flag enabled. I'm now also enabling this as the default for
distributions builds (react-dom/server on npm and
react-dom-server.production.min.js as umd bundle).
I'm using traverseStackChildren instead of traverseAllChildren because
traverseAllChildren is now only in the isomorphic package and we don't
want to build all of that that into the server package.
I also have to require lower case react for the builds to work.
* Server Rendering initial commit
Originally authored by spicyj, tweakes to rebase it and make it run by tomocchino.
Adding ReactDOMServerRendering and a createTagMarkup utility function which will be used in it.
* Fix build system, add shortcut scripts
* Make more ReactServerRendering-test unit tests pass
* Make ReactServerRendering-test pass with copious help from Ben
This is pretty hacky and I just inlined everything, but at least I sort of understand how it works now, and all of the tests are passing. There are also only 68 tests failing in the integration test suite.
* remove some unnecessary cruft
* Run prettier on ReactDOMServerRendering.js
* Fix more unit tests with Ben
* Add support for input and textarea by copy pasting a bunch of code from ReactDOMInput/ReactDOMTextarea
* Fix context unit tests with more copy paste :)
* progress on select
* Holy shit, 100% of ReactDOMServerIntegration tests are passing
* Checkpoint to fix some of the ReactDOMComponent-test tests
* Fix missing checkPropTypes
* Fix some unit tests in ReactDOMComponent-test
* Run prettier on everything, thanks Ben
* get rid of ssr tests that are looking for component file names
* add assertValidProps check
* rename flattenChildren to flattenOptionChildren per Ben
* Fix all the lint crap
* Move things around in the file and turn ReactDOMServerRenderer into a class
* remove changes I added to package.json
* remove separate createOpenTagMarkup file for now since everything should be copy pasted into a single file
* re-record Fiber tests
* Revert ReactDOMServer.js and the fiber tests per Sebastian
This also reverts the changes I made to ReactDOMComponent-test.js which removed the stack which is missing in the new server renderer"
* Rename files based on feedback
Moving src/renderers/dom/server/ReactDOMServerRendering.js to src/renderers/server/ReactServerRenderer.js and add src/renderers/server/ReactServer.js which makes this new codepath completely separate.
* Change throw to invariant, even though we probably need to remove this at some point
* fix prettier.. sigh
**what is the change?:**
See title.
**why make this change?:**
Both these dependencies were causing issues when working on React internally at
FB.
'lighthouse' requires node >=6 and we don't want to folks working on React to
using that version of node.
https://github.com/GoogleChrome/lighthouse/blob/master/package.json#L11
'nodegit' for me throws an error related to libssh2 and it's annoying to make
this work in every OS. See https://github.com/nodegit/nodegit/issues/1266
**test plan:**
`npm/yarn install`
Runs with no errors on my CentOS machine and also on MacOSX laptop.
**issue:**
This is blocking work related to https://github.com/facebook/react/issues/9398
* Move assertValidProps into shared/utils since it will be used by the server renderer
* Extract getCurrentOwnerName from assertValidProps and pass it in
**what is the change?:**
A test was added for a change to Fiber's behavior in #9608, and because of a
bug in our CirclCI script it landed when failing for non-fiber runs of the
tests.
This just wraps the test in a feature flag because it seems clear it was
only intended to test the new fiber behavior.
Thanks to @gaearon for pairing on this! :)
**why make this change?:**
So that tests are passing on master.
**test plan:**
`npm run test ReactCompositeComponentState`
**issue:**
None - figured it out before anyone opened an issue afaik.
* Move small utility modules out of ReactDOM(Fiber)?Component
These are all going to be needed in the server renderer, so I'm moving them out now so I can use them from in there.
* Fix `didWarnShadyDOM = false;` line
* Remove injectReactDOMEventListener from ReactBrowserEventEmitter
This PR removes the injection of ReactDOMEventListener from
ReactBrowserEventEmitter. Instead, the required initialization will
happen directly in ReactDOMInjection.
This injection was (probably) originally implemented for React Native
but never used, so we can clean it up.
* Mention how to see the full ouput of fiber tests
`ReactEventListener` is a DOM-specific module although the name suggests
otherwise. This change renames the module to the more specific
`ReactDOMEventListener`.
* Initial commit for WIP benchmarking infrastructure
* fixed lint issues and ran prettier
* added <rootDir>/scripts/bench/ to ignore paths for Jest
* tidied up code and fixed a few bugs in the runner.js
* fixed eslint
* improved the benchmark output from the runner
* fixed typo
* tided up print output in runner.js
* throw error if chrome canary is not installed on mac
* added better bench stats output (tables)
* added benchmark diff to table results
* adds bundle size comparisons to results
* tidied up the results
* fixed prettier output
* attempt to trigger bech for circleci build
* fixes flow exlclusion for lighthouse module
* added class components benchmark
* cleaned up stats.js
* stability changes
* circleci node version to 7
* added another benchmark
* added colours to the different benchmarks to check if being cached
* force no-cache headers
* added more info messages
* refactor chrome launching.
* fixed an issue where launcher.kill might fail
* Move server to runner. Launch it only once.
* tidy up
* changes the logic in how the remote repo is checked out
* removes bench from circleci build
* removed colors from benchmarks (no longer needed)
* added CI integration comment
* added hacker news benchmark
* added skipBuild functionality
* relabelled remote
* Add confidence intervals
* added first meaningful paint
* removed some unused code
* reverted code.json
* updated benchmark runs back to 10
* no longer breaks when results contain missing bundles
* adds CPU throttling
* renamed build to remote-repo
* small fix to build
* fixed bad merge
* upped runs to 10 from 2 again
* properly pulls master
* removes old-bench
* runs benchmarks in headless mode
* adds a --headless option
* improved the git build process
* added README
* updated based feedback from review
* adds merge base commit sha
* addressing more PR feedback
* remove built JS react files
* updated .gitignore
* added combined bundle load times to the metrics
Recreating the class instance causes refs (and other callbacks) to close
over stale instances.
Instead, re-use the previous instance. componentWillMount is called
again. We also call componentWillReceiveProps, to ensure that
state derived from props remains in sync.
* Remove loose check when assigning non-number inputs
This commit removes a check I added when working on number input
issues where we perform a loose check on an input's value before we
assign it. This prevented controlled text inputs from disallowing
numeric text entry.
I also added a DOM fixture text case.
Related issues:
https://github.com/facebook/react/issues/9561#issuecomment-298394312
* Use strict equality as a guard before assigning input.value
This commit adds back the guard around assigning the value property to
an input, however it does it using a strict equals. This prevents
validated inputs, like emails and urls from losing the cursor
position.
It also adds associated test fixtures.
* Add copy command after build for interup with surge.sh
* Add 'unreleased' incremental change log for v15.6.0
**what is the change?:**
Adding a section to the change log where we start accumulating
annotations for React v15.6.0.
**why make this change?:**
- Saves us the trouble of writing the change log entry all at once when
we do the release.
- Adds transparency about what is in the upcoming release, for those who
aren't following https://github.com/facebook/react/issues/9398
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Minor tweaks to v15.6.0 changelog annotation
**what is the change?:**
- added missing `#` for commit hashes
- added minor details to two annotations
Thanks to @gaearon for the code review comments.
**why make this change?:**
Consistency and clarity.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Remove hashes from commit numbers
**what is the change?:**
We had added hashes to some commit numbers, but ideally only do that
for PRs.
**why make this change?:**
Consistency - this is how github displays those types of links too. PRs
get a '#', and commits don't.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9398
* Report version and bundle type to DevTools
* Flip the flag the other way around
It's easier to remember 0 is always PROD, and 1 is like DEV flag. 2 could be PROFILE in the future.
* Add version to RN inject call
* Updated the warning message for setting defaultProps on instance property.
* Updated the testcases for the defaultProps warning.
* Updated the warning message for defaultProps set on instance property.
* tutorial: adds note about onClick
* tutorial: show full square component
* merge
* fixes line number
* tutorial: misc changes
* fixes Board render initial code sample
* [tutorial] adds codepen links and misc small fixes
* removes useless arrow functions, #9531
* {this.renderSquare} new lines
* be more explicit about history state
* fixes highlight
* following along locally
* changes todo to this.props.value
* removes calculateWinner from initial codepens and includes it in tutorial
* removes note about calculateWinner at end of file
* adds debug-view and debug-view-final
* removes debug view, updates codepen instructions
* adds another codepen
* tutorial.md
* tutorial.md
* tutorial.md
* tutorial.md
* Put . into links for consistency with docs
* Make the very first change easier to follow
* A few more changes
* Update Changelog for v15.5.1-15.5.4
This could really use extra code review attention since the history of
these changes was a bit convoluted to follow.
After talking to @bvaughn and @acdlite, we thought it might make sense
to put the 'add-ons' changes in a separate change log. The other option,
of including them in the main React change log, seemed the more
confusing of the two.
Also this commit is related to and somewhat blocked by
https://github.com/reactjs/prop-types/pull/40
**what is the change?:**
Adding the change log for recent patch versions of React.
**why make this change?:**
We missed this step in the flurry of releasing patches, and it's useful
for folks who want info about what version to use.
**test plan:**
Visual inspection of the change log.
**issue:**
https://github.com/facebook/react/issues/9443
* Further improve CHANGELOG entries for v15.5.1-15.5.4
**what is the change?:**
- Use the '[@author] in [#PR/commit]' format for annotations
- Make annotations less technical, more clear
- Move 'React Addons' updates into main changelog
- Remove separate 'React Addons' changelog
**why make this change?:**
These changes each make things more clear and accurate.
**test plan:**
Visual inspection
**issue:**
* Fix final nits in CHANGELOG
**what is the change?:**
- Put backticks around package names
- Reformat link to to commit in '([@user](...) in [#NNNN](...))' format
- Remove newlines after subheaders; in the past we sometimes have
included a newline after the subheader, but most recently it looks
like we do not.
- Add some missing punctuation.
**why make this change?:**
Consistency and aesthetics
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/issues/9443
* Add deprecation notice to v15.5.0-15.5.3
**what is the change?:**
Adding deprecation notice to some recent React versions.
**why make this change?:**
These versions of React use a version of `prop-types` that had a
critical bug. We updated the dependency in React 15.5.4, and hopefully
people will see this notice and update.
**test plan:**
Visual inspection
**issue:**
https://github.com/facebook/react/pull/9537
this was a surprise to me because the docs seemed to indicate that when
using an updater, the result _needed_ to be a new state object. I was
[not alone](https://twitter.com/ken_wheeler/status/857939690191806464)
i think in discovering this as a result of the previous tweet in the
thread.
Adds a server-rendering fixture based on create-react-app without ejecting.
This is using the full-page strategy because I wanted to flush out any issues with it. Turns out there's a lot of little things that are fixable and some non-fixable. This actually surfaced some differences between the current strategy and the one I had in mind.
This uses the asset manifest from webpack to pass the final URLs to the client. This ensures that we can render the same exact mark up on the client - including the URL to our own script that we're running in.
Doing full document renders work with 15.x as long as the checksum matches. However, with the patch up reviving strategy I had in mind it would end up removing the CSS tags that webpack injects before running our render call. This is a behavior change.
In dev mode the server runs a proxy in front of the normal CRA webpack server so that we can replace the HTML request for the root page.
I don't know what the best way to link in the react and react-dom packages. Each fixture has a different strategy so here's another one. Just add NODE_PATH=../../build/packages in front of all commands.
Apparently, when you mark something as external in Rollup, a require
statement is inserted even if the module isn't used. This is causing
ReactDOM and several other modules to be inserted unnecessarily.
We need a better fix for this, but I'm pushing this quick fix for
now since it's blocking sync to www.
* Add guide on integrating with non-react code
* Capitalize guide title
* Make links to other docs relative
* Rephrase 'What it does do'
* Remove experimental syntax
* Capitalize Backbone
* Remove empty lifecycle method in generic jQuery example
* Use shouldComponentUpdate() not componentWillUpdate()
* Prefer single quotes
* Add cleanup to generic jQuery example
* Capitalize React
* Generalize the section on Backbone Views
* Generalize the section on Backbone Models, a little
* Add introduction
* Adjust wording
* Simplify ref callbacks
* Fix typo in generic jQuery example
* Fix typos in Backbone models in React components
* Fix more typos in Backbone models in React components
* Add generic section on integrating with other view libraries
* Stress the benefits of an unchanging React element
* Small changes to introduction
* Add missing semicolon
* Revise generic jQuery wrapper section
Moved the section on using empty elements to prevent conflicts above the
code example and added brief introduction to that example.
* Add usage example for Chosen wrapper
* Prevent Chosen wrapper from updating
* Note that sharing the DOM with plugins is not recommended
* Mention how React is used at Facebook
* Mention React event system in template rendering section
* Remove destructuring from function parameters
* Do not name React components Component
* Elaborate on unmountComponentAtNode()
* Mention preference for unidirectional data flow
* Rename backboneModelAdapter
* Replace rest syntax
* Respond to updated model in connectToBackboneModel
* Rewrite connectToBackboneModel example
* Rework connectToBackboneModel example
* Misc changes
* Misc changes
* Change wording
* Tweak some parts
* Add reference to the Hyperscript libraries
I feel these should be mentioned as they provide terser syntax than using `R.createElement` directly, even with a shorthand.
* Rephrase
Latest versions of prop-types don't depend on React, so the factory is
not necessary, and in fact bloats the build because it is intended for
15.5 and so doesn't strip out the checkers in prod.
* Improve component type check in getComponentKey.
The sequence
```
component && typeof component === 'object'
```
checks whether component is any JavaScript object except document.all.
Since document.all cannot occur here, this can be replaced with the
usual
```
typeof component === 'object' && component !== null
```
sequence, which yields true for all JavaScript objects and is well
optimized by all JavaScript engines.
* Run yarn prettier.
- Update examples to no longer use React.DOM
- Add package and documentation entries for react-addons-dom-factories
- Update dom-factories readme
- Set up proxy to intercept React.DOM usage
- Update ReactDOM children tests to use createElement
- Add more specific warning assertion for React DOM factories
- Do not use expectDev in ReactDOMFactories tests
This should have been retained in our docs, since PropTypes are only
moved and not deprecated.
Partially handles #9467, and I'll make a separate PR to
https://github.com/reactjs/prop-types to add more docs to the README
there.
* Add test for React.PureComponent
* Add warning when shouldComponentUpdate is declared in a PureComponent
* Add actionable warning
* Add warning in Fiber
* Format added code by running yarn prettier
* Move pure sCU check to checkClassInstance
That way it warns before the component updates
* Use setProperty when setting style properties
setProperty is faster in all/most modern browsers. It also lets us support CSS variables.
* Only use setProperty when setting CSS variables
* Add test to ensure setting CSS variables do not warn
* Make this PR pretty again
* Run fiber test script
The prop-types lib got an anti-spamming change in 15.5.8 that broke some of our tests (see reactjs/prop-types/commit/e1d51dd0efbd0eee5e4a8d24759f2a4d518721d3). This PR resolves that by resetting the prop-types import between tests.
Use a ReactFeatureFlag instead. It won't be per-renderer, but we likely
won't need that.
When enableAsyncSubtreeAPI is false, unstable_asyncUpdates is ignored,
but does not warn or throw. That way if we discover a bug in async mode,
we can flip the flag and revert back to sync without code changes.
Unions don't enumerate all the possible combinations of bitfields. I'm
not actually sure why this was type-checking before.
number doesn't provide much safety but it's more correct.
The default priority of updates in a async tree is LowPriority, rather
than SynchronousPriority.
Warns if you call unstable_asyncRender on a tree that was created with
the normal, sync ReactDOM.render.
- A priority context of NoWork represents the default priority
- Changed the signature of getPriorityContext to accept the fiber that
is about to be updated.
A fiber has all the context flags of its parent. It may also add
additional ones during construction/mount. After mounting, contextTag
shouldn't change.
contextTag is a bitmask that describes properties about the fiber
and its subtree. For example, the AsyncUpdates flag indicates whether
the subtree should use async scheduling.
When a fiber is created, it inherits the bitmask of its parent.
* [Docs: Installation] Fix tabs responsive layout
* Move tabs a pixel down
* Remove left margin on first tab
* Remove the long line
* Fix mobile styles
Shallow renderer and test utils bundles
Adds new bundles introduced with React 15.5 release to master (and 16 alpha)
react-dom/test-utils:
This new bundle contains what used to be react-addons-test-utils. This bundle shares things from react-dom rather than duplicates them.
A temporary createRenderer method has been left behind as a way to access the new shallow renderer. This is for the ReactNative release cycle only and should be going away before the final release.
react-test-renderer/shallow:
This new shallow renderer is almost entirely stand-alone (in that it doesn't use the React reconciler or scheduler). The only touch points are ReactElement and prop/context validation. This renderer is stack and fiber compatible.
* Fix tests to pass when we warn for missing keys in fragments
In most cases we just needed to add the 'key' prop.
This ignores the tests which are already failing on master when running
with ` REACT_DOM_JEST_USE_FIBER=1` - there are 8.
All tests should now pass with `npm run test`, and the 8 which fail when
running `REACT_DOM_JEST_USE_FIBER=1 npm run test` are the same 8 which
are failing on master.
* Added missing key warning for children in array fragments
After trying twice to reuse the code between the ReactChildFiber and
ReactElementValidator, I am thinking that it's simpler to just have some
duplication of code. The parts that are shared are interleaved with
parts which cannot be shared, either because of singleton modules that
must be required differently in 'isomorphic' and the 'renderers', or the
fact that 'warning' requires a hard coded string.
Test Plan:
- Added test to ReactChildren-test
- Manually tested via fixture that was not committed.
* commit updated "scripts/rollup/results.json"
* Make 'ReactChildren-test' more specific, and remove unneeded nesting
Based on helpful tips from @spicyj and @aweary's review
- Made the unit test for the warning on missing keys more specific
- Removed unneeded nesting in the code which generates missing key
warning
- Change test syntax to use JSX to be more consistent
Also fixes flow warning.
* Commit update of scripts/rollup/results.json
* run "scripts/fiber/record-tests"
* Fix errors in React Native children management
- Support using appendChild to move an existing child (Fiber does this, but we were assuming all children here were new; Yoga throws if you insert a child that already has a parent)
- Calculate beforeChildIndex after removing old child (previously, off by one when the new position is later than the old position)
* Add better children management tests for RN
* Lift state up - Updating the documentation to mention that onClick is a synthetic event handler
* Review comments - Rephrase to handle synthetic events and event handler patterns
* Tweak
This fixes an issue where if we decided not to create a measurement we would clear ALL measurements from the performance entry buffer due to passing `undefined` as the entry name.
* Make nodeType into constant for readability and reuse
* Fix eslint line length warning
* Delete unused nodeType values
* Destructure HTMLNodeType constant
* Make nodeType into constant for readability and reuse
* Fix eslint line length warning
* Delete unused nodeType values
* Destructure HTMLNodeType constant
* Fix test
* Format using prettier
* Add warning if rendering and HTMLUnknownElement
* Records fiber tests
* Fixes linting and server render tests
* Incorporates review comments
* Uses ownerDocument instead of document
* uses el instead of creating a new element
* Removes warning check of voidElementTags
* Add missing space to unknown element warning
* Only call isCustomComponent once
* Spy on console in menuitem test
Since menuitem is treated as an unknown element in jsdom it triggers the unknown element warning.
* Add unknown element warning to Fiber
* Replace instanceof with toString check
It is more resilient.
* Record tests
* Updated the Good First Bug section in readme
* Inconsistent use of quotes. Prefered single quotes instead of double quotes
* Updated Good first bug link in how_to_contribute doc.
* Undo JSX attribute quote change
* don't capitalize "beginner friendly issue"
* Add tabs to installation page (#9275, #9277)
This adds tabs for create-react-app and existing apps to the installation section of the docs. The tab implementation is a simplified version of React Native's installation page.
Fixes#9275.
* Use classList instead of className
* Use same implementation as in RN
* Clarification of setState() behavior
`setState()` is a frequent source of confusion for people new to React, and I believe part of that is due to minimization of the impact of the asynchronous behavior of `setState()` in the documentation. This revision is an attempt to clarify that behavior. For motivation and justification, see [setState Gate](https://medium.com/javascript-scene/setstate-gate-abc10a9b2d82).
* Update reference-react-component.md
* Signature fix
* Update to address @acdlite concerns
* Add more details
(Temporarily) re-adds getters with deprecation warnings for React.PropTypes, React.checkPropTypes, and React.createClass.
* 08bd020: Replace all references to React.PropTypes with prop-types to avoid triggering our own warning message.
* ef5b5c6: Removed several references to React.createClass that appeared after rebasing this branch. (reviewed by @flarnie)
* 524ce20: Added getters for createClass and PropTypes to the main React isomorphic object, behind one-time warning messages. (reviewed by @spicyj)
* db48f54: Fixed Rollup bundles to inline 'prop-types' and 'create-react-class' for UMD builds only. (reviewed by @spicyj, @trueadm )
* cf49cfd: Updated tests-passing.txt to remove tests that were deleted in this branch.
* d34109a: Responses to PR feedback from @spicyj. (Added package.json dependencies to packages/react and packages/react-dom. Renamed a var. Expanded on an inline comment.)
* 488c8d2: Added warning for moved package to React.checkPropTypes accessor too and updated build script.
* 83bcb29: Wordsmithing for deprecation notices (added fb.me links).
* afdc9d2: Tweaked legacy module inlining to remove order-of-deps constraint
* d1348b9: Removed $FlowFixMe.
* 7dbc3e7: More wordsmithing of deprecation notices based on Dan's feedback.
* Amended implementation-notes.md to include a link to a blog post by Dan Abramov, explaining the difference between components, elements, and instances. An understanding of this distinction is crucial in tracing through Implementation pseudocode, and reading Dan's blog first may ease newcomers into understanding the implementation.
* adjusted wording to maintain stylistic consistency with rest of content, per @aweary's request
* Remove non-existent /lib/ from souce files
* Replace all shims with explicit access
This deletes shims and changes to access require('react').__DO_NOT_USE__ from renderers for global shared state.
I cloned flattenChildren() and traverseAllChildren() because they relied on CurrentOwner but were used both from Stack and Isomorphic. The stack implementations will die, and the isomorphic ones can be changed to be optimized for Children specifically in the future.
I also deleted UMD shims because they are now unnecessary. I moved the internals assignment to main modules since they're now used in tests, and made them direct UMD entry points.
* Update example snippet in old 'React.addons' doc page
This makes the example more consistent.
* Add back the pointers in docs that were mistakenly removed
In https://github.com/facebook/react/pull/9359 we accidentally removed
pointers in some doc pages. Putting them back now.
* Link to npm package instead of github page
This seems like a more stable place to link to in the 'context'
document.
Based on @bvaughn's feedback in https://github.com/facebook/react/pull/9359
* `react-addons-test-utils` -> `react-dom/test-utils`
Updating all references and docs on the `React.addons.TestUtils` and the
shallow renderer to refer to the correct targets.
Instead of:
```
const React = require('react');
// ...
React.addons.Testutils
// or
const ReactTestUtils = require('react-addons-test-utils');
```
we now show:
```
const ReactTestUtils = require('react-dom/test-utils');
```
And for shallow renderer, instead of:
```
const shallowRenderer = TestUtils.createRenderer();
```
we now show:
```
const shallowRenderer = require('react-test-renderer/shallow');
```
* Update the 'prev' and 'next' attributes of 'add-ons' docs
These flags are used to set arrow links to easily navigate through the
documents. They were wrong or missing in some of the 'add-ons' pages and
this bothered me when manually testing the updates from the previous
commit.
* Update syntax for instantiating shallow renderer
Missed this when updating the docs for the changes to shallow-renderer
in React 15.5.
* Fix pointers in addons docs
Thanks @bvaughn for catching this
* Make example of shallow renderer more consistent
We should show using the same variable names between code samples.
* Make names in example even more consistent
We should use the same variable name for the same thing across examples.
`renderer` -> `shallowRenderer`.
* Update docs to deprecate React<CSS>TransitionGroup
- removes link to the docs about `ReactCSSTransitionGroup` and
`ReactTransitionGroup` from the main navigation
- updates 'prev' and 'next' pointers to skip this page
- adds deprecation warning to the top of the page
- remove references to these modules from the packages README
- updates 'add-ons' main page to list this as a deprecated add-on
* Update `React.createClass` to `createReactClass` in the docs
The `React.createClass` method is being deprecated in favor of
`createReactClass`.
* Remove 'React.createClass' from top level API docs
It no longer makes sense to have a section for the 'createClass' method
in this page, since it won't be available as a top level method on
'React'.
I initially was going to pull the section about 'createClass' into a
separate page to add under 'addons' but it was short and duplicative of
the 'react-without-es6' docs. So I just linked to those.
* Remove *most* `React.PropTypes` from the docs
I am doing the docs for `context` in a separate commit because that case
was a bit less clear-cut.
We will no longer support `React.PropTypes` as a built-in feature of
React, and instead should direct folks to use the `PropTypes` project
that stands alone.
Rather than retaining the `React.PropTypes` examples and just revamping
them to show the use of the stand-alone `PropTypes` library with React,
it makes more sense to direct people to that project and reduce the
perceived API area and complexity of React core. The proper place to
document `PropTypes` is in the README or docs of that project, not in
React docs.
* Update `context` docs to not use `React.PropTypes`
We use `React.PropTypes` to define the `contextType` for the `context`
feature of React. It's unclear how this will work once `React.PropTypes`
is replaced by the external `PropTypes` library. Some options;
a) Deprecate `context`, either in v16 or shortly after. Seems reasonable
based on the intense warnings against using context that we have in the
docs -
https://facebook.github.io/react/docs/context.html#why-not-to-use-context
**Except** that probably some widely used libraries depend on it, like
`React-Router`.
b) Expect users will use external `PropTypes` library when defining
`contextTypes` and just don't do our `checkReactTypeSpec` against them
any more in v16.
c) Stop masking context and pass the whole context
unmasked everywhere. Worst option, do not recommend.
I went with `b` and assume that, for now, we will get users to use the
external `PropTypes` when defining context. I will update this PR if we
want a different approach.
* Remove 'addons' items from left nav, and deprecate 'addons' doc page
The plan:
[X] Remove links to 'addons' items from main navigation
[X] Add deprecation notices where appropriate, and update syntax to show
using the separate modules.
[ ] Update other references to 'React.addons' in docs. Coming in next
commit.
--- blocked but coming in future PRs
[ ] Link to a blog post describing the new locations of add-ons in the
deprecation notice on the '/docs/addons.html' page. Blocked until we
actually publish that blog post.
[ ] Move the docs for each add-on to the actual github repo where it now
lives.
[ ] Redirect the old add-ons doc permalinks to the docs in the separate
github repos for those modules.
[ ] Remove the old add-ons doc markdown files from React core docs.
* Remove references to `React.addons` from docs
Just misc. places where we referenced the 'addons' feature. All gone!
* WIP
* fbjs support
* WIP
* dev/prod mode WIP
* More WIP
* builds a cjs bundle
* adding forwarding modules
* more progress on forwarding modules and FB config
* improved how certain modules get inlined for fb and cjs
* more forwarding modules
* added comments to the module aliasing code
* made ReactPerf and ReactTestUtils bundle again
* Use -core suffix for all bundles
This makes it easier to override things in www.
* Add a lazy shim for ReactPerf
This prevents a circular dependency between ReactGKJSModule and ReactDOM
* Fix forwarding module for ReactCurrentOwner
* Revert "Add a lazy shim for ReactPerf"
This reverts commit 723b402c07116a70ce8ff1e43a1f4d92052e8f43.
* Rename -core suffix to -fb for clarity
* Change forwarding modules to import from -fb
This is another, more direct fix for ReactPerf circular dependency
* should fix fb and cjs bundles for ReactCurrentOwner
* added provides module for ReactCurrentOwner
* should improve console output
* fixed typo with argument passing on functon call
* Revert "should improve console output"
This breaks the FB bundles.
This reverts commit 65f11ee64f678c387cb3cfef9a8b28b89a6272b9.
* Work around internal FB transform require() issue
* moved ReactInstanceMap out of React and into ReactDOM and ReactDOMFiber
* Expose more internal modules to www
* Add missing modules to Stack ReactDOM to fix UFI
* Fix onlyChild module
* improved the build tool
* Add a rollup npm script
* Rename ReactDOM-fb to ReactDOMStack-fb
* Fix circular dependencies now that ReactDOM-fb is a GK switch
* Revert "Work around internal FB transform require() issue"
This reverts commit 0a50b6a90bffc59f8f5416ef36000b5e3a44d253.
* Bump rollup-plugin-commonjs to include a fix for rollup/rollup-plugin-commonjs#176
* Add more forwarding modules that are used on www
* Add even more forwarding modules that are used on www
* Add DOMProperty to hidden exports
* Externalize feature flags
This lets www specify them dynamically.
* Remove forwarding modules with implementations
Instead I'm adding them to react-fb in my diff.
* Add all injection necessary for error logging
* Add missing forwarding module (oops)
* Add ReactART builds
* Add ReactDOMServer bundle
* Fix UMD build of ReactDOMFiber
* Work in progress: start adding ReactNative bundle
* tidied up the options for bundles, so they can define what types they output and exclude
* Add a working RN build
* further improved and tidied up build process
* improved how bundles are built by exposing externals and making the process less "magical", also tidied up code and added more comments
* better handling of bundling ReactCurrentOwner and accessing it from renderer modules
* added NODE_DEV and NODE_PROD
* added NPM package creation and copying into build chain
* Improved UMD bundles, added better fixture testing and doc plus prod builds
* updated internal modules (WIP)
* removed all react/lib/* dependencies from appearing in bundles created on build
* added react-test-renderer bundles
* renamed bundles and paths
* fixed fixture path changes
* added extract-errors support
* added extractErrors warning
* moved shims to shims directory in rollup scripts
* changed pathing to use build rather than build/rollup
* updated release doc to reflect some rollup changes
* Updated ReactNative findNodeHandle() to handle number case (#9238)
* Add dynamic injection to ReactErrorUtils (#9246)
* Fix ReactErrorUtils injection (#9247)
* Fix Haste name
* Move files around
* More descriptive filenames
* Add missing ReactErrorUtils shim
* Tweak reactComponentExpect to make it standalone-ish in www
* Unflowify shims
* facebook-www shims now get copied over correctly to build
* removed unnecessary resolve
* building facebook-www/build is now all sync to prevent IO issues plus handles extra facebook-www src assets
* removed react-native-renderer package and made build make a react-native build dir instead
* 😭😭😭
* Add more SSR unit tests for elements and children. (#9221)
* Adding more SSR unit tests for elements and children.
* Some of my SSR tests were testing for react-text and react-empty elements that no longer exist in Fiber. Fixed the tests so that they expect correct markup in Fiber.
* Tweaked some test names after @gaearon review comment https://github.com/facebook/react/pull/9221#discussion_r107045673 . Also realized that one of the tests was essentially a direct copy of another, so deleted it.
* Responding to code review https://github.com/facebook/react/pull/9221#pullrequestreview-28996315 . Thanks @spicyj!
* ReactElementValidator uses temporary ReactNative View propTypes getter (#9256)
* Updating packages for 16.0.0-alpha.6 release
* Revert "😭😭😭"
This reverts commit 7dba33b2cfc67246881f6d57633a80e628ea05ec.
* Work around Jest issue with CurrentOwner shared state in www
* updated error codes
* splits FB into FB_DEV and FB_PROD
* Remove deps on specific builds from shims
* should no longer mangle FB_PROD output
* Added init() dev block to ReactTestUtils
* added shims for DEV only code so it does not get included in prod bundles
* added a __DEV__ wrapping code to FB_DEV
* added __DEV__ flag behind a footer/header
* Use right haste names
* keeps comments in prod
* added external babel helpers plugin
* fixed fixtures and updated cjs/umd paths
* Fixes Jest so it run tests correctly
* fixed an issue with stubbed modules not properly being replaced due to greedy replacement
* added a WIP solution for ReactCurrentOwner on FB DEV
* adds a FB_TEST bundle
* allows both ReactCurrentOwner and react/lib/ReactCurrentOwner
* adds -test to provides module name
* Remove TEST env
* Ensure requires stay at the top
* added basic mangle support (disbaled by default)
* per bundle property mangling added
* moved around plugin order to try and fix deadcode requires as per https://github.com/rollup/rollup/issues/855
* Fix flow issues
* removed gulp and grunt and moved tasks to standalone node script
* configured circleci to use new paths
* Fix lint
* removed gulp-extract-errors
* added test_build.sh back in
* added missing newline to flow.js
* fixed test coverage command
* changed permissions on test_build.sh
* fixed test_html_generations.sh
* temp removed html render test
* removed the warning output from test_build, the build should do this instead
* fixed test_build
* fixed broken npm script
* Remove unused ViewportMetrics shim
* better error output
* updated circleci to node 7 for async/await
* Fixes
* removed coverage test from circleci run
* circleci run tets
* removed build from circlci
* made a dedicated jest script in a new process
* moved order around of circlci tasks
* changing path to jest in more circleci tests
* re-enabled code coverage
* Add file header to prod bundles
* Remove react-dom/server.js (WIP: decide on the plan)
* Only UMD bundles need version header
* Merge with master
* disabled const evaluation by uglify for <script></script> string literal
* deal with ART modules for UMD bundles
* improved how bundle output gets printed
* fixed filesize difference reporting
* added filesize dep
* Update yarn lockfile for some reason
* now compares against the last run branch built on
* added react-dom-server
* removed un-needed comment
* results only get saved on full builds
* moved the rollup sized plugin into a plugins directory
* added a missing commonjs()
* fixed missing ignore
* Hack around to fix RN bundle
* Partially fix RN bundles
* added react-art bundle and a fixture for it
* Point UMD bundle to Fiber and add EventPluginHub to exported internals
* Make it build on Node 4
* fixed eslint error with resolve being defined in outer scope
* Tweak how build results are calculated and stored
* Tweak fixtures build to work on Node 4
* Include LICENSE/PATENTS and fix up package.json files
* Add Node bundle for react-test-renderer
* Revert "Hack around to fix RN bundle"
We'll do this later.
This reverts commit 59445a625962d7be4c7c3e98defc8a31f8761ec1.
* Revert more RN changes
We'll do them separately later
* Revert more unintentional changes
* Revert changes to error codes
* Add accidentally deleted RN externals
* added RN_DEV/RN_PROD bundles
* fixed typo where RN_DEV and RN_PROD were the wrong way around
* Delete/ignore fixture build outputs
* Format scripts/ with Prettier
* tidied up the Rollup build process and split functions into various different files to improve readability
* Copy folder before files
* updated yarn.lock
* updated results and yarn dependencies to the latest versions
features → feature
> There is nothing "bad" about using state or lifecycle hooks in components. Like any powerful feature**s**, they should be used in moderation, but we have no intention to remove them.
I can’t explain the exact grammatical principle this violates, but it sounds wrong to my native English ears that “feature” is plural here. Another way to check if the grammar sounds right is to change the order of the clauses: ”They should be used in moderation, like any powerful feature“ sounds right, whereas “They should be used in moderation, like any powerful features” does not.
* Show more meanignful stack trace for ReactNative errors
Clicking on the stack should jump to where the error actually occurred rather than to where it's logged in a redbox component.
* Made showDialog() return type stricter. Added mock and Flow types for ExceptionManager
* Prettier
* Handle null/string thrown errors
* Removed unused reference to emptyFunction
IE11 and Edge have a password unmask field that React prevents the
display of for controlled inputs. This commit adds DOM fixture
coverage for this test case.
If your renderer doesn't use host context, you might prefer to return null. This used to give an error:
> Invariant Violation: Expected host context to exist. This error is likely caused by a bug in React. Please file an issue.
I use a sentinel value instead now.
The code in ReactFiberHostContext is a little complicated now. We could probably also just remove the invariants.
* Remove captured scroll feature check
IE8 was the only browser that did not support captured scroll. We no
longer have that constraint.
* Remove WINDOW_HANDLE const
* Only re-assign defaultValue if it is different
* Do not set value if it is the same
* Properly cover defaultValue
* Use coercion to be smart about value assignment
* Add explanation of loose type checks in value assignment.
* Add test coverage for setAttribute update.
* Only apply loose value check to text inputs
* Fix case where empty switches to zero
* Handle zero case in controlled input
* Correct mistake with default value assignment after rebase
* Do not assign bad input to number input
* Only trigger number input value attribute updates on blur
* Remove reference to LinkedValueUtils
* Record new fiber tests
* Add tests for blurred number input behavior
* Replace onBlur wrapper with rule in ChangeEventPlugin
* Sift down to only number inputs
* Re-record fiber tests
* Add test case for updating attribute on uncontrolled inputs. Make related correction
* Handle uncontrolled inputs, integrate fiber
* Reorder boolean to mitigate DOM checks
* Only assign value if it is different
* Add number input browser test fixtures
During the course of the number input fix, we uncovered many edge
cases. This commit adds browser test fixtures for each of those instances.
* Address edge case preventing number precision lower than 1 place
0.0 coerces to 0, however they are not the same value when doing
string comparision. This prevented controlled number inputs from
inputing the characters `0.00`.
Also adds test cases.
* Accommodate lack of IE9 number input support
IE9 does not support number inputs. Number inputs in IE9 fallback to
traditional text inputs. This means that accessing `input.value` will
report the raw text, rather than parsing a numeric value.
This commit makes the ReactDOMInput wrapper check to see if the `type`
prop has been configured to `"number"`. In those cases, it will
perform a comparison based upon `parseFloat` instead of the raw input
value.
* Remove footnotes about IE exponent issues
With the recent IE9 fix, IE properly inserts `e` when it produces an
invalid number.
* Address exception in IE9/10 ChangeEventPlugin blur event
On blur, inputs have their values assigned. This is so that number
inputs do not conduct unexpected behavior in
Chrome/Safari. Unfortunately, there are cases where the target
instance might be undefined in IE9/10, raising an exception.
* Migrate over ReactDOMInput.js number input fixes to Fiber
Also re-record tests
* Update number fixtures to use latest components
* Add number input test case for dashes and negative numbers
* Replace trailing dash test case with replace with dash
Also run prettier
* Adding more SSR unit tests for elements and children.
* Some of my SSR tests were testing for react-text and react-empty elements that no longer exist in Fiber. Fixed the tests so that they expect correct markup in Fiber.
* Tweaked some test names after @gaearon review comment https://github.com/facebook/react/pull/9221#discussion_r107045673 . Also realized that one of the tests was essentially a direct copy of another, so deleted it.
* Responding to code review https://github.com/facebook/react/pull/9221#pullrequestreview-28996315 . Thanks @spicyj!
* Removed optimization for events without target in ReactNativeEventEmitter
This PR fixes the problem originally introduced in https://github.com/facebook/react/pull/6590
The problem is that `ResponderEventPlugin` (and `ResponderTouchHistoryStore`) relies on that fact that touch events are balanced.
So if one `startish` event happened, should be coming `endish` event. Otherwise there is no way to maintain internal `trackedTouchCount` counter. So, if we drop some events, we break this logic.
Moreover, that optimization clearly contradict with this statement from `ResponderEventPlugin`:
```
We must be resilient to `targetInst` being `null` on `touchMove` or
`touchEnd`. On certain platforms, this means that a native scroll has
assumed control and the original touch targets are destroyed.
```
This issue causes several major problems in React Native, and one of them (finally!) is easy to reproduce: https://github.com/facebook/react-native/issues/12976 .
The test also illustrates this problem.
* Prettier
* Addresses a circular dependency between NativeMethodsMixin and ReactNativeFiber:
* Created new ReactNativeFiberHostComponent with similar interface but without unnecessary call to findNodeHandle.
* Created new Flow interface for mixins to ensure ReactNativeFiberHostComponent and NativeMethodsMixinUtils stay synced.
* Moved helper methods to NativeMethodsMixinUtils to be shared between the 2 wrappers.
This diff was submitted and reviewed internally along with some other ReactNative changes. This is the React-only portion.
* Removed unused Flow type import
* Copied a Flow fix from internal
* Added a handful of SSR unit tests, ported from a previous pull request.
* Fixing linting errors
* Fixed a test helper function to properly report errors.
* Un-nested the new rendering tests. Updated the fiber test passing/not passing lists.
* Edited to comply with the react/jsx-space-before-closing eslint rule, which will soon be merged into master.
* Response to code review from @spicyj. Moved tests to separate file, reworked wording of test names, corrected use of canUseDom, and simplified tests against tagName. Thanks for the help, @spicyj!
* Converted the unit tests to use async-await style.
* Moved async-await babel transform for tests from .babelrc to preprocessor.js.
* Response to code review in PR #9089. Thanks, @spicyj!
* Fixing some bugs in the SSR unit tests.
* Missed deleting some repeated code in the last commit.
* Adding unit tests for property to attribute mapping in SSR.
* Removing some redundant unit tests.
* Oops. I forgot to re-run record-tests after c593dbc; fixing that here.
* Reformatting for prettier so that the build will pass.
In ReactDOM we don't dispatch events in the synthetic event system on to
text nodes. We back up one to the element before dispatching.
In React Native we don't do that. The iOS native side doesn't dispatch on
the text nodes but only the parent. The Android native side however does
dispatch on text nodes.
We already covered this for strings, but current element in Stack can be
a number if it is numeric text content.
`scripts/prettier/index.js write` will run prettier on source files.
Run using `yarn prettier`.
`scripts/prettier/index.js` will throw if any source files are not
formatted with prettier. We'll use this to block CI.
Based on similar script in Jest repo.
* Updated Chain React
Changed conference date from "Summer 2017" to given date on website
* Updated React Native EU
Updated date and place with information from website
* Fix version bump script when files are missing
* Add noop renderer to version bump script
Without this, grunt build fails due to the version mismatch.
* Remove unnecessary second getComponentName()
We already have one. The other one is also less fragile and doesn't throw on null type.
* Make setState in render warning check simpler
This skips it earlier since in most cases phase won't be "render".
This is unobservable.
* wip
* better
* better
* track commits
* better
* wip
* Fix
* Add some lifecycles
* wip
* Naming
* Moar emojis
* Remove stacks in favor of a flag
* Fix Flow
* Gate behind __DEV__
* Revert flag for testing
* Measure all lifecycles
* Push it to the limits
* Polish
* Indent
* Refactor and track cascading updates
* More prominent warnings
* Make mark names themselves readable
This is useful for RN Systrace which doesn't let us assign labels after the fact.
* Keep track of how many effects we call
* Fix typo
* Do less work to reduce the overhead
* Fix lint
* Remove closure
* Remove unintentional formatting changes
* Add tests
* Fix test regex and record tests
* Disable irrelevant tests needed for ReactPerf
* Fix typo
* Fix lint and flow
* Don't treat cWM or cWRP as cascading
* Whitespace
* Update tests
* Gate callComponentWillUnmountWithTimerInDev definition by DEV
* Move EventPluginRegistry._resetEventPlugins to DEV
This is not called during runtime at all and is only using in internal unit tests. Despite that, its currently being included in production builds. This change makes it so its only defined in DEV, which might even be too much (we can maybe inject it in our unit tests to avoid defining it at all in EventPluginRegistry)
* Remove _resetEventsPlugin, use resetModuleRegistry
This moves the non DEV methods to a new file called ReactFiberComponentTreeHook, updates existing references to DEV functions to remain inside DEV flags so they do not pull in ReactComponentTreeHook
* Don't schedule class fibers without relevant lifecycles for commit
* Separate Update and Ref effects
* Simplify the exit condition
* Add missing annotation
* Write conditions differently to avoid an extra check
* Inline markUpdateIfNecessary()
* Inline markUpdateIfAlreadyInProgress()
* add fixture components
* add a few more options and styles
* Test fixture updates
- Pull in React from window global
- Add field to TestCase for fix PR links
- Update some styles
* Remove unused Fixture.Result comment
* Remove leading # from resolvedBy link
* Implement tag loading utility that caches response
Don't bust the cache doing feature detection
COME ON
* Use 'local' without version for option
* Update Lifting State Up not to mix up DOM value with component state
A few weeks ago when teaching my friend, she got stuck on
`this.state.value` vs. `event.target.value`. As the documentation
talked a lot about "values", and the term value could mean three
different things (values in general, the "value" prop / DOM value of
the <input> component and the value in state/props), it was not weird
that she got a bit confused.
* Rename Lifting State Up onChange props to onTemperatureChange
This is in-line with how the temperature is provided as a prop named `temperature`
* Fix one value prop not being renamed to temperature
* Update codepen examples in Lifting state up documentation
* Update devtools state change to reflect docs change
* Added a handful of SSR unit tests, ported from a previous pull request.
* Fixing linting errors
* Fixed a test helper function to properly report errors.
* Un-nested the new rendering tests. Updated the fiber test passing/not passing lists.
* Edited to comply with the react/jsx-space-before-closing eslint rule, which will soon be merged into master.
* Response to code review from @spicyj. Moved tests to separate file, reworked wording of test names, corrected use of canUseDom, and simplified tests against tagName. Thanks for the help, @spicyj!
* Replace the header_links plugin with client-side generated anchors.
Fixesfacebook/react#4124
* Move anchor-link code into a separate script
Also adds a couple comments, for context.
Renderers can determine whether a node's children are offscreen based on
the host component's props. If so, they are given OffscreenPriority.
useSyncScheduling takes precedence.
When useSyncScheduling is set to true (as it is in the DOM renderer),
we shouldn't give OffscreenPriority to hidden subtrees. Everything
should be sync/task.
* Add forwarding modules
* Codemod to use full package path outside of own package
Files that require modules from a different package than their own now
does so by the npm path name instead of the providesModule.
* Codemod fbjs module dependencies
* Fix gulp module mapping config
This is a bit lame but because of our module rewrite we need to white
list all the paths that we don't *don't* want to rewrite.
* Move webcomponents.js polyfill to mocks
I'd like to move it out of shared to make it easier to sync this to RN.
Since this is only used for testing and a polyfill is essentially a mock.
Maybe this makes sense?
Rename to camel case to be consistent with providesModule.
* Update path to ignore in configs
Added a guard in the global error event listener to prevent nested
errors from being captured higher up the stack.
Also found a bug where the DEV version of invokeGuardedCallback would
infinite loop if there were nested invocations with the same name. Fixed
by appending the depth to the fake event name. (I'm actually not sure
why this is necessary.)
We can use this more flexible version for error handling in Fiber.
The DEV mode version uses same fake event trick as before to preserve
"break on uncaught exception" behavior when debugging.
Stack uses a module called ReactInvalidSetStateWarningHook, but all it
does is warn about setState inside getChildContext. Doesn't seem worth
keeping around, so I didn't use it for Fiber, but if I'm mistaken I'll
change it.
Allows users to check arbitrary objects against React prop types without
relying on the implementation details of the prop validators themselves.
An example of why this is important: some prop validators may throw,
while others return an error object. Calling a prop validator manually
requires handling both cases. `checkPropTypes` does this for you.
ReactPropTypeLocationNames was a map of location identifiers to location
display names, for use in warnings. But in practice, this did nothing
except rename "childContext" to "child context." Not worth it, IMO.
Since we are going to add an API for running prop type checks manually,
we need the ability to support arbitrary prop type locations. So
each place that used to accept a ReactPropTypeLocation now just accepts
a string.
> This PR adds a test (initially failing) for this case along with a fix for stack and fiber. The stack fix was copied from a Diff submitted by @sema. The fiber fix just required us to stop leaking properties for unmounted views.
> Longer term we may want to explicitly invoke a release event listener for a responder just before unmounting it. This PR does not do that.
Due to how Jest and other mocking libraries work in userland, modules that are required might not be referentially equal at various stages of the application lifecycle. This isnt a perfect fix, but by having the require calls inline, it has a better liklihood of ensuring emptyObject is the same reference
ReactStatelessComponent-test.js fails due to warnings not showing up when functional components mount or update. This PR ports the existing warnings from stack and re-applies them to fiber functional components and attempts to re-use some logic in ReactFiberContext that currently exists for showing warnings when dealing with class components.
...without dropping the update. This won't work the other way around,
if you assign to this.state before calling setState. we'll add a
deprecation warning so people stop relying on this pattern.
* Improved for a better understanding
that code shouldn't name this parameter onchange. It is so confusing for a starter of ReactJs like me. It looks like that the onChange is an common event from props.
* Update the lifting state up paragraph
I tried to write something to explain to starter programmers in react, how we lift the state up calling a method defined by the ancestor and called by the children that will affect the children element.
* Rewrite Lifting State Up
Now we won't add closures unnecessarily. I verified that we have no code that throws -- adding some then running `grunt build:modules` correctly throws.
In React Native events can fire on text nodes (on Android at least).
In that case, the current element will be a string and not props. These
can not have event handlers on them so we need to bail out so that
we don't throw later on.
Test Plan: Couldn't figure out how to write a unit test. :\ Verified that enter/leave bubbling now works correctly in one FB interface that was broken though.
This is currently used by both isomorphic and the renderer. I think that
we can probably split these up. The isomorphic type should actually be
different. It has to do with that the caller needs to know exactly which
type of element it is but this is never needed in the renderer which only
needs to know that the type is internally consistent.
The owner type is renderer dependent so it can literally be anything.
This delays the type check until the point when the engine will have to
perform a type check regardless.
Because the error is now thrown during the commit phase rather than
when the callback is originally scheduled, we warn in DEV when
scheduling so it's easier to track down.
Flow maybe types accept both null and undefined. When the final
parameter of a function accepts a maybe type, passing nothing
(undefined) successfully typechecks, which can lead to bugs if the
omission is accidental. Being forced to pass null is harder to screw up.
Explicit null checks are also faster.
Previously, calls to validateCallback() with a null callback value resulted in runtime errors if a certain transform was not applied prior to running. This commit wraps the invariant() with the condition check so as to avoid calling formatUnexpectedArgument() unless necessary. It also replaces the truthy/falsy callback check with an explicit check for improved performance.
* Add toTree() method to stack and fiber TestRenderer
* Address PR feedback
* Refactor TestRenderer to use correct root
* Rebase off master and fix root node references
* Add flow types
* Add test for null rendering components
* Remove last remaining lint error
* Add missing test
These mocks are things we expect to be available in the React Native
environment. I'd like to move them out of the renderer folder so that we
can sync that folder to React Native as is without overriding its mocks.
I motivate by the fact that they're not really part of the renderer code
itself. I leave the ReactNative mock since that is in fact part of the
renderer.
* Fixed ReactNativeFiber event system regression introduced in b354db2
Also added test coverage to ReactNativeEvents-test for Fiber
* ReactNative tests now run against fiber renderer when env flag set
Updated the test-framework-setup file so that record-tests runs native tests against ReactNativeFiber. ReactComponentTreeHook native tests all now fail but that's expected.
* Avoid calling setChildren() if no children
Submitted this internally already.
Needed because people import this file directly and they might not have the renderer inject the findNodeHandle handler yet.
We have a bunch of tests that are meant to test generic React behavior.
However, we've written the tests against the DOM renderer. This moves
tests that depend on ReactDOM or ReactTestUtils out of the shared repo.
This will let us sync the shared repo directly to environments that don't
support running these tests. Such as React Native.
* Revert "Revert "Warn if PropType function is called manually (#7132)""
This reverts commit be71f76ed8b7dbad25e3519455605252d3daf683.
In other words, now we again have the warning if you attempt to call PropTypes manually.
It was removed in #8066 but we shouldn't have done this since we still want to avoid people accidentally calling them in production (and even more so since now it would throw).
Fixes#8080.
* Pass secret in ReactControlledValuePropTypes
* Record tests
The entries of a map are a two-element array of [key, value], which
React will treat as fragments with children. This is unlikely to ever
be the intended behavior, so we warn.
It is strange to get a handle on the Fiber since it is one of possibly two
root Fibers. The correct way to get the current Fiber is through the
root.current.
I exposed the Fiber originally because I thought we might use it for
Portals but we went with a different approach. So we don't need this.
* Add note about refs on stateless components
* Move info about refs in the stateless components to the main section
* Simplification of the part about refs and functional components
* Tweaks
* Move sections around
* Oops
* Rearrange more sections
* Add onToggle event to details tag
Fixes#8761
* Map onToggle event on ReactDOMFiberComponent
* Tweak doc
* Trap events on setInitialProperties for details tag
The production error code system depends on the exact template string
that is passed to `invariant`. This changes the Fiber templates to
match the Stack ones.
* Explain arbitrariness of ref name in callback
The sample code was confusing because it's not clear that "textInput" in this.textInput is an arbitrary name for the ref.
* Tweak wording
* 'beginLifeCycleTimer' function of ReactDebugTool.js
* 'bindAutoBindMethod' function of ReactClass.js
* 'warnNoop' function of ReactServerUpdateQueue.js
* 'getInternalInstanceReadyForUpdate' function of ReactUpdateQueue.js
* 'warnNoop' function of ReactNoopUpdateQueue.js
* 'getDeclarationErrorAddendum' function of ReactDOMComponent.js
* 'getSourceInfoErrorAddendum' function of ReactElementValidator.js
* 'getDeclarationErrorAddendum' function of instantiateReactComponent.js and ReactElementValidator.js
* 'traverseAllChildrenImpl' function of traverseAllChildren.js
* 'attachRef' function of ReactRef.js
* 'mountIndeterminateComponent' function of ReactFiberBeginWork.js
* 'createFiberFromElementType' function of ReactFiber.js
* 'getDeclarationErrorAddendum' function of ReactDOMSelect.js
* 'unmountComponentAtNode' function of ReactMount.js
* 'getDeclarationErrorAddendum' function of ReactControlledValuePropTypes.js
* 'checkRenderMessage' function of CSSPropertyOperations.js
* 'getDeclarationErrorAddendum' function of ReactDomFiberSelect.js
* 'getCurrentComponentErrorInfo' function in 'ReactElementValidator'
* 'getDeclarationErrorAddendum' function in ReactDOMFiberComponent.js
* Initial React DevTools support for Fiber
* Record a newly failing irrelevant test
This is fine because we don't use it in Stack anyway (at least not that part), and we also rely on Set/Map in other parts of code.
The newly failing test is the one saying "it works without Map/Set".
* Explicitly check for Fiber DevTools support
This lets us ignore pre-Fiber DevTools instead of crashing them by injecting a different API.
* Track the roots in DevTools instead
* Lol Dan this is not how warnings work in our codebase
* Move injection to the renderer
* Notify DevTools about unmounts
* Make it work in production
* Fix lint and flow
* Fixups
* Address feedback
When visiting the yields, the root is the stateNode of the coroutine. If
its return value is wrong we'll end up at the alternate of the
workInProgress which will start scanning its children which is wrong.
There are a few different issues:
* Updates result in unnecessary duplicate placements because it can't find the current fiber for continuations.
* When run together, coroutine update and unmounting tests appear to lock down in an infinite loop. They don't freeze in isolation.
I don't have a solution for this but just leaving it for future fixes.
Coroutines was kind of broken because it tried to do reparenting and
enabling state preservation to be passed along the coroutine. However,
since we couldn't determine which Fiber was "current" on a reified yield
this was kind of broken.
This removes the "continuation" part of yields so they're basically just
return values. It is still possible to do continuations by just passing
simple functions or classes as part of the return value but they're not
stateful.
This means that we won't have reparenting, but I actually don't think we
need it. There's another way to structure this by doing all the state in
the first phase and then yielding a stateless representation of the result.
This stateless representation of the tree can then be rendered in different
(or even multiple) locations.
Because we no longer have a stateful continuation, you may have noticed
that this really no longer represent the "coroutine" concept. I will
rename it in a follow up commit.
It is slightly more useful this way because when we want to find host nodes
we typically want to do so in the second phase. That's the real tree where
as the first phase is more of a virtual part of the tree.
* Add benchmarking tutorial
I've written what I hope is the simplest introduction to benchmarking React components. It's meant to be straightforward and easy to follow for beginners. If you agree that it would be helpful, I'd like to add it to the docs.
Would also welcome any and all feedback.
* Just put links together
* Reminder: strip quotes from attributes with JS code
Web developers who are used to standards-compliant HTML and XML will, out of habit, put quotes around all attributes because the standards require them. Other templating systems like ASP.NET also require (or at least allow) quotes around attributes that contain code. This behavior will get users into trouble in JSX because a quoted attribute is always treated as a string literal, even if it contains curly-braced javascript code. Let's add to the docs to help newbies evade this problem.
* Tweak wording
I introduce the ReactDOMFrameScheduling module which just exposes
rIC and rAF.
The polyfill works by scheduling a requestAnimationFrame, store the time
for the start of the frame, then schedule a postMessage which gets
scheduled after paint. The deadline is set to time + frame rate.
By separating the idle call into a separate event tick we ensure that
layout, paint and other browser work is counted against the available time.
The frame rate is dynamically adjusted by tracking the minimum time between
two rAF callbacks. This is not perfect because browsers can schedule
multiple callbacks to catch up after a long frame. To compensate for this
we only adjust if two consecutive periods are faster than normal.
This seems to guarantee that we will hit frame deadlines and we don't end
up dropping frames. However, there is still some lost time so we risk
starving by not having enough idle time.
Especially Firefox seems to have issues keeping up on the triangle demo
However, that is also true for native rIC in Firefox. It seems like more
render work is scheduled on the main thread pipeline and also that JS
execution just generally has more overhead.
It's not just events that read the current props. Controlled components
do as well. Since we're no longer updating the Fiber pointer during updates
we have to instead read from the node props to get the current props.
Since this method is no longer just used for events I renamed it.
* Allow renderers to return an update payload in prepareUpdate
This then gets stored on updateQueue so that the renderer doesn't need to
think about how to store this.
It then gets passed into commitUpdate during the commit phase.
This allows renderers to do the diffing during the time sliced path,
allocate a queue for changes and do only the absolute minimal work to
apply those changes in the commit phase.
If refs update we still schedule and update.
* Hack around the listener problem
* Diff ReactDOMFiber properties in prepareUpdate
We now take advantage of the new capability to diff properties early.
We do this by generating an update payload in the form of an array with
each property name and value that we're about to update.
* Add todo for handling wasCustomComponentTag
* Always force an update to wrapper components
Wrapper components have custom logic that gets applied at the commit phase
so we always need to ensure that we schedule an update for them.
* Remove rootContainerInstance from commitMount
No use case yet and I removed it from commitUpdate earlier.
* Use update signal object in test renderer
* Incorporate 8652 into new algorithm
* Fix comment
* Add failing test for flipping event handlers
This illustrates the problem that happens if we store a pointer to the
Fiber and then choose not to update that pointer when no properties change.
That causes an old Fiber to be retained on the DOM node. Then that Fiber
can be reused by the pooling mechanism which then will mutate that Fiber
with new event handlers, which makes them active before commit.
* Store current props in the RN instance cache and on the DOM node
This represents the current set of event listeners. By not relying on the
Fiber, it allows us to avoid doing any effects in the commit phase when
nothing changes.
This is a bit ugly. Not super happy how this all came together.
* use an easier word
The word `mandatory` is relatively difficult for people with ESL (English as a second language), so I propose an alternative word.
This would be much easier to understand.
* use simpler word
* FiberDebugger uses packages built in local
* Fix key warnings in FiberDebugger
* Remove react packages from package.json and yarn.lock for using pacakges built in local
* Remove fiber.js from `files` in package.json
* Add a test for rendering SVG into a non-React SVG tree
It is failing in Fiber.
* Add a test for rendering HTML into non-React foreignObject
It happens to pass in Fiber.
* Determine root namespace by container namespace, not just tag
A tag alone is not enough to determine the tree namespace.
* Skip the test that exhibits jsdom bug in non-createElement mode
jsdom doesn't give HTML namespace to foreignObject.innerHTML children.
This problem doesn't exist in the browsers.
https://github.com/facebook/react/pull/8638#issuecomment-269349642
We will skip this test in non-createElement mode considering
that non-createElement mounting is effectively dead code now anyway.
A new module has been added (ReactFiberErrorLogger). This logs error information (call stack and component stack) to the console to make errors easier to debug. It also prompts users to use error boundaries if they are not already using them.
In the future, perhaps this will be injectable, enabling users to provide their own handler for custom processing/logging. For the time being, this should help with issues like this / #2461.
Previous (probably unintentional) behavior of Stack was to allow components to define childContextTypes without also supplying a getChildContext property. This PR updates Fiber to (temporarily) mimic that behavior. It also adds warning messages to both Fiber and Stack (along with a test).
For the time being, Fiber components with a missing getChildContext method will return the parent context as-is, after warning.
Fixes the case where there's an uncaught error and the root unmounts.
We implement this by rendering the root as if its child is null. Null is
not usually allowed at the top level, so we need to special case it.
Currently we update the memoized inputs (props, state) during the
complete phase, as we go back up the tree. That means we can't reuse
work until of its children have completed.
By moving memoization to the begin phase, we can do a shallow bailout,
reusing a unit of work even if there's still work to do in its children.
Memoization now happens whenever a fiber's `child` property is updated;
typically, right after reconciling. It's also updated when
`shouldComponentUpdate` returns false, because that indicates that the
given state and props are equal to the memoized state and props.
* fix failed tests on Windows #8737
* Use regexp literal instead of `RegExp` constructor so that we don't need to bother with escaping special character like `\` and `.`.
Note that by removing the path separator in regexp, I've relaxed the matching condition a little.Since there's little chance we have files like `XXXReact.d.ts`,it should not matter.
We have an invariant that checks the same case right afterwards.
The warning was originally added in #5884 with a distinct wording.
However it was later changed to the same wording as the invariant in #6008.
I don't see why we would want to have both since they're saying the same thing and with (almost) the same internal stack.
This test is identical to "should warn when stateless component returns array" earlier.
It was moved from another file in #5884 so it likely survived by accident.
* ReactTestRenderer move current impl to stack dir
* ReactTestRenderer on fiber: commence!
* ReactTestRenderer: most non-ref/non-public-instance tests are passing
* Move ReactTestFiberComponent functions from Renderer to Component file
* test renderer: get rid of private root containers and root Maps
* TestRenderer: switch impl based on ReactDOMFeatureFlag.useFiber
* ReactTestRenderer: inline component creation
* ReactTestRenderer: return to pristine original glory (+ Fiber for error order difference)
* TestRendererFiber: use a simple class as TestComponentInstances
* Add `getPublicInstance` to support TestRenderer `createNodeMock`
* Rename files to end. Update for `mountContainer->createContainer` change
* test renderer return same object to prevent unnecessary context pushing/popping
* Fiber HostConfig add getPublicInstance. This should be the identity fn everywhere except the test renderer
* appease flow
* Initial cleanup from sleepy work
* unstable_batchedUpdates
* Stack test renderer: cache nodeMock to not call on unmount
* add public instance type parameter to the reconciler
* test renderer: set _nodeMock when mounted
* More cleanup
* Add test cases for root fragments and (maybe?) root text nodes
* Fix the npm package build
Explicitly require the Stack version by default.
Add a separate entry point for Fiber.
We don't add fiber.js to the package yet since it's considered internal until React 16.
* Relax the ref type from Object to mixed
This seems like the most straightforward way to support getPublicInstance for test renderer.
* Remove accidental newline
* test renderer: unify TestComponent and TestContainer, handle root updates
* Remove string/number serialization attempts since Fiber ensures all textInstances are strings
* Return full fragments in toJSON
* Test Renderer remove TestComponent instances for simple objects
* Update babylon for exact object type syntax
* Use $$typeof because clarity > punching ducks.
* Minor Flow annotation tweaks
* Tweak style, types, and naming
* Fix typo
* Update refs-and-the-dom.md
I want to propose some changes to the Refs and the DOM documentation page.
- Make it clear that string refs are legacy. It seems that this information got lost during the transition to new docs and only some part stayed the same, which was confusing when first reading the docs.
- Clarify and explain that during render, if the ref callback is provided, it will get called twice, first with `null` and then with the rendered DOM element. Discussed in https://github.com/facebook/react/issues/4533 and first proposed docs change in PR #8333.
I've also planned on adding an example for passing the refs up the component chain based on something I've needed to solve myself (e.g. you want to connect two dynamic components by line in React, so you need to both use refs and propagate them up the chain), and while it would be great to read up on this in the docs, it may be too specific for this section; I'd be happy to hear any recommendations.
* Adds more specific information about the callback
* Moved the ref callback description to the Caveats section
* Fixed suggested nits
* Replace 'each render pass' with 'updates'
* Tweak the wording
* Verify that functional component ref warning is deduplicated
It's not a big problem for string refs because the ref stays the same and the warning code path runs once per mount.
However, it is super annoying for functional refs since they're often written as arrows, and thus the warning fires for every render.
Both tests are currently failing since we're mounting twice, so even the string ref case prints warnings twice.
* Extract the warning condition to the top level
We don't want to run getStackAddendumByID() unless we actually know we're going to print the warning.
This doesn't affect correctness. Just a performance fix.
* Deduplicate warnings about refs on functional components
This fixes the duplicate warnings and adds an additional test for corner cases.
Our goal is to print one warning per one offending call site, when possible.
We try to use the element source for deduplication first because it gives us the exact JSX call site location.
If the element source is not available, we try to use the owner name for deduplication.
If even owner name is unavailable, we try to use the functional component unique identifier for deduplication so that at least the warning is seen once per mounted component.
* Fiber: warn for refs on SFCs
* Stateless refs: update warning to use component stack
* Warn for function refs (stack and fiber)
* Add owner reference to ref warnings
* Centralize stack ref warnings in ReactRef.attachRef
* Fiber stateless comp ref warning should only do work when necessary
* ReactDebugCurrentFiber maybe FunctionalComponents should act this way instead
* (chore) scripts/fiber/record-tests
* Add component._compositeType to ReactInstance Flow definition
* Don't handle 'stack inside fiber' case in the warning
We don't have a test for it. It's easy to mess it up and print the wrong thing so instead of verifying it I'll just remove this bit.
* Revert the change to getCurrentFiberOwnerName
This happened to work, but it is just a coincidence. This change didn’t really match what the function was supposed to be doing.
I’m not sure what the correct fix would be yet so this commit breaks tests.
* Add component indirection to the tests using owner name
This passes in Stack. It helps ensure we supply the correct owner name.
* Invalid type invariant should read owner from element
This brings the Fiber behavior in line with how Stack does it. The Fiber test was passing accidentally but broke down in more complicated cases (such as when we have an <Indirection> between the owner and the failing element).
Now we can also remove the weird cases from getCurrentFiberOwnerName() that didn't really make sense but helped get the (incomplete) tests pass in the past.
* Fiber should throw on a string ref inside functional component
Only store cached masked/unmasked contexts on context consumers. Move all references to __reactInternal* cached attributes inside of ReactFiberContext.
* Show Source Error Addemden if __source available
* Add Parent Stack on invalid element type
* refactor to use normalizeCodeLocInfo
* Remove ( ) from addendum
This moves the current fixture architecture to one based around create-react-app. There are a few important things to note:
* The react-loader.js script is always loaded before the bundle and will populate React and ReactDOM on the window. It is then read from the window by all components.
* The UI for the "React Sandbox" or "React Fixtures App" is also rendered with whatever version of React the user has selected. This means we dont have to deal with iframes or worry about multiple versions of React potentially interferring. But it also means that all components must be written using createClass to be fully backwards compatable. I tested back to 0.13.1 and it works fine.
This will publish all packages in build/packages/*.tgz to the "next" tag. If the current version is "stable" (doesn't trigger semver.prerelease()) then it will also update the "latest" dist-tag to point at that version.
* Add manual build fixtures
* Inject ReactDOM into ReactWithAddons from ReactWithAddons
We used to read ReactDOM as a global inside ReactAddonsDOMDependenciesUMDShim.
This didn't work in AMD environments such as RequireJS and SystemJS.
Instead, I changed it so that ReactDOM gets injected into ReactWithAddons by ReactDOM itself.
This way we don't have to try to require it (which wouldn't work because AMD doesn't handle circular dependencies well).
This means you have to load ReactDOM first before using ReactDOM-dependent addons, but this was already the case before.
This commit makes all build fixtures pass.
* Memoize ReactDOM to avoid going into require on every access
* Add Brunch fixture
* Inline requires to work around Brunch bug
See #8556 and https://github.com/brunch/brunch/issues/1591#issuecomment-270742503 for context.
This appears to be a Brunch bug but we can keep a temporary fix until the next major.
* Fix typo in Proposing a Change section in how-to-contribute.md
Not sure if it was actually intended or was a typo but changed 'If you intend to change to the public API' --> 'If you intend to make a change to the public API'
* Simplify
* Component Lifecycle In Depth documentation
* first steps to improve react component reference
* improved react component reference
- remove the component-lifecycle-in-depth
* add a note for usage of ReactDOM.findDOMNode
* one note on componentWillReceiveProps
* remove old useless images for lifecycle docs
* Tweak wording
Moved ReactFiberClassComponent validateCallback() helper function into a standalone util used by both fiber and stack implementations. Validation now happens in ReactFiberUpdateQueue so that non-DOM renderers will also benefit from it.
Reverses the effect of batchedUpdates by resetting the current
batching context.
Does not affect nested updates, which are always deferred regardless
of whether they are inside a batch.
The DOM renderer assumes that resetAfterCommit is called after
prepareForCommit without any nested commits in between. That may not
be the case now that syncUpdates forces a nested update.
To address, this changes the type of prepareForCommit to return a value
which is later passed to resetAfterCommit.
Typically, a sync update is downgraded to Task priority if it's
scheduled within another batch of work, e.g. within a lifecycle like
componentDidMount. But syncUpdates should force sync updates to not
be downgraded to Task. This will cause performWork to be
called recursively.
Currently we assume that performWork is never called recursively.
Ideally that is the case. We shouldn't rely on recursion anywhere
in Fiber.
However, to support the use of syncUpdates as an opt-in to forced-
synchronous updates, we need the ability to call performWork
recursively.
At the beginning of performWork, the state of the scheduler is saved;
before exiting, that state is restored, so that the scheduler can
continue where it left off. I've decided to use local variables to stash
the previous state. We could also store them in a record and push it to
a stack, but this approach has the advantage of being isolated to
performWork.
This can only be caused by a bug in the renderer, but we should handle
it gracefully anyway.
Added a TODO to change capturedErrors and failedBoundaries so that they
are sets of instances (stateNodes) rather than fibers, to avoid having
to check the alternate. (This outside the scope of this PR.)
For legacy purposes. Only enabled in the DOM renderer. We can remove
this in a future release when we enable incremental-by-default.
This change is unobservable because syncUpdates actually schedules
Task updates when it is called from inside another batch. The correct
behavior is to recursively begin another batch of work. We will fix it
in a subsequent commit.
The finalizeInitialChildren HostConfig method now utilizes a boolean return type. Renderers can return true to indicate that custom effects should be processed at commit-time once host components have been mounted. This type of work is marked using the existing Update flag.
A new HostConfig method, commitMount, has been added as well for performing this type of work.
This change set is in support of the autoFocus prop.
* Push class context providers early
Previously we used to push them only after the instance was available. This caused issues in cases an error is thrown during componentWillMount().
In that case we never got to pushing the provider in the begin phase, but in complete phase the provider check returned true since the instance existed by that point. As a result we got mismatching context pops.
We solve the issue by making the context check independent of whether the instance actually exists. Instead we're checking the type itself.
This lets us push class context early. However there's another problem: we might not know the context value. If the instance is not yet created, we can't call getChildContext on it.
To fix this, we are introducing a way to replace current value on the stack, and a way to read the previous value. This also helps remove some branching and split the memoized from invalidated code paths.
* Add a now-passing test from #8604
Also rename another test to have a shorter name.
* Move isContextProvider() checks into push() and pop()
All uses of push() and pop() are guarded by it anyway.
This makes it more similar to how we use host context.
There is only one other place where isContextProvider() is used and that's legacy code needed for renderSubtree().
* Clarify why we read the previous context
* Use invariant instead of throwing an error
* Fix off-by-one in ReactFiberStack
* Manually keep track of the last parent context
The previous algorithm was flawed and worked by accident, as shown by the failing tests after an off-by-one was fixed.
The implementation of getPrevious() was incorrect because the context stack currently has no notion of a previous value per cursor.
Instead, we are caching the previous value directly in the ReactFiberContext in a local variable.
Additionally, we are using push() and pop() instead of adding a new replace() method.
ReactFiberStack is the new underlying stack used by ReactFiberContext and ReactFiberHostContext. The goal is to simplify the 2 context managers and to add more errors/dev-warnings when we pop unexpected.
This changeset currently causes a lot of tests to fail (as we are currently popping too many times and/or in the wrong order). I'm pushing this branch now to share with Sebastian as he is working on a related cleanup pass at beginWork.
* Add a failing test for recursion check
* Make requestIdleCallback() and requestAnimationFrame() shims async
They no longer need to be sync in tests because we already made DOM renderer sync by default.
This fixes a crash when testing incrementalness in DOM renderer itself.
* Style fix
* Fix lint
This was a bug because of the split between ClassComponent and IndeterminateComponent -- we didn't mark effects or push context when we come from an indeterminate component. Now they behave the same way.
The code is even clumsier than before but I'm pretty worried we'll screw these up in the future if we don't unify the paths.
Not many components exercise this path but Relay containers do so it's noticeable.
This is the same thing as the previous commit but with class, root and portal.
I noticed host and portal now already covers this case in their branches
since pushHostContainer is always at the top.
Since we only call bailout from within the host component branch now, we
can just move this to the branch where we already know that this is a
host component.
As part of this I noticed that we don't always push the host context so
I moved that to the beginning of the branch.
This is no longer needed. It is effectively covered by other branches
that tries to being merging the update queue which yields the same state
object as before if there is no work. That in turn bails out.
We can shortcut in the relevant paths if needed.
Now we only bail out once we've entered each branch.
This has some repetition with regard to hasContextChanged but I'm hoping
we can just get rid of all those branches at some point since they're
mostly for backwards compatibility right now.
The functional component branch is a bit special since it has sCU in it.
The class component branch actually already covers this in a bit convoluted
way.
I will next replicate this check in each other branch.
This consolidates the reset of context to one single place right before
any new work is started.
This place is burried in a bit of an awkward place but findNextUnitOfWork
happens right before any new work starts. That way we're guaranteed to have
an empty stack before we start anything new.
The benefit of this is that we don't have to rely .return being null when
entering beginWork but we also don't have to check it every time in the
hot path.
Fixes an issue (in both Stack and Fiber) where enqueueSetState causes
a synchronous update that flushes before enqueueCallback is ever called.
Now enqueueSetState et al accept an optional callback so that both
are scheduled at the same time.
Otherwise you fall into an infinite loop where root fails -> host env
throws -> root fails...
This is a worst-case scenario that should only be possible if there's
a bug in the renderer.
We warn about getInitialState() usage in class components because users may have accidentally used it instead of state. If they have also specified state though then we should skip this warning.
Context: https://twitter.com/soprano/status/810003963286163456
* (WIP) Nesting warnings
* Remove indirection
* Add a note about namespace
* Fix Flow and make host context required
This makes it easier to avoid accidental nulls.
I also added a test for the production case to avoid regressing because of __DEV__ branches.
We should be able to support passing a function to replaceState, which
receives the accumulation of all the previously applied state updates.
Which means we shouldn't drop those updates from the queue. Technically,
we could drop them only when an object is passed to replaceState, but
that seems like more trouble than it's worth.
Go back to using a flag, instead. I removed it before because I thought
we might want to get rid of the top-level UpdateQueue type and put
the fields directly on the fiber, but since we're keeping UpdateQueue
we can put hasForceUpdate on there.
The update is scheduled as if the current processing update has already
been processed; if it has the same or higher priority, it will be
flushed in the same batch.
We also print a warning.
The queue maintains a pointer to the last progressed update in the list.
Updates that come after that pointer are pending. The pointer is set to
the end of the list during reconciliation.
Pending updates are sorted by priority then insertion. Progressed
updates are sorted by the order in which they were applied during
reconciliation, which may not be by priority: if a component bails out
before the updates are committed, in the next render, the progressed
updates are applied in the same order that they were previously, even if
a higher priority update comes in.
Once a progressed update is flushed/committed, it's removed from
the queue.
We need to be able to access both, and since the list uses forward
pointers, it makes more sense to point to the one that comes first.
Otherwise to get the last progressed update you have to start at the
beginning of the list.
When resetting the priority in the complete phase, check the priority of
the update queue so that updates aren't dropped.
Updates inside render, child cWRP, etc are no longer dropped.
The next step is sort the queue by priority and only flush updates that
match the current priority level.
Restructures the update queue to maintain a pointer to the first
pending update, which solves a few problems:
- Updates that occur during the begin phase (e.g. in cWRP of a child)
aren't dropped, like they are currently. This isn't working yet because
the work priority is reset during completion. The following item will
fix it.
- Sets us up to be able to add separate priorities to each update in
the queue. I'll add this in a subsequent commit.
* Implement component stack for some warnings in Fiber
* Keep Fiber debug source up to date
When an element changes, we should copy the source and owner again.
Otherwise they can get stale since we're not reading them from the element.
* Remove outdated TODOs from tests
* Explicitly specify Fiber types to include in the stack
Fixes an accidental omission when both source and owner are null but displayName exists.
* Fix mised Stack+Fiber test to not expect extra warnings
When we're in Fiber mode we don't actually expect that warning being printed.
* Warn on passing different props to super()
* Implement duplicate key warnings
We keep known keys in a set in development. There is an annoying special case where we know we'll check it again because we break out of the loop early.
One test in the tree hook regresses to the failing state because it checks that the tree hook works without a Set available, but we started using Set in this code. It is not essential and we can clean this up later when we decide how to deal with polyfills.
* Move ReactTypeOfWork to src/shared
It needs to be available both to Fiber and Isomorphic because the tree hook lives in Isomorphic but pretty-prints Fiber stack.
* Add dev-only ReactDebugCurrentFiber for warnings
The goal is to use ReactCurrentOwner less and rely on ReactDebugCurrentFiber for warning owner name and stack.
* Make Stack invariant messages more consistent
Fiber used a helper so two tests had the same phrasing.
Stack also used a helper for most invariants but hardcoded a different phrase in one place.
I changed that invariant message to use a helper which made it consistent with what it prints in Fiber.
* Make CSSPropertyOperations use getCurrentFiberOwnerName()
This gets mount-time CSS warnings to be printed.
However update-time warnings are currently ignored because current fiber is not yet available during the commit phase.
We also regress on HostOperation hook tests but this doesn't matter because it's only used by ReactPerf and it doesn't work with Fiber yet anyway. We'll have to think more about it later.
* Set ReactDebugCurrentFiber during the commit phase
This makes it available during updates, fixing the last failing test in CSSPropertyOperations.
* Add DOM warnings by calling hooks directly
It is not clear if the old hook system is worth it in its generic incarnation. For now I am just hooking it up to the DOMFiber renderer directly.
* Add client-side counterparts for some warning tests
This helps us track which warnings are really failing in Fiber, and which ones depend on SSR.
This matches what we do in Fiber -- and doing it this way is the only way we can prepare new views in the background before unmounting old ones.
In particular, this breaks this pattern:
```js
class Child1 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Child2 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Parent extends React.Component {
render() {
return (
showChild1 ?
<Child1
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/> :
<Child2
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/>
);
}
}
```
Previously, `this.registered` would always be set -- now, after a rerender, `this.registered` gets stuck at null because the old child's componentWillUnmount runs *after* the new child's componentWillMount.
A correct fix here is to use componentDidMount rather than componentWillMount. (In general, componentWillMount should not have side effects.) If Parent stored a list or set of registered children instead, there would also be no issue.
This matches the behavior in Fiber. Normally we would change Fiber
to match Stack to minimize breaking changes for the initial release.
However, in this case it would require too large a compromise to change
Fiber to act like Stack.
We introduced runtime validation of tag names because we used to generate
HTML that was supposed to be inserted into a HTML string which could've
been an XSS attack.
However, these days we use document.createElement in most cases. That
already does its internal validation in the browser which throws. We're now
double validating it. Stack still has a path where innerHTML is used and
we still need it there. However in Fiber we can remove it completely.
In #2756 we ended up using toLowerCase to allow case insensitive HTML tags.
However, this requires extra processing every time we access the tag or
at least we need to process it for mount and store it in an extra field
which wastes memory.
So instead, we can just enforce case sensitivity for HTML since this might
matter for the XML namespaces like SVG anyway.
* Remove array indirection in host context
* Keep a single context stack with a null sentinel
This lets us keep subtrees separated without maintaining independent context arrays for subtrees.
* There is always exactly one null by the time we pop a portal
I was trying to be smart but didn't need to.
* Cache current context
* Enable additional (failing) portal tests
* Fix portal unmounting
When unmount a portal, we need to unmount *its* children from itself.
This is similar to what we would do for a root if we allowed deleting roots.
* Skip portals when looking for host siblings
A portal is not part of that host tree despite being a child.
* Fix comment typo
* Add a failing test for portal child reconciliation
It is failing because portal bails out of update, seeing null in pendingProps.
It is null because we set pendingProps to nextPortal.children, which is null in this test.
* Fix the bug when switching to a null portal child
If pendingProps is null, we do a bailout in beginWork.
This prevents unmounting of the existing child when the new child is null.
We fix this by changing portal fiber's pendingProps to be the portal object itself instead of its children.
This way, it is never null, and thus doesn't cause a false positive in the bailout condition.
* Add a comment about HostPortal in getHostSibling
* Revert the fix because I don't know why it worked
unmountHostComponents() should have worked despite finding the wrong parent because it should have changed the parent when pushing and popping the portals.
* Don't call commitDeletion recursively
This leads to a "Cannot find host parent" bug because commitDeletion() clears the return field.
When we're inside the loop, we assign node.sibling.return to node.return but by this moment node.return has already been nulled.
As a solution we inline code from commitDeletion() without the nulling.
It still fails tests but for a different reason (unrelated bug).
* Skip portal children in commitNestedUnmounts()
We are currently already visiting them in commitUnmount() portal case since it's recursive.
This condition avoids visting them twice.
* Set node.child.return before going deeper
It doesn't seem to influence existing tests but we have this protection in all other similar places.
It protects against infinite loops.
* Revert "Fix the bug when switching to a null portal child"
This reverts commit ed9747deedf11455ba3eb65648007ab99c26ea58.
I'll solve this by using an array in place of null instead.
* Use [] for empty Portal pendingProps
This avoids a false positive bailout with pendingProps == null when portal is empty.
- In the previous example, the code works even without using bind(this) in the constructor.
- the reason being handleClick doesn't even use `this` and its just calling the global function alert.
- this change make use of this via access this.state.
* Test that SVG elements get created with the right namespace
* Pass root to the renderer methods
* Keep track of host instances and containers
* Keep instances instead of fibers on the stack
* Create text instances in begin phase
* Create instance before bailing on offscreen children
Otherwise, the parent gets skipped next time.
We could probably create it later but this seems simpler.
* Tweak magic numbers in incremental tests
I don't understand why they changed but probably related to us moving some work into begin phase?
* Only push newly created nodes on the parent stack
Previously I was pushing nodes on the parent stack regardless of whether they were already in current or not.
As a result, insertions during updates were duplicated, and nodes were added to existing parents before commit phase.
Luckily we have a test that caught that.
* Fix lint
* Fix Flow
I had to wrap HostContext API into a closure so that it's parameterizeable with I and C.
* Use the same destructuring style in scheduler as everywhere else
* Remove branches that don't seem to run anymore
I'm not 100% sure this is right but I can't get tests to fail.
* Be explicit about the difference between type and tag
I was confused by th HACK comment so I learned how DOM and SVG work with casing and tried to write a more descriptive comment.
It also seems like passing fiber.type into finalizeInitialChildren() is a potential problem because DOM code assumes tag is lowercase.
So I added a similar "hack" to finalizeInitialChildren() that is identical to the one we have prepareUpdate() so if we fix them later, we fix both.
* Save and restore host context when pushing and popping portals
* Revert parent context and adding children in the begin phase
We can address this later separately as it is a more hot path.
This doesn't affect correctness of SVG container behavior.
* Add a test for SVG updates
This tests the "jump" reuse code path in particular.
* Record tests
* Read ownerDocument from the root container instance
This way createInstance() depends on the innermost container only for reading the namespace.
* Track namespaces instead of creating instances early
While we might want to create instance in the begin phase, we shouldn't let DOM guide reconciler design.
Instead, we are adding a new concept of "host context". In case of ReactDOMFiber, it's just the current namespace.
We are keeping a stack of host context values, ignoring those that are referentially equal.
The renderer receives the parent context and type, and can return a new context.
* Pop child context before reading own context and clarify API
It wasn't quite clear from the API which context was being returned by the renderer. Changed the API to specifically ask for child context, and thus to pop it before getting the current context.
This fixes the case with <foreignObject> to which I intended to give SVG namespace.
* Give SVG namespace to <svg> itself
* Don't allocate unnecessarily when reconciling portals
We create stacks lazily so that if portal doesn't contain <svg>s, we don't need to allocate.
We also reuse the same object for portal host context state instead of creating a new one every time.
* Add more tests for edge cases
* Fix up math namespace
* Maintain a separate container stack
* Fix rebase mistakes
* Unwind context on errors
* Reset the container state when reusing the object
* Add getChildHostContext() to ReactART
* Record tests
Solves a few things:
- Moves code out of performWork into workLoop so that it can
be optimized.
- errorLoop (now clearErrors) is no longer called recursively.
- Removes a while (true) loop inside performWork (not that it really
matters for optimization, since performWork contains a try block and
will be deopted, anyway).
If a ref throws while detaching, it should not prevent
componentWillUnmount from being called.
Additionally, errors thrown by removeChild should not be ignored, even
as the result of unmounting a failed subtree.
Subsequent failures should propagate the error to the next boundary.
The conceptual model for this is
try {
render();
} catch (error) {
setStateToRecover();
render();
}
Closes#8485
This uncovered a separate issue where some errors were being unscheduled
and rescheduled multiple times before flushing. Turns out we need to
check both a fiber and its alternate when determining if it represents a
failed unit of work. I didn't notice this before because we were
scheduling a new update on *every* boundary at the end of the commit
phase, not just the ones that captured an error during that commit. I
updated the unit tests to catch this in the future.
We still need tryComponentWillUnmount because deletion should be non-
interruptible.
Refactoring the commit phase to better handle errors also allows us
to switch between fast and slow versions of the work loop. The slower
version runs whenever there are captured errors; it must check each
unit of work to see if it has failed. The faster version runs in the
normal case where there are no errors. Whenever an error is thrown, we
switch from the fast work loop to the slow work loop.
This makes it easier to track when we enter and exit a batch of work.
Further steps needed in this refactor:
- Get rid of tryComponentDidMount, tryComponentDidUpdate, etc. in
favor of the try-catch blocks that wrap each pass of the commit phase.
- Need to be able to switch between performing work that is possibly
failed (slower because it requires an extra check on each iteration) and
work that we know for sure has no errors.
From D4296244:
> Each [...] had a component with innerHTML = '', causing us to go into HTML parsing code in the browser. Doing this takes 0.03ms per parse call which was 10x slower than skipping it.
This fixes the issue where using the .return pointer isn't guaranteed to
return the current Fiber so we might read the wrong props when we try
to get the current event.
This is unnecessary forwarding since this is no longer injectable.
However, I'd like to use the injectable getInstanceFromNode from
TreeTraversal so this avoids a cyclic dependency.
When we perform an update to the event handler we properly update the
immediate Fiber pointer of a child to be the current. However, when we
bubble events we use the return pointer which is not guaranteed to point
to the current Fiber even if we start from the current.
This manifests itself when we bailout in a parent. So I made the tests
use a PureComponent to illustrate this scenario. There is already a failing
case but I'm adding another one too.
This strategy finds the current fiber. It traverses back up to the root if
the two trees are completely separate and determines which one is current.
If the two trees converge anywhere along the way, we assume that is the
current tree. We find the current child by searching the converged child
set.
This could fail if there's any way for both return pointers to point
backwards to the work in progress. I don't think there is but I could be
wrong.
This may also fail on coroutines where we have reparenting situations.
**What** and **Why**:
* When using npm version 2, `object-assign` and `fbjs` were not getting properly installed
* This PR adds `object-assign` and `fbjs` as explicit dependencies to both `react-test-renderer` and `react-addons`
Fixes a bug when updating from a single text child (or
dangerouslySetInnerHTML) to regular children, where the previous
text content never gets deleted.
* Exit early in scheduleUpdate if a node's priority matches
This is a performance optimization and is unobservable. However, it
helps protect against regressions on the following invariants on which
it relies:
- The priority of a fiber is greater than or equal to the priority of
all its descendent fibers.
- If a tree has pending work priority, its root is scheduled.
* New error boundary semantics
- Recovering from an error boundary no longer uses Task priority by
default. The work is scheduled using whatever priority created the
error.
- Error handling is now a side-effect that happens during the
commit phase.
- The default behavior of an error boundary is to render null. Errors
do not propagate except when an boundary fails. Conceptually, this would
be like throwing an error from a catch block.
- A host container is treated like a no-op error boundary. The first
error captured by a host container is thrown at the end of the batch.
Like with normal error boundaries, the entire tree is unmounted.
* Fix broken setState callback test
* Add test for "unwinding" context when an error interrupts rendering
* Switch over primary effect types only
This avoids the need to create an export for every combination of bits.
* Only continue the work loop if the error was successfully captured
* Add more tests for incremental error handling
These tests are currently failing:
✕ catches render error in a boundary during partial deferred mounting
✕ catches render error in a boundary during animation mounting
✕ propagates an error from a noop error boundary during full deferred mounting
✕ propagates an error from a noop error boundary during partial deferred mounting
✕ propagates an error from a noop error boundary during animation mounting
The observed behavior is that unstable_handleError() unexpected gets called twice:
"ErrorBoundary render success",
"BrokenRender",
"ErrorBoundary unstable_handleError",
+ "ErrorBoundary render success",
+ "BrokenRender",
+ "ErrorBoundary unstable_handleError",
"ErrorBoundary render error"
* Verify batched updates get scheduled despite errors
* Add try/catch/finally blocks around commit phase passes
We'll consolidate all these blocks in a future PR that refactors the
commit phase to be separate from the perform work loop.
* NoopBoundary -> RethrowBoundary
* Only throw uncaught error once there is no more work to perform
* Remove outdated comment
It was fixed in #8451.
* Record tests
* Always reset nextUnitOfWork on error
This is important so that the test at the end of performAndHandleErrors() knows it's safe to rethrow.
* Add a passing test for unmounting behavior on crashed tree
* Top-level errors
An error thrown from a host container should be "captured" by the host
container itself
* Remove outdated comment
* Separate Rethrow and Noop scenarios in boundary tests
* Move try block outside the commit loops
* Make bad element type message same as in Stack
This makes Fiber emit the same message as Stack (aside from the missing owner information).
* Add a separate test verifying error includes owner name
Fiber currently doesn't pass it. This is just to keep track of it as a todo.
This handles the case where a host text bails out. In that case we need to
reuse its previous memoizedProps. We should also only schedule an actual
update if it did actually change its text content.
I updated the unit test to ignore comment nodes if we're using Fiber.
* Add iterable cases to MultiChildReconcile test
Stack currently supports rendering iterables, but Fiber does not.
Previously we didn't have any public API tests for iterables. We have tests for traverseAllChildren() which is shared between React.Children and Stack. However Fiber doesn't currently use it, and likely won't. So this commit is a first step towards actually testing iterable support via public API. The next step will be to port traverseAllChildren() tests to test React.Children API instead.
* Implement iterable reconciliation in Fiber
This uses the same exact algorithm as array reconciliation but uses iterator to step through.
This gets reconcile tests to pass again but introduces a regression in ReactMultiChildText case which uses Maps as children. It passed before because Maps were ignored, but now it's failing because this actually runs the Map code path in Fiber. We can throw early in this case when we want to follow up on this.
* Rewrite traverseAllChildren() tests against React.Children API
This function was used in React.Children and Stack.
The corresponding reconciliation functionality is being tested by ReactMultiChild tests.
So we can move these tests to ReactChildren and test its public API.
* Use a closure to bind gaurded callback
This way the fake event isn't being implicitly passed into the event handler
* Add tests for ReactErrorUtils
Add fiber test report
Linting fixes
We used to terminate the search on host nodes, and then use the nested unmount algorithm.
However this means we didn't unmount portals inside the host nodes.
We will probably need to restructure this somehow but for now I just added a recursive call to unblock myself.
* Remove output field
The idea was originally that each fiber has a return value. In practice
most of what we're modelling here are void functions and we track side
effects instead of return values.
We do use this for coroutines to short cut access to terminal yields.
However, since this can be nested fragments we end up searching the tree
anyway. We also have to manage this in transferOutput so it ends up being
as expensive. Maybe we can save some traversal for updates when coroutine
branches bail out but meh.
* Unmount child from the first phase of a coroutine
The goal of this is to avoid passing an opaque data structure that needs
to be recursively searched by the host.
I considered having some helper for doing the recursion but I figured it
might be helpful to let the reconciler move this around. For example we
might want to create an instance in beginWork and add to it as we go.
This would let us avoid traversing the tree twice and would solve the IE11
perf issue.
So instead, we create the instance first then call appendChild. I could
just call the normal one but I figured that I would make a special one
just in case. For example if you wanted to perform commits on a separate
thread from creation. This turned out to be useful in ReactNoop where I
can avoid searching the array for an existing one since I know the child
isn't there already. (Although splitting placement into insertion/move
might be better.)
Finally, we need the ability to update an instance after all the children
have been insertion. Such as `<select value={...} />`. I called this
finalizeInitialChildren.
This removes updateContainer and instead uses the regular child mutation
methods to insert into the root container and portals.
Since we're no longer clearing out the container DOM in updateContainer
we have to do that manually during initial mount. This now works on a
document and one of the tests end up unmounting the body when you render
into the document so I had to work around that bit since we don't yet
properly support rendering into the document root.
This misbehavior is particularly egregious because of our current strategy for updating a container in Fiber, but regardless -- if we restore focus to an offscreen node (ex: because it was reordered among its siblings) then we should not scroll the page to reveal it.
We could check the `overflow` computed style values before saving the scroll positions but that's unlikely to be any faster.
I tried to add a temporary check for the correct state in https://gist.github.com/spicyj/338147e989215b6eeaf48a6ce2d68d93 and run our test suites over it, but none of our existing test cases would have triggered that invariant. The new one I added does.
* Fix browser bundle for AMD
* Final fix for standalone browser build.
Much more scientific than the rest so it should stick.
* Throw when we can't find code we need to replace.
We're walking backwards up to the root to find the parent so that we can
propagate events further up to nested React parents. If we don't find a
root, that means that the tree was unmounted and we shouldn't send any
events to it.
This was supposed to fix an issue in refs-test but instead it revealed that
this strategy is broken.
The problem is that Placement effect is not sufficient when the insertion
is completed since the effect flag is reset then and the previous tree
has no effects in it to indicate that this is the wrong tree.
If there is no child there is nothing to tell us that this was the
workInProgress branch. Therefore, we need to look at the other branch
if there are children in it to see if *that* was the workInProgress branch.
We've already been warning for mutating styles so now we'll freeze them
in DEV instead. This isn't as good because we don't have more specific
warnings than the generic error that doesn't even fire in sloppy mode.
This lets Fiber pass the same tests.
This used to be done at the end of the transaction but I made it synchronous.
For this to work it needs to be applied after we have already set the .type
property since it is read by inputValueTracker.
We need this to safely extract the current event listeners from the props.
Unfortunately, we are still not safe to use the return pointer since it
may not point to the current tree when the Fiber is reused. So this is not
fully done yet.
* Use the public ReactDOMServer in tests
We need this because it runs the injection.
* Let Fiber skip react data attributes and comments in SSR tests
This markup is testing implementation details rather than behavior.
* [Fiber] Add ReactDOMFiber.unstable_createPortal()
While #8368 added a version of `ReactDOM.unstable_renderSubtreeIntoContainer()` to Fiber, it is a bit hacky and, more importantly, incompatible with Fiber goals. Since it encourages performing portal work in lifecycles, it stretches the commit phase and prevents slicing that work, potentially negating Fiber benefits.
This PR adds a first version of a declarative API meant to replace `ReactDOM.unstable_renderSubtreeIntoContainer()`. The API is a declarative way to render subtrees into DOM node containers.
* Remove hacks related to output field
My first contribution to React!
While upgrading a React project, I found some suspect SVG that needed updating, so I dug in after checking the docs. I knew that support for some SVG properties had been added (namely `xmlns` and `xmlnsXlink`), but I noticed them missing from the reference's attribute list. This pull request updates `reference-dom-elements.md` by adding said properties.
Only declare the variable once in this scope, instead of declaring them multiple times in the same scope.
This fixes#8318, even though it might technically be a shortcoming in Rollup.
* Update all Jest packages to 17.x, cache babel-jest transforms
* Remove the caching
Looking at the other builds it doesn't seem to actually be that necessary. The bottleneck is executors, not build time.
* Remove unnecessary package, fix fiber test runner
* Regenerate yarn lockfile
I forgot that the normal properties route doesn't do this. We also have
to make sure that the order is 1) insert children (options), 2) set
multiple 3) update the options.
Wrappers operate on the raw props object instead of the processed one.
We should probably clean this up a bit since it is very confusing and
unnecessary allocations to have two separate objects for props.
To avoid exposing the implementation details of fibers we'll just pass the
DOM node around instead. We'll attach any additional wrapper state on it.
We don't have to do it that way. We can also just invert the relationship
and put the node in the wrapper state.
I'll probably just get rid of the wrapper object and just put them as
expandos on the DOM.
We read the wrapper state during initial mount for server rendering support
but Fiber doesn't use it and we don't need it. We also can't because we
haven't yet completed the parent that has the selected.
I will need to remember to always insert children before setting the
selected value on the parent <select />. That way the DOM will deal with
the `selected` property of option properly.
Instead of passing around the owner and the internal fiber everywhere we
can set current owner during each commit. That way we have it available
globally where ever we need it.
That way we don't have to pass it as a DEV only argument nor expose the
internal representation to the host config.
This doesn't actually get the current owner yet. Will do that in a follow
up.
We'll stop tracking the input value tracking. We'll also stop uncaching the
node because we can just let the garbage collector take care of that. This
makes it easier to release components in trees that never mounted.
This also removes an invariant error which is covered by unit tests.
This is necessary to separate regardless because we don't want this to
fire for a component that was started but was thrown away because it never
mounted. We can come back to that later.
Basically, we don't need to remove the event listeners because we can just
check if something is still mounted when they fire instead. We'll rely on
garbage collection to clean them up.
We don't need to wait for the commit phase to start listening to events
since we have the node.
Next we'll stop unlistening to events too and instead just check isMounted.
Fiber manages children separately so we don't need to do it here.
However, we special case the text content children and
dangerouslySetInnerHTML.
This reveals a bug that we currently don't handle the case where we switch
from dangerouslySetInnerHTML or text children to element children, because
child insertions are handled before the parent updates. We could possibly
handle this case by removing all nodes before the first host child but
that is a bit unfortunate.
We have warned about not mutating styles already. At this point we can just
freeze the style object in DEV.
That way we can read it from the previous props object without storing
another copy of it.
Also delete the associated warning.
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
Showing how to create a form without labeling inputs is an accessibility anti-pattern. This change adds labels to the examples to address that. Codepen may still need to be updated depending on how that example is created.
* Update tutorial.md
Is it possible to be more clear here?
This implies that we are removing the constructor from GAME, and not board (which is what I believe the author is trying to say).
It took me several reads to understand.
With this edit, it is now clear that the adjustment is being made to -Board- and not to -Game-
* also remove "for Board earlier"
* Remove spread operator
I believe what was meant here was to express that you would create the new player object with all the previous properties of the existing player object in addition to now updating the score value. That being said, this is a simple example, and the player object clearly has no other values. Objects are not (by default) iterable using this operator, so this little piece does more harm than good. I believe the new example to be much clearer.
* Using Object.assign()
* Tweak wording
This traverses parent based on the type of internal instance it is passed.
If it is a Fiber it may have to traverse multiple steps until it finds a
HostComponent.
This will allow us to use the event system with Fiber.
This adds precaching to ReactDOMFiber. I.e. adding a handle from the DOM
node to the internal Fiber. This means that we need to expose an internal
handle to the reconciler.
We use duck typing to figure out if it is a Fiber or Stack instance.
The new failing tests are failing because this is now able to actually
fire events onto Fibers and then the result of those events are
incorrect where as they were ignored before.
* Reapply Check for event listener in props instead of bank (#8192)
This reverts the previous revert.
* Don't throw on falsy event listeners
Some code relies on passing null. This restores the earlier behavior.
This matches Stack behavior.
Had to rewrite a test that used Simulate because Fiber doesn't support events yet.
Also changed tests for componentDidUpdate() since Fiber intentionally doesn't pass prevContext argument.
We can avoid recreating the merged context object if the context provider work was reused. This is essential to avoid allocations for deep setState() calls.
As per discussion, this is better because then this code only runs for the class type of work. We will still need to fix bailouts for deep setState calls.
It is error-prone to push and pop context in begin or complete phases because of all the bailouts. Scheduler has enough knowledge to see if pushing is necessary because it knows when we go inside or outside the tree.
I'll plan to change all of our console.error and component-tree expects to expectDev. It's a little annoying that we need to make sure tests don't throw (see my change to normalizeCodeLocInfo) but any alternative would seem to require two separate test runs or a much more cumbersome syntax.
* Handles risky callbacks on setState. Fixes#8238
* Updates try-catch to cover `callback` when context is not present.
* Updates code to trapErrors instead of swallowing them.
* Fixes flow errors
* Incorporates review comments
* Traps only the first error.
Removes `callbackWasCalled` and updates fiber tests.
I came up with a contrived case of where nested controlled events could
fire within the same batch - but on different targets.
I think we came to the conclusion that controlled values typically cannot
use preventDefault so it is ok that they don't flush until after the event
has finished. So therefore we accumulate a queue of all the nested targets
within a batch and then restore state on all of them.
I'm still skeptical that this is the correct way to do controlled values.
The reason we have to do them in a single event loop is because when you
type, the sequence of values that get accepted or not can matter. I wonder
if there is a scenario we can come up with where you can fire multiple
inner events in an event loop and end up with batching causing problems.
This effectively just reimplements asap again but with no allocations for
a single target and no closure allocations.
* Make the Shallow Rendering example clearer
I was reading through the documentation, and I found that the `render` call on the `renderer` was missing.
* Use a regular function to define MyComponent
* Use _hostContainerInfo to track test renderer options
The transaction is not available when unmounting or updating the
instance, so we track it using _hostContainerInfo
* Throw if hostContainerInfo is not populated in getPublicInstance
* Linting fixes
* Remove transaction from ref lifecycle code path
We don't need to pass the transaction around anymore since we store the
test options on _hostContainerInfo instead
* Remove unused argument
If a controlled target fires within another controlled event, we should not
restore it until we've fully completed the event. Otherwise, if someone
reads from it afterwards, they'll get the restored value.
Not super happy with this particular solution.
* took codes.json from the 15-dev branch
* fixed react:extract-errors task in gulpfile
* generated error codes
* Revert "generated error codes"
This reverts commit b8f3aeed9d8f0d469edd5f6623fa6090930594d8.
* Added a README for the error code system
This reverts commit a878c3056d.
The previous stuff that this builds on didn't successfully land fully. Since I
want to measure this in isolation, I'll revert this for now.
This just reads events from the props instead of storing them in a
listener back.
I had to rewrite a bunch of tests to cover this model.
I removed the tests that just test the adding and removing over listeners
since there is no equivalent behavior anymore.
This reverts the implementation in 33325ad009.
I didn't mean to merge the implementation since it is incorrect and incomplete.
I meant to just merge the unit test.
* Ensure that we're listening to all onChange dependencies for controlled inputs
When there is no onChange event handler, we should still listen to it to
ensure controlled values get reset.
There is warning associated with this but the prod behavior should still be
respected.
* Rerun tests
When there is no onChange event handler, we should still listen to it to
ensure controlled values get reset.
There is warning associated with this but the prod behavior should still be
respected.
* Use explicit pass for restoring controlled state instead of asap
This gets rid of the first class ReactUpdates.asap scheduling. Instead of
scheduling a first class function to invoke later, I introduce an explicit
phase for restoring controlled state after dispatching events.
We assume that the deepest event target is the thing that needs its state
restored.
* Drop special cases for onChange in wrappers
We're now not using anything special about onChange handling in the
wrappers. Yay!
* Attempt to fix ReactDOMTextComponent test in Fiber
Obviously, some tests pass but the reconciliation is still incomplete on this in Fiber.
Those changes just ignore reconciliation Comments while asserting (this fixes 2 tests already) but now shows that Fiber lacks some reconciliation features.
* Transmit a parentInstance to commitTextUpdate
This is done in case a Node#normalize() was performed on the parent instance and that the TextInstance got desolidarized from the parent. We provide the parent known by the parent Fiber to reattach the DOM node in this case.
* Added a more complex case around split nodes
This test does not assume one split node substitution alone but also some non-split nodes.
* Fiber supports split text nodes
This is done by suppressing nodes appearing during the split. this is based by comparing against the old value known by the Fiber.
* Simplify siblings cleaning in commitTextUpdate
No need to assert instanceof Text since the length comparator will work correctly.
* Ensure non-text nodes won't be removed
* Fix flow for Fiber Text reconciliation additions
Mostly define types as optionals. Respects the strict DOM API around Node & Element.
* Append at any stack stage only if necessary
The direct parent of the TextNode fiber may not contain the host node. We have to go through the hierarchy. However, since this work may be expensive, we only do it if absolutely necessary!
* Use tag & ReactTypeOfWork to find an HostComponent
* Addfailing scenario when running Node.normalize()
It happens when non-text-elements are added in the mix. @sebmarkbage seems to have an idea on how to fix it. This is just a repro of the bug!
* Register failing/passing fiber tests
This gets rid of the global flag on if something has listened to onSelect
and instead reads the isListening map if all the events are covered.
This is required if we want to attach events locally at roots.
Could be slower perf wise to handle events. An alternative solution would
be to attach a special flag on the listener map for the document so we
don't have to check the full dependency list.
However, my favorite solution would be to just eagerly attach all event
listeners (except maybe wheel). Then we don't have to do any of this stuff
on a per element basis.
* Print a warning in fiber for lacking render method
* Reject initial non-object state in Fiber
Rejects Arrays, Strings & Numbers. Allows nulls.
* Centralize fiber checks on ES6 Classes
* Add classic & instance property checks on fiber
- check the absence of getInitialState & getDefaultProps as methods
- check the absence of propTypes & contextTypes at instance-level
* Convert to normalized React `warning` calls
* Support lifecycle typo detection in fiber
* Get the complete warnings from the existing code
* Only check classInstance once
Avoid rechecking while resuming
* Can warn component while resuming but only once
This is achieved by tracking the warning state in the Fiber structure.
* Remove warning deduplication
* Factor name retrieval in a getName helper
* Use invariant instead of throw
* Read inst.state only once for the invariant
* Fix condition on the instance state
* Register failing/passing fiber tests
* Check if textContent should be set for textarea
shouldSetNodeTextContent returns whether a node.textContent should be
updated. Currently it only covers one case, which is to avoid setting
the textContent if the text is empty and a placeholder exists.
* Only set node.value if it's equal to initialValue
In IE11 textContent is populated when the placeholder attribute is set.
Without this check, we end up setting node.value equal to the
placeholder text, causing the textarea to actually render with the text
inside.
This check makes sure that textContent is equal to our expected
initialValue, which should be the case when using defaultValue.
* Remove placeholder/textarea check, use contentToUse instead
* Refactor scheduling functions and introduce Task priority
There was lots of duplication across all the scheduling functions. I
think we're far enough along that we can start trying to clean some
stuff up.
Also introduces a new priority level provisionally called Task priority.
This is for work that completes at the end of the current tick, after
the current batch of work has been committed. It's different from
Synchronous priority, which needs to complete immediately.
A full implementation of Task priority will follow. It will replace
the current batching solution.
* Implement Task priority
Task priority is similar to Synchronous priority. Both are flushed in
the current tick. Synchronous priority is flushed immediately (e.g. sync
work triggered by setState will flush before setState exits), where as
Task is flushed after the current batch of work is committed.
Currently used for batchedUpdates and nested sync updates. Task should
also be used for componentDidUpdate/Mount and error boundary work. I'll
add this in a later commit.
* Make error boundaries use Task Priority
I have all but one error fixed. Not sure how tricky the last one is,
but I'm cautiously optimistic. Pushing to show my current progress.
* Remove recursion from handleErrors
Changed the algorithm of handleErrors a bit to ensure that boundaries
are not revisited once they are acknowledged.
* Add incremental error boundary test
Discovered an edge case: a noop error boundary will break in incremental
mode unless you explicitly schedule an update.
* Refactor error boundaries in Fiber
* Simplify trapError() calls
The existing logic was written before we had a proper error handling system.
* Remove unnecessary flags
* Prevent performTaskWork recursion
* Be stricter about preventing recursion
Before, this code was bailing out after encoutering a null child because it thought it was out of old children. Seen when reconciling [null, <span />, <Image />] with [null, <span />, <Image />] in XUISelector.
This is already where we trap non-bubbling events. We also already branch
on the tag type so we know if it is interactive or not.
This will let us get rid of the didPutListener and willDeleteListener
abstractions.
I use a simple onclick = emptyFunction to avoid the need for a bookkeeping
map.
Covers some bugs I encountered while working on this feature.
Introduces a syncUpdates API to ReactNoop. Is this something we'd want
to expose to the reconciler?
Without this fix, in non-batched mode, the update is scheduled first and
synchronously flushed before the callback is added to the queue. The
callback isn't called until the next flush.
A bit of restructuring so that setState uses whatever the current
priority context is, like top-level render already does.
Renamed defaultPriority to priorityContext, and added a new variable
called defaultPriorityContext. Having two separate variables allows the
default to be changed without interfering with the current context.
This removes an optimization that avoids call update on ReactDOMSelect
twice in an onChange event.
2601b6a0b0 (commitcomment-19643403)
None of the other controlled components do this. The only reason to do it
here is because of the loop.
I'd like to remove this because I'd like to remove all the side-effects
that happen in onChange, other than user defined behavior. I'd also like to
get rid of state that track sequences. It is easier if everything is just
diffing.
Alternatively I can store the previous value that we processed and only
reprocess if the value has changed. However, that would requires the array
for multiple values to be immutable and I don't think we enforce that
right now.
In Fiber, I believe that we'll be able to batch both these updates into a
single commit.
Instead of scheduling individual callbacks to asap, we schedule one and
then do all the work in that one.
I'm doing this for architectural refactoring reasons.
Nevertheless, I'm adding a contrived unit test that this fixes. :)
The type of `ReactFiber.Fiber.effectTag` is `TypeOfSideEffect`.
Thus we should assign `ReactTypeOfSideEffect.NoEffect` value instead of
`ReactPriorityLevel.NoWork` even if they are same values.
* Make test more complete
* Add a failing test for scheduling in reverse order
It hangs forever because we don't clear next pointer when unscheduling a root. Therefore, when it's scheduled again, it brings all its previous chain with it, potentially creating a cycle.
* Clear the next pointer when unscheduling a root
Fixes a potential infinite cycle when we reschedule a root.
* Add new tests to Fiber test tracker
This should be safe because we've been warning for this. The LinkedStateMixin is technically exposed on React.addons without a warning but presumably you wouldn't be using it without a valueLink or checkedLink.
I do this primarily to clear up what the custom onChange listeners are doing.
Renamed the final prop type helper to ReactControlledValuePropTypes.
Gets rid of an obsolete word in the documentation for "State and Lifecycle":
"Consider the ticking clock example from the one of the previous sections."
->
"Consider the ticking clock example from one of the previous sections."
* Test Fiber internals differently in ReactElement
Instead of being able to access the owner's instance via getPublicInstance(), we use the Fiber's stateNode. (Fiber does not have methods, it's just a structure!)
* Fix isCompositeComponentWithType for fiber
In ReactTestUtils.isCompositeComponentWithType, we provide a way to walk through Fiber's internals in place of using _currentElement.type. We keep support for non-fiber though.
* Test fiber reconciler consistently
Use typeof instance.tag to test if we're using the fiber reconciler
* Remove unnecessary comment
Now that commits are treated as atomic, it is possible that componentDidMount, componentDidUpdate, or componentWillUnmount threw in multiple places during the commit. We need to make sure we notify all affected boundaries of the first errors in them.
This moves calls that don't know if they're in a Fiber or Stack
context to use ReactGenericBatching.batchedUpdates.
The corresponding one will be injected from either the stack
reconciler and/or the fiber reconciler if they're loaded at the
same time.
This lets them share the event system when they're both used
at once.
This can also be useful for libraries that call
unstable_batchedUpdates today but don't know which renderer to
use.
Instead of relying on IDs, we now use instances for everything so
this should be reflected by the test.
This still has a _rootNodeID to store the listeners which I will
remove next.
The code section above these changes defines a `formatName` function
that expects a parameter `user`. The code section containing these
changes incorrectly called `formatName(user.name)`. For those following
along with CodePen, this section should correctly call
`formatName(user)`.
Prior to this, React was using a nextDebugID variable that was locally
scoped to both `instantiateReactComponent` and `ReactShallowRenderer`.
This caused problems when the debugIDs would collide, the `itemMap` in
`ReactComponentTreeHook` would be overwritten and tests would fail
with the message "Expected onBeforeMountComponent() parent and
onSetChildren() to be consistent".
This change shares the debugID with both modules thus preventing any
collisions in the future.
* Reapplied fixes to updated docs from master
* Reapplied fixes to Forms, removed ES2016 function includes()
* Missing carriage return
* Adding back some line breaks
* Making requested changes.
* Making space changes
* Fixed typo and removed unnecessary hyphen.
* Reworded select, and highlighted line
* Fixed string styles
* Refactored <label> to use htmlFor
* Another refactor of <label>
* Removed name prop from radiobutton
* Reapplied fixes to updated docs from master
* Reapplied fixes to Forms, removed ES2016 function includes()
* Missing carriage return
* Adding back some line breaks
* Making requested changes.
* Making space changes
* [Fiber] Add top level render callbacks into ReactDOMFiber and ReactNoop
* [Fiber] Support multiple render callbacks
* [Fiber] `this` in render callbacks are public instances
* [Fiber] commitLifeCycles move to behind the effectTag check
* Implement string refs using callback closures
* Merge Fiber type to avoid Flow intersection bugs
Still one remaining type error that I'm not sure how to fix
* Fix Flow issue with an unsafe cast
* Fix missing semicolon
* Add a type import I missed earlier
This fix relies on the props and state objects being different
to know if we can avoid a componentDidUpdate. This is not a great
solution because we actually want to use the new props/state
object even if sCU returns false. That's the current semantics
and it can actually be important because new rerenders that are
able to reuse props objects are more likely to have the new props
object so we won't be able to quickly bail out next time.
I don't have a better idea atm though.
These two implementations are identical. Except for some
invariants for some reason.
Since this relies on an implementation detail of the internal
component tree rather than an implementation detail of the
renderer, we might as well merge them and remove the injection.
These are new features that aren't covered by existing tests.
It is now possible to use findDOMNode to find a text node.
When a component returns a fragment, it will search to find the
first host component just like element.querySelector does.
First we need to check if a component subtree is mounted at all.
If it is, we need to search down the fiber for the first host
node. However, we might be searching the "work in progress"
instead of current.
One realization is that it doesn't matter if we search work in
progress or current if they're the same. They will generally be
the same unless there is an insertion pending or something in
the alternate tree was already deleted. So if we find one of
those cases, we switch to look in the alternate tree instead.
There are two cases where we have a Fiber that is not actually
mounted. Either it is part of a tree that has not yet been
inserted or it is part of a tree that was unmounted.
For the insertion case, we can check the parents to see if there
is any insertion effect pending along the parent path.
For deletions, we can now check if any of the return pointers
is null without actually being the root.
This is the naive implementation that doesn't cover the case
where it has completed but not yet committed. It also doesn't
deal with unmounts since they currently don't clean up the item
in the ReactInstanceMap.
This is just moving a bunch of DOM files.
It moves things into dom/stack and dom/fiber respectively. The
dom/stack folder remains split into client/server.
Mainly the shared folder is now my best guess for files that
we can reuse in fiber. Everything else will get forked or
reimplemented.
Also moved the event system out of renderers/shared/stack and
into renderers/shared/shared.
When keys line up in the beginning but the type doesn't
we don't currently delete the child. We need to track that this
fiber is a not a reuse and if so mark the old one for deletion.
This splits DefaultInjection into one with all the properties
and event configuration and a separate one for the things that
are relevant to he stack reconciler.
That way we can reuse the property and event system for Fiber
without pulling in all the other stuff.
This isn't a complete solution to all attributes. It's just that
we run a lot of unrelated unit tests by testing className so
we need it for the tests.
The tutorial wants to throw a 'warning' and explains about 'key' of React's list, but it throws nothing since there is sensible key.
"key={move}" should be removed, and added after explaining about key.
* Consider Host Component classes when creating a new internal instance
* Remove unused tagToComponentClass & injectComponentClasses from ReactHostComponent
This doesn't deal with the fact that work is usually deferred
so this will return null for first render (except in sync tests).
It also doesn't deal with top levels being fragments etc.
It doesn't deal with the host instance type being a wrapper
around the public instance. This needs to be unified with refs
and findDOMNode better.
However, this does expose that we reactComponentExpect and
ReactTestUtils doesn't work very well with Fiber.
If work has progressed on a state update that gets resumed
because of another state up, then we won't have an new
pendingProps, and we also won't have any memoizedProps because
it got aborted before completing. In that case, we can just
fallback to the current props.
I think that they can't have diverged because the only way they
diverge is if there is new props.
This lets us bail out on state only updates in more cases which
the unit tests reflect.
We currently only filter out "NoWork" in the beginning of this
function. If the NoWork root is after the one with work it will
show up in the second loop. There's probably a more efficient
way of doing this but this works for now.
This showed up in this PR because a new unit test gets unblocked
which ends up with this case.
This refactors the initialization process so that we can share
it with the "module pattern" initialization.
There are a few new interesting scenarios unlocked by this.
E.g. constructor -> componentWillMount -> shouldComponentUpdate
-> componentDidMount when a render is aborted and resumed.
If shouldComponentUpdate returns true then we create a new
instance instead of trying componentWillMount again or
componentWillReceiveProps without being mounted.
Another strange thing is that the "previous props and state"
during componentWillReceiveProps, shouldComponentUpdate and
componentWillUpdate are all the previous render attempt. However,
componentDidMount's previous is the props/state at the previous
commit. That is because the first three can execute multiple
times before a didMount.
I couldn't figure out how to do this yarn alone so I ended up
just manually hacking the yarn to force a downgrade of babylon
to 6.8.0 since otherwise it gets resolved to 6.12.0 which is
broken.
* Use the memoized props/state from the workInProgress
We don't want to use the "current" props/state because if we have
started work, then pause and continue then we'll have the newer
props/state on it already. If it is not a resume, it should be the
same as current.
* Deprioritize setState within a deprioritized tree
Currently we flag the path to a setState as a higher priority
than "offscreen". When we reconcile down this tree we bail out
if it is a hidden node. However, in the case that node is already
completed we don't hit that bail out path. We end up doing the
work immediately which ends up committing that part of the tree
at a higher priority.
This ensures that we don't let a deprioritized subtree get
reconciled at a higher priority.
* Bump idx in unit test
This proves that this number is actually deprioritized.
Refactors the class logic a bit.
I moved scheduleUpdate out into the scheduler since that's where
the scheduling normally happens. I also moved it so that we can
rely on hoisting to resolve the cycle statically.
I moved the updater to a new class component file. I suspect we
will need a bit of space in here since the class initialization
code is quite complex.
The class component dependency is currently fixed in BeginWork
so we can't move complete or commit phase stuff to it. If we need
to, we have to initialize it in the scheduler and pass it to the
other phases.
If we abort work but have some completed, we can bail out if
the shouldComponentUpdate returns true. However, then we have
a tree that is low priority. When we bailout we currently use
the "current" tree in this case. I don't think this is right.
I'm not sure why I did that.
Similarly, when we complete we use the "current" props if we
didn't have pending props to do. However, we should be using
the memoized props of that tree if it is a pending work tree.
Added a unit test that covers these two cases.
This reorganizes the two commit passes so that all host
environment mutations happens before any life-cycles. That means
that the tree is guaranteed to be in a consistent state at that
point so that you can read layout etc.
This also lets us to detach all refs in the same pass so that
when they get invoked with new instances, that happens after it
has been reset.
During the deletion phase we call detachRefs on any deleted refs.
During the insertion/update phase we call attachRef on class
and host components.
Unfortunately, when a ref switches, we are supposed to call all
the unmounts before doing any mounts. This means that we have to
expact the deletion phase to also include updates in case they
need to detach their ref.
These happen in the commit phase *before* the setState callback.
Unfortunately, we've lost the previous state at this point since
we've already mutated the instance. This needs to be fixed
somehow.
While we're deleting nodes, we need to call the unmount
life-cycle. However, there is a special case that we don't want
to keep deleting every host node along the way since deleting the
top node is enough.
We only use the effect list when we reuse our progressed children.
Otherwise it needs to reset to null.
In all other branches, other than bailoutOnLowPriority, we
revisit the children which recreates this list.
We should also not add fibers to their own effect list since it
becomes difficult to perform work on self without touching the
children too. Nothing else does that neither.
Since that means that the root isn't added to an effect list we
need to special case the root.
This shortcut had a bug associated with it. If beginWork on this
child returns null, then we don't call completeWork on that fiber.
Since removing this short cut adds another time check, we have to
add a single unit of time in tests to account for the top level
call now taking one more unit.
This was also the only recursive call in all of fiber so it's nice
to get rid of it to guarantee that a flat stack is possible.
Instead of passing the full list of children every time to
update the host environment, we'll only do inserts/deletes.
We loop over all the placement effects first and then later
we do the rest.
First clear any progressed deletions for any case where we start
over with the "current" set of children.
Once we've performed a new reconciliation we need to add the
deletions to the side-effect list (which we know is empty because
we just emptied it).
For other effects, instead of just adding a fiber to an effect
list we need to mark it with an update. Then after completion
we add it to the the effect list if it had any effects at all.
This means that we lose the opportunity to control if a fiber
gets added before or after its children but that was already
flawed since we want certain side-effects to happen before others
on a global level.
Instead, we'll do multiple passes through the effect list.
When we reconcile children we need to track the deletions that
happen so that we can perf side-effects later as a result. The
data structure is a linked list where the next pointer uses the
nextEffect pointer.
However, we need to store this side-effect list for reuse if we
end up reusing the progressedChild set. That's why I add a
separate first/last pointer into this list so that we can keep it
for later.
When we don't have any previous fibers we can short cut this path
knowing that we will never have any previous child to compare to.
This also ensures that we don't create an empty Map in this case.
We use this to track the index slot that this Fiber had at
reconciliation time. We will use this for two purposes:
1) We use it to quickly determine if a move is needed.
2) We also use it to model a sparce linked list, since we can have
null/false/undefined in our child set and these take up a slot for
the implicit key.
This implements the first step to proper child reconciliation.
It doesn't yet track side-effects like insert/move/delete but has
the main reconciliation algorithm in place.
The goal of this algorithm is to branch early and avoid rechecking those conditions. That leads to some duplications of code.
There are three major branches:
- Reconciling a single child per type.
- Reconciling all children that are in the same slot as before from the beginning.
- Adding remaining children to a temporary Map and reconciling them by scanning the map.
Even when we use the Map strategy we have to scan the linked list to line up "same slot" positions because React, unlike Inferno, can have implicit keys interleaved with explicit keys.
We'll enable updating of text nodes. To be able to test that we
need the text nodes to be mutable. They're currently just strings
in the Noop renderer so this makes them an object instead.
That exposed a bug in ReactFiberCommitWork for text nodes.
This needs to be fixed somehow. The reconciler could know if you
are mounting this continuation into the same spot as before and
then clone it. However, if the continuation moves, this info is
lost. We'd try to unmount it in one place and mount the same fiber
in another place.
Dropped the unnecessary use of findDOMNode.
Dropped unnecessary arrow functions.
Math.random() -> id counter, since this used to be
non-deterministic which is not ideal for unit tests.
getOriginalKeys() used to rely on implementation details
to scan that the internal data structure maintained its
structure, however, since that is unobservable we don't
need to test the internal data structure itself. We're
already testing refs and dom structure which is the only
observable effect of the reorder.
These nodes rendering into Text nodes in the DOM.
There is a special case when a string is a direct child of a host
node. In that case, we won't reconcile it as a child fiber. In
terms of fibers, it is terminal. However, the host config special
cases it.
It is kind of unfortunate that we have to special case this kind
of child in the HostConfig. It would be nice to unify this with
other types of child instances. Text nodes have some weird special
cases, but those special cases tend to *vary* by environment.
They're not the same special cases so not sure how valuable it is
to have a special protocol and special types for it.
We currently treat nested arrays as a unique namespace from top
level children. So that these won't share key namespaces. This
adds a new fiber type that will represent the position of a
fragment.
This is only used for nested arrays. Even if you return an array
from a composite component, we don't need this since they share
namespace with a single top level component.
This still doesn't implement the complete reconciliation
algorthim in child fiber. That's coming later.
Otherwise Flow finds obscure files in docs/vendor.
Seems like you'd only get them if you have a local checkout of docs Ruby dependencies.
This explains why Travis didn't fail.
* Initial pass at the easy case of updates (updates that start at the root).
* Don't expect an extra componentWillUnmount call
It was fixed in #6613.
* Remove duplicate expectations from the test
* Fix style issues
* Make naming consistent throughout the tests
* receiveComponent() does not accept safely argument
* Assert that lifecycle and refs fire for error message
* Add more tests for mounting
* Do not call componentWillMount twice on error boundary
* Document more of existing behavior in tests
* Do not call componentWillUnmount() when aborting mounting
Previously, we would call componentWillUnmount() safely on the tree whenever we abort mounting it. However this is likely risky because the tree was never mounted in the first place.
People shouldn't hold resources in componentWillMount() so it's safe to say that we can skip componentWillUnmount() if componentDidMount() was never called.
Here, we introduce a new flag. If we abort during mounting, we will not call componentWillUnmount(). However if we abort during an update, it is safe to call componentWillUnmount() because the previous tree has been mounted by now.
* Consistently display error messages in tests
* Add more logging to tests and remove redundant one
* Refactor tests
* Split complicated tests into smaller ones
* Assert clean unmounting
* Add assertions about update hooks
* Add more tests to document existing behavior and remove irrelevant details
* Verify we can recover from error state
* Fix lint
* Error in boundary’s componentWillMount should propagate up
This test is currently failing.
* Move calling componentWillMount() into mountComponent()
This removes the unnecessary non-recursive skipLifecycle check.
It fixes the previously failing test that verifies that if a boundary throws in its own componentWillMount(), the error will propagate.
* Remove extra whitespace
The script that strips providesModule is very sensitive.
Test plan:
Searched for providesModule in build. No more.
reactComponentExpect used to have problems too but doesn't seem
to anymore. Don't know why.
* Add warning for shady-dom use with rendered react components in DEV
* Make shady dom warning emit only once regardless of number of components
* Use didWarnShadyDom as warning argument & add missing shadyRoot check to ReactDOMComponent
* Add check for shady dom test to run only when createElement flag is true
* Pass false to warning in shadyDom warning check
* Add consistent DOM phrasing for shady DOM warnings
* Reference component name in shady DOM warning if it exists
* Add check for if owner exists in shady dom warning
* Add test for named component using createClass for shady DOM warning
* Clean up named component test for shady DOM warning
* Fix trailing comma linting issue on named shady DOM warning test
Before this change calling renderToStringImpl would inject
ReactDefaultBatchingStrategy after completion, even if a custom batching
strategy was injected before. This makes renderToStringImpl keep a reference to
the batching strategy before it runs and reinject it afterwards.
* Add more to Codebase Overview
* WIP
* Start a reconciler overview
* Add a few more sections
* todo
* WIP
* Finish it
* Whitespace
* Minor tweaks
* Minor tweaks
* Ensure lib/ is packaged for react-test-renderer
* Run npm pack from right working directory
We were running this on the original packages not the compiled ones, resulting in missing files
* Reduce confusion in testing documentation.
Just wanted to add some clarity to this page and link to the react tutorial on Jest's website to give people more information. Also changed enzyme's definition from library to utility to help reduce the confusion. Hope this makes sense to everybody :)
See https://twitter.com/damusnet/status/780752042675597312
cc @lelandrichardson
* Update 10.4-test-utils.md
* Add a hook that throws a runtime warning for invalid WAI ARIA attributes and values.
* Resolved linting errors.
* Added a test case for many props.
* Added a test case for ARIA attribute proper casing.
* Added a warning for uppercased attributes to ReactDOMInvalidARIAHook
When you put the output of a bash command in a variable, it replaces the `\n` with a space. Using `ls` instead of `echo` fixes it
Test Plan:
Run
```
ALL_FILES=`find src -name '*.js' | grep -v umd/ | grep -v __tests__ | grep -v __mocks__`
COUNT_ALL_FILES=`ls $ALL_FILES | wc -l`
echo $COUNT_ALL_FILES
```
Make sure that it outputs 221
Use the newly added tracking system to track the number of fiber tests that are passing/failing.
I first tried to modify the grunt lint rule for it and send the output in stdout but unfortunately grunt displays the rule + done messages there. I had like 30 lines of js already and I figured I could just write 3 lines of bash and it would work the same. Let me know if you want me to use another approach for it.
Test Plan:
Run the commands that have been introduced in this commit but the facts-tracker one
Run `echo $FIBER_TESTS` and make sure it prints `666/1434`
* Introduce facts-tracker
We want to be able to track various things like number of files that are flowified, number of tests passing with Fiber...
This introduces a tool that lets you do that. The API is very simple, you execute the script with a list of tuples [key value] and it's going to create a `facts` branch and put a txt file for each fact and values over time.
```
node scripts/facts-tracker/index.js \
"flow-files" "$COUNT_WITH_FLOW/$COUNT_ALL_FILES"
```
Test Plan:
This is tricky to test because Travis only exposes the private variables (github token) when it processes a committed file and not on branches. The reason is that otherwise anyone could send a pull requests that does `echo $GITHUB_TOKEN` and steal your token.
Given this constraint, I did all the work using two of my repos:
- https://github.com/vjeux/facts-tracker
- https://github.com/vjeux/facts-tracker-test
and am sending this pull request that should work as is /fingers crossed/, but we won't be able to test it out until it is committed.
Note that once this lands, I'm going to kill those two repos.
* Update with all the suggested changes
* Branch on a flow type in travis.yml
* Use $GITHUB_TOKEN
* properly escape it
* Resolve flow errors with ReactTestRenderer
* Add whitespace between types and methods
* extend ReactMultiChild instead of using Object.assign
* Use ReactElement type from ReactElementType
* Make ReactMultiChild a class
This ensures we ignore relative to our project root and won't be tripped up by issues where checkouts in other places result in Flow passing when it shouldn't (eg on Travis CI where the checkout path is `/home/travis/build/facebook/react`)
* High priority work
Adds the ability to schedule and perform high priority work. In the
noop renderer, this is exposed using a method `performHighPriWork(fn)`
where the function is executed and all updates in that scope are given
high priority.
To do this, the scheduler keeps track of a default priority level.
A new function `performWithPriority(priority, fn)` changes the default
priority before calling the function, then resets it afterwards.
* Rename overloaded priority terms
"High" and "low" priority are overloaded terms. There are priority
levels called HighPriority and LowPriority. Meanwhile, there are
functions called {perform,schedule}HighPriWork, which corresponds
to requestAnimationFrame, and {perform,schedule}LowPriWork, which
corresponds to requestIdleCallback. But in fact, work that has
HighPriority is meant to be scheduled with requestIdleCallback.
This is super confusing.
To address this, {perform,schedule}HighPriWork has been renamed
to {perform,schedule}AnimationWork, and
{perform,schedule}LowPriWork has been renamed to
{perform,schedule}DeferredWork. HighPriority and LowPriority
remain the same.
* Priority levels merge fix
This also buffers all rows into a single console.log call.
This is because jest nows adds the line number of each console.log
call which becomes quite noisy for these trees.
This is unfortunate since we agreed on using the `null | Fiber`
convention instead of `?Fiber` but haven't upgraded yet and this
is the pattern I've been using everywhere else so far.
We should be able to abort an update without any side-effects to the
current tree. This fixes a few cases where that was broken.
The callback list should only ever be set on the workInProgress.
There's no reason to add it to the current tree because they're not
needed after they are called during the commit phase.
Also found a bug where the memoizedProps were set to null in the
case of an update, because the pendingProps were null. Fixed by
transfering the props from the instance, like we were already doing
with state.
Added a test to ensure that setState can be called inside a
callback.
Callbacks are stored on the same queue as updates. They care called
during the commit phase, after the updates have been flushed.
Because the update queue is cleared during the completion phase (before
commit), a new field has been added to fiber called callbackList. The
queue is transferred from updateQueue to callbackList during completion.
During commit, the list is reset.
Need a test to confirm that callbacks are not lost if an update is
preempted.
Rather than bubble up both trees, bubble up once and assign to the
alternate at each level.
Extract logic for adding to the queue to the StateQueue module.
Updates are scheduled by setting a work priority on the fiber and bubbling it to
the root. Because the instance does not know which tree is current at any given
time, the update is scheduled on both fiber alternates.
Need to add more unit tests to cover edge cases.
This colocates the reliance on alternate with the scheduler, so
that we have the option to not use this, or more easily break
apart the initial mount phase into an optimized path.
I'll probably end up reverting this before the bigger release
since it is not part of the official public API. However,
it is useful to be able to compare the performance between
functional components and classes.
The findPendingWork phase is the same as just walking the tree the
normal way effectively. It only makes things more complex to
think about. We might possibly be able to write a few special
branches to optimize it but for now it doesn't seem necessary.
The priority level gets reset at the wrong time because I rely
on mutating it at the wrong point. This moves it to the end of
completed work as a second pass over the children to see what
the highest priority is. This is inefficient for large sets but
we can try to find a smarter way to do this later. E.g. passing
it down the stack.
This bug fix revealed another bug that I had flagged before that
we're finding work to do in the "current" tree instead of the
working tree. For trees that were paused, e.g. childInProgress
trees, this won't work since don't have a current tree to search.
Therefore I fixed findNextUnitOfWorkAtPriority to use
workInProgress instead of current.
* Implement optional mockConfig and getMockRef
* default mockConfig, walk render tree
* Pass mockConfig to transaction
* Attach mockConfig to transaction
* type mockConfig in ReactRef
* Expect object in native component ref test
* Fix argument name for attachRefs
* Add mockConfig support to legacy refs
* Pass transaction to getPublicInstance
* Implement getMockConfig on ReactTestReconcileTransaction
* Merge defaultMockConfig and mockConfig options
* Rename mockConfig to testOptions
* Break getPublicInstnce into three lines
* createMockRef -> createNodeMock
Due to a typo in PR#7667 where I put 'DispatchConfig' when the type was
'EventTypes', there were some flow errors being thrown.
Then PR#7642 fixed a bug in SimpleEventPlugin and added some untyped
methods, which threw more flow errors.
Last, while fixing this, I fixed two eslint errors in the
SimpleEventPlugin test.
* Cull disabled mouse events at plugin level. Remove component level filters
* DisabledInputUtils tests are now for SimpleEventPlugin
* Add click bubbling test
* Add isInteractive function. Use in iOS click exception rules
* Invert interactive check in local click listener. Add test coverage
* Reduce number of mouse events disabable. Formatting in isIteractive()
* Switch isInteractive tag order for alignment
* Update formatting of isInteractive method
To demonstrate multiple arguments `bind(this, arg1, arg2, ...)`, also not to pass in for than what `handleClick` needed, namely props, or maybe even pass item itself, etc.
Going to change the kor file after review.
In order to properly type an `Operation`, we need to change the call site from having two arguments: one for `type` and one for `payload` into an object that contains both. This isn't a perf regression because we were already constructing this object in the first place and doesn't change the emitted event so shouldn't affect the dev tools.
None of the call sites are actually flow-ified so it isn't technically used but once we will, it'll make sure that we don't send random strings and payload through those very generic methods.
React IDs have been killed and there was one call site left in a test. I trimmed down the implementation to keep only what is actually used and inlined it inside of the test so we don't get more people using it in the future.
* Type SimpleEventPlugin and TapEventPlugin
- Renamed file from 'ReactSynteticEvent' to 'ReactSyntheticEventType'
- Fills in the 'any' holes that were left in DispatchConfig type and the
type annotations in EventPluginRegistry.
- Adds polymorphic PluginModule type and related types
- Uses hack to support indexable properties on 'Touch' type in
TapEventPlugin
The issue in TapEventPlugin is that the code is accessing one of four
possible properties on the 'Touch' type native event using the bracket
accessor. Classes in Flow don't support using the bracket accessor,
unless you use a declaration and the syntax `[key: Type]: Type`.[1] The
downside of using that here is that we create a global type, which we
may not need in other files.
[1]: https://github.com/facebook/flow/issues/1323
Other options:
- Use looser typing or a '@FixMe' comment and open an issue with Flow to
support indexing on regular classes.
- Rewrite TapEventPlugin to not use the bracket accessor on 'Touch'. I
thought the current implementation was elegant and didn't want to
change it. But we could do something like this:
```
if (nativeEvent.pageX || nativeEvent.pageY) {
return axis.page === 'pageX' ? nativeEvent.pageX : nativeEvent.pageY;
} else {
var clientAxis = axis.client === 'clientX' ? nativeEvent.clientX : nativeEvent.clientY;
return nativeEvent[axis.client] + ViewportMetrics[axis.envScroll];
}
```
It turns out that flow cannot type `this` with a function constructor + prototype overrides. Turning it to a class makes flow happy and has minimal impact on the output.
In open source, we already use the loose version of the class transform and internally we have one that's outputting even less code if you have `@preventMunge` in the header.
See discussion in https://www.facebook.com/groups/2003630259862046/permalink/2098480820376989/
We disabled coverage in Travis because the implementation was crashing ( https://github.com/facebook/react/issues/6290 ). Since we upgraded to Jest 15, the entire coverage implementation is brand new so we should give it another try.
This commit takes the first incremental step towards adding type checks
to the React event code. A couple of issues came up.
There is an issue with the SyntheticEvent type: Flow declares a
SyntheticEvent type[1] that lacks the non-public properties which are
used in React internals. To solve this I declared a class that extends
SyntheticEvent. This class can be expanded as we add Flow types to more
places where SyntheticEvent instances are referenced.
I'm happy to change this if folks prefer a different approach.
Some options I considered:
- Override the SyntheticEvent declaration with our own declaration
- Pro: We can use 'SyntheticEvent' as a type just like we are used to
when working in any other codebase.
- Pro: No need to import any type since it's a declaration
- Pro: Only one version of SyntheticEvent; less confusion.
- Con: Could get out of sync with real implementation.
- Con: Duplicates part of the type declared in Flow.
- Import the SyntheticEvent class and use that as the type
- Pro: Keeps type definition in sync with the real implementation.
- Con: Declaration overrides implementation so I'm not sure this would
work.
- Con: Have to remember to import the type.
- Declare a separate type called ReactSyntheticEvent that extends
SyntheticEvent
- Pro: Stays in sync with the Flow SyntheticEvent type;
less duplication.
- Pro: Differentiates this type from the Flow SyntheticEvent type;
less confusion.
- Pro: No need to import any type since it's a declaration
- Con: Could get out of sync with real implementation.
I also ran into an issue where a variable was only non-null when
'__DEV__' is true, similar to PR #7586.[2] The work-around is to force
it to be typed non-null and add a comment documenting the reason. At
this time Flow doesn't have a better way to deal with the situation.
Next steps:
- Specific type for the 'dispatchConfig' property of SyntheticEvent
- More detailed types for PluginName and PluginModule
Lastly; note that I renamed some variables to follow the convention of
reserving PascalCase for classes, enums, and Flow types.
[1]: https://github.com/facebook/flow/blob/master/lib/react.js#L277-L293
[2]: b99eb5087b
We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.
It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
Jest 15 has just been released and is way more awesome: http://facebook.github.io/jest/blog/2016/09/01/jest-15.html
This pull request updates jest from version 12 to 15. Right now there's a fix in jest around Symbol that hasn't been released yet, so this will break CI and cannot be merged it. But once it ships by the end of the day, we'll be good to go :)
See comments inline for all the changes I've done.
This is the last callsite of keyMirror! It removes 0.5k gzipped :)
The only trick with this one is that ReactTestUtils actually iterates over the list of all the events. Instead of duplicating the logic, I used the $Enum feature of flow that lets us statically extract out the type from the dynamic value. Inside of react-dom we're no longer requiring the file directly so it doesn't bloat the file size, and we still get to have static typing, best of both worlds!
This one is interesting because we have transaction objects being passed around everywhere in the codebase but there's actually no Transaction class. It's a "mixin" that comes to life by being Object.assigned to the prototype of a real "class" (before class was cool!). Therefore, we can't just say `var Transaction = require('Transaction'); (transaction: Transaction) => { }` because it would be the object that contains a mixin and not an instance of a transaction.
The trick I use is to export `TransactionType` and alias it to `Transaction` in the file as it doesn't actually require transaction. In case they do, we'll figure it out, but in the few files I looked at, it doesn't seem to be the case.
For the perform function, it actually typechecks pretty well!
This one was really interesting to type as it's doing a lot of unusual JavaScript. Fortunately flow is now pretty kick ass and I've been able to mostly type it. The only missing piece is that it won't check the constructor arguments.
If you are a fb employee, you can follow the discussion here: https://www.facebook.com/groups/flowtype/permalink/1132359430146004/
Incrementally type ReactInstance by adding the types of attach/detachRef.
I moved isValidOwner as a function inside of the file since it's never used externally.
This one involves a bit more work as I added "phantom" flow types to a bunch of places where the type is a ReactPropTypeLocations even though those files are not `@flow` yet.
A good side effect is that `ReactPropTypeLocationNames` keys are now correctly typed, this means that they cannot go out of sync without breaking flow :)
Flow doesn't really support the concept of variables that are non-null but only inside of a `__DEV__` block. There's an internal post about it ( https://www.facebook.com/groups/flowtype/permalink/1132437726804841/ ) and the conclusion is that we should force it to be non-null and trust the developer to put the proper DEV checks in place.
We need to export FlushHistory type and I submitted a PR on flow to fix the type of console.table which is too restrictive.
I'm already starting to see the benefits of flow, I can look at random variables in the code and flow knows what shape the objects are! It's really useful to try and understand what's going on :)
In Type ReactComponentTreeHook #7504, I merged even though travis didn't report green (travis for all the fb repos has been backlogged like crazy since this morning) by manually doing `npm test` and `npm run flow` but I didn't ensure that lint was all green.
@millermedeiros pinged me about it so here's a quick fix
For this one, I wanted to type a non-trivial piece of the codebase and ran into the fact that we do not have types for ReactElement nor ReactInstance, so I had to create them.
I'll add comments inline
It used to be slow whenever a type miss occurred because expensive `Error` objects were being created. For example, with `oneOfType([number, data])`, passing a date would create an `Error` object in `number` typechecker for every item.
The savings depend on how much commonly you used `oneOfType()`, and how often it had “misses”. If you used it heavily, you might see 1.5x to 2x performance improvements in `__DEV__` after this fix.
* Write failing test
* Ensure .min and .max are set before .value
* Adjusting test for false negative
* Revert test adjustment (apparently it was only failing locally)
I already had to aliasify to have better control over the requires
so we might as well do it everywhere for consistency.
This probably makes it easier to rebase the rollup work too
because aliases seems to be how you solve this in that world.
This is needed for flat builds. It also lets us get rid of a bunch
of special cases in the build scripts.
It also allow us to just copy the source files into React Native
instead of having to build first to resolve the special cases.
* Remove onBeforeMountComponent hook event
It is unnecessary.
We now pass the element as part of onInstantiateComponent, and it can't change before mounting.
* Remove onComponentHasMounted hook event
It is unused after #7410.
* Replace on(Begin|End)ReconcilerTimer hook events
We already have onBeforeUpdateComponent.
Let's just have on(Before?)(Mount|Update|Unmount)Component and stick with them.
This removes double event dispatches in some hot spots.
* Remove onComponentHasUpdated hook
The tests still pass so presumably it was not necessary.
* Add missing __DEV__ to TestUtils code
* Replace on(InstantiateComponent|SetParent) with onBeforeMountComponent
This lets us further consolidate hooks.
The parent ID is now passed as an argument to onBeforeMountComponent() with the element.
* Remove onMountRootComponent hook event
It is unnecessary now that we pass the parent ID to onBeforeMountComponent.
* Use parentDebugID = 0 both for roots and production
This removes some awkward branching.
This builds a `react-dom-fiber.js` bundle which exposes ReactDOMFiber.
This allows early experiments with the new Fiber reconciler.
I also expose it in the npm package through `react-dom/fiber`.
This copies modules into three separate packages instead of
putting it all in React.
The overlap in shared and between renderers gets duplicated.
This allows the isomorphic package to stay minimal. It can also
be used as a direct dependency without much risk.
This also allow us to ship versions to each renderer independently
and we can ship renderers without updating the main react package
dependency.
We currently write all our tests against the DOM implementation.
I need a way to run the Fiber tests against it. But I don't want
to take on any package dependencies on Fiber modules yet.
There's a problem with jest right now where you can't globally
mock modules that already exist. So I have to add a global call
to jest.mock.
Luckily we already have a way to test the useCreateElement paths
using a feature flag. I won't activate this flag in travis until
it passes, but the idea is to run all three variants in travis.
I'm not sure that invoking rAF and rIC synchronously is the best
way to test this since it doesn't capture the backwards
compatibility aspect. I.e. the fact that people might be relying
on the synchronous nature in real apps too. It's a start.
Ideally, jest would have these built-in.
* Remove unnecessary indirection from the tree hook
* Replace onSetDisplayName, onSetOwner, onSetText with one event
Less events is better.
onSetDisplayName, onSetOwner, and onSetText only existed because we didn't initially track elements.
* Remove unused variables
* Prevent internal performance regression
This only affects Facebook website, not open source version of React.
On the Facebook website, we don't have a transform for warnings and invariants.
Therefore, expensive arguments will be calculated even if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.
In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).
* Put warning() that shows up in profile behind condition
* corrected ReactChildrenMutationWarningHook's name
* changed `onComponentHasMounted` to `onMountComponent`
and get element from `ReactComponentTreeHook` instead of keeping an internal store
Without this we end up bundling all of the isomorphic React into
the DOM bundle. This was fixed in #7168 too but I'll just do an
early fix to ensure that #7168 is purely an npm change.
* Cut out isomorphic dependencies from the renderers
These files reaches into isomorphic files.
The ReactElement functions are exposed on the React object anyway
so I can just use those instead.
I also found some files that are not shared that should be in
renderers shared.
* Found a few more shared dependencies
renderSubtreeIntoContainer is only used by the DOM renderer.
It's not an addon.
ReactClass isn't needed as a dependency since injection doesn't
happen anymore.
* Use a shim file to load addons' dependencies on DOM
By replacing this intermediate file we can do the lazy loading
without needing any lazy requires. This set up works with ES
modules.
We could also replace the globalShim thing with aliased files
instead for consistency.
* Bundle DOM renderers into their individual UMD bundles
Instead of exposing the entire DOM renderer on the react.js
package, I only expose CurrentOwner and ComponentTreeDevtool which
are currently the only two modules that share __state__ with the
renderers.
Then I package each renderer in its own package. That could allow
us to drop more server dependencies from the client package. It
will also allow us to ship fiber as a separate renderer.
Unminified DEV after before
react.js 123kb 696kb
react-with-addons.js 227kb 774kb
react-dom.js 668kb 1kb
react-dom-server.js 638kb 1kb
Minified PROD after before
react.min.js 24kb 154kb
react-with-addons.min.js 37kb 166kb
react-dom.min.js 149kb 1kb
react-dom-server.min.js 144kb 1kb
The total size for react.min.js + react-dom.min.js is +19kb larger
because of the overlap between them right now. I'd like to see
what an optimizing compiler can do to this. Some of that is fbjs
stuff. There shouldn't need to be that much overlap so that's
something we can hunt. We should keep isomorphic absolutely
minimal so there's no reason for other React clones not to use it.
There will be less overlap with Fiber.
However, another strategy that we could do is package the
isomorphic package into each renderer bundle and conditionally
initialize it if it hasn't already been initialized. That way
you only pay an overlap tax when there are two renderers on the
page but not without it. It's also easier to just pull in one
package. The downside is the versioning stuff that the separate
npm package would solve. That applies to CDNs as well.
ReactWithAddons is a bit weird because it is packaged into the
isomorphic package but has a bunch of DOM dependencies. So we have
to load them lazily since the DOM package gets initialized after.
This took a while to figure out, but we need to be able to store
children that are currently being worked on separately from the
current children. We always need a canonical "current" children
so that we can update them. However, we also need a different set
that we're currently working on so that we have a way to get to
already progressed work.
This solve the starvation problem in the first render because now
we can reach children that were never rendered and have a place
to store their progressed work on. The unit test changes tests
this.
This lets us get rid of the hasWorkInProgress flag.
When we reconcile new children we need to reconcile them against
progressed work so that we can reuse it. The progressed work is
"work in progress" nodes. So in that case we need to mutate
instead of clone, to preserve the invariant that only two versions
exist at any given point. This effectively forks the
ReactChildFiber implementation.
We need to use the *other* child because we reset it to the
current one on the way up.
We also need to reset the first/last side-effects to that of the
children so that we're committing the right thing.
Thanks @acdlite. Add comment about future unit test coverage.
This was actually hiding the fact that we are only able to reuse
existing work if it was marked as completely finished which it
won't be if we reuse its pending priority.
However, we should be able to bail out even if there is work
remaining in a subtree.
When we downprioritize children we need to remember to reuse the
old children in the update side-effect.
This whole set up is very unfortunate since we can have children
in our active tree that never actually finished rendering. This
strategy might be fundamentally flawed, not sure.
This might become confusing later but is unreachable today. That's
because existing pendingProps only matter when a clone is updated,
but this path can only matter when it is created.
If the current work is higher priority than the new work, then
don't bother resetting the unit of work pointer since it won't
affect the execution order.
I'm paranoid about inline-ability so I use this pattern of adding
a constant to the closure everywhere.
ES6 modules help avoid that but we can't use that consistently
because of the dependency injection so instead I opt for making
this explicit everywhere.
Grep: \b[a-zA-Z_$\d]+\.[a-zA-Z_$\d]+\(
'change' custom events raise "Member not found" in <= IE10. To
circumvent this, the SyntheticEvent class now checks for "typeof
event.cancelBubble !== 'unknown'". This eliminates this exception and
maintains the expected bubbling functionality.
Addresses #7320.
* PropTypes: distinguish nullable from optional object field
This gives a more precise message (no type semantics change) to the case of passing a field in an object, but whose value is `null`:
Before:
```js
propTypes: {
foo: React.PropTypes.number.isRequired
}
```
Would scream "Required prop `foo` was not specified in `MyComp`".
Now it'll be "Required prop `foo` was specified in `MyComp`, but its value is `null`.".
Works as expected in nested objects.
This fixes the issue of a component transitively passing a `null`, specifying the correct field to the child but have the child tell it that it didn't provide the prop.
Optional field and nullable are two different things anyway.
* Add missing test case.
* Reword messages.
For controlled inputs, `updateWrapper` was getting called before the
`type` prop had a chance to update. This could lead to a case where
switching from the `text` to `number` type caused a validation error
that would prevent the proper input value from being assigned.
This commit moves the call to `ReactDOMInput.updateWrapper` below
`_updateProperties` to avoid this situation.
"It is worth repeating: there is no configuration files or complicated folder structures." > "It is worth repeating: there are no configuration files or complicated folder structures."
- Reverts change to use sectionid on layouts (was unreliable), using config to make sure that's specified on all pages that need it
- Adds permalinks to all other pages so that og data is correct
- Corrects some permalinks that were in correct (translations)
* Eagerly evaluate inline requires in Jest
I inlined some requires in #7188 to fix the build size regression.
However this caused an issue with Jest due to it resetting module registry between tests.
This is a temporary fix to #7240.
It should be reverted as part of #7178.
* Make the hack work in all environments
Previously, the extract-components script would create the same number of layers of composites as the page it captures, but it would output a new class for each time any composite is used (since we don't want to replicate all the component logic).
I changed the script to output a single type for each type in the input -- and each generated component takes an index for which output it should return. This should be closer to how the original code behaves, especially with respect to VM function call lookups where the amount of polymorphism makes a difference.
I re-recorded the benchmarks with the new scripts. They run significantly faster:
```
Comparing old.txt (control) vs new.txt (test)
Significant differences marked by ***
% change from control to test, with 99% CIs:
* ssr_pe_cold_ms_jsc_jit
% change: -41.73% [-43.37%, -40.09%] ***
means: 39.3191 (control), 22.9127 (test)
* ssr_pe_cold_ms_jsc_nojit
% change: -44.24% [-46.69%, -41.80%] ***
means: 45.8646 (control), 25.5764 (test)
* ssr_pe_cold_ms_node
% change: -45.61% [-47.38%, -43.85%] ***
means: 90.1118 (control), 49.0116 (test)
```
This is probably in part due to the changes here, but also the page I captured has changed somewhat in the meantime and there seem to be slightly fewer components in the hierarchy, so they're not really comparable. But going forward we can use this benchmark which should be more accurate. I also included an identical copy that uses stateless functional components so we can test optimizations to those later.
As reported in #7227, unmounting performance regressed with React 15.
It seems that `delete` has become much slower since we started using numeric keys.
Forcing dictionary keys to start with a dot fixes the issue.
* Add failing test demonstrating a ReactPerf warning
* Make the failing ReactPerf test more precise
* Make ReactPerf.start() work during reconciliation
* Reorder lifecycle methods for greater clarity
* Fix memory leak
* Error boundaries should not break ReactPerf
* Put onBeginFlush/onEndFlush into transaction wrappers
This looks cleaner even though it is not strictly necessary.
We still call them manually for unmounting because it doesn't have a transaction.
This provides an easy way to indicate that components should only rerender when given new props, like PureRenderMixin. If you rely on mutation in your React components, you can continue to use `React.Component`.
Inheriting from `React.PureComponent` indicates to React that your component doesn't need to rerender when the props are unchanged. We'll compare the old and new props before each render and short-circuit if they're unchanged. It's like an automatic shouldComponentUpdate.
* Add failing tests for #7187 and #7190
* Pass shouldHaveDebugID flag to instantiateComponent
This allows us to remove a hack that was added in #6770 and caused #7187 and #7190.
* Move logic for choosing whether to use debugID outside instantiate
Touch behavior is inconsistent across different platforms, and ResponderTouchHistoryStore currently fatals when assumptions are broken. In addition, the behavior differs between development and production.
This pull request does a few things to make ResponderTouchHistoryStore easier to deal with:
Adds Flow to keep the TouchEvent, Touch, and TouchRecord types straight.
Changes behavior to be consistent across environments. This means either always throwing or never throwing (and making use of warning and console.error as appropriate).
When an orphaned move or end event is received, print debug information and ignore it instead of crashing and burning.
* Warn if PropType function is called in production
* Check if console is undefined before warning
* Randomize value of ReactPropTypesSecret
* Remove dev environment tests
* Rename typeCheckPass to productionWarningCheck
* Rename productionWarningCheck to expectWarningInProduction
* Call toString on Math.random()
* Rename test block for React type checks
* Make sure warning isnt emitted for failing props
* Cache warning by component and prop, warn in dev
* Pass ReactPropTypesSecret to internal checks
* Move tests to ReactPropTypes-test.js
* Update the warning message to include link
* Do not test warning for unions with invalid args
Summary:
I had to cast into any because flow doesn't think that checking the lowercase version of nodeName is a valid way to refine the variable from HTMLElement to HTMLInputElement. I'm also not confident enough in changing the implementation to an instanceof HTMLInputElement to please flow. It also takes care of the null check in the process.
The `nodeName &&` condition wasn't useful since the two branches are checking it against concrete values and actually makes the type different since nodeName is not a boolean per se. I replaced them with if conditions to make it clearer what it actually did instead of doing boolean logic tricks.
It is unclear why I had to type supportedInputTypes, see this internal post for a discussion: https://www.facebook.com/groups/flowtype/permalink/1084168611631753/
The only difference in behavior is that I now explicitely convert to boolean the object dereference via `!!`.
Test Plan:
npm run flow
Careful inspection of the code
Reviewers: @zpao @spicyj
* Inline dev-only requires
This reduces the production bundled build size.
* Use new references after resetting module registry in tests
This fixes the tests which were broken due to inlining some requires.
This commit fixes#5473: ReactDOMServer.renderToString: presence of onClick
handler causes errors on async update
This commit performs the following changes:
- Adds a getUpdateQueue method to ReactServerRenderingTransaction,
ReactReconcileTransaction, ReactNativeReconcileTransaction and
ReactTestReconcileTransaction
- Make the ReactCompositeComponent call this getUpdateQueue instead of using
ReactUpdateQueue that was unwanted at certain moments on server
- On ReactServerRenderingTransaction, dispatch ReactUpdateQueue's methods
while rendering and warning methods afterwards. This is done through the new
ReactServerUpdateQueue class
- Added a series of tests that mimics the case presented in #5473 with setState,
forceUpdate and replaceState
- Add flow typechecking on concerned files
- Removed the prop transitionAppearTimeout from
addons/transitions/ReactTransitionGroup in order to remove a warning
when passing unknown props to DOM elements.
This is only for host nodes so that the DOM tree is fully updated
by the time we've flushed.
Classes will schedule their life-cycles *after* their children's
side-effects.
This creates a new API for processing side-effects on the host
environment.
During initial reconciliation host instances are created during
the time sliced periods.
During updates there is an opportunity for the host
to prepare something on the instance during the time slicing, and
to determine whether there were any changes. The could be thrown
away.
At the commit phase, these changes are finally committed to the
host instance.
This adds tracking of side-effects that gets scheduled during an
update.
As the tree gets reconciled, the side-effectful fibers are linked
together in an ordered singly linked list. That way we can walk
the linked list to commit only the work that needs to be
synchronous - quickly.
We also store first and last nodes within a fiber. That
way when we reuse an already processed subtree, we can reuse that
subset of the linked list.
This is not just the parent Instance but also the return Fiber for
some piece of work. This clarifies and buys into this definition.
Basically, in the current model you will always pass into a fiber
from the parent that you're going to return to. Even if you get
aborted and reused this will be updated to the correct return
fiber before you get back here.
I don't have any guarantees in place to enforce this right now. I
don't really know how to, but seems safe. :)
I confirmed that the use of keyword properties work for old
engines because we have the transform enabled in our build system.
This tries to reuse work that was completed but another higher
priority event came in. This tries to avoid starvation when high
priority events causes low pri work to keep rerendering from
scratch.
First I fix a bug where host components didn't properly bail out
although this was unobservable.
When we bail out, we need to ensure that we preserve the highest
remaining priority work that is left to do for that subtree.
This still isn't properly handling the case when that work has the
*same* priority as the current one. That work will be flushed the
*next* tick instead of the current pass.
I can't create a test for that yet since I need setState to get to
that state.
This fixes some bugs with the clones and traversing backwards
through them. It is important that we maintain the correct parent
at all times and that clones have the correct values.
We need to carefully clone everything on the way up to the the
fiber with the next work to do.
This code is a bit messy and fragile now. I'm sure I didn't get it
all right but I want to get the basics in place first. Then we can
structure this part better. I think the general algorithm is sound
though.
We need a canonical stateful root for each. I don't really want to
overload the HostContainer for this purpose since it makes the
fiber code more specialized.
Instead I create a root which represents an actual stateful root.
When these get scheduled they get chained together in a linked
list. However, we don't hold onto anything that doesn't have
scheduled work. This will help us release everything automatically
in the GC, as long as there are no subscriptions nor scheduled
work.
This is a bit poorly structured. I'll restructure when the pieces
are better in place.
Basically we reset the priority of a node before work on the
children. The children then bump their parent if they end up
having work left.
This is the first time we're seeing deep updates happening. The
new unit test demonstrates this.
There is an interesting case that happens when we fall back out of
a deep update. We end up "completing" a node that we didn't begin.
This probably breaks in coroutines. When that completes, it'll try
to render the sibling next but that should bail out so we check
for any pending work on the sibling. That one I'm not sure about.
This is essentially equivalent to the current top level wrappers.
They contain the next children to be mounted into a container node
from the host.
It is the responsibility of the host to retain references to them
for updates.
I expect them to be able to exist in the middle of the tree in
the future, for renderSubtreeIntoContainer.
This flag on fibers will be used to track what priority of work is
needed by that subtree, if any at all.
Also fix up the TypeOfWork to have consistent naming and typing.
* Fix for 5468: Validate proptype definitions sooner
Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added __DEV__ warning for invalid oneOf/OneOfType args
* Suppress redundant error on warn; typeCheckWarn() removed
* Return no-op
* Using emptyFunction module for consistency
* Remove createChainableTypeChecker() call
* Adjust test to assert type check passes when warned
* create failing test case
* Fix renderSubtreeIntoContainer to update context
Fixes#6599
* Also test re-rendering due to prop update
* Address review feedback
This was added to catch internal errors in React but doesn't seem to be doing much good except frustrating people more when their apps throw (#6895, FB-internal t11950821). Until more proper error boundaries land, let's make this a warning.
Although it is unreasonable to set every possible property for
simulated events, `type` is useful for event handlers that are shared
between types and potentially have different behaviors.
* Resolve refs in the order of the children
React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved.
With the current `ReactMultiChild`, this is *usually* the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when **a new child is mounted during an update**.
In this case, the `mountComponent()` call used to be delayed until `ReactMultiChild` processes the queue. However, this is inconsistent with how updates normally work: unlike mounting, updating and unmounting happens inside `ReactChildReconciler.updateChildren()` loop.
This PR changes the `mountComponent()` to be performed inside `ReactChildReconciler`, just like `receiveComponent()` and `unmountComponent()`, and thus ensures that `attachRef()` calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved.
This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change).
* Use array instead of object to avoid lookups
Summary:
The only callsite of ReactStateSetters is in LinkedStateMixin which lives in addons/link. Better move it there to avoid cluttering the other folder.
Test Plan:
None
Reviewers: @zpao @spicyj
Summary:
The only callsite left was removed here: e8af100849 (commitcomment-17570210) but the code to handle it remained.
Test Plan:
tbgs and ibgs, make sure there's no callsites.
Reviewers: @jimfb, @spicyj, @sebmarkbage
* Standardise format of the three "state" questions.
The original format follows the template:
> 1. x? if `x` then probably isn't state
> 2. y? if `!y` then probably isn't state
> 3. z? if `z` then it's not state
This caused both me and a hallway tester to do a double take.
The proposed reformulation allows the answers to follow the same template.
In the same spirit, it uses the same contraction pattern in the last answer (`it's not state`-> `it isn't state`). This has the welcome side effect to make the lack of "probably" stand out more.
* Update phrasing in thinking in reacr
Summary:
Trying to start adding flow types to files in React. I needed to add a script to package.json in order to run flow, flow-bin is already a dependency.
I had to rewrite the implementation a bit. Flow doesn't recognize
```
var currentIsArray = Array.isArray(current);
if (currentIsArray) {
// not refined
}
```
but the following does work
```
if (Array.isArray(current)) {
// refined
}
```
Test Plan:
npm run-script flow
npm run-script test accumulate
Reviewers: @zpao @spicyj
* Workaround IE lacking innerHTML on SVG elements
* Add tests for setInnerHTML
* Correctly check if node has innerHTML property
* Ensure tests for setInnerHTML actually tests both codepaths
* Provide mock element for setInnerHTML tests
* Only use SVG setInnerHTML workaround for SVG elements
This avoids using .alternate as much as possible and isolates it
to the root. For anything that is "work in progress" this happens
to be the same as the alternate field. To avoid an extra "current"
field on work in progress fibers, we can just use the alternate.
The timing for when this is true might be a bit tricky to reason
about so I explicitly pass the current value everywhere from the
top. That way we can always change this in the future to use an
explicit field or we can try to maintain a parallel data
structure that remembers which was the "current" fiber for each
wip child.
These values represent fibers that are incomplete. In the current
model they're mutated in place. In a completely immutable model
they would need to be cloned for every step they make progress.
I.e. one where the child is still in this WIP state and one when
it is complete.
To clarify this I'll name them workInProgress while they're in
that state, which is also what Jordan did in his prototype.
This splits the Fiber type into Fiber and Instance. This could be
two different object instances to save memory. However, to avoid
GC thrash I merge them into one.
When ReactChildFiber reconciles children, it clones the previous
fiber. This creates a new tree for work-in-progress. The idea is
that once flushed, this new tree will be used at the root.
However, we know that we'll never need more than two trees
at a time. Therefore my clone function stores the clone on the
original. Effectively this creates a fiber pool.
Ideally, the .alternate field shouldn't be used outside of clone
so that everything can work with pure immutability. I cheat a bit
for now so I don't have to pass both trees everywhere.
ReactChildFiber is a bit hacky for reuse and doesn't solve all
cases. Will fix that once I try to get parity.
Also ignore examples, important because react can be installed by the commonjs
one and the modules will get detected there too, resulting in duplicate
definitions
Most people don't use the official Flux implementation or docs so I think this is likely to be more confusing than helpful. Maybe later we can add a better comparison of data management solutions.
This gets rid of a field that we only need for coroutines.
We might need this if we have multi phase handlers in the future
but then maybe we can just use multiple tags.
This has a few benefits:
1) This allows the element to always remain on the young generation.
2) The key can be accessed on the fiber which is easier to keep as the
same class and is directly accessible in the child reconciliation of every
object.
3) This conveniently means that we don't have to create a fake element for
continuations which was really hacky.
We can still do the quick bailout of rerendered things using the props
object which is also unique.
We don’t want to have different behavior in development and production.
Previously, we used to ignore getters on key/ref in dev, but we’d read them in prod.
Now, we only ignore the getters that we *know* we created so the production logic doesn’t differ.
This way in other cases both DEV and PROD falls through to the check for undefined.
This fixes#6879 and a similar bug introduced for cloneElement() in 94d0dc68c8.
It currently fails in `createElement` because of #6879 which was introduced in #5744.
It also fails in `cloneElement` because the code with that bug was extracted and shared in 94d0dc68c8.
Previously, this threw:
```
FAIL src/test/__tests__/ReactTestUtils-test.js (7.291s)
● ReactTestUtils › it can fail context when shallowly rendering
- TypeError: Cannot read property '_source' of null
at describeID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:70:46)
at Object.ReactComponentTreeDevtool.getStackAddendumByID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:203:15)
at checkReactTypeSpec (src/isomorphic/classic/types/checkReactTypeSpec.js:76:58)
at ReactCompositeComponentMixin._checkContextTypes (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:668:5)
at ReactCompositeComponentMixin._processContext (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:607:14)
at ReactCompositeComponentMixin.mountComponent (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:191:30)
at ReactShallowRenderer._render (src/test/ReactTestUtils.js:483:14)
at _batchedRender (src/test/ReactTestUtils.js:460:12)
at ReactDefaultBatchingStrategyTransaction.Mixin.perform (src/shared/utils/Transaction.js:140:20)
at Object.ReactDefaultBatchingStrategy.batchedUpdates (src/renderers/shared/stack/reconciler/ReactDefaultBatchingStrategy.js:65:19)
at Object.batchedUpdates (src/renderers/shared/stack/reconciler/ReactUpdates.js:112:20)
at ReactShallowRenderer.render (src/test/ReactTestUtils.js:453:16)
at Spec.eval (src/test/__tests__/ReactTestUtils-test.js:289:34)
at jasmine.Block.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:1067:17)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at jasmine.Queue.start (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2053:8)
at Spec.jasmine.Spec.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2380:14)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at onComplete (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2096:18)
at Spec.jasmine.Spec.finish (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2354:5)
at eval [as onComplete] (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2381:10)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2110:14)
at eval (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2090:18)
at Timeout.e [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:440:19)
at tryOnTimeout (timers.js:224:11)
at Timer.listOnTimeout (timers.js:198:5)
```
* Don't count the time inside flushes towards lifecycle hooks
Fixes#6842.
We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush.
This solves an issue with portals which cause updates while a lifecycle timer is already running.
I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table.
* Fix up the comment
This helps us make sure we don't break React ART in a minor or patch release. The idea is to not change these files when making minor or patch changes. Copied directly from react-art with requires fixed. (I also picked a different haste name just in case.)
* Fix componentWillUnmount() not counted by ReactPerf
* Test that functional component render() time shows up in ReactPerf
* Test for setState() code path updates being included
* Update shallowCompare to accept nextContext
Across our application we are using immutable objects as properties and thus using shallowCompare for all our {{shouldComponentUpdate}}. Because of this children with contextTypes don't get updates when the context on the parent changes. Adding an additional comparison for context (when it is provided) fixes this problem.
* Remove the undefined check
* Add nextContext
This adds some tests for getElement() and verifies that it works for text components too.
The code that calls the instrumentation is fixed where necessary so that the tests pass.
We extract common logic between DOM and native tests so they don't diverge.
Also, rather than build a tree object in advance for testing, we will walk the tree on the go.
This lets us have much more specific error messages with a clear path when something goes wrong.
Test Plan: Changed the preprocessor to log the output of babel.transform and saw
```
var _jsxFileName = 'src/isomorphic/modern/element/__tests__/ReactJSXElementValidator-test.js';
```
in the resulting output, instead of an absolute path.
One of the ReactMultiChildText tests renders 2145 roots (and even more components) and unmounts none of them. Now we don't loop through them all a bunch of times so the test takes 20 seconds instead of 60.
We should clean up instantiateReactComponent somehow so that the onSetDisplayName call isn't produced for the TopLevelWrapper, which should allow us to just store an array of unmountedIDs instead of a hash map so we at least don't have double maps. This change mirrors the old logic though.
Reviewers: @gaearon, @sebmarkbage
Being able to get the source for your parent components seems useful, and ReactComponentTreeDevtool is best poised to be able to do that.
I'm also not sure it makes sense to have separate DOM-specific `onMountDOMComponent` and `onUpdateDOMComponent` events, so I removed them for now. Even if we want them, their timing seemed sort of arbitrary.
I also made it so DOM devtools can listen to non-DOM events too. Willing to change that if people think it's ugly though.
I *think* this should refer to the second example, where the instance to the ref is stored. In any case please can someone confirm for my own understanding?
For clarity.
I left "native event" as-is because there's a lot of it, it's not particularly ambiguous, and SimulateNative/nativeTouchData are public API in ReactTestUtils.
`ReactDebugTool` used to only call `purgeUnmountedComponents()` while profiling, so information about unmounted instances kept accumulating when not profiling.
Additionally, unmounting in React Native and rendering to string did not correctly clean up the devtool.
Finally, the tests tested the wrong behavior and relied on explicit `purgeUnmountedComponent()` calls.
To fix this, we:
* Test specifically that unmounting is enough to clean up the tree devtool.
* Add missing `onBeginFlush` and `onEndFlush` calls to server and native rendering so `ReactDebugTool` knows when to copy the tree.
Fixes#6750
This is an outline for the new reconciler infrastructure.
I created a noop renderer to have something to get started from.
I split the reconciler folder into old and new, as well as shared.
I put shouldUpdateReactComponent in shared as an example of a
utility that can easily be shared between both. I plan on breaking
out more utilities like these.
* New approach for 6062 fix : Show source line number on unknown property warning
* WIP: ReactDebugToolEventForwarderDevTool
* Update event signature to debugID
* Trigger events in ReactDOMComponent
* Renamed to onMountDOMComponent; passing in element directly
* Added debugID; updated simple test
* Added test for multi-div JSX to ref exact line
* Added test for composite component
This just configures flow to be checked and fixes our existing
Flow typed files.
Possible enhancements:
Export .js.flow declarations from the build. Unclear whether this
will be a supported workflow in the future or not, so let's wait
on that.
We should fail builds and CI on Flow errors.
Ideally we should lint for Flow style guides (like no space before
colon).
Technically this shouldn't happen but it seems possible with ReactNativeMount.unmountComponentAtNode().
For now, let's just ignore these lifecycle events because ReactPerf makes a hard assumption that all lifecycle hooks happen inside batches.
We can revisit later when we have a comprehensive test suite for ReactPerf itself.
This makes it easier to figure out where the docs live.
Googling for e.g. `react-addons-update` also works, but this should
make things easier for people that hyperclick directly to the source.
This is no longer needed on the native side.
This is also the last use of the Platform flag. React Core is now
platform agnostic with regard to React Native. So I'll remove
the mocks and dependency.
* Create 01-why-react.zh-TW.md
Translation for language code [zh-TW](https://en.wikipedia.org/wiki/Zh-TW)
* Update 01-why-react.zh-TW.md
change "封裝性非常好" to "封裝性高"
The current warning condition caused the first error to be swallowed, and all the next errors to be logged. I believe the intention was the opposite: to log the first error, and to ignore any next errors for the same method.
This can happen if something gets unmounted before the event gets
dispatched. I'm not sure how this works out exactly but this
preserves previous behavior in this scenario.
This fixes an issue where handling events on a node that was just removed threw a "All native instances should have a tag." error and matches what we do in the DOM renderer in ReactEventListener.
This isn't actually used right now so I can't test it. Because the
Chrome devtools are broken for React Native. The Nuclide integration
is in the react-native repo.
Our module rewrite whitelist needs to ignore providesModule files
that are going to be required from the global React Native
environment.
We also need to add ReactDOM to providesModule since we removed it
from React Native.
Moving the event plugins into their dedicated folder
Removing the ExecutionEnvironment override. I will just have to fix where needed. Probably related to the Chrome debugger?
* Only fire input value change events when the value changes
fixes#554, fixes#1471, fixes#2185 (still trying to figure out why)
* catch programmatic value changes
* move value tracking to seperate module
- Use correct "Note" formatting so they render correctly
- reordered sections so Node is first
- Use "Node.js" consistently (it is a product name just like Nashorn)
- added/tweaked some of the text
- simplified the Java code so it doesn't hit the internet.
ReactDOMInput and a few other classes handle change event by scheduling updateWrapper() in an asap().
It gets executed after the batch, which confuses ReactPerf that expects all DOM writes to happen during a batch.
Since this implementation of ReactPerf relying on the stack is going away, let's plug the hole temporarily by ignoring DOM writes that occur during postponed updateWrapper(). In any case, they have no relation to actual calculations of wasted renders, as they don't occur due to updateComponent(), but rather due to onChange() special DOM behavior.
This fixes#5548
This commit migrates over the disabled property behavior from
ReactDOMButton into a general purpose disabled event filter. It also
applies that behavior to inputs, selects, and textareas.
Since "This" is the subject and singular, "have" should be "has"
New wording explaining implementation details
Grammar fix for 15.0 blog post
Since "This" is the subject and singular, "have" should be "has"
Fix wording for 15.0 blog post
nitpicks
There seems to be a bug with medikoo/es6-symbol where the global state
affects the implementation of the polyfill. I found this by running the
individual test file alone then running all the tests using `grunt
test`. I found that it passes when ran alone and failed when ran
collectively.
I did not find this buggy behavior with zloirock/core-js's
implementation of a polyfill for Symbol. Thus, removing I will keep the
more popular polyfill (core-js) and remove the buggy polyfill
(es6-symbol).
If you are reading this and can think of a confounding factor that is
causing this bug, please let me know and we can try to work together to
add support for medikoo/es6-symbol.
Let's get more specific with our tests. Symbol has to be a function if
it's a polyfill. There are no object polyfills out there. (If there is,
ping me and I'll add support)
Instead of checking if Symbol is undefined, let's check if it's a
function instead since instanceof is depending that Symbol is already a
function.
1) If it is a native Symbol
2) If it is spec-compliant
3) Try to match non-spec compliant polyfill by a instanceof check on Symbol if it exists in the global namespace
Most ES6 polyfills will add support by implementing `Symbol` as a
function. This causes `typeof` to return `function` rather than `symbol`
for polyfilled clients.
With the edition of ECMA-262, we now have a new primative type called
Symbol. This primative type should be added to the PropTypes, as users
will eventually be using Symbols in their props for describing unique
and immutable data, such as identifiers.
Dev builds wrap synthetic events inside other events for a better debug
experience. However IE/Edge won't allow access to the
DataTransfer.dropEffect property if it's wrapped in this way.
The first time a drag event is fired, test if we're in an environment
that behaves this way and disable React's improved development
experience if we are.
We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory.
Before submitting a pull request, please make sure the following is done:
1. Fork [the repository](https://github.com/facebook/react) and create your branch from `master`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch TestName` is helpful in development.
5. Run `yarn test-prod` to test in the production environment. It supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open `chrome://inspect`, and press "Inspect".
7. Format your code with [prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing: https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Test Plan
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
# Configuration for probot-stale - https://github.com/probot/stale
# Number of days of inactivity before an issue becomes stale
daysUntilStale:90
# Number of days of inactivity before a stale issue is closed
daysUntilClose:7
# Issues with these labels will never be considered stale
exemptLabels:
- "Partner"
- "React Core Team"
- "Resolution: Backlog"
- "Type: Bug"
- "Type: Discussion"
- "Type: Needs Investigation"
- "Type: Regression"
# Label to use when marking an issue as stale
staleLabel:"Resolution: Stale"
issues:
# Comment to post when marking an issue as stale.
markComment:>
This issue has been automatically marked as stale.
**If this issue is still affecting you, please leave any comment** (for example, "bump"), and we'll keep it open.
We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
# Comment to post when closing a stale issue.
closeComment:>
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
pulls:
# Comment to post when marking a pull request as stale.
markComment:>
This pull request has been automatically marked as stale.
**If this pull request is still relevant, please leave any comment** (for example, "bump"), and we'll keep it open.
We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.
# Comment to post when closing a stale pull request.
closeComment:>
Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you!
React is one of Facebook's first open source projects that is both under very active development and is also being used to ship code to everybody on [facebook.com](https://www.facebook.com). We're still working out the kinks to make contributing to this project as easy and transparent as possible, but we're not quite there yet. Hopefully this document makes the process for contributing clear and answers some questions that you may have.
Want to contribute to React? There are a few things you need to know.
## [Code of Conduct](https://code.facebook.com/codeofconduct)
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.facebook.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
## Our Development Process
Some of the core team will be working directly on GitHub. These changes will be public from the beginning. Other changesets will come via a bridge with Facebook's internal source control. This is a necessity as it allows engineers at Facebook outside of the core team to move fast and contribute from an environment they are comfortable in.
### `master` is unsafe
We will do our best to keep `master` in good shape, with tests passing at all times. But in order to move fast, we will make API changes that your application might not be compatible with. We will do our best to communicate these changes and always version appropriately so you can lock into a specific version if need be.
### Test Suite
Use `grunt test` to run the full test suite with PhantomJS.
This command is just a facade to [Jest](https://facebook.github.io/jest/). You may optionally run `npm install -g jest-cli` and use Jest commands directly to have more control over how tests are executed.
For example, `jest --watch` lets you automatically run the test suite on every file change.
You can also run a subset of tests by passing a prefix to `jest`. For instance, `jest ReactDOMSVG` will only run tests in the files that start with `ReactDOMSVG`, such as `ReactDOMSVG-test.js`.
When you know which tests you want to run, you can achieve a fast feedback loop by using these two features together. For example, `jest ReactDOMSVG --watch` will re-run only the matching tests on every change.
Just make sure to run the whole test suite before submitting a pull request!
### Pull Requests
**Working on your first Pull Request?** You can learn how from this *free* series [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github)
The core team will be monitoring for pull requests. When we get one, we'll run some Facebook-specific integration tests on it first. From here, we'll need to get another person to sign off on the changes and then merge the pull request. For API changes we may need to fix internal uses, which could cause some delay. We'll do our best to provide updates and feedback throughout the process.
*Before* submitting a pull request, please make sure the following is done…
1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes (`grunt test`).
5. Make sure your code lints (`grunt lint`) - we've done our best to make sure these rules match our internal linting guidelines.
6. If you haven't already, complete the CLA.
### Contributor License Agreement (CLA)
In order to accept your pull request, we need you to submit a CLA. You only need to do this once, so if you've done this for another Facebook open source project, you're good to go. If you are submitting a pull request for the first time, just let us know that you have completed the CLA and we can cross-check with your GitHub username.
[Complete your CLA here.](https://code.facebook.com/cla)
## Bugs
### Where to Find Known Issues
We will be using GitHub Issues for our public bugs. We will keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.
### Reporting New Issues
The best way to get your bug fixed is to provide a reduced test case. jsFiddle, jsBin, and other sites provide a way to give live examples. Those are especially helpful though may not work for `JSX`-based code.
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. With that in mind, please do not file public issues; go through the process outlined on that page.
## How to Get in Touch
* IRC - [#reactjs on freenode](https://webchat.freenode.net/?channels=reactjs)
* Discussion forum - [discuss.reactjs.org](https://discuss.reactjs.org/)
## Meeting Notes
React team meets once a week to discuss the development of React, future plans, and priorities.
You can find the meeting notes in a [dedicated repository](https://github.com/reactjs/core-notes/).
## Style Guide
Our linter will catch most styling issues that may exist in your code.
You can check the status of your code styling by simply running: `grunt lint`
However, there are still some styles that the linter cannot pick up. If you are unsure about something, looking at [Airbnb's Style Guide](https://github.com/airbnb/javascript) will guide you in the right direction.
### Code Conventions
* Use semicolons `;`
* Commas last `,`
* 2 spaces for indentation (no tabs)
* Prefer `'` over `"`
*`'use strict';`
* 80 character line length
* Write "attractive" code
* Do not use the optional parameters of `setTimeout` and `setInterval`
### Documentation
* Do not wrap lines at 80 characters
## License
By contributing to React, you agree that your contributions will be licensed under its BSD license.
We wrote a **[contribution guide](https://reactjs.org/contributing/how-to-contribute.html)** to help you get started.
React is a JavaScript library for building user interfaces.
* **Just the UI:** Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.
* **Virtual DOM:** React abstracts away the DOM from you, giving a simpler programming model and better performance. React can also render on the server using Node, and it can power native apps using [React Native](https://facebook.github.io/react-native/).
* **Data flow:** React implements one-way reactive data flow which reduces boilerplate and is easier to reason about than traditional data binding.
* **Declarative:** React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.
* **Component-Based:** Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep state out of the DOM.
* **Learn Once, Write Anywhere:** We don't make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using [React Native](https://reactnative.dev/).
**NEW**! Check out our newest project [React Native](https://github.com/facebook/react-native), which uses React and JavaScript to create native mobile apps.
[Learn how to use React in your own project](https://reactjs.org/docs/getting-started.html).
[Learn how to use React in your own project](https://facebook.github.io/react/docs/getting-started.html).
## Installation
React has been designed for gradual adoption from the start, and **you can use as little or as much React as you need**:
* Use [Online Playgrounds](https://reactjs.org/docs/getting-started.html#online-playgrounds) to get a taste of React.
* [Add React to a Website](https://reactjs.org/docs/add-react-to-a-website.html) as a `<script>` tag in one minute.
* [Create a New React App](https://reactjs.org/docs/create-a-new-react-app.html) if you're looking for a powerful JavaScript toolchain.
You can use React as a `<script>` tag from a [CDN](https://reactjs.org/docs/cdn-links.html), or as a `react` package on [npm](https://www.npmjs.com/package/react).
## Documentation
You can find the React documentation [on the website](https://reactjs.org/docs).
Check out the [Getting Started](https://reactjs.org/docs/getting-started.html) page for a quick overview.
The documentation is divided into several sections:
You can improve it by sending pull requests to [this repository](https://github.com/reactjs/reactjs.org).
## Examples
We have several examples [on the website](https://facebook.github.io/react/). Here is the first one to get you started:
We have several examples [on the website](https://reactjs.org/). Here is the first one to get you started:
```js
varHelloMessage=React.createClass({
render:function(){
return<div>Hello{this.props.name}</div>;
}
});
```jsx
functionHelloMessage({name}){
return<div>Hello{name}</div>;
}
ReactDOM.render(
<HelloMessagename="John"/>,
<HelloMessagename="Taylor"/>,
document.getElementById('container')
);
```
This example will render "Hello John" into a container on the page.
This example will render "Hello Taylor" into a container on the page.
You'll notice that we used an HTML-like syntax; [we call it JSX](https://facebook.github.io/react/docs/jsx-in-depth.html). JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.
You'll notice that we used an HTML-like syntax; [we call it JSX](https://reactjs.org/docs/introducing-jsx.html). JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. If you're using React as a `<script>` tag, read [this section](https://reactjs.org/docs/add-react-to-a-website.html#optional-try-react-with-jsx) on integrating JSX; otherwise, the [recommended JavaScript toolchains](https://reactjs.org/docs/create-a-new-react-app.html) handle it automatically.
## Installation
## Contributing
The fastest way to get started is to serve JavaScript from the CDN (also available on [cdnjs](https://cdnjs.com/libraries/react) and [jsdelivr](https://www.jsdelivr.com/projects/react)):
The main purpose of this repository is to continue to evolve React core, making it faster and easier to use. Development of React happens in the open on GitHub, and we are grateful to the community for contributing bugfixes and improvements. Read below to learn how you can take part in improving React.
### [Code of Conduct](https://code.fb.com/codeofconduct)
We've also built a [starter kit](https://facebook.github.io/react/downloads/react-0.14.8.zip) which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
Facebook has adopted a Code of Conduct that we expect project participants to adhere to. Please read [the full text](https://code.fb.com/codeofconduct) so that you can understand what actions will and will not be tolerated.
If you'd like to use [bower](http://bower.io), it's as easy as:
Read our [contributing guide](https://reactjs.org/contributing/how-to-contribute.html) to learn about our development process, how to propose bugfixes and improvements, and how to build and test your changes to React.
And it's just as easy with [npm](http://npmjs.com):
```sh
npm i --save react
```
## Contribute
The main purpose of this repository is to continue to evolve React core, making it faster and easier to use. If you're interested in helping with that, then keep reading. If you're not interested in helping right now that's ok too. :) Any feedback you have about using React would be greatly appreciated.
### Building Your Copy of React
The process to build `react.js` is built entirely on top of node.js, using many libraries you may already be familiar with.
#### Prerequisites
* You have `node` installed at v4.0.0+ and `npm` at v2.0.0+.
* You are familiar with `npm` and know whether or not you need to use `sudo` when installing packages globally.
* You are familiar with `git`.
#### Build
Once you have the repository cloned, building a copy of `react.js` is really easy.
```sh
# grunt-cli is needed by grunt; you might have this installed already
npm install -g grunt-cli
npm install
grunt build
```
At this point, you should now have a `build/` directory populated with everything you need to use React. The examples should all work.
### Grunt
We use grunt to automate many tasks. Run `grunt -h` to see a mostly complete listing. The important ones to know:
```sh
# Build and run tests with PhantomJS
grunt test
# Lint the code with ESLint
grunt lint
# Wipe out build directory
grunt clean
```
### Good First Bug
To help you get your feet wet and get you familiar with our contribution process, we have a list of [good first bugs](https://github.com/facebook/react/labels/good%20first%20bug) that contain bugs which are fairly easy to fix. This is a great place to get started.
### Good First Issues
To help you get your feet wet and get you familiar with our contribution process, we have a list of [good first issues](https://github.com/facebook/react/labels/good%20first%20issue) that contain bugs which have a relatively limited scope. This is a great place to get started.
### License
React is [BSD licensed](./LICENSE). We also provide an additional [patent grant](./PATENTS).
React documentation is [Creative Commons licensed](./LICENSE-docs).
Examples provided in this repository and in the documentation are [separately licensed](./LICENSE-examples).
### More…
There's only so much we can cram in here. To read more about the community and guidelines for submitting pull requests, please read the [Contributing document](CONTRIBUTING.md).
## Troubleshooting
See the [Troubleshooting Guide](https://github.com/facebook/react/wiki/Troubleshooting)
If you believe you have found a security vulnerability in React, we encourage you to let us know right away. We will investigate all legitimate reports and do our best to quickly fix the problem.
Please refer to the following page for our responsible disclosure policy, reward guidelines, and those things that should not be reported:
We use [Jekyll](http://jekyllrb.com/) to build the site using ([mostly](http://zpao.com/posts/adding-line-highlights-to-markdown-code-fences/)) Markdown, and we host it by pushing HTML to [GitHub Pages](http://pages.github.com/).
## Installation
If you are working on the site, you will want to install and run a local copy of it.
### Dependencies
In order to use Jekyll, you will need to have Ruby installed.
Mac OS X comes pre-installed with Ruby, but you may need to update RubyGems (via `gem update --system`).
Otherwise, [RVM](https://rvm.io/) and [rbenv](https://github.com/sstephenson/rbenv) are popular ways to install Ruby.
Once you have RubyGems and installed Bundler (via `gem install bundler`), use it to install the dependencies:
```sh
$ cd react/docs
$ bundle install # Might need sudo.
$ npm install
```
### Instructions
The site requires React, so first make sure you've built the project (via `grunt`).
Use Jekyll to serve the website locally (by default, at `http://localhost:4000`):
```sh
$ cd react/docs
$ bundle exec rake
$ bundle exec jekyll serve -w
$ open http://localhost:4000/react/
```
We use [SASS](http://sass-lang.com/) (with [Bourbon](http://bourbon.io/)) for our CSS, and we use JSX to transform some of our JS.
If you only want to modify the HTML or Markdown, you do not have to do anything because we package pre-compiled copies of the CSS and JS.
If you want to modify the CSS or JS, use [Rake](http://rake.rubyforge.org/) to compile them:
```sh
$ cd react/docs
$ bundle exec rake watch # Automatically compiles as needed.
# bundle exec rake Manually compile CSS and JS.
# bundle exec rake js Manually compile JS, only.
```
## Afterthoughts
### Updating `facebook.github.io/react`
The easiest way to do this is to have a separate clone of this repository, checked out to the `gh-pages` branch. We have a build step that expects this to be in a directory named `react-gh-pages` at the same depth as `react`. Then it's just a matter of running `grunt docs`, which will compile the site and copy it out to this repository. From there, you can check it in.
**Note:** This should only be done for new releases. You should create a tag corresponding to the release tag in the main repository.
We also have a rake task that does the same thing (without creating commits). It expects the directory structure mentioned above.
```sh
$ bundle exec rake release
```
### Removing the Jekyll / Ruby Dependency
In an ideal world, we would not be adding a Ruby dependency on part of our project. We would like to move towards a point where we are using React to render the website.
// Each of these mixins support comma separated lists of values, which allows different transitions for individual properties to be described in a single style rule. Each value in the list corresponds to the value at that same position in the other properties.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
