Scheduling in React • Hacker News Board

Re: Scheduling in React

#51

Post by philipp-spiess » Thu, Mar 07, 2019, 9:19 PM UTC

gambler wrote: post #48

You can significantly improve on the baseline performance simply by doing: handleChange = event => { const value = event.target.value; this.setState({ inputValue: value }); setTimeout(() => { this.props.onChange(value); }, 1); setTimeout(() => { sendAnalyticsPing(value); }, 1); }; And wrapping mining function inside Name(): setTimeout(() => { miningBitcoin(2); }, 1); In fact, to me this pretty much seems as fast as t…

It feels a bit faster, yes. The reason is that the input value is updated earlier.

The problem is, that the UI is still unresponsive when the timeouts fire which you feel if you type fast or look at the animation/fps meter.

Instead of a setTimeout, you could also debounce the two expensive updates (as I've noted in the post). This would at least make sure that they are batched so if you type fast you only need to re-render the list once.

Re: Scheduling in React

#52

Post by gambler » Thu, Mar 07, 2019, 9:24 PM UTC

acemarke wrote: post #50

gambler wrote: post #48

You can significantly improve on the baseline performance simply by doing: handleChange = event => { const value = event.target.value; this.setState({ inputValue: value }); setTimeout(() => { this.props.onChange(value); }, 1); setTimeout(() => { sendAnalyticsPing(value); }, 1); }; And wrapping mining function inside Name(): setTimeout(() => { miningBitcoin(2); }, 1); In fact, to me this pretty much seems as fast as t…

How does this "improve" at all? In fact, that example will eliminate any chance React might have of batching multiple updates into a single render pass. React wraps all event handlers in a call to `unstable_batchedUpdates()`. All updates that are queued in that event handler will be batched together. Splitting updates into multiple ticks will keep them from being batched.

Try it instead of theorizing:

https://codesandbox.io/s/07293kpnn

The UI is nearly as responsive as their improved example.

I'm not a React expert, but I do know that browsers defer timeouts until they have time to process them. This can be used to take heavy-hitting functions out of events that block UI interactions. It can also be used for self-throttling recursive IIFEs.

Re: Scheduling in React

#53

Post by onion2k » Thu, Mar 07, 2019, 9:25 PM UTC

dplgk wrote: post #13

I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

A user is often ok with a delay...

Every user group focus test I've ever done on an app with a janky UI has brought it up as a significant "The app is so slow!" issue. On the things I build users hate UI delays.

Re: Scheduling in React

#54

Post by acemarke » Thu, Mar 07, 2019, 9:35 PM UTC

gambler wrote: post #52

acemarke wrote: post #50

Earlier quoted context omitted.

How does this "improve" at all? In fact, that example will eliminate any chance React might have of batching multiple updates into a single render pass. React wraps all event handlers in a call to `unstable_batchedUpdates()`. All updates that are queued in that event handler will be batched together. Splitting updates into multiple ticks will keep them from being batched.

Try it instead of theorizing: https://codesandbox.io/s/07293kpnn The UI is nearly as responsive as their improved example. I'm not a React expert, but I do know that browsers defer timeouts until they have time to process them. This can be used to take heavy-hitting functions out of events that block UI interactions. It can also be used for self-throttling recursive IIFEs.

And I would say I reasonably qualify as a "React expert", and was having a discussion on this topic yesterday:

https://twitter.com/acemarke/status/1103373148169347072

There's a lot of nuance involved here. Moving some behavior outside the current tick may speed certain things up. Keeping multiple React updates in the same tick may _also_ speed other things up. It depends on what work is being done in these additional callbacks, and where/when they're being executed.

In this specific case: `this.props.onChange()` calls the parent component's `setState()`. That should ideally be kept in the same tick as `this.setState()`, so they can be batched.

`sendAnalyticsPing()` does _not_ cause a React update. That should indeed be moved out to a separate tick, so that it doesn't slow down this update.

Re: Scheduling in React

#55

Post by danabramov » Thu, Mar 07, 2019, 9:36 PM UTC

Dan from React team checking in, just wanted to post a few extra thoughts about this!

https://twitter.com/dan_abramov/status/1103768273064259590

Re: Scheduling in React

#56

Post by philipp-spiess » Thu, Mar 07, 2019, 9:40 PM UTC

gambler wrote: post #52

acemarke wrote: post #50

Earlier quoted context omitted.

How does this "improve" at all? In fact, that example will eliminate any chance React might have of batching multiple updates into a single render pass. React wraps all event handlers in a call to `unstable_batchedUpdates()`. All updates that are queued in that event handler will be batched together. Splitting updates into multiple ticks will keep them from being batched.

Try it instead of theorizing: https://codesandbox.io/s/07293kpnn The UI is nearly as responsive as their improved example. I'm not a React expert, but I do know that browsers defer timeouts until they have time to process them. This can be used to take heavy-hitting functions out of events that block UI interactions. It can also be used for self-throttling recursive IIFEs.

If you delay the artificial slowness that I added in the Text component after the rendering, it sure will be faster. The point is to simulate an expensive component tree with this.

If we keep that in (https://codesandbox.io/s/93yv4j129p), my previous comment holds true: https://news.ycombinator.com/item?id=19332577

Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9p You can see that this example does not need any optimizations out of the box. This is why I added the slowness to simulate a more complex app.

Re: Scheduling in React

#57

Post by philipp-spiess » Thu, Mar 07, 2019, 9:45 PM UTC

dplgk wrote: post #13

I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

Keep in mind that the APIs are still WIP. I choose an example with lots of APIs on purpose.

There's a lot that can be inferred by e.g. looking at the event type or understanding semantics. I expect this to be better when the features near completion.

Re: Scheduling in React

#58

Post by bfrydl » Thu, Mar 07, 2019, 9:48 PM UTC

acemarke wrote: post #47

bfrydl wrote: post #43

Earlier quoted context omitted.

Yes, I'm familiar with the arguments against it, but my experience using Redux has led me to strongly disagree with them. I don't think the proposed benefits have much value in actual practice, and limiting the use of dispatch to plain objects makes state logic easier to understand in my opinion. Also, I think my primary issue with redux-thunk isn't that you dispatch a non-object but that the getState argument encour…

I understand most of your concerns, and it seems like we'll have to agree to disagree to some extent. FWIW, I specifically addressed several concerns regarding use of `getState` in my post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [0]. I agree that trying to fully capture the potentially dynamic behavior with static types can be painfully difficult. I don't actually use TS myself, yet…

I do think we need to agree to disagree. That being said according to the README for the Redux Starter Kit these are listed as problems it wants to solve:

• "Configuring a Redux store is too complicated"

• "I have to add a lot of packages to get Redux to do anything useful"

• "Redux requires too much boilerplate code"

I can't help but point out that all of these concerns can also be solved by not using any extra libraries and just doing what I suggested.

Configuration: createStore()

Lot of packages: Not needed, just pass dispatch around.

Boilerplate code: Pretty much just combineReducers calls.

Re: Scheduling in React

#59

Post by acemarke » Thu, Mar 07, 2019, 9:51 PM UTC

bfrydl wrote: post #58

acemarke wrote: post #47

Earlier quoted context omitted.

I understand most of your concerns, and it seems like we'll have to agree to disagree to some extent. FWIW, I specifically addressed several concerns regarding use of `getState` in my post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [0]. I agree that trying to fully capture the potentially dynamic behavior with static types can be painfully difficult. I don't actually use TS myself, yet…

I do think we need to agree to disagree. That being said according to the README for the Redux Starter Kit these are listed as problems it wants to solve: • "Configuring a Redux store is too complicated" • "I have to add a lot of packages to get Redux to do anything useful" • "Redux requires too much boilerplate code" I can't help but point out that all of these concerns can also be solved by not using any extra libr…

I'd encourage you to read through the RSK docs further to see what all it actually does, then :)

Re: Scheduling in React

#60

Post by Tade0 » Thu, Mar 07, 2019, 10:05 PM UTC

hombre_fatal wrote: post #46

Tade0 wrote: post #6

Impressive, but I don't think there's much of a use case for this. Sure that last example ran at close to 60fps, according to the meter, but did it really? I mean, as a user I experienced no performance gains, because I was focused on that lower part of the UI and I think most users would as well.

People are highly aware of when their input is locked up. It's like trying to type commands over SSH on a bad or laggy connection: you have to keep pausing, wait for it to catch up, and ensure there are no typos or anything. Oops, need to backspace, wait, and edit that character. Oops, backed up too far. Classic example of this is a naive markdown preview box that updates on every keypress. As the input grows, the ex…

Though I found the demonstration intolerable and would hope, as a user of your application, that you wouldn't settle on "meh, the user won't notice/care."

Actually I would just debounce it and add a spinner. No need to shoehorn additional operations in between, which are going be outdated in a split second anyway.