Implement the Fetch as you Render Approach for Improved Performance
Share this video with your friends
Along with the release of Suspense, the React team has given us some recommendations for how we approach structuring our data loading so we can optimize both dynamic loading of code and data. There are two approaches to data and code loading that are common in the React ecosystem, and one that the React team is recommending called "fetch as you render." Let's compare these approaches to understand how they differ and why "fetch as you render" is the superior approach over "fetch on render" and "fetch then render."
How would you handle the case, where you implemented optimistic loading, like here, but in some cases the predictive URL was not correct?
Hi Stephen, That's a good question. Unfortunately there's not much you can do in that case. You'll have to use the suspending Img component solution (or just deal with the issues we had before).
One solution might be to make an endpoint that acts as a proxy so you can make the image URLs predictable (and have the server proxy to the actual image URL).
Is the number of concurrent request dependent on the browser's implementation?
e.g.) If Chrome allows 6 max network connections, and 10 resources are created and requesting data, then would first 6 request will be sent, and rest (4) will be loaded subsequently?
Yes, you may bump against the browser's number of concurrent requests limitation (which is a good argument for graphql honestly), but even then the more you make concurrently the better off you are because even if the browser limits the requests going out, it will be able to fire off the rest while you're parsing the results of the ones that have already returned.