Support for Standard Schema

[kaorun343]

https://github.com/standard-schema/standard-schema

Currently, zod and yup are only supported officially by conform.
If the Standard Schema is supported by conform, we can utilize the other validation libraries.

[chimame]

I was interested in supporting Standard Schema and looked into how to implement it. In conclusion, it's difficult to support.

First, I'll explain how Conform validates FormData as a prerequisite.

1. Convert FormData to an Object
2. Convert the Schema (e.g., Zod) defined by the developer into a Schema that can validate FormData
3. Validate the Object using the converted Schema

The rough processing order is as follows. The important thing is the "Schema conversion for validating FormData" in step 2. Since FormData values are all treated as strings, they need to be converted to the type specified by the developer, such as numeric or boolean.

Next, the data validation method for Standard Schema is as follows.

import type {StandardSchemaV1} from '@standard-schema/spec';
import * as z from 'zod';

export async function standardValidate<T extends StandardSchemaV1>(
  schema: T,
  input: StandardSchemaV1.InferInput<T>
): Promise<StandardSchemaV1.InferOutput<T>> {
  let result = schema['~standard'].validate(input);
  if (result instanceof Promise) result = await result;

  // if the `issues` field exists, the validation failed
  if (result.issues) {
    throw new Error(JSON.stringify(result.issues, null, 2));
  }

  return result.value;
}

const zodResult = await standardValidate(z.string(), 'hello');

As you can see from this code, the validation entity of Standard Schema is Zod, and Standard Schema is merely to standardize Schema validation and results.

The problem with this is that the "Schema conversion for validating FormData" process, which explains the process of validating Conform's FormData, requires support for each passed Schema library, even when using Standard Schema.
To support Standard Schema, the first problem is whether to support "Schema conversion for validating FormData" for all Schema libraries that Standard Schema supports, which is honestly unrealistic. Although many Schema libraries now support Standard Schema, supporting all of them on the Conform side is equivalent to supporting libraries other than Zod and yup.
Then, is it realistic to have the "Schema conversion for validating FormData" done by the developer themselves, rather than on the library side? Or, perhaps we could extract the current @conform-to/zod's "Schema conversion for validating FormData" as a low-level API so that it can be used. In that case, what would the API of the Standard Schema-compatible library look like?

import { useForm } from '@conform-to/react';
import { unstable_coerceFormValue as coerceFormValue } from '@conform-to/zod'; // new API
import { parseWithStandardSchema } from '@conform-to/standard-schema'; // new Library
import { z } from 'zod';

const schema = z.object({
  email: z.string(),
  password: z.string(),
});

function ExampleForm() {
  const [form, { email, password }] = useForm({
    onValidate({ formData }) {
      return parseWithStandardSchema(formData, {
        schema: coerceFormValue(schema),
      });
    },
  });

  // ...
}

If the code shown in the proposal does not provide coerceFormValue, or if it is a Schema library that does not provide it, the developer needs to implement a function like coerceFormValue themselves. Implementing coerceFormValue is very time-consuming.
If there is no "Schema conversion for validating FormData" like coerceFormValue, would you still want Standard Schema support? Even if you still request it, Standard Schema supports various Schemas. Is it common to use multiple Schema libraries in an application that uses Conform?

These questions have arisen, and I believe that support is difficult due to the difficulty of supporting Standard Schema and the demands of developers using Conform.

Of course, if you have any good ideas other than mine, please let me know. I would also like to consider implementation.

[aaronadamsCA]

What if, instead of just supporting the Standard Schema interface, Conform also went ahead and implemented the interface?

If you shipped a Conform schema builder, focused exclusively on the concepts specific to form data parsing and nothing else, I think you could eventually stop shipping any code specific to any one validation library, since you would no longer need to inspect or transform their schemas.

The specific syntax isn't what's important here, so don't get too caught up on it (though I did try to think ahead about smooth migration and granular error messaging).

import { createFormSchema } from "@conform-to/schema"; // new library
import * as v from "valibot";
import * as z from "zod";

// The form schema could be a Conform schema (instead of a Zod or Valibot schema)
const schema = createFormSchema((field) => ({
  // Coercion concerns could be isolated, so no more transforming schemas! 🎉
  number: field.number(),
  fieldset: field.object({
    checkbox: field.boolean(),
  }),

  // Each field could potentially default to optional, to align with HTML forms
  optionalField: field.text(),
  requiredField: field.text().required(),

  // You could eventually implement the full set of input types and constraints!
  range: field.range().min(0).max(100).step(5),

  // Each field could now use any Standard Schema validator
  url: field.text(z.url({ protocol: /^https$/ })),
  email: field
    .email()
    .required()
    .pipe(v.email("The email is badly formatted.")),

  // File fields could get the special treatment they deserve
  image: field.file({
    // Optional validator for the file upload
    input: z.file().mime("image/png").max(1_000_000),
    // Optional validator for the field value before/after the file upload
    output: z.object({ storageKey: z.string() }),
  }),
}));

// It would work just like a Zod schema
schema.parse(formData);

// But it would also be a Standard Schema!
schema["~standard"].validate(formData);

Presumably there wouldn't be any requirement to use this schema builder; Conform could accept any Standard Schema–compliant validator. But I think this could potentially improve the form-building experience enough to be worth it for most projects.

[edmundhung]

I agree that having a HTML-first schema library could simplify a lot of problems and make form handling feel more natural. In fact, I experimented with something like this in Conform's early design, but eventually removed it from the scope since maintaining a schema library is a huge effort on its own.

One of the biggest challenges is conditional validation. It is why our discussion in #1032 gets tricky, but it's something that's hard to get right even if we have full control over it. For example, Yup's APIs are designed around form validation and include many helpers for conditional logic, though that also makes it tricky to achieve the type safety people want. That complexity, along with the long-term maintenance cost, is why I have not pursued it further so far.

That said, this is definitely something I would love to revisit eventually. To make it happen sooner, I would need ideas and help from others who are also excited about exploring this direction.

[aaronadamsCA]

Yep, that all makes sense. That's why I figured a very narrowly focused schema library could potentially reduce long-term complexity, since you could more or less ignore the existence of conditional constructs.

• If a schema's form fields are static, it lends itself to much stronger types and introspection utilities.

• A schema within those constraints could potentially be composed with @remix-run/multipart-parser to parse and validate an entire form, one field at a time, while it streams to the server. 😮

• You could probably support piping a field, an object, or even the entire form to another schema library. The Conform schema would define the union of everything valid, like the implementation signature of an overloaded function; then the other library could parse and transform as needed, ideally without it being any of Conform's concern.

• The user could still build an entire form schema using other libraries, just like they do today; they'd just lose a few of the newer, nicer features.