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 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.
Sebastian Markbåge
Dan Abramov
Sergey Rubanov
Constantin Gavrilete
Sebastian Markbage
Antti Ahti
Toru Kobayashi
Marcio Puga
Ashish
Andrew Poliakov
Alireza Mostafizi
William Hoffmann
Giuseppe
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