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.
- 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 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.
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.
* 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
* [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).
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.
* 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
* 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
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.
* [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
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
* 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
* 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
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.
* 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 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
* 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
* 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.
* Improve release script process documentation
* Improved pre-publish instructions/message based on feedback
* Added reminder to attach build artifacts to GitHub release
* 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
* [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
* 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.
* 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.
* 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
* [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
* 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
* 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
* 🔥 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
* 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
* 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
* 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
* 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
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.
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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
```
$ 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.
```
This is the first step - pulling the ReactDOMFrameScheduling module out
into a separate package.
Co-authored-by: Brandon Dail <aweary@users.noreply.github.com>
* 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).
* 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
* 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 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.
* 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).
* 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
* 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.
* [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
* [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
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.
* 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
* 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.
* 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
* 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
* 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
* 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
* 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
* 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
* 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.
* 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
* 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
* 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
* 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.
* 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.
* Forked ReactFeatureFlags for React Native to enable debugRenderPhaseSideEffects GK
* Changed debugRenderPhaseSideEffects in www feature flags to be runtime as well
* 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
* 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.
* 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
* 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 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
* 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
* 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
* 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
* 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.
* 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
* 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
* 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
* 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
* 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
* 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
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.
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
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.
```
* 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
* Add license headers on build bundles
* Add the filename IMO to header
* Preserve headers in production bundles
* Use ECMASCRIPT5_STRICT to preserve "use strict"
* 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
* [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
* 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
* 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
* 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'
The critical semantics are resilient to browser flakiness, so we don't
need this feature test.
Also added comments explaining how invokeGuardedCallback dev works.
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.
* 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.
* 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.
* 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
* 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.
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.
* 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.
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
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.
* 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.
* 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
* 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.
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.
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;
```
**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
* 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
* 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
* 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
* 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
Sunil Pai