Beyond React 16 by Dan Ambramov – Async Rendering and React Suspense
So if I understand it correctly, anything after this line inside the render...<p><pre><code>    const movie = movieDeatailsFetch.read(props.id);
    ...
</code></pre>
... will block rendering and will defer to a parent &lt;Placeholder &#x2F;&gt; component to render instead?<p>Interesting magic I&#x27;d say, since I wouldn&#x27;t expect such a line to block my rendering.<p>Wouldn&#x27;t it be a more &quot;React way&quot; to have HOC component or a render prop that would work exactly like this .read() API?<p><pre><code>   &lt;MovieDetailsFetcher&gt;
     {movie =&gt; &lt;MovieDetails movie={movie} &#x2F;&gt; }
   ...
</code></pre>
Then this HOC component doesn&#x27;t need to have the IO-logic in the render, it can put it in the `componentWillMount` or inside another lifecycle method of React.<p>What&#x27;s the advantage of putting the IO operation in the render instead of inside a lifecycle method?<p>Also, how&#x27;s race-conditioning done? Does the fetcher library have the logic to only render the last fetcher, or is it more complicated than that?<p>There&#x27;s lots of magic, especially in the IO part, and would&#x27;ve loved if he went more into detail on how it&#x27;s actually done - it&#x27;s a JS-conf afterall.<p>Also, a fetch()-promise-based API is not the only type of IO-interface we have. In fact it&#x27;s only one of many.<p>HTTP2 for instance is on the horizon offering more complex interfaces with open connections possibly returning several results like websockets - on the other hand a Promise only returns one result and then dies. Observables might be a more interesting abstraction for IO-kind of things.<p>Also, testing this seems rather complex since the render is effectively doing a side-effect.<p>In any case, cool lateral thinking and I love hearing these type of talks about cool new futuristic stuff rather than some boring old thing everybody knows about.