Injecting form values/state to register({ validate }) callback functions

[Trollyal]

Would it be possible to inject current values/state (or both!) of form to validator functions, to make dynamic validations easier?

Let's assume we have form like this

interface Form {
  foo: string
  bar: string
}

and we only want the bar be required if foo is non-empty.

Right now it would go like this

const { register, watch } = useForm<Form>({
  defaultValues: {
    foo: '',
    bar: '',
  }
})

const fooValue = watch('foo')

<input  type="text" {...register('foo', { deps: ['bar'] }} />
<input  type="text" {...register('bar', {
  validate: {
    required: _ => !!fooValue
  }
} }) />

That works fine i guess, but it requires boilerplate and can only be done after the useForm hook has been initialized. I have made for our in-house use a utility that handles creating form and registering fields automatically from config, but in that config has no idea about watch etc. since it's initialized before the useForm.

What if we could do something like this:

<input  type="text" {...register('bar', {
  validate: {
    required: (value, formValues) => !!formValues.foo
  }
} }) />

It would improve the UX, remove the need of having to watch the values and it could be accessed from anywhere.
Is something like this possible?

[Moshyfawn]

Take a look at #8065. I believe, it's the same type of usage question.

I don't think RHF will provide formValues and formState to the validation callbacks at this time.

[Trollyal]

This unfortunately does not meet the condition I'm working with. I might need to make another abstraction on the registrations, where i would provide the values to a callback function which would produce serialized validate object with properties.

Thank you anyway! :)

[Moshyfawn]

I've created a very crude CSB due to my lack of time (broken / any types and some JS weirdness, sry). I kinda made it work with not some much friction from RHF. I'm very interested to get the user feedback on the topic, as it might be a part of RHF to potentially improve upon.

So, if you have a spare moment, could you look into the example and, maybe, tweak it to match your use-case better.