Qwik: valiForm in formAction doesn't apply pipeline transformations about modular-forms HOT 9 OPEN

The "problem" is related to the fact that Modular Forms uses Valibot only for validation and does not consider the output. The background is that with transform it is possible to make more extensive changes to the data set and Modular Forms does not know how to handle this. For example, if the data type changes, Modular Forms could break.

More infos:

• #20
• #40

For now, you can use Modular Forms's transform feature to trim a string: https://modularforms.dev/qwik/guides/transform-inputs

from modular-forms.

Thank you! Yes I will give some thought to this. Maybe it can make sense to change Modular Forms or to develop a form library with a similar API than Modular Forms that is perfectly tailored to Valibot.

from modular-forms.

Thanks for pointing to the related issues.

I'll try to create a similar function as proposed in #20.

The problem with using modular Form's transform is that it is not the DX I'm looking for. I want to define all my schema in one place and use it throughout my application. Using the transform feature of modular form, I will basically be rewriting the same code twice.

from modular-forms.

But I wonder if adding const parsedValues = parse(requestSchema, values) in my action isn't just the best API I can use right now.

Yes, this is the best workaround at the moment.

from modular-forms.

How about changing the implementation a bit to support the inference of the output of zod/valibot for the SubmitHandler? Of course it would mean that the validate option of createForm would also have to change to take into account the result of the schema parser. This is something that in my opinion would seriously level up the type safety of the form handling.

You are doing an awesome work already! Thank you for trying your best to create the best form library possible.

from modular-forms.

I don't think Modular Form's current API is so far from Zod/Valibot that it necessitates a new form library. I think the underlying issue here is mainly server-side; since applying transformations at the form level could yield to unexpected/buggy behavior client-side.

Server-side

With server actions, I think it makes sense to always apply validation (as is currently the case) and transformations (as is not currently the case) to respect what the schema says.

In my schema, I have

  firstName: () =>
    string([
      toTrimmed(),
    ]),

But toTrimmed doesn't get applied in my formAction$ unless I use my own parsed values with const parsedValues = parse(requestSchema, values) as explained above.

I expected this to work out of the box by applying toTrimmed with valiForm$ as the second argument to formAction$. Without that transformation getting applied, I will have strings like "blablabla " (with many spaces) in my database, which is something I definitely want to avoid.

So in

export const useFormAction = formAction$<LoginForm>((values) => {
  // Runs on server
}, valiForm$(LoginSchema));

The second argument with valiForm$(LoginSchema) should apply transformations out of the box, and even transformations that change the data type shouldn't be of issue here (right?). valiForm$ might not be easy to modify due to client-side requirements (see below 👇), so perhaps we could introduce a new valiParse$ function?

Client-side

On the client, I think that it doesn't always make sense to apply transformations client side.

For example, a toTrimmed transformation could prevent the user from adding multiple spaces at once client-side, and therefore tell him that it can't be done. On the other hand, what would transform(number(), (amount) => amount * 100) mean? Every time the user enters a number, the transformation would add two zeros at the end of it? That wouldn't mean anything.

So I think for client-side transformations, it's best to use Field-level transformations as in https://modularforms.dev/qwik/guides/transform-inputs.

from modular-forms.

Yes. You are correct that the schema level transformations only make sense on onSubmit$ and on formAction$.

from modular-forms.

Thank you for the detailed feedback. I agree in principle and will give it some thought.

from modular-forms.

But I wonder if adding const parsedValues = parse(requestSchema, values) in my action isn't just the best API I can use right now.

from modular-forms.