parseBeforeSubmit on Field level

[ms88privat]

feature request

Would it be possible to have a parseBeforeSubmit prop on the Field? It should behave similar to parse but only runs before the form submit and can also handle async stuff. Maybe every field's parseBeforeSubmit would run in parallel before resolving to the final form onSubmit.

This would ensure a better decoupling between different types of input components and its parent form. At the moment the Form always has to know and handle some kind of special input components separately. For example if the Form includes a "Rich Text Editor Field" it can not parse & serialize its value on every keystroke, so we have to do it inside the forms onSubmit function. Another example would be a component which handles image uploads and transformations before submitting the page.

Let me know what you think, thanks!

[jgoux]

I was going to open an issue about it!

I'd like to be able to transform a value before it's passed to the Form's onSubmit function.

For example when dealing with inputs of type number, I'd like to be able to let the client side validation does its job and apply parseFloat just before submit, as Erik pointed out here

Another use case is that I'd like to include specific fields in my final values object, even if they are empty (currently they aren't included in values as they're undefined). Applying a transform like value => { if (value === undefined) { return null }} would solve this issue as well.

I can currently do all of this in onSubmit, but having a way to transform these values at the field level would be much more convenient as we can create custom fields like <NumberField name="count"/> that you can just drop into your Form and have the expected value coming in onSubmit.

[erikras]

Merci to @jgoux for the Twitter ping today. I still think that the answer is to just do it yourself in the submit function. This is not that popular of a request, and also, the beauty of our language is that we can compose functions as we desire. It would be easy, for example, to write a thing like:

<Form onSubmit={convertToFloat('price', 'margin')(actualOnSubmit)}>...</Form>

I need more convincing that this should be the responsibility of the form library.

[jgoux]

I think it's all about how smart you want your Field inputs to be.

In my example, if I have a design system with a lot of "smart" fields such a NumberField, ScanField, RatingField, I'd like to handle as much as I can in their implementation and just have to drop them within a Form and get my data ready to be submitted.

In your example, I'd have to apply your function in every single form where I'm using a NumberField, I think it's a missed opportunity for something more self-contained.

So having a way to hook into before/afterSubmit event at the field's value level makes a lot of sense to me. It's already available for validation purpose, why stop there?

[jonatankruszewski]

Hi!

I wanted to add a +1 for this feature.

This could be extremely helpful for currency inputs. We have a currency Input that manages the value as a string since we want to manipulate it in all kinds of ways. We use parse and format for it, and it works beautifully.

We don't use a number because we want to memoize when the user types a comma (or dot, depending on the language) but hasn't input a decimal yet.

But, at the end of the day, we would like to parse to a number before submission.

Parsing it at the handleSubmit function breaks the Single Responsibility Principle. Each field should manage itself, which has been done nicely in this library. It is a pity to have to handle that outside the field level.

As @jgoux said, having a way to hook into before/afterSubmit event at the field's value level makes a lot of sense to me too.

Thanks