* Test that SVG elements get created with the right namespace
* Pass root to the renderer methods
* Keep track of host instances and containers
* Keep instances instead of fibers on the stack
* Create text instances in begin phase
* Create instance before bailing on offscreen children
Otherwise, the parent gets skipped next time.
We could probably create it later but this seems simpler.
* Tweak magic numbers in incremental tests
I don't understand why they changed but probably related to us moving some work into begin phase?
* Only push newly created nodes on the parent stack
Previously I was pushing nodes on the parent stack regardless of whether they were already in current or not.
As a result, insertions during updates were duplicated, and nodes were added to existing parents before commit phase.
Luckily we have a test that caught that.
* Fix lint
* Fix Flow
I had to wrap HostContext API into a closure so that it's parameterizeable with I and C.
* Use the same destructuring style in scheduler as everywhere else
* Remove branches that don't seem to run anymore
I'm not 100% sure this is right but I can't get tests to fail.
* Be explicit about the difference between type and tag
I was confused by th HACK comment so I learned how DOM and SVG work with casing and tried to write a more descriptive comment.
It also seems like passing fiber.type into finalizeInitialChildren() is a potential problem because DOM code assumes tag is lowercase.
So I added a similar "hack" to finalizeInitialChildren() that is identical to the one we have prepareUpdate() so if we fix them later, we fix both.
* Save and restore host context when pushing and popping portals
* Revert parent context and adding children in the begin phase
We can address this later separately as it is a more hot path.
This doesn't affect correctness of SVG container behavior.
* Add a test for SVG updates
This tests the "jump" reuse code path in particular.
* Record tests
* Read ownerDocument from the root container instance
This way createInstance() depends on the innermost container only for reading the namespace.
* Track namespaces instead of creating instances early
While we might want to create instance in the begin phase, we shouldn't let DOM guide reconciler design.
Instead, we are adding a new concept of "host context". In case of ReactDOMFiber, it's just the current namespace.
We are keeping a stack of host context values, ignoring those that are referentially equal.
The renderer receives the parent context and type, and can return a new context.
* Pop child context before reading own context and clarify API
It wasn't quite clear from the API which context was being returned by the renderer. Changed the API to specifically ask for child context, and thus to pop it before getting the current context.
This fixes the case with <foreignObject> to which I intended to give SVG namespace.
* Give SVG namespace to <svg> itself
* Don't allocate unnecessarily when reconciling portals
We create stacks lazily so that if portal doesn't contain <svg>s, we don't need to allocate.
We also reuse the same object for portal host context state instead of creating a new one every time.
* Add more tests for edge cases
* Fix up math namespace
* Maintain a separate container stack
* Fix rebase mistakes
* Unwind context on errors
* Reset the container state when reusing the object
* Add getChildHostContext() to ReactART
* Record tests
Solves a few things:
- Moves code out of performWork into workLoop so that it can
be optimized.
- errorLoop (now clearErrors) is no longer called recursively.
- Removes a while (true) loop inside performWork (not that it really
matters for optimization, since performWork contains a try block and
will be deopted, anyway).
If a ref throws while detaching, it should not prevent
componentWillUnmount from being called.
Additionally, errors thrown by removeChild should not be ignored, even
as the result of unmounting a failed subtree.
Subsequent failures should propagate the error to the next boundary.
The conceptual model for this is
try {
render();
} catch (error) {
setStateToRecover();
render();
}
Closes#8485
This uncovered a separate issue where some errors were being unscheduled
and rescheduled multiple times before flushing. Turns out we need to
check both a fiber and its alternate when determining if it represents a
failed unit of work. I didn't notice this before because we were
scheduling a new update on *every* boundary at the end of the commit
phase, not just the ones that captured an error during that commit. I
updated the unit tests to catch this in the future.
We still need tryComponentWillUnmount because deletion should be non-
interruptible.
Refactoring the commit phase to better handle errors also allows us
to switch between fast and slow versions of the work loop. The slower
version runs whenever there are captured errors; it must check each
unit of work to see if it has failed. The faster version runs in the
normal case where there are no errors. Whenever an error is thrown, we
switch from the fast work loop to the slow work loop.
This makes it easier to track when we enter and exit a batch of work.
Further steps needed in this refactor:
- Get rid of tryComponentDidMount, tryComponentDidUpdate, etc. in
favor of the try-catch blocks that wrap each pass of the commit phase.
- Need to be able to switch between performing work that is possibly
failed (slower because it requires an extra check on each iteration) and
work that we know for sure has no errors.
From D4296244:
> Each [...] had a component with innerHTML = '', causing us to go into HTML parsing code in the browser. Doing this takes 0.03ms per parse call which was 10x slower than skipping it.
This strategy finds the current fiber. It traverses back up to the root if
the two trees are completely separate and determines which one is current.
If the two trees converge anywhere along the way, we assume that is the
current tree. We find the current child by searching the converged child
set.
This could fail if there's any way for both return pointers to point
backwards to the work in progress. I don't think there is but I could be
wrong.
This may also fail on coroutines where we have reparenting situations.
Fixes a bug when updating from a single text child (or
dangerouslySetInnerHTML) to regular children, where the previous
text content never gets deleted.
* Exit early in scheduleUpdate if a node's priority matches
This is a performance optimization and is unobservable. However, it
helps protect against regressions on the following invariants on which
it relies:
- The priority of a fiber is greater than or equal to the priority of
all its descendent fibers.
- If a tree has pending work priority, its root is scheduled.
* New error boundary semantics
- Recovering from an error boundary no longer uses Task priority by
default. The work is scheduled using whatever priority created the
error.
- Error handling is now a side-effect that happens during the
commit phase.
- The default behavior of an error boundary is to render null. Errors
do not propagate except when an boundary fails. Conceptually, this would
be like throwing an error from a catch block.
- A host container is treated like a no-op error boundary. The first
error captured by a host container is thrown at the end of the batch.
Like with normal error boundaries, the entire tree is unmounted.
* Fix broken setState callback test
* Add test for "unwinding" context when an error interrupts rendering
* Switch over primary effect types only
This avoids the need to create an export for every combination of bits.
* Only continue the work loop if the error was successfully captured
* Add more tests for incremental error handling
These tests are currently failing:
✕ catches render error in a boundary during partial deferred mounting
✕ catches render error in a boundary during animation mounting
✕ propagates an error from a noop error boundary during full deferred mounting
✕ propagates an error from a noop error boundary during partial deferred mounting
✕ propagates an error from a noop error boundary during animation mounting
The observed behavior is that unstable_handleError() unexpected gets called twice:
"ErrorBoundary render success",
"BrokenRender",
"ErrorBoundary unstable_handleError",
+ "ErrorBoundary render success",
+ "BrokenRender",
+ "ErrorBoundary unstable_handleError",
"ErrorBoundary render error"
* Verify batched updates get scheduled despite errors
* Add try/catch/finally blocks around commit phase passes
We'll consolidate all these blocks in a future PR that refactors the
commit phase to be separate from the perform work loop.
* NoopBoundary -> RethrowBoundary
* Only throw uncaught error once there is no more work to perform
* Remove outdated comment
It was fixed in #8451.
* Record tests
* Always reset nextUnitOfWork on error
This is important so that the test at the end of performAndHandleErrors() knows it's safe to rethrow.
* Add a passing test for unmounting behavior on crashed tree
* Top-level errors
An error thrown from a host container should be "captured" by the host
container itself
* Remove outdated comment
* Separate Rethrow and Noop scenarios in boundary tests
* Move try block outside the commit loops
* Make bad element type message same as in Stack
This makes Fiber emit the same message as Stack (aside from the missing owner information).
* Add a separate test verifying error includes owner name
Fiber currently doesn't pass it. This is just to keep track of it as a todo.
This handles the case where a host text bails out. In that case we need to
reuse its previous memoizedProps. We should also only schedule an actual
update if it did actually change its text content.
I updated the unit test to ignore comment nodes if we're using Fiber.
* Add iterable cases to MultiChildReconcile test
Stack currently supports rendering iterables, but Fiber does not.
Previously we didn't have any public API tests for iterables. We have tests for traverseAllChildren() which is shared between React.Children and Stack. However Fiber doesn't currently use it, and likely won't. So this commit is a first step towards actually testing iterable support via public API. The next step will be to port traverseAllChildren() tests to test React.Children API instead.
* Implement iterable reconciliation in Fiber
This uses the same exact algorithm as array reconciliation but uses iterator to step through.
This gets reconcile tests to pass again but introduces a regression in ReactMultiChildText case which uses Maps as children. It passed before because Maps were ignored, but now it's failing because this actually runs the Map code path in Fiber. We can throw early in this case when we want to follow up on this.
* Rewrite traverseAllChildren() tests against React.Children API
This function was used in React.Children and Stack.
The corresponding reconciliation functionality is being tested by ReactMultiChild tests.
So we can move these tests to ReactChildren and test its public API.
* Use a closure to bind gaurded callback
This way the fake event isn't being implicitly passed into the event handler
* Add tests for ReactErrorUtils
Add fiber test report
Linting fixes
We used to terminate the search on host nodes, and then use the nested unmount algorithm.
However this means we didn't unmount portals inside the host nodes.
We will probably need to restructure this somehow but for now I just added a recursive call to unblock myself.
* Remove output field
The idea was originally that each fiber has a return value. In practice
most of what we're modelling here are void functions and we track side
effects instead of return values.
We do use this for coroutines to short cut access to terminal yields.
However, since this can be nested fragments we end up searching the tree
anyway. We also have to manage this in transferOutput so it ends up being
as expensive. Maybe we can save some traversal for updates when coroutine
branches bail out but meh.
* Unmount child from the first phase of a coroutine
The goal of this is to avoid passing an opaque data structure that needs
to be recursively searched by the host.
I considered having some helper for doing the recursion but I figured it
might be helpful to let the reconciler move this around. For example we
might want to create an instance in beginWork and add to it as we go.
This would let us avoid traversing the tree twice and would solve the IE11
perf issue.
So instead, we create the instance first then call appendChild. I could
just call the normal one but I figured that I would make a special one
just in case. For example if you wanted to perform commits on a separate
thread from creation. This turned out to be useful in ReactNoop where I
can avoid searching the array for an existing one since I know the child
isn't there already. (Although splitting placement into insertion/move
might be better.)
Finally, we need the ability to update an instance after all the children
have been insertion. Such as `<select value={...} />`. I called this
finalizeInitialChildren.
Dan Abramov