This adds tracking of side-effects that gets scheduled during an
update.
As the tree gets reconciled, the side-effectful fibers are linked
together in an ordered singly linked list. That way we can walk
the linked list to commit only the work that needs to be
synchronous - quickly.
We also store first and last nodes within a fiber. That
way when we reuse an already processed subtree, we can reuse that
subset of the linked list.
This is not just the parent Instance but also the return Fiber for
some piece of work. This clarifies and buys into this definition.
Basically, in the current model you will always pass into a fiber
from the parent that you're going to return to. Even if you get
aborted and reused this will be updated to the correct return
fiber before you get back here.
I don't have any guarantees in place to enforce this right now. I
don't really know how to, but seems safe. :)
I confirmed that the use of keyword properties work for old
engines because we have the transform enabled in our build system.
This tries to reuse work that was completed but another higher
priority event came in. This tries to avoid starvation when high
priority events causes low pri work to keep rerendering from
scratch.
First I fix a bug where host components didn't properly bail out
although this was unobservable.
When we bail out, we need to ensure that we preserve the highest
remaining priority work that is left to do for that subtree.
This still isn't properly handling the case when that work has the
*same* priority as the current one. That work will be flushed the
*next* tick instead of the current pass.
I can't create a test for that yet since I need setState to get to
that state.
This fixes some bugs with the clones and traversing backwards
through them. It is important that we maintain the correct parent
at all times and that clones have the correct values.
We need to carefully clone everything on the way up to the the
fiber with the next work to do.
This code is a bit messy and fragile now. I'm sure I didn't get it
all right but I want to get the basics in place first. Then we can
structure this part better. I think the general algorithm is sound
though.
We need a canonical stateful root for each. I don't really want to
overload the HostContainer for this purpose since it makes the
fiber code more specialized.
Instead I create a root which represents an actual stateful root.
When these get scheduled they get chained together in a linked
list. However, we don't hold onto anything that doesn't have
scheduled work. This will help us release everything automatically
in the GC, as long as there are no subscriptions nor scheduled
work.
This is a bit poorly structured. I'll restructure when the pieces
are better in place.
Basically we reset the priority of a node before work on the
children. The children then bump their parent if they end up
having work left.
This is the first time we're seeing deep updates happening. The
new unit test demonstrates this.
There is an interesting case that happens when we fall back out of
a deep update. We end up "completing" a node that we didn't begin.
This probably breaks in coroutines. When that completes, it'll try
to render the sibling next but that should bail out so we check
for any pending work on the sibling. That one I'm not sure about.
This is essentially equivalent to the current top level wrappers.
They contain the next children to be mounted into a container node
from the host.
It is the responsibility of the host to retain references to them
for updates.
I expect them to be able to exist in the middle of the tree in
the future, for renderSubtreeIntoContainer.
This flag on fibers will be used to track what priority of work is
needed by that subtree, if any at all.
Also fix up the TypeOfWork to have consistent naming and typing.
* Fix for 5468: Validate proptype definitions sooner
Added typeCheckWarn() func and updated the oneOf/oneOfType tests
Added __DEV__ warning for invalid oneOf/OneOfType args
* Suppress redundant error on warn; typeCheckWarn() removed
* Return no-op
* Using emptyFunction module for consistency
* Remove createChainableTypeChecker() call
* Adjust test to assert type check passes when warned
* create failing test case
* Fix renderSubtreeIntoContainer to update context
Fixes#6599
* Also test re-rendering due to prop update
* Address review feedback
This was added to catch internal errors in React but doesn't seem to be doing much good except frustrating people more when their apps throw (#6895, FB-internal t11950821). Until more proper error boundaries land, let's make this a warning.
Although it is unreasonable to set every possible property for
simulated events, `type` is useful for event handlers that are shared
between types and potentially have different behaviors.
* Resolve refs in the order of the children
React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved.
With the current `ReactMultiChild`, this is *usually* the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when **a new child is mounted during an update**.
In this case, the `mountComponent()` call used to be delayed until `ReactMultiChild` processes the queue. However, this is inconsistent with how updates normally work: unlike mounting, updating and unmounting happens inside `ReactChildReconciler.updateChildren()` loop.
This PR changes the `mountComponent()` to be performed inside `ReactChildReconciler`, just like `receiveComponent()` and `unmountComponent()`, and thus ensures that `attachRef()` calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved.
This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change).
* Use array instead of object to avoid lookups
Summary:
The only callsite of ReactStateSetters is in LinkedStateMixin which lives in addons/link. Better move it there to avoid cluttering the other folder.
Test Plan:
None
Reviewers: @zpao @spicyj
Summary:
Trying to start adding flow types to files in React. I needed to add a script to package.json in order to run flow, flow-bin is already a dependency.
I had to rewrite the implementation a bit. Flow doesn't recognize
```
var currentIsArray = Array.isArray(current);
if (currentIsArray) {
// not refined
}
```
but the following does work
```
if (Array.isArray(current)) {
// refined
}
```
Test Plan:
npm run-script flow
npm run-script test accumulate
Reviewers: @zpao @spicyj
Sebastian Markbage
Troy DeMonbreunandDan Abramov
starkchandDan Abramov
Ben AlpertandGitHub
EstebanandDan Abramov
Swaroop SMandDan Abramov
Evan JacobsandDan Abramov
Sergey RubanovandChristopher Chedeau
JimandGitHub
Christopher Chedeau
Toru KobayashiandPaul O’Shannessy
Christoph PojerandBen Alpert
Dominic GannawayandBen Alpert
Brandon DailandJim
Hiroyuki WadaandJim