Optimistic navigation when using defer

[alfredsgenkins]

Hey!

I would like to propose optimistic navigation, aka. navigation before loader has returned any result. Currently, navigation, in case when defer is used happens right when server has responded with first critical data. On slow network connection, where the most waiting comes from reaching the server, this could save a lot of time. This is important, as in the real application, I could have enough data to render optimistic UI for next page, passing it, for example, through a history state.

Consider the following site (currently fully CSR): https://ui.scandiweb.com I have implemented a very smooth transitions to PLP and to PDP no matter the network speed, utilizing history state. I can assure user navigation will take the same time, no matter the network connection speed. Once I migrated to remix, despite me switching to defer dynamically (based on if that is an initial page request), I still have to wait for server to respond before page is switched to reuse the prepared history data.

Is there any way around such behavior now? Can we add it?

Otherwise, I would be forced to write custom rendering solution based on React Router, without actually using loaders. Which are VERY CONVENIENT.

Basically, I want router behave as follows:

1. Call loader to render the initial page
2. Once navigated in app
   1. switch route instantly
   2. Call loader in background
   3. Update with data once returned, ideally, keeping the same history key

I kinda expect such behavior when switching to use defer loader.

[alfredsgenkins]

I have created a simple graphics to showcase the problem I am referring to:

In case someone is looking into making this possible, here is how I solved it (a bit hacky):

const criticalData = '{"promise":"__deferred_promise:promise"}';

const proxyFetch = (): void => {
  const originalFetch: typeof fetch = window.fetch;

  // eslint-disable-next-line sonarjs/cognitive-complexity
  window.fetch = (...args: Parameters<typeof fetch>): Promise<Response> => {
    const [resource] = args;
    const url: string = resource.toString();

    if (url.includes("_data")) {
      let controller: ReadableStreamDefaultController<Uint8Array> | undefined;

      const stream = new ReadableStream<Uint8Array>({
        start(c) {
          controller = c;

          // Immediately enqueue the criticalData without waiting for original fetch
          controller.enqueue(new TextEncoder().encode(`${criticalData}\n\n`));

          // We don't await the original fetch, thus making the response available immediately
          originalFetch(...args)
            .then((response) => {
              const reader = response.body!.getReader();
              const push = (): void => {
                reader
                  .read()
                  .then(({ done, value }) => {
                    if (done) {
                      controller?.close();
                      return;
                    }

                    // Process the chunk, skipping criticalData
                    const decoder = new TextDecoder();
                    const textChunk = decoder.decode(value, { stream: true });

                    if (textChunk.includes(criticalData)) {
                      // skipping critical data
                      const [, secondPart] = textChunk.split("\n\n");

                      // push only second part of the chunk
                      if (secondPart) {
                        controller?.enqueue(
                          new TextEncoder().encode(secondPart)
                        );
                      }

                      push();
                      return;
                    }

                    // console.log("received full data", bufferedString);
                    controller?.enqueue(value);

                    push();
                  })
                  .catch((err) => {
                    // console.error("Failed to read", err);
                    controller?.error(err);
                    reader.cancel();
                  });
              };
              push();
            })
            .catch((err) => {
              // console.error("Failed to fetch", err);
              controller?.error(err);
            });
        },
        // cancel(reason) {
        //   console.log("Stream cancelled", reason);
        // },
      });

      return Promise.resolve(
        new Response(stream, {
          headers: new Headers({
            "Content-Type": "text/remix-deferred; charset=utf-8",
          }),
        })
      );
    }

    return originalFetch(...args);
  };
};

proxyFetch();

This way, awaiting initial response from server is skipped, and Remix thinks we got the reply instantly.

[kiliman]

It's possible the new clientLoader RFC will handle this use case.

#7634

Initial implementation in #8092

[alfredsgenkins]

@kiliman right, thanks! The other question is why should we actually wait for server when using defer? Maybe we should by default return ReadableStream and pipe the response into it once ready? Is there any reason it is done the way it works now? I guess stuff would work faster this way. I guess, that there could be some critical data from server, that we need our application to mount with, therefore returning as is – is not safe.

[alfredsgenkins]

Client loaders seem to be live now. I explored them, and seems like the documentation does not mention we can use defer inside of them. I am sure this will help to eliminate the need to wait for first byte from server. However, it seems to be run after the server response, thus won't help to return "known" data derived from previous page. My question is: is there a way to switch route immediately, to render optimistic navigation, while still using a loader for data fetching. I like the BFF approach, and would not like to keep it.

[sumann7916]

Hi! Having the same problem. created skeletons for all my pages and used defer as well but the problem seems to slow navigation due to waiting time being long. The proxyfetch should probably fix this for now. Do I need to call the proxyfetch some where else as well?

[alfredsgenkins]

I think this should be a default behaviour.

[akhmadshin]

Hello, I was able to achieve optimistic navigation in next.js, I'm sure you can do it in Remix too. But to make it work I used a lot of hacks and tricks.

1. I skipped default data loading on soft navigation
2. All requests are going through tanstack-query (https://tanstack.com/query/v4/docs/framework/react/guides/ssr)
3. Known data goes to placeholdeData prop (https://tanstack.com/query/v4/docs/framework/react/guides/placeholder-query-data)

here's my website
https://akhmadshin.dev/

[alfredsgenkins]

Thanks for sharing! Indeed, we figured the same approach with SWR loader following this instruction: https://swr.vercel.app/docs/with-nextjs.en-US#pre-rendering-with-default-data

[akhmadshin]

Is it hard to skip data loading on soft navigation in remix? I was able to achieve it in next js only by monkey patching router. I made a library for it:
https://github.com/akhmadshin/next-optimistic-router

BTW, it's nice to meet another optimistic navigation enthusiast

[alfredsgenkins]

Well, it is not as hard, as for NextJS. It appears that the patch for fetch I posted in original discussion + defer in response are required on frontend. For BE we added custom logic (looking into request headers) to differentiate between BFF requests and initial loads.

I guess it is easier, compared to NextJS as "defer" essentially has all of the logic inside, we only had to skip TTFB waiting from server. I would love for Remix to add some flag do it automatically.

[akhmadshin]

glad to hear it! Maybe gonna try remix for next project