Formik: Pass component props as context for yup validation

[berdyshev]

Feature

Yup validation can accept the context which can be used for validation purposes, but which is not a part of schema/values. Can we pass props as context?

Current Behavior

I see that validateYupSchema can accept context argument but it's not used anywhere.

Desired Behavior

Be able to use component's props and validation rules.

Suggested Solutions

Add component's props as context for validateYupSchema()

[latviancoder]

This seems similar to #506. Does my answer there help?

[berdyshev]

yes, it could help, but it seems more like workaround, than a solution

[dphaener]

@latviancoder We are running into the same issue, and while #506 certainly provides a workaround, would be nice to have this feature.

[stale[bot]]

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

[stale[bot]]

ProBot automatically closed this due to inactivity. Holler if this is a mistake, and we'll re-open it.

[DaddyWarbucks]

Rather than passing the whole set of component props, it seems simple enough to add another prop validationContext that would ultimately be passed to the yup context options. I know this was closed automatically. But, would you be open to a PR that adds another prop validationContext?

[dmlukichev]

Need this one too.
Although solution from #506 works, it doesn't look clean enough.
Ready to create a PR if agree on syntax (validationContext as @DaddyWarbucks lgtm).

[klis87]

+1 to this, I also really need it, sometimes yup schemas need some external information which isn't part of schema, for example I need an object in when clause to conditionally modify schema based on this object.

One interesting thing, it seeems that this feature is already partially implemented https://github.com/jaredpalmer/formik/blob/master/src/Formik.tsx#L694 , but for some reason context isn't passed at all https://github.com/jaredpalmer/formik/blob/master/src/Formik.tsx#L253

[jordan-jarolim]

First of all, thank you for amazing library :) I think this should be reopened since there is still no nice && clean way how to provide context to yup validation. @jaredpalmer

[klis87]

I will add, that for now I mitigated this issue by passing schema creator to validationSchema, sth like
validationSchema={() => createSchema(context)}, but of course recreating schema especially a big one for every render is not good for performance, and thats why we have yup context

[DaddyWarbucks]

My PR was closed for a fix to this issue for some valid reasons. Although Formik is somewhat "inspired" by Yup, the two aren't married. There are no props that are "just for Yup's sake". You can pass a Yup schema, or any other schema with a .validate(values) method. Those _other_ schemas however may not accept a second argument options.context. This means something like validationContext would be a prop "just for Yup's sake".

Similar to @klis87 solution above and another referenced here I think a good solution is to just use React composability to solve this

import { Formik, yupToFormErrors } from 'formik';

export default props => {
  return (
    <Formik
      validate={(values, props) => {
        return props.validationSchema
          .validate(values, { abortEarly: false, context: props.context })
          .catch(err => {
            throw yupToFormErrors(err);
          });
      }}
      {...props}
    />
  );
};

See comments on PR for some more info: https://github.com/jaredpalmer/formik/pull/1508

I think the real solve for this is some documentation.

[klis87]

@DaddyWarbucks thx for this example. I really regret though that your PR was rejected. In my opinion Formik and Yup ARE married, so let's not cause them divorced, Formik without yup would be different library and personally I wouldn't use it standalone. Some arguments:
a) Yup is even recommended in Formik get started- https://jaredpalmer.com/formik/docs/overview#complementary-packages
b) validationSchema imho is bound to yup anyway, give me at least one popular library which has the same interface which would work with Formik out of the box
c) one extra context prop won't hurt really, and it could be also potentially used for other custom schemas
d) if yup usage is recommended together with formik, yup context should be supported, let's not pretend that you could integrate any validation library to work with Formik, yup integration isn't abstracted to this extend anyway, so either support it fully or abstract validators to a flexible API so that we could have external plugins like formik-yup
e) we can do this with my solution by recreating schema on render, or by @DaddyWarbucks wrapper, but we really do not use libraries to write wrappers around it requiring knowledge about their internals, you could just as easily fork it and do whatever you want instead, come on, this is just one extra prop we are asking

[DaddyWarbucks]

I don't disagree. I do think that context should be supported OTB. But, I have recently gotten more into OS (making PR's like this one) as well as have been maintaining some large personal/professional projects myself and I can truly appreciate not wanting to extend an API when there is already a pretty decent solution. Maintainers should be judicious of what makes it into their library, because ultimately they are responsible for it and not the person that wrote a certain PR (myself in this case). I get it...what happens when my PR breaks the whole library because I missed something because I am writing it in my free time just for fun (and general good of the community, but fun too) and then some Fortune 500 company using the library loses millions of dollars.

I realized after writing my PR and seeing some more work/comments on the subject this

I rarely use the rest of Formik's components directly from Formik itself. I almost always create my own <Input /> component that builds on top of <Field /> with my classes, logic, etc. So why not do the same for the <Formik /> component itself. Just solve it with simple React."

IMHO, we do often use libraries to write our own wrappers around things though. A good library gets you 80% of the way there and leaves you enough "escape hatches" to form it into your exact needs (like a validate method and exposed yupToFormErrors). If there were some docs "Advanced Yup" that outlines this solution and we call came across that first, we probably wouldn't care that its not "out of the box". We would look and say, "Ohhh what nice composability this library has". We do this everyday with React components.

With that said, some docs are much easier to maintain and are less risky. I am willing to bet we could get a PR moved through for that. I may attempt that this afternoon and will reference this comment.

[jaredpalmer]

The function version of validationSchema is there for a reason. I think adding some docs around advanced Yup usage is a great idea

[klis87]

I understand your point. Adding this to docs would be indeed a good compromise :+1:

[ldicocco]

I have done a PR with an implementation of this for v2

[ldicocco]

As the addition of a schema.validateAt for field level validation makes the previous workaround for passing the validation context no longer equivalent to full validation context, I think that an explicit validation context solution is now an improvement.