Two nested 'FormProvider', where the child wants to access the parent instance

[yamakeeeeeeeeen]

I want to use a different instance in the main screen and in the modal.
In that case, one of them needs to be passed by props, right?

A simple sample has been created.

https://codesandbox.io/s/react-hook-form-v6-form-context-forked-5y4l9?file=/src/Dialog.js

I want to click 'submit' in the dialog and get the value of the main screen.
However, since we are currently accessing the instance in the dialog, if we want to do that, we need to pass either of the instances in props.

[bluebill1049]

    <>
      <FormProvider {...methods}>
        <form onSubmit={handleSubmit((data) => console.log(data))}>
          <label>Main Screen Input</label>
          <input name="test" ref={register({ required: true })} />
          <label>Main Screen Child Input</label>
          <Test />

          <button onClick={() => setIsOpen(true)}>Dialog Open</button>
          <input type="submit" />
        </form>
      </FormProvider>
      <Dialog open={isOpen} setIsOpen={setIsOpen} />
    </>

is this a possible solution? instead burry two useForm inside of each others?

[bluebill1049]

not sure double nested context will work correctly, i don't think it's the intended usage for context API as well.

[yamakeeeeeeeeen]

@bluebill1049
I think you're right, it could be solved by moving the dialog up in the hierarchy.
I now realize that my component design was wrong.
Thank you for your answer.

[bluebill1049]

No worries 😉

[Steffi3rd]

I have a similar problematic with modal : #3704

But I don't want to access to the parent methods.

[david-morris]

I also have this use case a lot and it would be nice if it weren't relying on undefined behavior.

If you have forms which represent different views of the same type of information, you'll want any view-specific options to be in their own context.

If a user fills out a form and can do different things with that information, e.g. save a template of an order, there aren't good alternatives to nested forms.

As for just making those fields optional, well, then you have a lot of optional data you have to keep track of when you're submitting each type of form. Which, by the way, how are you going to handle their validation and dispatching the different use case's submit?

Of course you can write a bunch of code to do that, but then you have to maintain that code, and the type system isn't as helpful because your types are broader than they need to be, and you're annotating the types you imported from GraphQL and are violating DRY (by repeating lots of nested GraphQL input types with subtle tweaks).

Or is there something I'm missing?

[belaszalontai]

@bluebill1049 I understand that do not use nested FormProviders, but why? Is there a special issue coming from the implementation or from the nature of react? Or it is just not yet tested?

What is wrong with this simplified approach which works perfectly for me:

export interface InterfaceOne {		
  PropertyOfInterfaceOne: string;
}

export interface InterfaceTwo {		
  PropertyOfInterfaceTwo: string;
}

Parent Component:

const methods = useForm<InterfaceOne>();
const otherModuleMethods = useForm<InterfaceTwo>();

  return (
          <FormProvider {...methods}>
            <FormProvider {...otherModuleMethods}>
              <Component1 />
            </FormProvider>
          </FormProvider>
        );

Component1:

const { getValues, formState } = useFormContext<InterfaceOne>();
const { getValues: otherModuleGetValues, formState: otherModuleFormState } = useFormContext<InterfaceTwo>();

// using otherModuleGetValues and otherModuleFormState on Save

return ( <>
		<Controller name="PropertyOfInterfaceOne" .../>
		<Dialog>
			<OtherModuleComponentEmbedded />
		</Dialog>
		</>
		);

OtherModuleComponentEmbedded:

const { getValues, formState } = useFormContext<InterfaceTwo>();
return ( <>
		<Controller name="PropertyOfInterfaceTwo" />
		</>
		);

Unfortunatelly I have no other options because I have to nest (embed) a complex component coming from another module of the whole project.

Thank you for your answer in advance,

[caweidmann]

For anyone who needs nested FormProviders what I ended up doing is wrapping them in normal contexts, and for now it seems to work. Not sure if it's bad practise or not. Instead of relying on the useFormContext provided by react-hook-form you can create your own context and then listen to that instead. It can get complicated though to keep track of everything. See example below for a simplified version.

I would recommend to only pass those values through the custom context that are strictly required further down in a nested fashion or another FormProvider. In a sense we are duplicating logic...

// FormParentContext.tsx
import { createContext, useContext, useMemo } from 'react'
import { FormProvider, useForm } from 'react-hook-form'

const FormParentContext = createContext(null)

export const FormParentContextProvider = ({ children }) => {
  const methods = useForm({
    defaultValues: {
      firstName: '',
    },
  })
  const firstName = methods.watch('firstName')

  const value = useMemo(() => {
    return {
      firstName,
    }
  }, [firstName])

  return (
    <FormParentContext.Provider value={value}>
      <FormProvider {...methods}>
        {/**
         * firstName will be available in <FormOne /> via react-hook-form useFormContext()
         */}
        <FormOne />
      </FormProvider>

      {/**
       * firstName will be available in {children} via useFormParentContext() and a further FormProvider can be used within children
       */}
      {children}
    </FormParentContext.Provider>
  )
}

export const useFormParentContext = () => {
  const context = useContext(FormParentContext)
  if (!context) {
    throw new Error(`Please ensure to wrap your component in a "FormParentContextContextProvider"!`)
  }
  return context
}

[sKopheK]

@belaszalontai how would useFormContext know what context to read without providing any extra parameter?

[yhc-readonly]

Same question with @sKopheK 🤔