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.
The tutorial wants to throw a 'warning' and explains about 'key' of React's list, but it throws nothing since there is sensible key.
"key={move}" should be removed, and added after explaining about key.
* 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.
I couldn't figure out how to do this yarn alone so I ended up
just manually hacking the yarn to force a downgrade of babylon
to 6.8.0 since otherwise it gets resolved to 6.12.0 which is
broken.
* 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.
Dan Abramov
Toru Kobayashi
Marcio Puga
Ashish
Sebastian Markbåge
Andrew Poliakov
Alireza Mostafizi
William Hoffmann
Giuseppe
Sebastian Markbage
Jason Grlicky
Jun Kim
Diego Muracciole
Phil Quinn
Brad Vogel
Oskari Mantere
Avinash Kondeti
Taeho Kim
Nathan Hardy
Cody Reichert
Ragnar Þór Valgeirsson
BEAUDRU Manuel
Ben Alpert
Christopher Chedeau
Kevin Lacker
Andrew Clark
Piper Chester