A navigation to a dynamic server-rendered page is blocked until the server responds. In Next.js, the first step to improving the experience is to add a `loading.js` file. This unblocks navigation and gives the user feedback while the content streams in.

Docs · Is `loading.js` the same as a `<Suspense>` boundary? Not quite. `loading.js` becomes the fallback UI of a Suspense boundary, but because it is a convention, it can be rendered and prefetched ahead of time. Regular Suspense boundaries need a server round-trip to render their fallback. So, are suspense boundaries bad? No. You can use Suspense deeper in a Page to break up rendering into smaller chunks and stream them as they become available. Since the page is already rendering on the server at that point, no additional round-trip is needed. What about static pages? Pages rendered at build time don't need a `loading.js` file because all their content is already available and can be prefetched when <Link>'d to.

delba-remotion-framework when?

when the repo isn't this

Except when you click a link and it takes a second before loading.ts shows up 😆

Nextjs sucks waiting for tanstack start stable

Another nice video as always, Delba 🤍🔥

🤍

Is adding a 'loading.tsx' a good approach even if you're using SSR?

Suspense looks so much better than the loading.tsx file

Do you mean at the 29s mark? That is using both, loading.js for the form and suspense for inventory and orders. * there is a code mistake here, I should have split the promise.all into separate promises, which are then passed down.