Single-fetch typesafety: defineLoader and defineAction

[pcattori]

// turbo-stream for bare objects
let loader1 = () => ({a: 1})
useLoaderData<typeof loader1>(); // { a: number }

// Jsonify for `json`/`defer`
let loader2 = () => json({a: 1})
useLoaderData<typeof loader2> // JsonifyObject<{a: number}>

// typesafety for args and return type via `defineLoader`
let loader3 = defineLoader(({ request }) => {
  //                          ^? Request
  return {a: 1, b: () => 2}
  //            ^ `b` being a function causes a type error for `defineLoader`
})

See changeset for more detail

[changeset-bot]

🦋 Changeset detected

Latest commit: cdbea62

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@remix-run/cloudflare	Patch
@remix-run/deno	Patch
@remix-run/node	Patch
@remix-run/react	Patch
@remix-run/server-runtime	Patch
@remix-run/cloudflare-pages	Patch
@remix-run/cloudflare-workers	Patch
@remix-run/dev	Patch
@remix-run/architect	Patch
@remix-run/express	Patch
@remix-run/serve	Patch
@remix-run/testing	Patch
create-remix	Patch
remix	Patch
@remix-run/css-bundle	Patch
@remix-run/eslint-config	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brophdawg11]

Do we want to remove response from LoaderFunctionArgs and ActionFunctionArgs now too and let it come in via defineLoader/defineAction?

[brophdawg11]

Also - if you don't use defineLoader should we still be trying to infer single fetch types? Or are we saying the two are mutually exclusive?

• LoaderFunctionArgs -> JSON inference
• defineLoader -> turbo-stream inference

I don't know if I was expecting a Date to be inferred here anymore without opting into defineLoader?

export function loader({ request, response }: LoaderFunctionArgs) {
  return {
    string: "hello",
    date: new Date(),
  };
}

export default function Index() {
  const loaderData = useLoaderData<typeof loader>();
  console.log(loaderData.date.toISOString());
  //                     ^ Should this be typed as a date without the use of defineLoader?

  return (...);
}

[sergiodxa]

Is this type exported somewhere?

[sergiodxa]

Could URLSearchParams be added to this too? I remember someone reporting in Discord that they tried to return this and it failed.

[pcattori]

We're using Jacob's turbo-stream library under-the-hood so support for URLSearchParams would need to be added there.

[sergiodxa]

What if CustomType class has a toJSON? Couldn't the badData.toJSON() method be called and then return as a plain JSON? So you will not get a CustomType client-side but at least the data.

[pcattori]

The contract for single-fetch (and turbo-stream which is what it is using under-the-hood) is that a type T in becomes a type T out. So CustomType -> string is not supported. If you want you can manually call toJSON():

export let loader = () => {
  return { a: myCustomTypeInstance.toJSON() }
}

The point is to have less coercion and magic. Having the serialization be basically a glorified ID function is the thing that unlocks a bunch of the simplified types features. Plus it means we can support recursive types much better than the current approach.

[gustavopch]

@sergiodxa FIY, I raised the same question on Discord: https://discord.com/channels/770287896669978684/1233404747885576293/1233417203693523104

[brophdawg11]

Cross posting my response from discord as well for visibility

We're hesitant to add to much "custom" stuff like this to turbo-stream because it's a stopgap solution that will be replaced with the RSC wire streaming format once we land the RSC work. So the limitations of what can and can't be streamed are going to eventually be defined by React, not us

I.e., if we add toJson support now, folks will start relying on it. Then if we incorporate RSC and it doens't support toJSON, it would be a breaking change for your apps. So we're keeping this simpler now until we know in greater detail how the RSC story shakes out.

[pcattori]

@brophdawg11 looks like there are still a couple places in the codebase that rely on response in LoaderFunctionsArgs and ActionFunctionArgs, so left that in for now.

[pcattori]

Also - if you don't use defineLoader should we still be trying to infer single fetch types? Or are we saying the two are mutually exclusive?

Bare objects are always single-fetch serialized after you enabled single-fetch future flag + types, as intended: