We should be able to support passing a function to replaceState, which
receives the accumulation of all the previously applied state updates.
Which means we shouldn't drop those updates from the queue. Technically,
we could drop them only when an object is passed to replaceState, but
that seems like more trouble than it's worth.
Go back to using a flag, instead. I removed it before because I thought
we might want to get rid of the top-level UpdateQueue type and put
the fields directly on the fiber, but since we're keeping UpdateQueue
we can put hasForceUpdate on there.
The update is scheduled as if the current processing update has already
been processed; if it has the same or higher priority, it will be
flushed in the same batch.
We also print a warning.
The queue maintains a pointer to the last progressed update in the list.
Updates that come after that pointer are pending. The pointer is set to
the end of the list during reconciliation.
Pending updates are sorted by priority then insertion. Progressed
updates are sorted by the order in which they were applied during
reconciliation, which may not be by priority: if a component bails out
before the updates are committed, in the next render, the progressed
updates are applied in the same order that they were previously, even if
a higher priority update comes in.
Once a progressed update is flushed/committed, it's removed from
the queue.
We need to be able to access both, and since the list uses forward
pointers, it makes more sense to point to the one that comes first.
Otherwise to get the last progressed update you have to start at the
beginning of the list.
When resetting the priority in the complete phase, check the priority of
the update queue so that updates aren't dropped.
Updates inside render, child cWRP, etc are no longer dropped.
The next step is sort the queue by priority and only flush updates that
match the current priority level.
Restructures the update queue to maintain a pointer to the first
pending update, which solves a few problems:
- Updates that occur during the begin phase (e.g. in cWRP of a child)
aren't dropped, like they are currently. This isn't working yet because
the work priority is reset during completion. The following item will
fix it.
- Sets us up to be able to add separate priorities to each update in
the queue. I'll add this in a subsequent commit.
* Implement component stack for some warnings in Fiber
* Keep Fiber debug source up to date
When an element changes, we should copy the source and owner again.
Otherwise they can get stale since we're not reading them from the element.
* Remove outdated TODOs from tests
* Explicitly specify Fiber types to include in the stack
Fixes an accidental omission when both source and owner are null but displayName exists.
* Fix mised Stack+Fiber test to not expect extra warnings
When we're in Fiber mode we don't actually expect that warning being printed.
* Warn on passing different props to super()
* Implement duplicate key warnings
We keep known keys in a set in development. There is an annoying special case where we know we'll check it again because we break out of the loop early.
One test in the tree hook regresses to the failing state because it checks that the tree hook works without a Set available, but we started using Set in this code. It is not essential and we can clean this up later when we decide how to deal with polyfills.
* Move ReactTypeOfWork to src/shared
It needs to be available both to Fiber and Isomorphic because the tree hook lives in Isomorphic but pretty-prints Fiber stack.
* Add dev-only ReactDebugCurrentFiber for warnings
The goal is to use ReactCurrentOwner less and rely on ReactDebugCurrentFiber for warning owner name and stack.
* Make Stack invariant messages more consistent
Fiber used a helper so two tests had the same phrasing.
Stack also used a helper for most invariants but hardcoded a different phrase in one place.
I changed that invariant message to use a helper which made it consistent with what it prints in Fiber.
* Make CSSPropertyOperations use getCurrentFiberOwnerName()
This gets mount-time CSS warnings to be printed.
However update-time warnings are currently ignored because current fiber is not yet available during the commit phase.
We also regress on HostOperation hook tests but this doesn't matter because it's only used by ReactPerf and it doesn't work with Fiber yet anyway. We'll have to think more about it later.
* Set ReactDebugCurrentFiber during the commit phase
This makes it available during updates, fixing the last failing test in CSSPropertyOperations.
* Add DOM warnings by calling hooks directly
It is not clear if the old hook system is worth it in its generic incarnation. For now I am just hooking it up to the DOMFiber renderer directly.
* Add client-side counterparts for some warning tests
This helps us track which warnings are really failing in Fiber, and which ones depend on SSR.
This matches what we do in Fiber -- and doing it this way is the only way we can prepare new views in the background before unmounting old ones.
In particular, this breaks this pattern:
```js
class Child1 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Child2 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Parent extends React.Component {
render() {
return (
showChild1 ?
<Child1
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/> :
<Child2
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/>
);
}
}
```
Previously, `this.registered` would always be set -- now, after a rerender, `this.registered` gets stuck at null because the old child's componentWillUnmount runs *after* the new child's componentWillMount.
A correct fix here is to use componentDidMount rather than componentWillMount. (In general, componentWillMount should not have side effects.) If Parent stored a list or set of registered children instead, there would also be no issue.
This matches the behavior in Fiber. Normally we would change Fiber
to match Stack to minimize breaking changes for the initial release.
However, in this case it would require too large a compromise to change
Fiber to act like Stack.
We introduced runtime validation of tag names because we used to generate
HTML that was supposed to be inserted into a HTML string which could've
been an XSS attack.
However, these days we use document.createElement in most cases. That
already does its internal validation in the browser which throws. We're now
double validating it. Stack still has a path where innerHTML is used and
we still need it there. However in Fiber we can remove it completely.
In #2756 we ended up using toLowerCase to allow case insensitive HTML tags.
However, this requires extra processing every time we access the tag or
at least we need to process it for mount and store it in an extra field
which wastes memory.
So instead, we can just enforce case sensitivity for HTML since this might
matter for the XML namespaces like SVG anyway.
* Remove array indirection in host context
* Keep a single context stack with a null sentinel
This lets us keep subtrees separated without maintaining independent context arrays for subtrees.
* There is always exactly one null by the time we pop a portal
I was trying to be smart but didn't need to.
* Cache current context
* Enable additional (failing) portal tests
* Fix portal unmounting
When unmount a portal, we need to unmount *its* children from itself.
This is similar to what we would do for a root if we allowed deleting roots.
* Skip portals when looking for host siblings
A portal is not part of that host tree despite being a child.
* Fix comment typo
* Add a failing test for portal child reconciliation
It is failing because portal bails out of update, seeing null in pendingProps.
It is null because we set pendingProps to nextPortal.children, which is null in this test.
* Fix the bug when switching to a null portal child
If pendingProps is null, we do a bailout in beginWork.
This prevents unmounting of the existing child when the new child is null.
We fix this by changing portal fiber's pendingProps to be the portal object itself instead of its children.
This way, it is never null, and thus doesn't cause a false positive in the bailout condition.
* Add a comment about HostPortal in getHostSibling
* Revert the fix because I don't know why it worked
unmountHostComponents() should have worked despite finding the wrong parent because it should have changed the parent when pushing and popping the portals.
* Don't call commitDeletion recursively
This leads to a "Cannot find host parent" bug because commitDeletion() clears the return field.
When we're inside the loop, we assign node.sibling.return to node.return but by this moment node.return has already been nulled.
As a solution we inline code from commitDeletion() without the nulling.
It still fails tests but for a different reason (unrelated bug).
* Skip portal children in commitNestedUnmounts()
We are currently already visiting them in commitUnmount() portal case since it's recursive.
This condition avoids visting them twice.
* Set node.child.return before going deeper
It doesn't seem to influence existing tests but we have this protection in all other similar places.
It protects against infinite loops.
* Revert "Fix the bug when switching to a null portal child"
This reverts commit ed9747deed.
I'll solve this by using an array in place of null instead.
* Use [] for empty Portal pendingProps
This avoids a false positive bailout with pendingProps == null when portal is empty.
- In the previous example, the code works even without using bind(this) in the constructor.
- the reason being handleClick doesn't even use `this` and its just calling the global function alert.
- this change make use of this via access this.state.
Andrew Clark
Andrew Clark
Dan Abramov
Brian Vaughn
Brian Vaughn
Ben Alpert
Ben Alpert
Gaëtan Renaudeau
Sebastian Markbåge
Sebastian Markbage
comerc
Chris