Batching makes it difficult to perform imperative actions like focus

[astoilkov]

React version: 16.9.5

Steps To Reproduce

1. Overwrite batched updates with the following code: ReactDOM.unstable_batchedUpdates = callback => callback()
2. Batched updates aren't actually overwritten.

Reasoning

I recognize that this may not be classified as bug because it isn't a documented feature but I have tried to search for a different solution but to no avail. Fixing this behavior can open a new way of using React. I tried writing on Stack Overflow and writing to @gaearon.

I have a number of arguments which support the disabling of batched updates in event handlers and in effects initialization. If anybody is willing to read a document and consider this scenario I am willing to write an RFC.

[astoilkov]

I started wondering if RFCs for changes to React isn't a better place to write this issue. Let me know if you agree and I will close this one and write one there.

[gaearon]

If anything, we are going to batch more by default, not batch less. Batching is important for multiple reasons, including drastically improving performance for bubbling events, and to avoid inconsistent trees.

If you need to make a specific call unbatched, you can do this manually:

ReactDOM.flushSync(() => {
  // this setState won't be batched
  setState(something)
})

[astoilkov]

Is there a way to apply flushSync() to every event handler? I can provide a custom useLayoutEffect() and useEffect() functions but it is harder with event handlers.

We constantly observe bugs caused by the same code behaving differently in two places because at one place batching is happening and at the other, it isn't. I am not saying disabling batching by default, I believe in general this is better for most projects but I can clearly see that in our project it is introducing bugs for the past year. This is strange because our software is almost bug-free. However, batching is probably our biggest contributor to bugs right now.

[gaearon]

Is there a way to apply flushSync() to every event handler?

No. (And you'd need to apply it to setState calls, not event handlers.)

We constantly observe bugs caused by the same code behaving differently in two places because at one place batching is happening and at the other, it isn't.

This is interesting. This behavior has been there for over five years, and this is the first time I'm hearing this worded so strongly. (Usually people learn about batching once, learn not to read from this.state, and call it a day.) So I'm curious if there are particular patterns that cause this to be an issue for you.

If it's the inconsistency that gets you, you could apply batchedUpdates in more places instead. In a future version of React, this will be the default behavior for everything so the inconsistency will go away.

[gaearon]

I guess if you really want to do it, maybe something like this could work:

const origSetState = React.Component.prototype.setState
React.Component.prototype.setState = function() {
  ReactDOM.flushSync(() => {
    origSetState.apply(this, arguments);
  })
}

and you can probably come up with something similar for Hooks (or use your own useState Hook).

Needless to say, this is terrible for performance and will cause issues both for third-party components and for the future you who will be debugging this.

[astoilkov]

I am currently writing an example to show you the cases we are hitting and why bugs are appearing. Will get back to you soon.

[astoilkov]

Here is the example: https://codesandbox.io/s/cranky-sanderson-7kdcx.

Now let me explain:

1. Clicking "Log in" throws an error showing the bug.
2. I know that this example can be fixed by adding autoFocus to the input. However, imagine that focusing is conditional and the component doesn't know if it should focus itself when being created. If the new component should be focused is determined from the place that triggers the new component to show so no way to know in the component itself. Adding if the component should be focused as a state property introduces a new set of problems that I can explain if you want.
3. The same happens with any method of the element like scrollIntoView() or getBoundingClientRect(). For us focus() and scrollIntoView() are the most common. Mainly focus().
4. I understand this is a domain-specific problem because our application is shortcut-heavy and manages focus very strictly. I can even show you the app and give you 4-5 bugs that were caused by that behavior.

The main problem is that inputRef.current in the onClick() handler will have a different value depending on batched updates being used or not.

Note that if you can't understand what are the use cases of having access to a ref after updating the state I can go into bigger details and real-world use cases in our app.

I hope that you understood me. Let me emphasize that our app manages focus a lot and React isn't good at handling focus. Maybe if a good solution for focusing exists this kind of problems can be fixed with an abstraction and not by disabling batched updates but until then I have tried many things and haven't found a solution.

[astoilkov]

By the way, using flushSync() we can do something else and avoid disabling batched updates directly. We have methods that change the state and we can wrap all of them with flushSync(). I am describing everything above in order to help you understand a set of use cases that I believe are valid. I hope I will be helpful because for me it is a little strange I didn't found anybody talking about this problem.

[gaearon]

Thanks for a clear example.

Let me emphasize that our app manages focus a lot and React isn't good at handling focus. Maybe if a good solution for focusing exists this kind of problems can be fixed with an abstraction and not by disabling batched updates but until then I have tried many things and haven't found a solution.

That's a good callout. It's fair to say React doesn't really give you the tools to do it very well. We've been doing some work in that area but it's behind an experimental flag and is not ready to be a stable API yet. This is definitely something that's on our minds but we won't have a solution in the very near future.

In class-based code, you could do this to work around the problem:

setState({ isVisible: true }, () => {
  this.inputRef.curent.focus()
})

That's the idiomatic workaround in classes. We don't (yet?) have something similar exposed for Hooks because that exact API won't work. In particular, it would "see" old props and state which would be highly confusing.

Currently, in function components the only way you can get "notified" about commits is with useLayoutEffect. Here is an example:

  useLayoutEffect(() => {
    if (isTwoFactorAuthenticationVisible) {
      inputRef.current.focus();
    }
  }, [isTwoFactorAuthenticationVisible]);

That would solve your problem: https://codesandbox.io/s/laughing-fast-9785u.

However, I agree this solution isn't ideal because the desire to focus might in some cases have more to do with which action triggered it rather than which state changed.

I think there are at least two opportunities for RFC design here:

• More intuitive and declarative focus management that works within the React paradigm. (There was some work on this here: RFC: Focus Management API reactjs/rfcs#109, although I don't think this necessarily addresses your concerns. Maybe you could comment on it.)
• A way to express "run some side effect after a particular setState is flushed". We have this for classes, but not for Hooks. It seems like a useful feature. But it's not clear what the design should be like. So working on that would also be beneficial.

I don't think the solution is to "revert back" to a paradigm where each setState is atomic. We think this would be a regression. Instead, we think this needs to be "fixed forward" by finding the right abstractions that work with the React model. In the meantime, I hope the workarounds above are reasonable.

[gaearon]

I reopened this for discussion with a different title.