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

yup.ref(...).transform is not a function #423

Closed
iamvanja opened this issue Jan 14, 2019 · 8 comments
Closed

yup.ref(...).transform is not a function #423

iamvanja opened this issue Jan 14, 2019 · 8 comments

Comments

@iamvanja
Copy link

Trying to create a computed field that depends on another one. Something like:

...
  originalField: yup.array().default([]),
  computedField: yup.ref('originalField')
    .transform(function (currentValue, originalValue) {
      let value = currentValue || originalValue

      // do some transformation here

      return value
    }),
...

Is .ref not designed for something like this? If not, is there anything else I could try?
I would like to keep this logic on a schema level if possible.

Thanks!

@jquense
Copy link
Owner

jquense commented Jan 14, 2019

yes that's right, a Ref isn't a schema, its only proxy value. In not sure exactly want you want to do but you can resolve a ref value in a transform:

yup.array().transform(function () {
  const otherValue = this.resolve('otherField')
})

@iamvanja
Copy link
Author

That's perfect! Thanks :)

@iamvanja
Copy link
Author

It looks like computedField will run transform only when computedField's value is provided. Otherwise it will return what is defined through default. Which makes sense, but does not work quite work with my idea of an "imaginary field".
Thanks for the lightning fast response nonetheless :)

@iamvanja
Copy link
Author

This can be closed.

@vonagam
Copy link
Contributor

vonagam commented Feb 5, 2019

For future readers. Right now reference documentation is wrong and second argument for ref is actually not an options object, but mapFn which maps value from referenced to resolved one. Example:

yup.object({
  x: yup.ref('y', (a) => a + 1),
}).cast({
  y: 3,
}); // => {y: 3, x: 4}

@jquense
Copy link
Owner

jquense commented Feb 5, 2019

I HAVE NO IDEA WHEN I ADDED THAT AND DON'T REMEMBER WHY :P

@vonagam
Copy link
Contributor

vonagam commented Feb 5, 2019

Well, you might have the same need as the opener of this issue.

A valid need.

Unlike contextPrefix option, which is not used by anyone (since nobody asked why it isn't working) and complicates things a bit, since you will not be able to simply use reference.key as unique id (like here), because $ref and @ref might point to the same object if second one uses @ as contextPrefix, but will have different keys (so blacklist/whitelist might not work properly).

@jquense
Copy link
Owner

jquense commented Feb 5, 2019

Yeah there a few crufty things originally added I think to match joi, but they aren't used and we aren't really trying to match joi anymore. I'm glad for the second pair of eyes on the old code 👍

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

No branches or pull requests

3 participants