4 ms·

Hi Dan! Thanks for the great work. I wanted to discuss a few use-cases where React's new runtime model makes things less predictable: * Suppose you want a :hov

Hi Dan! Thanks for the great work. I wanted to discuss a few use-cases where React's new runtime model makes things less predictable: * Suppose you want a :hover CSS selector to be applied at the same instant as a state change triggered by that hover. It's no longer reliable. Hence you're stuck with having to change the DOM in response to the state change to match a different selector. * The browser may often set component state via its own behavior. (Small contrived ex: setting the scrollTop position of an inner element based on tabbing to a link.) Pretending that virtual DOM represents DOM, especially at X time, can get you in a lot of trouble. How would you deal with these contrived (yet realistic) examples?

danabramov 7y ago
>Suppose you want a :hover CSS selector to be applied at the same instant as a state change triggered by that hover. It's no longer reliable. Hence you're stuck with having to change the DOM in response to the state change to match a different selector. Not sure I understand the problem. Can you make a CodeSandbox demo? That said you can always wrap an update in `ReactDOM.flushSync(() => { ... })` to force it to run synchronously. But I'm not sure I understand the scenario or which problem you're referring to without a concrete example I could run. >The browser may often set component state via its own behavior. (Small contrived ex: setting the scrollTop position of an inner element based on tabbing to a link.) Pretending that virtual DOM represents DOM, especially at X time, can get you in a lot of trouble. I don't understand what this means. Again, a concrete demo would help ground the conversation. I think you might have some flawed assumptions about what React does, but I can't tell for sure because I don't understand what you're saying. Thank you! It's worth saying we've been using Concurrent Mode in production for about a year now. There are some snags we still need to solve, but they don't sound a lot like what you're describing.

danabramov 7y ago

>Suppose you want a :hover CSS selector to be applied at the same instant as a state change triggered by that hover. It's no longer reliable. Hence you're stuck with having to change the DOM in response to the state change to match a different selector. Not sure I understand the problem. Can you make a CodeSandbox demo? That said you can always wrap an update in `ReactDOM.flushSync(() => { ... })` to force it to run synchronously. But I'm not sure I understand the scenario or which problem you're referring to without a concrete example I could run. >The browser may often set component state via its own behavior. (Small contrived ex: setting the scrollTop position of an inner element based on tabbing to a link.) Pretending that virtual DOM represents DOM, especially at X time, can get you in a lot of trouble. I don't understand what this means. Again, a concrete demo would help ground the conversation. I think you might have some flawed assumptions about what React does, but I can't tell for sure because I don't understand what you're saying. Thank you! It's worth saying we've been using Concurrent Mode in production for about a year now. There are some snags we still need to solve, but they don't sound a lot like what you're describing.