Hacker News Reader

Comment by polskibus | Hacker News Reader

I wonder if they considered a new base class instead, for example reactAsyncComponent? That way developer as to declare his component as async-safe explicitly, without all that hard to follow rename thing. Engine could recognize async classes and perform rendering differently for them.

View on HN

Yes, we considered it. Two arguments against this:

1. A single “async component” is useless because the power of async rendering is in letting React coordinate the work of the whole tree. As long as just one leaf isn’t async-compatible, the whole tree isn’t.

2. In practice most components already are async-compatible. So we don’t want to hold off progress by forcing people to explicitly specify it. Instead the plan is to outlaw patterns that we know won’t work.

Hope this makes sense.

It does, thanks. Hopefully there will be a set of dev warnings, tests or sth that a developer can read or run that will help him verify whether the component tree is "async-ready".

BTW, I've watched your jsconf, great presentation, can't wait to use all those goodies (also love HN for a chance of response straight from react core team :)

>Hopefully there will be a set of dev warnings, tests or sth that a developer can read or run that will help him verify whether the component tree is "async-ready".

We'll offer a <StrictMode> component in React 16.3 that warns about some unsafe patterns (like legacy lifecycles and a few other issues). Later on we'll provide more testing tools for libraries.

Reply on news.ycombinator.com