Resolve refs in the order of the children #7101
Merged
+89
−22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved. With the current `ReactMultiChild`, this is *usually* the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when **a new child is mounted during an update**. In this case, the `mountComponent()` call used to be delayed until `ReactMultiChild` processes the queue. However, this is inconsistent with how updates normally work: unlike mounting, updating and unmounting happens inside `ReactChildReconciler.updateChildren()` loop. This PR changes the `mountComponent()` to be performed inside `ReactChildReconciler`, just like `receiveComponent()` and `unmountComponent()`, and thus ensures that `attachRef()` calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved. This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change).
ghost
added
| @@ -127,6 +130,13 @@ var ReactChildReconciler = { | |||
| // The child must be instantiated before it's mounted. | |||
| var nextChildInstance = instantiateReactComponent(nextElement); | |||
| nextChildren[name] = nextChildInstance; | |||
| mountImages[name] = ReactReconciler.mountComponent( | |||
There was a problem hiding this comment.
We use an array for this in mountChildren so I can change it here too if necessary.
|
This looks good to me but that extra allocation worries me. It is going to stay on the young generation so I guess it is fine. You should at least make it an array if that's possible and lookups are fast. We might want to keep this for a minor release at least. Can have small artifacts show up. |
|
@sebmarkbage Changed to use an array. Stamp? |
Do you mean queue it for 15.3.0 but use on the website? |
zpao
pushed a commit
that referenced
this pull request
Jul 13, 2016
* Resolve refs in the order of the children React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved. With the current `ReactMultiChild`, this is *usually* the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when **a new child is mounted during an update**. In this case, the `mountComponent()` call used to be delayed until `ReactMultiChild` processes the queue. However, this is inconsistent with how updates normally work: unlike mounting, updating and unmounting happens inside `ReactChildReconciler.updateChildren()` loop. This PR changes the `mountComponent()` to be performed inside `ReactChildReconciler`, just like `receiveComponent()` and `unmountComponent()`, and thus ensures that `attachRef()` calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved. This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change). * Use array instead of object to avoid lookups (cherry picked from commit 83cbc3e)
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
React makes no guarantees about ref resolution order. Unfortunately, some of the internal Facebook component APIs (specifically, layer dialogs) currently depend on the ref resolution order. Specifically, the assumption is that if the layer dialog is placed as a last child, by the time it mounts or updates, the refs to any previously declared elements have been resolved.
With the current
ReactMultiChild, this is usually the case but not always. Both initial mount and an update of all components satisfy this assumption: by the time a child mounts or updates, the previous children’s refs have been resolved. The one scenario where it isn’t true is when a new child is mounted (or replaced) during an update.In this case, the
mountComponent()call used to be delayed untilReactMultiChildprocesses the queue. Therefore, for newly mounted components,attachRef()gets enqueued too late, and previously existing children resolve their refs first even when they appear after newly mounted components. This subtly breaks the assumption made by our dialog layer APIs.Demo fiddle: https://jsfiddle.net/c1f9chm3/
This PR changes the
mountComponent()to be performed insideReactChildReconciler.updateChildren(), just likereceiveComponent()andunmountComponent(). This ensures thatattachRef()calls are enqueued in the order the children were processed, so by the time the next child flushes, the refs of the previous children have been resolved.This is not ideal and will probably be broken by incremental reconciler in the future. However, since we are trying to get rid of mixins in the internal codebase, and layered components are one of the biggest blockers to that, it’s lesser evil to temporarily make ref resolution order more strict until we have time to fix up the layer APIs to not rely on it, and are able to relax it again (which would be a breaking change).
Reviewers: @spicyj @sebmarkbage
Is this a breaking change? Personally I don’t think so because ref resolution order is indeterministic (in fact that’s the issue I’m trying to fix here). We used to resolve refs in a specific order in almost all cases except mounting. So I think it’s hard to even accidentally rely on the existing behavior. However in theory I can imagine something breaking in a ref-heavy code. So I’m torn.