3 ms·

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 compo

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 https://codesandbox.io/s/93yv4j129p), my previous comment holds true: https://news.ycombinator.com/item?id=19332577 https://news.ycombinator.com/item?id=19332577 Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9p 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.

danabramov 8y ago
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’ll prepare our own examples when the features are stable.
- gambler 8y ago
  >in Concurrent Mode we can interrupt a render in the middle if user does an interaction Can you interrupt an arbitrary user-written function that's called inside the rendering stack?
  - philipp-spiess 8y ago
    No, that's not possible in JavaScript. The important part is that React components are lazily evaluated[1] and are not rendered as a stack. So React can render a few components and then pause for higher priority work. As a user of the framework, you don't need to care about this though. So your mental model can be that of an interruptable function. [1]: https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluation https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluatio...
  - ivanwonder 8y ago
    I think to interrupt a render means interrupt the process of reconciliation. you don't have to response the user input until the difference of whole React element has been found. https://overreacted.io/react-as-a-ui-runtime/#consistency https://overreacted.io/react-as-a-ui-runtime/#consistency

danabramov 8y ago

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’ll prepare our own examples when the features are stable.

gambler 8y ago
>in Concurrent Mode we can interrupt a render in the middle if user does an interaction Can you interrupt an arbitrary user-written function that's called inside the rendering stack?
- philipp-spiess 8y ago
  No, that's not possible in JavaScript. The important part is that React components are lazily evaluated[1] and are not rendered as a stack. So React can render a few components and then pause for higher priority work. As a user of the framework, you don't need to care about this though. So your mental model can be that of an interruptable function. [1]: https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluation https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluatio...
- ivanwonder 8y ago
  I think to interrupt a render means interrupt the process of reconciliation. you don't have to response the user input until the difference of whole React element has been found. https://overreacted.io/react-as-a-ui-runtime/#consistency https://overreacted.io/react-as-a-ui-runtime/#consistency