…k#13959)

- Partial revert of facebook#13732
 - Fixes facebook#13958.

* Simplify imports in ReactChildFiber
* Import type first in ReactCurrentFiber
* Simplify imports in ReactFiberBeginWork
* Simplify imports in ReactFiberScheduler
* Simplify import in ReactFiberTreeReflection
* Simplify import in ReactFiberUnwindWork
* Remove repeated import
* Fix imports from ReactFiberExpirationTime
* Master imports in ReactFiberBeginWork

People are probably gonna do this all the time.

…book#14036)

Mostly to catch this:

```js
useEffect(async () => {
  // ...
  return cleanup;
});
```

Is this too restrictive? Not sure if you would want to do like

```js
useEffect(() => ref.current.style.color = 'red');
```

which would give a false positive here. We can always relax it to only warn on Promises if people complain.

…acebook#14003)

* chore: don't rely on jest fake timers scheduling real timers

* re-add one part not working with Jest 23

… 16.4.2 and 16.5.0. Fails in Edge in some scenarios. (facebook#14095)

Replaced 'var' with 'const'

Check for existence of `setTimeout` and `clearTimeout` in the runtime
before using them, to ensure runtimes without them (like .NET ClearScript)
do not crash just by importing `react-dom`.

* 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

console.error.apply() fails in IE9, but I verified this works (and it works everywhere else too). :)

This is required to use lazy.

Test Plan:
* Verified lazy works on a real world use case (shows spinner, shows real content).
* Verified that if I change the primary content's styles to have `display: 'none'` then it never appears (i.e., the code in `unhide` reads the styles successfully)

…g primary children (facebook#14083)

* Avoid double commit by re-rendering immediately and reusing children

To support Suspense outside of concurrent mode, any component that
starts rendering must commit synchronously without being interrupted.
This means normal path, where we unwind the stack and try again from the
nearest Suspense boundary, won't work.

We used to have a special case where we commit the suspended tree in an
incomplete state. Then, in a subsequent commit, we re-render using the
fallback.

The first part — committing an incomplete tree — hasn't changed with
this PR. But I've changed the second part — now we render the fallback
children immediately, within the same commit.

* Add a failing test for remounting fallback in sync mode

* Add failing test for stuck Suspense fallback

* Toggle visibility of Suspense children in mutation phase, not layout

If parent reads visibility of children in a lifecycle, they should have
already updated.

The `enableHooks` feature flag used to only control whether the API
was exposed on the React package. But now it also determines if the
dispatcher and implementation are included in the bundle.

We're using hooks in www, so I've switched the feature flag to `true`
in the www build.

(Alternatively, we could have two feature flags: one for the
implementation and dispatcher, and one for exposing the API on the
React package.)

Setting to null isn't correct; setting to '' is. I opted to use dangerousStyleValue for consistency with the main path that we set things.

Fixes facebook#14114.

Test Plan:
Verified setting to '' works in Chrome and IE11. (Setting to null works in Chrome but not in IE11.)

* Resolve defaultProps for Lazy components

* Make test fail again

* Undo the partial fix

* Make test output more compact

* Add a separate failing test for sync mode

* Clean up tests

* Add another update to both tests

* Resolve props for commit phase lifecycles

* Resolve prevProps for begin phase lifecycles

* Resolve prevProps for pre-commit lifecycles

* Only resolve props if element type differs

* Fix Flow

* Don't set instance.props/state during commit phase

This is an optimization. I'm not sure it's entirely safe. It's probably worth running internal tests and see if we can ever trigger a case where they're different.

This can mess with resuming.

* Keep setting instance.props/state before unmounting

This reverts part of the previous commit. It broke a test that verifies we use current props in componentWillUnmount if the fiber unmounts due to an error.

…k#14128)

Adds a check to the existing fuzz tester to confirm that the props are
set to the latest values in the commit phase. Only checks
componentDidUpdate; we already have unit tests for the other lifecycles,
so I think this is good enough. This is only a redundancy.

* Recover from errors with a boundary in completion phase

* Use a separate field for completing unit of work

* Use a simpler fix with one boolean

* Reoder conditions

* Clarify which paths are DEV-only

* Move duplicated line out

* Make it clearer this code is DEV-only

…ebook#14033)

* Applies context object warnings to ReactDOM server

)

Fixes a bug where deletion effects in the primary tree were dropped
before entering the second render pass.

Because we no longer reset the effect list after the first render pass,
I've also moved the deletion of the fallback children to the complete
phase, after the tree successfully renders without suspending.

Will need to revisit this heuristic when we implement resuming.

…ok#14138)

…acebook#14141)

…acebook#14065)

* Fixed `treeBaseDuration` by propagating its value from the suspended tree to the Fragment React temporarily wraps around it when showing the fallback UI.
* Fixed `actualDuration` by recording elapsed profiler time in the event of an error.
* Fixed `actualDuration` in concurrent mode by propagating the time spent rendering the suspending component to its parent.

Also updated ReactSuspensePlaceholder-test.internal to cover these new cases.

* 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.

…ook#13914)

* Refactor ESLint configuration to enable better IDE integration

* Minor tweaks

…acebook#14157)

Vestigial behavior that should have been removed in facebook#13823.

Found using the Suspense fuzz tester in facebook#14147.

* Add failing test for ping on unmounted component

We had a test for this, but not outside of concurrent mode :)

* Don't warn if an unmounted component is pinged

* Don't warn if an unmounted component is pinged

* Suspense fuzz tester

The fuzzer works by generating a random tree of React elements. The tree
two types of custom components:

- A Text component suspends rendering on initial mount for a fuzzy
  duration of time. It may update a fuzzy number of times; each update
  supsends for a fuzzy duration of time.
- A Container component wraps some children. It may remount its children
  a fuzzy number of times, by updating its key.

The tree may also include nested Suspense components.

After this tree is generated, the tester sets a flag to temporarily
disable Text components from suspending. The tree is rendered
synchronously. The output of this render is the expected output.

Then the tester flips the flag back to enable suspending. It renders the
tree again. This time the Text components will suspend for the amount of
time configured by the props. The tester waits until everything has
resolved. The resolved output is then compared to the expected output
generated in the previous step.

Finally, we render once more, but this time in concurrent mode. Once
again, the resolved output is compared to the expected output.

I tested by commenting out various parts of the Suspense implementation
to see if broke in the expected way. I also confirmed that it would have
caught facebook#14133, a recent bug related to deletions.

* When a generated test case fails, log its input

* Moar fuzziness

Adds more fuzziness to the generated tests. Specifcally, introduces
nested Suspense cases, where the fallback of a Suspense component
also suspends.

This flushed out a bug (yay!) whose test case I've hard coded.

* Use seeded random number generator

So if there's a failure, we can bisect.

Oopsie!

This could have been avoided if our types were modeled correctly with
Flow (using a disjoint union).

Fuzz tester didn't catch it because it does not generate cases where
a Suspense component mounts with no children. I'll update it.

sizebot comments can be confusing when not based on reality.

If results.json doesn't exist, danger will fail. This is what we want.

This is one of the most insidious quirks of React DOM that people run into. Now we warn when we think an update is dangerous.

We still allow rendering `{background, backgroundSize}` with unchanging values, for example. But once you remove either one or change `background` (without changing `backgroundSize` at the same time), that's bad news. So we warn.

Fixes facebook#6348.

Fixes facebook#13964.

…ook#14182)

* 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.

I figured out a simpler way to do facebook#14181. It does allocate some but I think that's OK. Time complexity might even be better since we avoid the nested loops the old one had.

Replace core with react, dom-client with react-dom

* Store node_modules generated by CI script as an artifact
* NPM pack artifacts before archiving

* Add 16.6.3 Changelog

* Remove unreleased fix

* Drop another unreleased fix

Scheduler needs to schedule a task that fires after paint. To do this,
it currently posts a message event to `window`. This happens on every
frame until the queue is empty. An unfortunate consequence is that every
other message event handler also gets called on every frame; even if
they exit immediately, this adds up to significant per-frame overhead.

Instead, we'll create a MessageChannel and post to that, with a
fallback to the old behavior if MessageChannel does not exist.

Every browser we can about supports MessageChannel. The ones we don't
care about will fallback to the setTimeout implementation.

…ook#13786)

* Add a checkbox to fixtures UI to choose React production build

* Assign header__label class name to label directly, instead of using a separate span

* center the production checkbox vertically

…ok#14245)

Disables the recently introduced (facebook#14181) warning for shorthand
CSS property collisions by wrapping in a feature flag. Let's hold off
shipping this until at least the next minor.

In the process of switching to MessageChannel, it seems the postMessage call was modified to pass `"*"` (originally the target origin value from `window.postMessage`). This actually ends up triggering serialization, whereas passing `undefined` bypasses.

To save some investigation, passing a Number like `0` still incurs serialization overhead - `undefined` has special behavior.

…k#14218)

* Clear properties on unmount of fiber to ensure objects are not retained

…acebook#14218)" (facebook#14275)

This reverts commit 9b2fb24.

* Clear fields on unmount of fiber to avoid memory leak

Whenever we do this, Rollup needs to materialize this as an object.
This causes it to also add the Babel compatibility property which is
unnecessary bloat. However, since when we use these, we leak the object
this often also deopts any compiler optimizations.

If we really need an object we should export default an object.

Currently there is an exception for DOMTopLevelEventTypes since
listing out the imports is a PITA and it doesn't escape so it should
get properly inlined. We should probably move to a different pattern
to avoid this for consistency though.

…k#14291)

* Warn about reassigning this.props

* Improve the warning

* Don't show the spammy bug warning if we suspect it's a component bug

"Here's" should be changed to "Here" in the given sentence.

…4308)

* Add failing test for defaultProps between lazy() and memo()

* Add another regression test for defaultProps resolution order

* Resolve outer props for MemoComponent

…ok#14309)

New release scripts.

Learn more at https://github.com/facebook/react/blob/master/scripts/release/README.md

Added regression test for release scripts

I had some confusion yesterday with this, figured this reads a little better.  Ran these steps locally to verify they work.

* Add progress bars to longer running async release tasks
* Updated to 0.2 progress estimator version

facebook#14330)

Regression introduced in facebook#14182 resulted in errors no longer being emitted on streams, breaking many consumers.

Co-authored-by: Elliot Jalgard <elliot.j@live.se>

* Make useEffect(async) warning more verbose

* Nit

useMutationEffect has problems (namely, refs aren't attached at the time that it runs) and we're not positive it's necessary. useLayoutEffect runs at the same time as componentDidMount/Update so it's sufficient for all existing use cases; it can be used in any case that useEffect happens too late. Until we figure out what we want to do, let's delete it.

…ed (facebook#14339)

* Release script auto-determine the latest Canary build if none specified

…rns (facebook#14298)

* Add a test for current defaultProps behavior in lazy

* Add a warning against definining defaultProps on the outer wrapper

* Warn about setting propTypes too

* Remove redundant async

* Validate propTypes for resolved lazy types

Note this only works for elements created after resolving. So it's not ideal. But it provides the best stack trace for those cases.

* Add a test for lazy(forwardRef()) propTypes check

* Validate memo() inner propTypes and warn about shadowing

* Add test verifying nested lazy is unsupported

* Change error wording to remove "Promise elements"

* Improve error message for nested lazy() and add tests

* Validate propTypes for memo in the reconciler when necessary

* Add comments for why we're calling checkPropTypes

* Fix Flow and lint

* Undo unintentional formatting changes

* Remove unnecessary case (it is handled by function code path)

* Add test coverage for memo(fn.defaultProps).propTypes

* Test should be agnostic of where resolving happens

That's an implementation detail and we might want to change it later. Let's keep it easy by making tests just check that validation happened, not at which stage.

* Unify traversal logic in createElement

This moves all type traversal into createElement. When lazy resolves, we call createElement once to re-check.

* Match prod behavior for propTypes/defaultProps shims closer

* Revert "Unify traversal logic in createElement"

This reverts commit 2e77ca4.

See facebook#14298 (comment)

* Undo unnecessary change to getComponentName