Refactors the class logic a bit.
I moved scheduleUpdate out into the scheduler since that's where
the scheduling normally happens. I also moved it so that we can
rely on hoisting to resolve the cycle statically.
I moved the updater to a new class component file. I suspect we
will need a bit of space in here since the class initialization
code is quite complex.
The class component dependency is currently fixed in BeginWork
so we can't move complete or commit phase stuff to it. If we need
to, we have to initialize it in the scheduler and pass it to the
other phases.
If we abort work but have some completed, we can bail out if
the shouldComponentUpdate returns true. However, then we have
a tree that is low priority. When we bailout we currently use
the "current" tree in this case. I don't think this is right.
I'm not sure why I did that.
Similarly, when we complete we use the "current" props if we
didn't have pending props to do. However, we should be using
the memoized props of that tree if it is a pending work tree.
Added a unit test that covers these two cases.
We only use the effect list when we reuse our progressed children.
Otherwise it needs to reset to null.
In all other branches, other than bailoutOnLowPriority, we
revisit the children which recreates this list.
We should also not add fibers to their own effect list since it
becomes difficult to perform work on self without touching the
children too. Nothing else does that neither.
Since that means that the root isn't added to an effect list we
need to special case the root.
This shortcut had a bug associated with it. If beginWork on this
child returns null, then we don't call completeWork on that fiber.
Since removing this short cut adds another time check, we have to
add a single unit of time in tests to account for the top level
call now taking one more unit.
This was also the only recursive call in all of fiber so it's nice
to get rid of it to guarantee that a flat stack is possible.
Instead of passing the full list of children every time to
update the host environment, we'll only do inserts/deletes.
We loop over all the placement effects first and then later
we do the rest.
First clear any progressed deletions for any case where we start
over with the "current" set of children.
Once we've performed a new reconciliation we need to add the
deletions to the side-effect list (which we know is empty because
we just emptied it).
For other effects, instead of just adding a fiber to an effect
list we need to mark it with an update. Then after completion
we add it to the the effect list if it had any effects at all.
This means that we lose the opportunity to control if a fiber
gets added before or after its children but that was already
flawed since we want certain side-effects to happen before others
on a global level.
Instead, we'll do multiple passes through the effect list.
This implements the first step to proper child reconciliation.
It doesn't yet track side-effects like insert/move/delete but has
the main reconciliation algorithm in place.
The goal of this algorithm is to branch early and avoid rechecking those conditions. That leads to some duplications of code.
There are three major branches:
- Reconciling a single child per type.
- Reconciling all children that are in the same slot as before from the beginning.
- Adding remaining children to a temporary Map and reconciling them by scanning the map.
Even when we use the Map strategy we have to scan the linked list to line up "same slot" positions because React, unlike Inferno, can have implicit keys interleaved with explicit keys.
These nodes rendering into Text nodes in the DOM.
There is a special case when a string is a direct child of a host
node. In that case, we won't reconcile it as a child fiber. In
terms of fibers, it is terminal. However, the host config special
cases it.
It is kind of unfortunate that we have to special case this kind
of child in the HostConfig. It would be nice to unify this with
other types of child instances. Text nodes have some weird special
cases, but those special cases tend to *vary* by environment.
They're not the same special cases so not sure how valuable it is
to have a special protocol and special types for it.
We currently treat nested arrays as a unique namespace from top
level children. So that these won't share key namespaces. This
adds a new fiber type that will represent the position of a
fragment.
This is only used for nested arrays. Even if you return an array
from a composite component, we don't need this since they share
namespace with a single top level component.
This still doesn't implement the complete reconciliation
algorthim in child fiber. That's coming later.
* High priority work
Adds the ability to schedule and perform high priority work. In the
noop renderer, this is exposed using a method `performHighPriWork(fn)`
where the function is executed and all updates in that scope are given
high priority.
To do this, the scheduler keeps track of a default priority level.
A new function `performWithPriority(priority, fn)` changes the default
priority before calling the function, then resets it afterwards.
* Rename overloaded priority terms
"High" and "low" priority are overloaded terms. There are priority
levels called HighPriority and LowPriority. Meanwhile, there are
functions called {perform,schedule}HighPriWork, which corresponds
to requestAnimationFrame, and {perform,schedule}LowPriWork, which
corresponds to requestIdleCallback. But in fact, work that has
HighPriority is meant to be scheduled with requestIdleCallback.
This is super confusing.
To address this, {perform,schedule}HighPriWork has been renamed
to {perform,schedule}AnimationWork, and
{perform,schedule}LowPriWork has been renamed to
{perform,schedule}DeferredWork. HighPriority and LowPriority
remain the same.
* Priority levels merge fix
This is unfortunate since we agreed on using the `null | Fiber`
convention instead of `?Fiber` but haven't upgraded yet and this
is the pattern I've been using everywhere else so far.
Callbacks are stored on the same queue as updates. They care called
during the commit phase, after the updates have been flushed.
Because the update queue is cleared during the completion phase (before
commit), a new field has been added to fiber called callbackList. The
queue is transferred from updateQueue to callbackList during completion.
During commit, the list is reset.
Need a test to confirm that callbacks are not lost if an update is
preempted.
Rather than bubble up both trees, bubble up once and assign to the
alternate at each level.
Extract logic for adding to the queue to the StateQueue module.
Updates are scheduled by setting a work priority on the fiber and bubbling it to
the root. Because the instance does not know which tree is current at any given
time, the update is scheduled on both fiber alternates.
Need to add more unit tests to cover edge cases.
This colocates the reliance on alternate with the scheduler, so
that we have the option to not use this, or more easily break
apart the initial mount phase into an optimized path.
I'll probably end up reverting this before the bigger release
since it is not part of the official public API. However,
it is useful to be able to compare the performance between
functional components and classes.
The findPendingWork phase is the same as just walking the tree the
normal way effectively. It only makes things more complex to
think about. We might possibly be able to write a few special
branches to optimize it but for now it doesn't seem necessary.
The priority level gets reset at the wrong time because I rely
on mutating it at the wrong point. This moves it to the end of
completed work as a second pass over the children to see what
the highest priority is. This is inefficient for large sets but
we can try to find a smarter way to do this later. E.g. passing
it down the stack.
This bug fix revealed another bug that I had flagged before that
we're finding work to do in the "current" tree instead of the
working tree. For trees that were paused, e.g. childInProgress
trees, this won't work since don't have a current tree to search.
Therefore I fixed findNextUnitOfWorkAtPriority to use
workInProgress instead of current.
This took a while to figure out, but we need to be able to store
children that are currently being worked on separately from the
current children. We always need a canonical "current" children
so that we can update them. However, we also need a different set
that we're currently working on so that we have a way to get to
already progressed work.
This solve the starvation problem in the first render because now
we can reach children that were never rendered and have a place
to store their progressed work on. The unit test changes tests
this.
This lets us get rid of the hasWorkInProgress flag.
When we reconcile new children we need to reconcile them against
progressed work so that we can reuse it. The progressed work is
"work in progress" nodes. So in that case we need to mutate
instead of clone, to preserve the invariant that only two versions
exist at any given point. This effectively forks the
ReactChildFiber implementation.
We need to use the *other* child because we reset it to the
current one on the way up.
We also need to reset the first/last side-effects to that of the
children so that we're committing the right thing.
Thanks @acdlite. Add comment about future unit test coverage.
This was actually hiding the fact that we are only able to reuse
existing work if it was marked as completely finished which it
won't be if we reuse its pending priority.
However, we should be able to bail out even if there is work
remaining in a subtree.
When we downprioritize children we need to remember to reuse the
old children in the update side-effect.
This whole set up is very unfortunate since we can have children
in our active tree that never actually finished rendering. This
strategy might be fundamentally flawed, not sure.
I'm paranoid about inline-ability so I use this pattern of adding
a constant to the closure everywhere.
ES6 modules help avoid that but we can't use that consistently
because of the dependency injection so instead I opt for making
this explicit everywhere.
Grep: \b[a-zA-Z_$\d]+\.[a-zA-Z_$\d]+\(
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.
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.
Sebastian Markbage