-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove buggy unstable_deferredUpdates() #13488
Conversation
Pushed up a fix. |
Why deferred update depends on the |
I don't understand what you're asking. |
Sorry for my confusing! I mean, I don't understand why But interactive update is about event type like this and |
Normally when we're inside an interactive handler (like However once we're inside |
Can we just remove this API? We haven't found a legit use case for it that isn't solved by calling |
Is setState outside handlers already automatically lo pri in async mode? I didn’t realize this. If so, does it only happen if the component you set state on is inside an async tree? Or how else do we determine it should be lo pri by default (when today it’s sync by default)? |
Yep that's how it works |
ReactDOM: size: -0.1%, gzip: -0.1% Details of bundled changes.Comparing: 53ddcec...803ee47 react-dom
Generated by 🚫 dangerJS |
@@ -1568,11 +1568,14 @@ function scheduleWork(fiber: Fiber, expirationTime: ExpirationTime) { | |||
function deferredUpdates<A>(fn: () => A): A { |
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.
Do you want to remove it from the scheduler/noop too?
@gaearon Hi, dan, I have 2 questions here
1.If so, all ways which could make us jump out the handlers like So why we only choose " 2.Another question is, I'm a little confused with the "It only happen if the component you set state on is inside an async tree." But I don't see you use the And if I add the Wish you could clarify these 2 questions, Really appreciated, thanks! |
In practice we'll suggest people to use
You're right. Initially the test was written for
The update inside an "interactive" event, and it seems like we currently flush all interactive updates if an input was rendered. It's necessary for controlled inputs, but I'm not sure it makes sense for uncontrolled ones. I'll follow up. Thank you! |
Addresses one of the issues brought up by @NE-SmallTown in #13488 (comment)
expect(syncValueRef.current.textContent).toBe(''); | ||
|
||
setUntrackedInputValue.call(inputRef.current, 'hello'); | ||
inputRef.current.dispatchEvent(new MouseEvent('input', {bubbles: true})); |
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.
This might look like nitpicking, since it's completely unrelated to the issue at hand, but I'm honestly curious on why you used MouseEvent
for input here.
Sorry for the random chime in 👐
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 think I used click at first and then forgot to change when I rewrote the test
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 see. Thanks for the quick answer :)~
Summary: The async mode unstable API deferredUpdates was removed in React 16.5.0 with facebook/react#13488 As discussed there, the alternative workaround is to simply use requestIdleCallback or requestAnimationFrame. Once a better API is released (tracking facebook/react#13306) we can use that instead for deferred async updates. Reviewed By: hansonw Differential Revision: D9814299 fbshipit-source-id: 8848cf05cd11ffba65b6d87233e2f5205121179b
Summary: The async mode unstable API deferredUpdates was removed in React 16.5.0 with facebook/react#13488 As discussed there, the alternative workaround is to simply use requestIdleCallback or requestAnimationFrame. Once a better API is released (tracking facebook/react#13306) we can use that instead for deferred async updates. Reviewed By: hansonw Differential Revision: D9814299 fbshipit-source-id: 8848cf05cd11ffba65b6d87233e2f5205121179b
* Add a failing test for deferredUpdates not being respected * Don't consider deferred updates interactive * Remove now-unnecessary setTimeout hack in the fixture * Remove unstable_deferredUpdates
Addresses one of the issues brought up by @NE-SmallTown in facebook#13488 (comment)
This fixes the issue I was seeing in my JSConf demo, and that currently exists in the fixture:
react/fixtures/unstable-async/time-slicing/src/index.js
Lines 67 to 68 in 53ddcec
react/fixtures/unstable-async/time-slicing/src/index.js
Lines 110 to 111 in 53ddcec
When we enterdeferredUpdates
, we should treat them as deferred — regardless of whether we're in an interactive handler.As per discussion below, we decided
unstable_deferredUpdates
is unnecessary since any update outside of event handlers in async mode is already treated as low priority. In userland code, the suggested solution for explicitly scheduling them will bescheduleWork
(from the unreleased scheduler package). Until that package is published,requestIdleCallback
orrequestAnimationFrame
work as alternatives.