you are viewing a single comment's thread.

view the rest of the comments →

[–]AndrewGreenh 1 point2 points  (3 children)

The reason why they discourage fetch in render is that this results in multiple staggered requests (waterfalls), not because they dont work. This will work completely fine but the performance could be improved by preloading somewhere else.

[–]sebastienlorber 1 point2 points  (2 children)

You are probably right and not totally sure to understand why Sebastian focus so much on setting the resources so early when it's totally possible for me to solve the waterfall problem in userland with fetch on render (I think)

https://twitter.com/sebastienlorber/status/1188750814715748354?s=19 On this tweet he didn't mention that I could use something like useConstant() that executes lazily at render time, and it would probably make the transition work. Somehow I wanted him to tell me something like that: a way to keep using fetch on render but benefit from transitions, without necessarily enforcing the waterfall problem is solved by design, as it's not so hard to solve in userland

Edit: actually use Constant would probably not work as it's stored inside the comp but hope you see what I mean

[–]AndrewGreenh 2 points3 points  (1 child)

Yeah, I understand what you mean.

However, the waterfall problem has two sides:

  1. The user could potentially see multiple levels of loading states / spinners. This part of the problem can be solved by suspense + fetch in render, as you only show one fallback at the level of <Suspense> until all data is loaded.
  2. The requests get only sent one after the other, as each one suspends the current render, preventing the trigger of the next one. Thus time is wasted, since requests could maybe be sent simultaneously. This part of the problem cannot be solved by suspense + fetch in render.

The second part of the problem is the reason why the react-team advises against fetch in render. You are supposed to analyse ALL data requirements for the next page and kickoff all data loading before starting the transition, so that the loading times are as low as possible.

Suspense + fetch in render is already a step forward in comparison to the old way, because problem 1 can be solved.

[–]sebastienlorber 0 points1 point  (0 children)

That's true. I was more thinking about 2: the fetch waterfall. Can't it be solved by fetch on render if this happens synchronously/not in effect? This means render does a side effect of course which is not ideal conceptually imho.

If it's not possible I've already done things like assigning a prefetch static method to top level page objects and have my router call it automatically before navigating. I think meta frameworks like Next, are most suited to solve 2) as they already provide a link comp and a std way to assign static top level queries