Typechecker Assisted Form Validation for Actions

[rwoll]

actions accept untrusted user input, so many actions follow this recipe:

1. get form data
2. run validation
3. use validated data

action code from jokes tutorial illustrating this pattern

export async function action({ request }: ActionArgs) {
  const userId = await requireUserId(request);
const formData = await request.formData();

const title = formData.get("title");

const body = formData.get("body");
if (typeof title !== "string" || title.length === 0) {

return json(

{ errors: { title: "Title is required", body: null } },

{ status: 400 }

);

}
if (typeof body !== "string" || body.length === 0) {

return json(

{ errors: { title: null, body: "Body is required" } },

{ status: 400 }

);

}
const note = await createNote({ title, body, userId });

Since this is a common pattern, it would be helpful to either:

1. Have a Remix convention/top-level exported function that Remix runs to perform runtime validation on the data before passing it along (I'm not sure what this API would look like—neither how one defines a validator nor the shape of the data (and metadata) that gets passed along). The idea would be to have one place to tell developers to do runtime validation, and then everyone else the compile time typechecks could be trusted as not lying
2. XOR Remix provides type utilities that can be optionally used with the action that ensures the user validates the data.

The second is inspired by some experimentation I was doing with Socket.IO types using Nominal Types to force the developer to call a context-specific runtime validation function.

In other words, it's a strategy to bridge compile-time and run-time typechecking. The typechecker knows where the untrusted data boundaries are, and demands you to call the appropriate validation function before you're able to use the data.

It might look something like this:

Replace:

export async function action({ request }: ActionArgs) {

with:

export async function action({ request }: ActionArgsWithFormDataValidation<typeof PostSchema>) {

this would then prevent you from directly accessing request.formData(), and would force you to pass the request through

const validated = validatedFormData(myPostSchemaValidator, request);

before using it like:

console.log(validated.title); // this not only typechecks/autocompletes, it also was runtime checked by the validation function

Below, you'll find a working prototype of such a type powered by zod as the validator. The internal implementation (sandwiched between the INTERNAL IMPLEMENTATION comments), is a bit fun (?) to follow (but not user-facing¹); however, I walk through it (in the context of Socket.IO) here building up from first-principles-ish to explain how the types are constructed to help us achieve the goal (and how they combine together).

After looking at the prototype below and the comments, it's important to note, the developer's steps are only:

1. define schema (e.g. PostSchema) with zod.
2. replace ActionArgs with ActionArgsWithFormDataValidation<typeof PostSchema>
3. call await validatedFormData(PostSchema, request);

and the way all the types are glued/constructed, PostSchema drives all the inferred types, so things cannot get out of sync and compile (since the typechecker will tell you where to sync things up).

Prototype

// INTERNAL IMPLEMENTATION DETAILS
// =======================================================
import z, { ZodType } from "zod";
type Untrusted<T> = T | { __brand: "UNTRUSTED" };
type UntrustedRequest<T> = Request | { __brand: "UNTRUSTED_REQUEST", __sub_brand: T }

function validate<T, Z extends T>(schema: z.Schema<Z>, data: Untrusted<T>): T {
  return schema.parse(data);
}

async function validatedFormData<T, Z extends T>(schema: z.Schema<Z>, request: UntrustedRequest<T>): Promise<T> {
  if (!(request instanceof Request)) {
    throw new Error("expected request object");
  }

  const untrusted: Untrusted<T> = Object.fromEntries((await request.formData()).entries()) as unknown as Untrusted<T>;
  return validate(schema, untrusted);
}

type ActionArgsWithFormDataValidation<T extends ZodType> = Omit<ActionArgs, "request"> & { request: UntrustedRequest<z.infer<T>> }
// =======================================================
// END INTERNAL IMPLEMENTATION DETAILS

const PostSchema = z.object({
  title: z.string().min(1),
  body: z.string().min(1),
});

const AnotherSchema = z.object({
  bar: z.number(),
});

function someNumReqThing(request: UntrustedRequest<number>) {}


export async function action({ request }: ActionArgsWithFormDataValidation<typeof PostSchema>) {
  const userId = await requireUserId(request as any); // ignore this for now :) 

  // We want this to give a compile-time error:
  const formData = await request.formData();
  // ⚠️ COMPILE-TIME ERROR:
  // Property 'formData' does not exist on type 'UntrustedRequest<{ title: string; body: string; }>'.
  //     Property 'formData' does not exist on type '{ __brand: "UNTRUSTED_REQUEST"; }'.


  // We want this to give a compile time error to so the compiler forces us to use the expected validation
  // function (e.g. one for PostSchema which is referenced in ActionArgsWithFormDataValidation<typeof PostSchema>), and not some other random Schema)
  const data = await validatedFormData(AnotherSchema, request);
  // ⚠️ COMPILE-TIME ERROR:
  // Argument of type 'ZodObject<{ bar: ZodNumber; }, "strip", ZodTypeAny, { bar: number; }, { bar: number; }>' is not assignable to parameter of type 'ZodType<{ title: string; body: string; }, ZodTypeDef, { title: string; body: string; }>'.
  //   Types of property '_type' are incompatible.
  //     Type '{ bar: number; }' is missing the following properties from type '{ title: string; body: string; }': title, body
  
  // 🎉🎉🎉😁😁😁 The typechecker essentially forced us to add this line AND the code is both compile-time and run-time correct here!
  const { title, body } = await validatedFormData(PostSchema, request); 

  // A request type derived from ActionArgsWithFormDataValidation<typeof PostSchema>, should not be compatible with just any
  // other request (e.g. UntrustedRequest<number>)
  someNumReqThing(request);
  // ⚠️ COMPILE-TIME ERROR:
  // Argument of type 'UntrustedRequest<{ title: string; body: string; }>' is not assignable to parameter of type 'UntrustedRequest<number>'.
  // Type '{ __brand: "UNTRUSTED_REQUEST"; __sub_brand: { title: string; body: string; }; }' is not assignable to type 'UntrustedRequest<number>'.
  //   Type '{ __brand: "UNTRUSTED_REQUEST"; __sub_brand: { title: string; body: string; }; }' is not assignable to type '{ __brand: "UNTRUSTED_REQUEST"; __sub_brand: number; }'.
  //     Types of property '__sub_brand' are incompatible.
  //       Type '{ title: string; body: string; }' is not assignable to type 'number'

  const note = await createNote({ title, body, userId });

  return redirect(`/notes/${note.id}`);
}

Additional Comments

• a similar utility type could be defined for dealing with JSON posted data
• the utility type can be cleaned up so request.url and other "safe" fields are accessible without any validation
• since this requires a validation function/lib to be useful, perhaps it is better as a third-party package

Related Links

• Made LoaderFunction, MetaFunction and ActionFunction generic #1254
• feat: add loader type inference #3276

cc: @colinhacks, @mattpocock, @ryanflorence since it looks like there's been lots of type-related discussion amongst y'all!

Footnotes

1. Except for the compiler errors which you can see samples of in the code snippet 🤮 ↩

[kiliman]

Although very interesting (and I also have a validation helper using zod remix-params-helper). I don't see this ever being part of the core. The nice thing about Remix is that it works like plumbing. It does the least amount needed to get your data from A to B, and for the most part stays out of your way.

There are just too many use cases that trying to be one-size-fits-all would be very complicated and probably impossible. Much better to let the developer choose the solution that fits their needs.

And although I agree that you should validate data on requests, forcing you to add validation would be a huge barrier to entry for somebody trying out Remix, or even just creating simple projects.

Anyway, just my 2c.

[rwoll]

To clarify, this is less about the validation function, and more about getting the types helping users do the safe thing.

Libraries/frameworks that have client and server code co-existing (at least in pre-compiled source like Remix and to an extent Socket.IO) make it hard for the developer to know where the "trusted" data boundaries are. Where and when do I, as a developer, need to call validation? Furthermore, the built-in types/autocomplete provide a false sense of confidence that data is validated in some places.

The docs allude to this (https://remix.run/docs/en/v1/tutorials/jokes#network-type-safety) but it's really easy to miss (or just forget about after some time), but I think it can be worthwhile to think: how can we get the typechecker tell us where we need to validate our data and where the trust boundaries are. It's more than just a validation function—it's a type that forces you to call a validation function.

The proposed ideas are less about the solution, and more meant to get the conversation going of: how can the framework (and its types) help the user write safer backends?