Possible defer bug: server-side data not serialized, not a drop-in replacement for json as implied by docs

[G-Rath]

I have effectively the following:

import { json } from '@remix-run/node';
import { useLoaderData } from '@remix-run/react';
import { DateTime } from 'luxon';
import { setTimeout } from 'node:timers/promises';
import React from 'react';

// this is actually a db query
const getReport = async () => {
  return Promise.resolve({ name: 'my report', createdAt: new Date() });
};

// this is actually a set of external API requests, based on the report
const countReportHours = async report => {
  return setTimeout(3000, 5);
};

export const loader = async () => {
  const report = await getReport();
  const hours = await countReportHours(report);

  return json({ report, hours });
};

const Index = (): React.ReactElement => {
  const { report, hours } = useLoaderData<typeof loader>();

  const createdAt = DateTime.fromISO(report.createdAt);

  return (
    <div>
      <h1>{report.name}</h1>
      <p>
        Created{' '}
        <abbr
          title={createdAt.toLocaleString({
            dateStyle: 'long',
            timeStyle: 'long',
            hour12: true
          })}
        >
          {createdAt.toRelative()}
        </abbr>
      </p>
      <p>Hours to date: {hours}</p>
    </div>
  );
};

export default Index;

Because determining the count of hours for a report can take more than a few seconds, I figured I would show a bit of UI so people knew the app was actually loading - based on the docs I expected I could just safely replace json with defer:

import { defer } from '@remix-run/node';
import { Await, useLoaderData } from '@remix-run/react';
import { DateTime } from 'luxon';
import { setTimeout } from 'node:timers/promises';
import React, { Suspense } from 'react';

// this is actually a db query
const getReport = async () => {
  return Promise.resolve({ name: 'my report', createdAt: new Date() });
};

// this is actually a set of external API requests, based on the report
const countReportHours = async report => {
  return setTimeout(3000, 5);
};

export const loader = async () => {
  const report = await getReport();
  const hoursPromise = countReportHours(report);

  return defer({ report, hoursPromise });
};

const Index = (): React.ReactElement => {
  const { report, hoursPromise } = useLoaderData<typeof loader>();

  const createdAt = DateTime.fromISO(report.createdAt);

  return (
    <div>
      <h1>{report.name}</h1>
      <p>
        Created{' '}
        <abbr
          title={createdAt.toLocaleString({
            dateStyle: 'long',
            timeStyle: 'long',
            hour12: true
          })}
        >
          {createdAt.toRelative()}
        </abbr>
      </p>
      <Suspense>
        <Await resolve={hoursPromise}>
          {hours => <p>Hours to date: {hours}</p>}
        </Await>
      </Suspense>
    </div>
  );
};

export default Index;

Except it seems there is a difference when the initial server-side render is done: with json the data is always serialized so report.createdAt is an ISO string both server and client side, but with defer it remains an instance of Date server side and thus Luxon explodes due to expecting an ISO string to parse.

I feel like this is probably a bug but wouldn't be surprised if it's not via "we can't always assume this should be JSON, that's the point of the json helper, etc"; if it isn't a bug then I think this should be made clear in the documentation along with how to properly handle this - currently it seems that maybe I need to manually do JSON.stringify + JSON.parse which seems pretty annoying...

What's scarier (and is a bug if there isn't a bug in defer) is that the types don't convey this - TypeScript always expects that the data has been serialized regardless of using defer or json.

[G-Rath]

Ok so after trying to work around this in the meantime by doing a typeof created === 'string' ? ... : ..., I'm still getting errors from Luxon but it seems to be happening client side so rendering does succeed.

I've tried to replace that in my example with a custom class with a toJSON:

class Mx {
  public toJSON() {
    return { name: 'world' };
  }
}

// report is now `{ name: 'my report', subject: new Mx() }`, and we show `<p>Subject: {report.subject.name}</p>`

That produces a huge number of React hydration errors and then Remix throws a timeout error even though its successfully rendered the initial page; I assume this is because when rendering server-side report.subject.name resolves to undefined since it has not been serialized and something in the stack is handling this very poorly so very scary "whole app crash" errors are shown - I can fix this by adding a getter for name in addition to toJSON which ensures name can be accessed in both server and client side rendering.

I'm happy to accept part of this is because I've just assumed too much about e.g. <Suspense> and so am not realizing there's some caveat like it needs to be the root of your tree or something, but even if that's the case I still think there's some improvement to be had to the streaming docs