-
Notifications
You must be signed in to change notification settings - Fork 47.7k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Context providers and consumers should bailout on already finished work #12254
Conversation
Fixes bug where a consumer would re-render even if its props and context had not changed.
@gaearon Ready for review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Verified it fixes my issue. Code seems to make sense.
} else if (oldProps === newProps) { | ||
return bailoutOnAlreadyFinishedWork(current, workInProgress); | ||
} | ||
} else if (changedBits !== 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could just be else
This change seems to make sense to me. 👍 |
@sebmarkbage I'm gonna merge this as-is so I can start the sync. If you have additional feedback, I'll fix in a follow up. |
'A context consumer expects a single child that is a function. ' + | ||
'If you did pass a function, make sure there is no trailing or leading whitespace around it.', | ||
if (__DEV__) { | ||
warning( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move this to context creation then? Or do we already warn there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Context creation is too early. Needs to check on every render. Like a prop type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean createElement
when we know type is a context consumer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. Idk, not sure what the advantages are. I thought about using propTypes
but if the plan is to remove those eventually? Although maybe this is an indication that would shouldn't...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idk, not sure what the advantages are.
You get a JS stack trace pointing where it happened.
…rk (facebook#12254) * Context providers and consumers should bail-out on already finished work Fixes bug where a consumer would re-render even if its props and context had not changed. * Encode output as JSON string * Add weights to random action generator * Add context to triangle fuzz tester * Move bailouts to as early as possible * Bailout if neither context value nor children haven't changed (sCU) * Change prop type invariant to a DEV-only warning
…rk (facebook#12254) * Context providers and consumers should bail-out on already finished work Fixes bug where a consumer would re-render even if its props and context had not changed. * Encode output as JSON string * Add weights to random action generator * Add context to triangle fuzz tester * Move bailouts to as early as possible * Bailout if neither context value nor children haven't changed (sCU) * Change prop type invariant to a DEV-only warning
Fixes bug where a consumer would re-render even if its props and context had not changed.