* Workaround IE lacking innerHTML on SVG elements
* Add tests for setInnerHTML
* Correctly check if node has innerHTML property
* Ensure tests for setInnerHTML actually tests both codepaths
* Provide mock element for setInnerHTML tests
* Only use SVG setInnerHTML workaround for SVG elements
This avoids using .alternate as much as possible and isolates it
to the root. For anything that is "work in progress" this happens
to be the same as the alternate field. To avoid an extra "current"
field on work in progress fibers, we can just use the alternate.
The timing for when this is true might be a bit tricky to reason
about so I explicitly pass the current value everywhere from the
top. That way we can always change this in the future to use an
explicit field or we can try to maintain a parallel data
structure that remembers which was the "current" fiber for each
wip child.
These values represent fibers that are incomplete. In the current
model they're mutated in place. In a completely immutable model
they would need to be cloned for every step they make progress.
I.e. one where the child is still in this WIP state and one when
it is complete.
To clarify this I'll name them workInProgress while they're in
that state, which is also what Jordan did in his prototype.
This splits the Fiber type into Fiber and Instance. This could be
two different object instances to save memory. However, to avoid
GC thrash I merge them into one.
When ReactChildFiber reconciles children, it clones the previous
fiber. This creates a new tree for work-in-progress. The idea is
that once flushed, this new tree will be used at the root.
However, we know that we'll never need more than two trees
at a time. Therefore my clone function stores the clone on the
original. Effectively this creates a fiber pool.
Ideally, the .alternate field shouldn't be used outside of clone
so that everything can work with pure immutability. I cheat a bit
for now so I don't have to pass both trees everywhere.
ReactChildFiber is a bit hacky for reuse and doesn't solve all
cases. Will fix that once I try to get parity.
Also ignore examples, important because react can be installed by the commonjs
one and the modules will get detected there too, resulting in duplicate
definitions
Most people don't use the official Flux implementation or docs so I think this is likely to be more confusing than helpful. Maybe later we can add a better comparison of data management solutions.
This gets rid of a field that we only need for coroutines.
We might need this if we have multi phase handlers in the future
but then maybe we can just use multiple tags.
This has a few benefits:
1) This allows the element to always remain on the young generation.
2) The key can be accessed on the fiber which is easier to keep as the
same class and is directly accessible in the child reconciliation of every
object.
3) This conveniently means that we don't have to create a fake element for
continuations which was really hacky.
We can still do the quick bailout of rerendered things using the props
object which is also unique.
Keyan ZhangandGitHub
Jim
Toru KobayashiandJim
ogomandJim
Brandon DailandJim
Hiroyuki WadaandJim
Josh HuntandBen Alpert
Yusong LiuandJim
Sebastian Markbåge
Timothy Yung
Sebastian Markbage
Dan Abramov
AlexanderandDan Abramov
Paul O’Shannessy
Daniel RosenwasserandPaul O’Shannessy
Andrew ImmandJim
Sasha AickinandBen Alpert
hjmossandJim
Alex JacobsandDan Abramov
Nate NorbergandJim