Should Deferred data aborted errors have to be caught by our application when navigating between pages?

[freshollie]

Until upgrading to remix v2 we were noticing stack traces from sentry like this:

Error: Deferred data aborted
  at AbortSignal.a(/build/_shared/chunk-2CU7I464.js:2:12460)
  at AbortSignal.r(/build/_shared/chunk-RP4EADUA.js:16:30463)
  at mt.cancel(/build/_shared/chunk-2CU7I464.js:2:13866)
  at ? (/build/_shared/chunk-2CU7I464.js:1:22831)
  at Map.forEach(<anonymous>)
...

(Ignore the missing source map but you get the gist)

In remix v2 these errors are actually shown in the app (good) so it means we were actually able to catch why they were occurring and the solution:

It seems that using defer(...) and then the <Await /> component actually requires that the promise returned from useLoaderData is wrapped in something to prevent the abort error from becoming uncaught

 const { data } = useLoaderData<typeof loader>();
  
 return (
   <Suspense fallback={<LoadingPage />}>
     <Await resolve={catchDeferredAbort(data)}>
       {(resolveData) => {
         if (!resolveData) {
           return <NotFoundPage />;
         }
         return <Details data={resolveData} />;
       }}
     </Await>
   </Suspense>
 );

With my function catchDeferredAbort being

const catchDeferredAbort = <T,>(p: Promise<T>) =>
p.catch((e) => {
  if (e instanceof Error) {
    if (e.message !== "Deferred data aborted") {
      throw e;
    }
  }
  return new Promise<T>(() => {});
});

My question is: Is this really desired behaviour? If a user is navigating away from a page with a deferred loader, do we really ever want to catch and show something else in place of the deferred data when the page is about to unmount? I guess why is this not caught internally within remix and ignored?

[arpitdalal]

Using catchDeferredAbort does work but it breaks useFetcher with a key.

Here's a quick demo of this issue. with catchDeferredAbort link uses this function to catch deferred abort but no catchDeferredAbort link doesn't use this function. Both of them use useFetcher with a key to show an optimistic update to the user. no catchDeferredAbort page looks okay and works as expected but with catchDeferredAbort doesn't show that optimistic update and doesn't even log the fetcher.formData.get("title") in browser console.

I know this is a temporary workaround but just want to put this out that using this function will break useFetcher if you're using it with a key.
P.S. I spent this morning debugging why optimistic updates weren't working as expected after catchDeferredAbort was added.

[freshollie]

Ok good to know. For our use case I’ve not noticed the useFetcher issue as we don’t use that here.

Sort of shows that potentially this should be something handled internally.

[oswaldoacauan]

@arpitdalal does this break useFetcher for any component in the <Await> tree?

[arpitdalal]

@arpitdalal does this break useFetcher for any component in the <Await> tree?

Never tried it. But this also breaks loading indications with useNavigation

[oswaldoacauan]

For anyone that ends-up on this thread, we fixed with a different trade-off, instead of catching the error and ignoring it, we decided to just show our Skeleton component using the errorElement prop from the <Await> component, this will not have the other issues with useFetcher and useNavigation as mentioned by previous comment but it will swallow errors if your promise fails for w/e reason.

<Suspense fallback={<Skeleton />}>
  {/* 
    HACK: When navigating between pages while data is loading we get a "Deferred Data Aborted" error, 
    we don't need to handle this error, so we just use the skeleton component to ignore the error
  */}
  <Await resolve={promiseFromLoader} errorElement={<Skeleton />}>