Prior to this, React was using a nextDebugID variable that was locally
scoped to both `instantiateReactComponent` and `ReactShallowRenderer`.
This caused problems when the debugIDs would collide, the `itemMap` in
`ReactComponentTreeHook` would be overwritten and tests would fail
with the message "Expected onBeforeMountComponent() parent and
onSetChildren() to be consistent".
This change shares the debugID with both modules thus preventing any
collisions in the future.
* [Fiber] Add top level render callbacks into ReactDOMFiber and ReactNoop
* [Fiber] Support multiple render callbacks
* [Fiber] `this` in render callbacks are public instances
* [Fiber] commitLifeCycles move to behind the effectTag check
* Implement string refs using callback closures
* Merge Fiber type to avoid Flow intersection bugs
Still one remaining type error that I'm not sure how to fix
* Fix Flow issue with an unsafe cast
* Fix missing semicolon
* Add a type import I missed earlier
This fix relies on the props and state objects being different
to know if we can avoid a componentDidUpdate. This is not a great
solution because we actually want to use the new props/state
object even if sCU returns false. That's the current semantics
and it can actually be important because new rerenders that are
able to reuse props objects are more likely to have the new props
object so we won't be able to quickly bail out next time.
I don't have a better idea atm though.
These two implementations are identical. Except for some
invariants for some reason.
Since this relies on an implementation detail of the internal
component tree rather than an implementation detail of the
renderer, we might as well merge them and remove the injection.
These are new features that aren't covered by existing tests.
It is now possible to use findDOMNode to find a text node.
When a component returns a fragment, it will search to find the
first host component just like element.querySelector does.
First we need to check if a component subtree is mounted at all.
If it is, we need to search down the fiber for the first host
node. However, we might be searching the "work in progress"
instead of current.
One realization is that it doesn't matter if we search work in
progress or current if they're the same. They will generally be
the same unless there is an insertion pending or something in
the alternate tree was already deleted. So if we find one of
those cases, we switch to look in the alternate tree instead.
There are two cases where we have a Fiber that is not actually
mounted. Either it is part of a tree that has not yet been
inserted or it is part of a tree that was unmounted.
For the insertion case, we can check the parents to see if there
is any insertion effect pending along the parent path.
For deletions, we can now check if any of the return pointers
is null without actually being the root.
This is the naive implementation that doesn't cover the case
where it has completed but not yet committed. It also doesn't
deal with unmounts since they currently don't clean up the item
in the ReactInstanceMap.
This is just moving a bunch of DOM files.
It moves things into dom/stack and dom/fiber respectively. The
dom/stack folder remains split into client/server.
Mainly the shared folder is now my best guess for files that
we can reuse in fiber. Everything else will get forked or
reimplemented.
Also moved the event system out of renderers/shared/stack and
into renderers/shared/shared.
When keys line up in the beginning but the type doesn't
we don't currently delete the child. We need to track that this
fiber is a not a reuse and if so mark the old one for deletion.
This splits DefaultInjection into one with all the properties
and event configuration and a separate one for the things that
are relevant to he stack reconciler.
That way we can reuse the property and event system for Fiber
without pulling in all the other stuff.
This isn't a complete solution to all attributes. It's just that
we run a lot of unrelated unit tests by testing className so
we need it for the tests.
* Consider Host Component classes when creating a new internal instance
* Remove unused tagToComponentClass & injectComponentClasses from ReactHostComponent
This doesn't deal with the fact that work is usually deferred
so this will return null for first render (except in sync tests).
It also doesn't deal with top levels being fragments etc.
It doesn't deal with the host instance type being a wrapper
around the public instance. This needs to be unified with refs
and findDOMNode better.
However, this does expose that we reactComponentExpect and
ReactTestUtils doesn't work very well with Fiber.
If work has progressed on a state update that gets resumed
because of another state up, then we won't have an new
pendingProps, and we also won't have any memoizedProps because
it got aborted before completing. In that case, we can just
fallback to the current props.
I think that they can't have diverged because the only way they
diverge is if there is new props.
This lets us bail out on state only updates in more cases which
the unit tests reflect.
We currently only filter out "NoWork" in the beginning of this
function. If the NoWork root is after the one with work it will
show up in the second loop. There's probably a more efficient
way of doing this but this works for now.
This showed up in this PR because a new unit test gets unblocked
which ends up with this case.
This refactors the initialization process so that we can share
it with the "module pattern" initialization.
There are a few new interesting scenarios unlocked by this.
E.g. constructor -> componentWillMount -> shouldComponentUpdate
-> componentDidMount when a render is aborted and resumed.
If shouldComponentUpdate returns true then we create a new
instance instead of trying componentWillMount again or
componentWillReceiveProps without being mounted.
Another strange thing is that the "previous props and state"
during componentWillReceiveProps, shouldComponentUpdate and
componentWillUpdate are all the previous render attempt. However,
componentDidMount's previous is the props/state at the previous
commit. That is because the first three can execute multiple
times before a didMount.
* Use the memoized props/state from the workInProgress
We don't want to use the "current" props/state because if we have
started work, then pause and continue then we'll have the newer
props/state on it already. If it is not a resume, it should be the
same as current.
* Deprioritize setState within a deprioritized tree
Currently we flag the path to a setState as a higher priority
than "offscreen". When we reconcile down this tree we bail out
if it is a hidden node. However, in the case that node is already
completed we don't hit that bail out path. We end up doing the
work immediately which ends up committing that part of the tree
at a higher priority.
This ensures that we don't let a deprioritized subtree get
reconciled at a higher priority.
* Bump idx in unit test
This proves that this number is actually deprioritized.
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.
This reorganizes the two commit passes so that all host
environment mutations happens before any life-cycles. That means
that the tree is guaranteed to be in a consistent state at that
point so that you can read layout etc.
This also lets us to detach all refs in the same pass so that
when they get invoked with new instances, that happens after it
has been reset.
During the deletion phase we call detachRefs on any deleted refs.
During the insertion/update phase we call attachRef on class
and host components.
Unfortunately, when a ref switches, we are supposed to call all
the unmounts before doing any mounts. This means that we have to
expact the deletion phase to also include updates in case they
need to detach their ref.
These happen in the commit phase *before* the setState callback.
Unfortunately, we've lost the previous state at this point since
we've already mutated the instance. This needs to be fixed
somehow.
Josh Perez
Andrew Clark
Toru Kobayashi
Andrew Clark
Sebastian Markbåge
Sebastian Markbage
Dan Abramov
Antti Ahti
Diego Muracciole
Avinash Kondeti
Ben Alpert