Support other schema libraries through Standard Schema

[gabrielgrant]

This looks awesome! Would it be possible to support other schema libs? Or is it too closely coupled to the valibot implementation?

[rnza0u]

Yep, that would be very nice indeed.

It would also make it more stable in the long run, especially when validation libraries have breaking changes.

[fabian-hiller]

Yes, I can replace the Valibot-specific code with the Standard Schema interface for v1. I am a Standard Schema co-creator by the way. However, I must point out that Formisch initializes the form store (each state of the form is a signal) based on the schema structure, but Standard Schema does not provide this information because each schema library is implemented differently. Supporting multiple schema libraries would therefore require us to use adapters for each one, which would decrease DX. Please comment below to let me know which schema library you are interested in using with Formisch.

[LeCarbonator]

@fabian-hiller I'll gladly request a Zod adapter. However, I also got a question regarding the schemas:

Are there other benefits you see of focusing on valibot specifically instead of Standard Schema apart from the form's store?
Perhaps working with some of the features that valibot provides that other validation libraries don't? Or maybe playing into Valibot's types?

[fabian-hiller]

Right now no. But there might be benefits in the long run. For example, we could extract information from the schema to output HTML specific attributes like required automatically for better accessibility. Until the library is more popular it is probably not worth investing time into supporting Zod or other schema libraries as I should probably focus on providing docs and support for meta frameworks first.

[gabrielgrant]

Personally quite interested in usage with Arktype, but understand there are obviously more features that can be more easily provided by more closely integrating with one/a smaller number of validation/schema libs

[Khauri]

Since there's plans already to support StandardSchema, I think exposing an adapter API and leaving it up to the community to create adapters could be something to consider and isn't too much of a DX hit imo

import { createForm, Field, Form } from '@formisch/solid';
import {type} from 'arktype';
import formischAdapterArkType from 'formisch-adapter-arktype';

const LoginSchema = type({
  email: "string.email",
  password: "string >= 8",
});

export default function LoginPage() {
  const loginForm = createForm({
    schema: LoginSchema,
    adapter: formischAdapterArkType
  });
  // ...
}

[CamilleHbp]

I concur. This would also do a lot for the library in the long run. A lot of form libraries are tightly coupled with Frontend framework and validation libray. While totally understandable, if Formish supports the biggest frontend frameworks and validation libraries, it would increase adoption, IMO. 💪

[fabian-hiller]

Thank you for your feedback! If you want to use Formisch with a different schema library than Valibot, don't forget to give the top comment a thumb up. I will use the feedback here to decide whether to include this feature in Formisch v1 or a later version.

[frasza]

I would absolutely love to get support for this, since current solution we are using at work is falling behind but we still actively use Zod at the moment. Otherwise library looks fantastic, hope for this to land.

[sandros94]

For once, I'll be the one who goes against the grain.

Don't get me wrong, I love StandardSchemaV1. Not only I've helped integrating it in various aspects of the Nuxt/Nitro/h3 ecosystems but I also daily drive it in all projects and personal libraries.

I personally consider validation schemas the main source of truth for all forms. In todays world if you leave a public-facing form unattended, without data validation, it becomes a matter of time before you get targeted by bots. They will most likely try their best to inject SQL or any sort of known CVEs into your server side. So IMO any form must refer to their related validation schema, and I hope we all agree on this last part.

The missalignment I see between forms and validation schemas

I wont circle around it: the problem is that the DOM is string-based, while all validation logic is type-based.

Now, there are frameworks that try to mitigate this, but at some point they will inevitably hit HTMLInputElement where its event.target.value will inevitably be a string. For those frameworks that DO have an internal casting (you can read this comment and examples I left in another issue) we have someway to instruct a field that "hey, this is a number, output a number type" or an optional, or a nullish, or email, or whatever.

So a Transformation step is always required before validation, either done by the framework itself or additional tooling altogether. But in any case this transformation step must be guided/instructed, it doesn't know what we expect to receive in our validation schema. In the current situation every developer (or LLM that might assist them) has to write the form twice: one when defining the validation schema, v.number(), and the second when writing the related field, <input type="number">. Once these gets out of sync, this portion of the app breaks potentially creating a waterfall of errors.

But what does this have to do with StandardSchema?

There is no common language yet, no common patterns within the libraries to achieve the above. In fact, as I see it, not even valibot itself has all the required tooling. Ok yes, it does have getDefault to retrieve the default value for any particular field, but for example it doesn't have a getType to ask the validation schema what that field is about (is it a string? a number? an email?) and this is required (as @fabian-hiller mentioned above) to even just initialize the internal state, we haven't reached the validation nor submission steps yet.

Most of the time authors of form libraries usually are not authors/maintainers of the validation libraries and viceversa. @fabian-hiller not only is trying his best to achieve so, but also drafted, defined and released with @colinhacks and @ssalbdivad (sorry for the ping, but credit where credit is due) what we now call StandardSchemaV1, a common language for input, output, error and validation type interfaces between all validation libraries. But to achieve that they all had to already have the internal tooling, in their own different ways.

So, to me, I would firstly bridge that gap between valibot and forms, which is already a huge task since formisch aims to be framework agnostic. Then with its working methodology use it as the ground starting point for other validation libraries to start from, and then talk about StandardSchema integration. Much like it was done with StandardJSONSchema, maybe StandardFormSchema? 😏

Conclusion

I'm also convinced that once we have the tooling for bridging that gap, with proper state initialization and field props control, we could theoretically write the forms within our schemas directly and have them automatically render.

In valibot's terms imagine an API like:

import { formAction } from 'formisch/valibot'
import * as v from 'valibot'

const Schema = v.pipe(
  v.object({
    username: v.pipe(v.string(), v.trim(), v.nonEmpty(), v.minLength(4)),
    email: v.pipe(v.string(), v.email(), formAction({ class: 'text-blue' })),
    password: v.pipe(v.string(), v.minLength(8)),
  }),
  formAction({
    fields: {
      password: {
        component: 'PasswordComponent',
      }
    }
  })
);

Where formAction would use metadata under the hood, which in general is a common tool to all validation libraries. Then Formisch, when it receives this schema, it would just need to infer the core informations for each field, then look at the metadata for any potential overrides.

[fabian-hiller]

Thank you for your feedback! Could you provide more details about the formAction API?

[fabian-hiller]

@dosu what do you think about this issue? What is the right path going forward? Think hard!