I think this is a great point made. I wonder if it makes sense to build into the core of react to have render method execute on priority levels configured for the components themselves. I agree that this adds a good deal of complexity otherwise for quicker projects.
Scheduling in React
71–80 of 109 posts
Re: Scheduling in React
#72Impressive, 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.
I found the second example to be way less janky. I want to be able to see what I type as I type it (e.g. for spelling mistakes). Taking a second to correlate that with results I am willing to accept, but if an app is janky with basic interactions I am leaving.
You can see the difference between first and second approaches that way. Although both would be fast if we remove that artificial slowdown (simulating a larger app).
However I also want to note that you shouldn’t base your idea of what Concurrent Mode will feel like based on an alpha version demo. It’s work in progress and we didn’t mean to imply it’s ready to be denied at face value. https://twitter.com/dan_abramov/status/1103769293479653376
Re: Scheduling in React
#73As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.
Re: Scheduling in React
#74Re: Scheduling in React
#75Earlier quoted context omitted.
Sorry, I know you're heavily involved in this ecosystem, I just don't really see the need for any of this. create-react-app is mostly about webpack, isn't it? Redux works fine on its own.
FWIW, I'm a Redux maintainer, and I built this specifically in response to how I've seen people _want_ to use Redux, and the concerns they've raised about using Redux. [0] Almost everyone uses `redux-thunk` [1]. Adding that to a plain Redux store takes a few steps. Adding middleware _and_ setting up the Redux DevTools Extension adds another couple steps [2] So, RSK's `configureStore()` does that by default [3]. Accid…
Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally.
It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and the people you surround yourself with, even after fully considering your ideas.
I also knew you were a Redux contributor when I first responded. I was wondering how long I could disagree with you before you pulled rank.
Re: Scheduling in React
#76I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though
Perhaps it would not have been so bad if they just kept the interface the same ...
Re: Scheduling in React
#77Re: Scheduling in React
#78As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.
Re: Scheduling in React
#79Earlier quoted context omitted.
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/9859x0wm9…
The important part btw is that in Concurrent Mode we can interrupt a render in the middle if user does an interaction, and handle that interaction first. Without blocking the thread. This is something setTimeout is incapable of helping with. Because even if you delay the work, at some point it’s still gonna block. In either case this example is very simplified and doesn’t illustrate the subtle difference as much. We’…
Can you interrupt an arbitrary user-written function that's called inside the rendering stack?
Re: Scheduling in React
#80I 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.
Management is complaining that our website is less responsive than our competition's ...