[janci]

> if you want to have consistent behavior with classic HTML/HTTP apps

Why is that desirable? I see it more like a limitation of server-rendered web apps. Many times you can show useful UI before actual data is fully loaded (i.e. search / filter controls or basic data you already have).

Certainly, cascading fetching is undesirable and you should know what data you need to fetch and start the requests as soon as possible, but not necessarily before the route transition occurs.

[beejiu]

> I see it more like a limitation of server-rendered web apps.

It's not an intrinsic limitation of server-rendered apps. Apollo solves this https://www.apollographql.com/docs/react/performance/server-... as do many other data-fetching libraries.

[leovingi]

>Many times you can show useful UI before actual data is fully loaded (i.e. search / filter controls or basic data you already have).

It can be done, yeah, but it has to be handled very carefully because it runs the risk of causing more issues than it solves. I can't count the number of times I've used the AWS Console, loaded a page, clicked on a control, only to find that the data that was loaded a few milliseconds before caused the elements on the page to shift so now I clicked on a completely different button, started the process to load a new page and now have to reload the old one and wait for the entire page to finish loading or risk a misclick again.

[tuyiown]

We mostly agree, my point is more about risk management of uncontrolled loadings. I think it's better to naturally land on consistent, known mechanisms, in the idea that it simplifies code as first intent, and then adjust your preferred/desired implementation case by case.