Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass component props as context for yup validation #503

Closed
berdyshev opened this issue Mar 9, 2018 · 19 comments
Closed

Pass component props as context for yup validation #503

berdyshev opened this issue Mar 9, 2018 · 19 comments
Labels

Comments

@berdyshev
Copy link
Contributor

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
Copy link

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

@berdyshev
Copy link
Contributor Author

berdyshev commented Mar 12, 2018

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

@dphaener
Copy link

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

@stale
Copy link

stale bot commented Aug 15, 2018

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 stale bot added the stale label Aug 15, 2018
@stale
Copy link

stale bot commented Aug 22, 2018

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

@stale stale bot closed this as completed Aug 22, 2018
@DaddyWarbucks
Copy link

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
Copy link

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
Copy link
Contributor

klis87 commented Feb 15, 2019

+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
Copy link

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
Copy link
Contributor

klis87 commented Feb 25, 2019

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
Copy link

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: #1508

I think the real solve for this is some documentation.

@klis87
Copy link
Contributor

klis87 commented Jun 1, 2019

@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
Copy link

DaddyWarbucks commented Jun 1, 2019

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
Copy link
Owner

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

@klis87
Copy link
Contributor

klis87 commented Jun 2, 2019

I understand your point. Adding this to docs would be indeed a good compromise 👍

@ldicocco
Copy link
Contributor

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

@ldicocco
Copy link
Contributor

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.

@jglesner
Copy link

jglesner commented Feb 16, 2021

In looking at the Formik validation documentation (https://formik.org/docs/guides/validation) it appears that props are only available to the validate function when using withFormik. However, I experimented with the construct that @DaddyWarbucks provided above <Formik validate={(values,props) => {}} > in the hopes that I could get access to props for passing context to yup. Unfortunately, props is undefined (using Formik v2.0.8). Is there a way to get access to props from within the Formik validate function without using withFormik?

@brookemahoney
Copy link

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

Yes, in other words, if you visit https://formik.org/docs/api/withFormik#validationschema-schema--props-props--schema , you'll see that the function version of validationSchema takes the component props as an argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.