Formik: [Next] Validation guide

[Andreyco]

@jaredpalmer Would you mind removing yup internal wiring from package?

It is extremely easy to use any validation library. Instead, we should provide examples on wiring 3rd party libraries of choice with Formik.

I am down for this task if you approve.

TODO: validations guides

• [ ] jquense/yup
• [ ] poppinss/indicative
• [ ] tdegrunt/jsonschema
• [ ] remote (REST) validation

[jaredpalmer]

I am all for making the docs agnostic about validation in 0.9. Would like to see examples with Yup, jsonschema, ajv, lgtm, and validator.js

However, we use Yup at the Palmer Group and have yet to find anything better. So need to think about fully removing it. PS. (I am aware that we could just pass around the transform function or wrap Yup ourselves, but that's annoying 🤷‍♂️ IMHO ).

[Andreyco]

Understand all your concerns ;)

About annoying and repetitive part - I solve this by creating custom higher order component, which wires validation lib of my choice with Formik - approach very similar to Field component.

I am pretty confident if docs show this to users they won't complaint - or I hope, at least :)

Sidenote: Now, I use poppinss/indicative, since I am big fan of Laravel's validation API and indicative is inspired by this API.

[Andreyco]

Are you working on docs in unpublished branch? I cannot find any reference, but I am pretty sure I saw a screenshot of new docs page somewhere...

[jaredpalmer]

That was just some sketch mockups. This week @eanwhite and I are dogfooding 0.9. I’ll start writing the the docs probably the following week

[vladshcherbin]

+1 from me, I also use laravel-style validation library and a custom HOC form component to wire it with formik.

[Andreyco]

@jaredpalmer take whatever time you need to think about this. Please, let me know your opinion later then.

I am definitely down for writing validation integration docs no matter what the result is.

[jaredpalmer]

@Andreyco Just add a section (H2) in 0.9 readme anywhere called Validation:

## Validation

Intro (you can use your own validators). They can be promises or an object.

### Custom validation function

### Using 3rd-party validation libraries

You can use any validation library you want. You may or may not wish to transform the library's errors to `{ [field]: string }`.

#### 3rd-party lib 1

#### 3rd-party lib 2

#### 3rd-party lib 3

#### 3rd-party lib 4

[jaredpalmer]

@Andreyco

Running list (feel free to add):

• jquense/yup (obvi)
• poppinss/indicative
• tdegrunt/jsonschema

[Andreyco]

@jaredpalmer I believe, remote validation example could bring some value for users. Including it in docs.

[Andreyco]

Pushing updates this night

[scottluptowski]

However, we use Yup at the Palmer Group and have yet to find anything better. So need to think about fully removing it. PS. (I am aware that we could just pass around the transform function or wrap Yup ourselves, but that's annoying :man_shrugging: IMHO ).

@jaredpalmer In the interim, is there an appetite for a configuration option where Yup is the default implementation but others can provide their own validation functions?

This would preserve backwards compatibility by insuring that the default exports of Formik retain their existing behavior.

Something like

export default const withFormik = buildFormikComponent() // base options by default
export {
  buildFormikComponent
}

In this example, buildFormikComponent takes an options hash and returns withFormik.
One of the options available to buildFormikComponent would be providing an alternate implementation of runValidationSchema (or validateYupSchema). This would allow users to provide a validationSchema of any shape to their copy of withFormik and know it is run through the provided function

Thanks for your consideration 👍 😄

[carlosagsmendes]

@Andreyco are you currently using Indicative with Formik? If so, is it safe to move from Yup to Indicative? Thanks in advance