Skip to content

Conversation

@acdlite
Copy link
Collaborator

@acdlite acdlite commented Nov 17, 2017

In the current implementation, pendingProps is null if there are no new props since the last commit. When that happens, we bail out and reuse the current props.

But it makes more sense to always set pendingProps to whatever the next props will be. In other words, pendingProps is never null on the work-in-progress: it points to either new props, or to the current props. Modeling it this way lets us delete lots of code branches and is easier to reason about bail outs: just compare the pending props to the current props.

In the current implementation, pendingProps is null if there are no new
props since the last commit. When that happens, we bail out and reuse
the current props.

But it makes more sense to always set pendingProps to whatever the next
props will be. In other words, pendingProps is never null: it points to
either new props, or to the current props. Modeling it this way lets us
delete lots of code branches and is easier to reason about bail outs:
just compare the pending props to the current props.
@acdlite acdlite force-pushed the always-set-pending-props branch from 2fc9256 to 9103f02 Compare November 17, 2017 01:48
let newChild = createWorkInProgress(
currentChild,
currentChild.pendingProps,
currentChild.pendingProps !== null
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So when is pendingProps null?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We set it back to null in the complete phase, unless we tear (down-prioritize), in which case the torn props are stored on the current fiber. https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberCompleteWork.js#L395-L405

Copy link
Collaborator Author

@acdlite acdlite Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebmarkbage Thanks for pointing that out; realized it's simpler to just never reset pending props. Updated!

@acdlite acdlite force-pushed the always-set-pending-props branch 2 times, most recently from cdb508a to c927915 Compare November 17, 2017 04:24
Copy link
Collaborator

@sebmarkbage sebmarkbage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the original idea was that not all input may have referential equality objects as their input (and comparison to null is slightly faster anyway).

@acdlite acdlite merged commit 2ae4c62 into facebook:master Nov 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants