Add other context data to the FormProvider

[sergiupop]

Hello :)

I have a form wrapped in a FormProvider component which takes the useForm methods as props. I would like to pass additional props to the Form context (for example, I would like to pass a FormId such that I can uniquely identify my current form and retrieve different information related to it), such that I can access them within each of my fields components, without having to pass this prop individually to each field. I didn't find a way to do this with the current API. Is there a reason why only useForm methods are allowed as props in the FormProvider component? Would it be a bad practice to have the FormProvider wrapped in a custom provider where I would pass my custom props? In this way I would have to retrieve the props from two different contexts: useFormContext and myCustomContext, which I don't find very attractive. Any other suggestion would be appreciated! Thanks

[mlnor27]

Hi! I'd love to know more about that. It could be really handy to leverage the form provider to pass any data down the tree.
@bluebill1049 Could you please clarify our ability to achieve this given what is provided? If this isn't supported, do you often read about those needs, and if that's the case, would you consider integrating this at some point, from your initiative or via contributions?

[ottovw]

Absolutely agree. this would be great feature!

My usecase: In some cases the form shouldn't be editable / view only and i would like to control this via the context.

[wowczarczyk]

@bluebill1049 this actually would be a nice feature to access the context you can pass to the useForm hook from the object returned by the useFormContext hook. That is not possible right now, right?

[Moshyfawn]

Having additional props on the FormProvider would get the context way out of scope of RHF.

You don't pass additional stuff into the MUI ThemeProvider as it has it's own theme context. Same goes for, say, the Recoil RecoilRoot.

Now, there's an argument to be able to pass additional information via the RHF FormProvider as, say, the Redux StoreProvider allows for a custom context. But it's a lot of overhead for RHF.

I don't think RHF will provide a custom context in the nearest future.

That said, @bluebill1049, if you want to look at the way Redux implements the custom context to potentially implement the fieldArray feature (#7544) and can think of anything else that might benefit this approach, might be worth considering.

[bluebill1049]

I agree with all the above. Also, type safety is another important aspect.

[wowczarczyk]

Sounds good, tbh I just wanted it to be used to pass the disabled state from the parent component that hosts RHF to some descendants but I can drill it or use some custom React context, no big deal. Thanks for your input!

[genshinw]

Sounds good, tbh I just wanted it to be used to pass the disabled state from the parent component that hosts RHF to some descendants but I can drill it or use some custom React context, no big deal. Thanks for your input!

I also want to pass the 'disable' state down ，how do you deal with it finally?

[wowczarczyk]

Drilling :)

[carlBgood]

Having additional props on the FormProvider would get the context way out of scope of RHF.

I don't know. As a form handler, a large aspect is form input construction. Pretty standard example:

A page component with a form. Using a custom hook - it loads useForm() with generic types passed via the custom hook. Returns methods and the submit handler - that allows the page component to to pass the methods to the FormProvider and enable the form to be built across multiple components. All we did here was put the useForm() call into a custom hook. Which makes sense when you want to add an API call to get initial data. So then we can pass that data on to the form. But here's where it gets helpful if useForm() simply accepted something like a contextData object to pass any sort of necessary data to the rest of the form components.

This would be extremely helpful in a simple example like this:

Let's say I'm building a permissions forms that uses an API loaded data object to construct the inputs. It's not technically "form data" in the sense that it's related to input values - but rather the inputs themselves. If we could pass this 'UI' related data to the useForm() hook, we could build components much easier. Instead of parking that data outside of RHF and using a state management library (because a hook won't suffice) for a simple thing as context (at which point adding another layer of context to the form)... we could simply pass the 'pageData' (usually what I call it) into RHF to utilize throughout our form construction.

As it is now. In the the custom hook, I have to call useForm(), my API (let's say a Tanstack Query), then parse out the pageData and use Zustand or Redux to manage that while RHF takes only the form values despite RHF managing my inputs as well - but requiring me to build them outside of RHF relevant context.

This is all to say I rely heavily on RHF - and absolutely love it. Hope this comes across much more as a much desired feature that would save countless amounts of time by just adding a variable to the FormProvider outside of the scope of the methods.