5 ms·

I am horrified. I didn't see mentioned, proper data fetching _must_ happen before UI rendering if you want to have consistent behavior with classic HTML/HTTP ap

I am horrified. I didn't see mentioned, proper data fetching _must_ happen before UI rendering if you want to have consistent behavior with classic HTML/HTTP apps, e.g. the current page content stays displayed until the received html starts to be rendered (with the actual data for pure HTML). You loading feed back _has_ to happen from the interacted page in first intent. If you want to have an after routing/rendering loading feedback, such as skeleton or so, you still can do it, but it will be opt-in, not an after thought of savage data fetching and rendering that really might happens as the application gains features and diverts from the simple POC patterns. Proper data fetching and rendering cannot happen without a router. Remix solved this with their updated react-router, I know that this router has a bad rep with breaking changes, but they finally landed the implementation that neatly cover most if not all the use cases for routing with dynamic code imports and data fetching.

janci 2y ago
> 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.
- leovingi 2y ago
  >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.
- beejiu 2y ago
  > 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-side-rendering/ https://www.apollographql.com/docs/react/performance/server-... as do many other data-fetching libraries.
- tuyiown 2y ago
  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.
Bjartr 2y ago
> Proper data fetching and rendering cannot happen without a router. Got any suggestions for where to look if I'd like to learn more about what that means exactly?
- tuyiown 2y ago
  It's a bit dense, but you'll have a broad overview in react routers docs https://reactrouter.com/en/main/start/overview https://reactrouter.com/en/main/start/overview
  - lukebuehler 2y ago
    Even better examples are in the latest updates to bulletproof react. They combine react router pre-fetching with tanstack query.
viraptor 2y ago
Why do you go with "must"? For example I interact with a medical app. When you open a patient card, there's lots of data getting requested. It halts the new context opening for a long time, even though you need only a fragment of this data. I'd love it if it didn't wait and instead opened the basic information with placeholder blocks that get loaded as the data comes in. You really don't need all the old visits loaded in a collapsed tree that you're not going to use. This would save significant amount of time ever day.
- ndriscoll 2y ago
  How much is lots? I would think for a single patient, you'd generally be requesting maybe a couple dozen kB unless there are images, but those should be loaded separately. Looking at the Crowdstrike thread from the other day on this site for example, it looks like 500 comments amounts to ~120 kB and loads in about as many ms (and that's with gzip. br or zstd should do better).
  - viraptor 2y ago
    It's not the size. The main view contains bits from so many tables and in situations where the context decides how to calculate other results. Compression is cool, but it can't solve running a chain of queries.
    - wruza 2y ago
      If you can’t quickly collect data for a principal view, the data structure is incorrect. This doesn’t solve your problem cause it’s usually unlikely that one can refactor a data problem on sight in a shipped app, but doesn’t make this case normal too. Most apps don’t need such partial loading optimization and shouldn’t be designed as such. Normalizing it creates a web full of never-ending spinners, which already is a plague.
      - viraptor 2y ago
        It's medical software which existed for over a decade. The main view for the patient includes billing details, family connections, reminders, previous booking, documents, outstanding tests, pregnancy status, preventive care preferences, etc. There's lots to optimise in this app/db for sure, but you're underestimating the real complexity. Whatever you do, you're still querying 20+ tables (in non trivial ways) and calculations.
beejiu 2y ago
It's perfectly possible and common to generate a server-side render with the data fetched, so it doesn't break any consistency with the client-server model.
- tuyiown 2y ago
  Yes, that's also why it's great to use a router compatible with react SSR render capabilities, since you'll have a consistent and predictable behavior either from first rendering on the web client, or page change and loading on client js code.

janci 2y ago

> 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.

leovingi 2y ago
>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.
beejiu 2y ago
> 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-side-rendering/ https://www.apollographql.com/docs/react/performance/server-... as do many other data-fetching libraries.
tuyiown 2y ago
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.

Bjartr 2y ago

> Proper data fetching and rendering cannot happen without a router. Got any suggestions for where to look if I'd like to learn more about what that means exactly?

tuyiown 2y ago
It's a bit dense, but you'll have a broad overview in react routers docs https://reactrouter.com/en/main/start/overview https://reactrouter.com/en/main/start/overview
- lukebuehler 2y ago
  Even better examples are in the latest updates to bulletproof react. They combine react router pre-fetching with tanstack query.

viraptor 2y ago

Why do you go with "must"? For example I interact with a medical app. When you open a patient card, there's lots of data getting requested. It halts the new context opening for a long time, even though you need only a fragment of this data. I'd love it if it didn't wait and instead opened the basic information with placeholder blocks that get loaded as the data comes in. You really don't need all the old visits loaded in a collapsed tree that you're not going to use. This would save significant amount of time ever day.

ndriscoll 2y ago
How much is lots? I would think for a single patient, you'd generally be requesting maybe a couple dozen kB unless there are images, but those should be loaded separately. Looking at the Crowdstrike thread from the other day on this site for example, it looks like 500 comments amounts to ~120 kB and loads in about as many ms (and that's with gzip. br or zstd should do better).
- viraptor 2y ago
  It's not the size. The main view contains bits from so many tables and in situations where the context decides how to calculate other results. Compression is cool, but it can't solve running a chain of queries.
  - wruza 2y ago
    If you can’t quickly collect data for a principal view, the data structure is incorrect. This doesn’t solve your problem cause it’s usually unlikely that one can refactor a data problem on sight in a shipped app, but doesn’t make this case normal too. Most apps don’t need such partial loading optimization and shouldn’t be designed as such. Normalizing it creates a web full of never-ending spinners, which already is a plague.
    - viraptor 2y ago
      It's medical software which existed for over a decade. The main view for the patient includes billing details, family connections, reminders, previous booking, documents, outstanding tests, pregnancy status, preventive care preferences, etc. There's lots to optimise in this app/db for sure, but you're underestimating the real complexity. Whatever you do, you're still querying 20+ tables (in non trivial ways) and calculations.

beejiu 2y ago

It's perfectly possible and common to generate a server-side render with the data fetched, so it doesn't break any consistency with the client-server model.

tuyiown 2y ago
Yes, that's also why it's great to use a router compatible with react SSR render capabilities, since you'll have a consistent and predictable behavior either from first rendering on the web client, or page change and loading on client js code.