What would be the definition of a "registered" input

[Moshyfawn]

There're quite a few discussions now with questions on how to get the currently registered fields. Most recent are #7618 and #7620. It raised a couple of question for me:

• Why do you need to know whether or not the input has been registered?
• What "registered" input even is?
• Is there a pattern people don't know about that helps to get the functionality they are trying to achieve?

The "Why?"

I'd think the reason to get the registered input would be something to do with omitting the unregistered value from the submitted data, which can be achieved by providing the shouldUnregister: true prop to useForm hook options.
Is it something to do with disabling the field's validation? But the validation (whether it's the HTML validation attributed like required or the custom validation callback) won't run since the validation requirements are on the field that's unmounted. Having a top level form validation schema can also deal with the field being unmounted (aka disabled): it should factor in the ability to unmount the field that can be omitted by setting the value as optional.

The "What?"

I don't have a concrete understanding of what people mean by "registered" input. Is it that the form has the field input's ref? But some field (i.e. some UI lib component) don't even expose their ref. How do you understand what's registered then? Is that the input is uncontrolled and the register form method is used to.. "register" it? So, are you looking for the mounted components? If so, what doesn't work with approaches described in the "Why?" section.

The "What's missing?"

This question is both "Why?" and "What?" sections combined, I guess.. But I don't want to re-write and rearrange the whole structure of this question lol xD

[msageryd]

Edit:

The text in this post is not how I see it anymore. See comment below #7643 (comment)

I'll leave this post here anyway as a background. Maybe it helps someone else who is also on the wrong track regarding register.

---

I'll offer my take on this.

Decoupoling data/rules from UI

My goal when choosing a form library has been to decouple the "form engine" from the visual form. This goal is what led me to Final-Form, which has exactly this philosophy.

After realising that maintenance of FF is quite minimal, I looked around and found RHF, which seems to have almost the same philosopy.

To me, "register" a field, is the process to allocate storage for the field value at the backend (i.e. RHF). If I register fieldA I want to be able to set a value for this field even if it's not visible in the UI (i.e. no TextInput or alike is mounted). I'd expect all registered fields to be included in the submit dataset, even if some fields where never mounted in the UI.

Ideally, the registering should also include any validation rules and all the fields metadata. When time comes for mounting a field (for example on the next page in a wizard), it would be great to have all the metadata at hand, i.e. texts (captions, helptext), styles (icons, colors). This capability does not yet exist in RHF. Final-Form has this and It's great to be able to link any metadata to a registered field.

As of now I keep metadata in a separate structure which is keyed with the name of each field. This structure is available to the UI elements via context.

Why register fields that might not even be mounted?

I might have a very specific use case, but to me this is essential. My forms are organized in tree form. There is a main form, from which sub-forms can be opened. Registered fields can be rendered as input fields or preview fields (readonly) Here is a simple example:

Registered fields:

• moduleName (string)
• useDefaults (bool)
• modulePrice (number)

Main form shows:

• moduleName
• useDefaults

A subform "Pricing" can be opened, but does not need to be opened. I the user checks useDefaults, the modulePrice field will be populated automatically via cross field rules (I call these "conditions"). modulePrice could be shown as a preview field on the main form so the user can see the default value. If the subform isn't opened the modulePrice field will never be mounted, but it still holds essential data that needs to be collected at submit.

[bluebill1049]

To me, "register" a field, is the process to allocate storage for the field value at the backend (i.e. RHF). If I register fieldA I want to be able to set a value for this field even if it's not visible in the UI (i.e. no TextInput or alike is mounted). I'd expect all registered fields to be included in the submit dataset, even if some fields where never mounted in the UI.

you can include those none register values into the defautValues.

[bluebill1049]

I don't get why people want to know what's register as for form, you want the form produces as value. I may miss something in here.

[danielhammerl]

@bluebill1049 so i currently have a very specific reason for wanting to know which fields are registered currently:

I use react hook form in a larger app owned by a bigger company in the financial sector. We have a couple of forms, about 10 with varios of fields, all in all about 150 different fields currently (app is not finished yet, field number may raise to about 250 or so), partly with very heavy and complex logic. Some changes in some fields will result to changes in other fields, not all fields are always in the same formular ( as i said about 10 forms, only one is mounted and rendered at once ) so on changes we sometimes have to call setValue for changing the value in a fields, sometime when the fields are in another formular we toggle some hidden backend magic. Now the problem is that in our business case complete formulars can be there additionally to the main formular or not, meaning on every "a field should change another field" we have to check: is the other field rendered / registered currently? If yes, call set value, if no, do something other. Because everything is conditionally the simplest way for us would be to get the information from rhf, because the fields which are registered in rhf are the fields which we have to call setValue on, changes in other fields we have to make with something other.

I hope you understand our usecase.

Currently we are using this information by reading some data in control, but as docs are saying this is for internal use only so of course this is very unstable, and for us the use case would be so important that i / we would implement this feature by ourself if it would be ok

Edit: Because of the question "what are registered inputs", maybe im using the wrong term. For me a "registered" field is a field react hook form knows about and handles for me, and this by calling the register function

[bluebill1049]

I would recommend your guys implement this logic at your app-level for now, using the control objects could lead to issues later on and it's definitely not stable in that object. In fact, I think it's probably better to track that registered input at your app level, as it may give you additional control.

here is what i would do, you can have a wrapper function around register, trackedRegister(regsiter) in that higher function you can do your tracking and other business logic.

[danielhammerl]

thank you @bluebill1049 for your answer.

I also thought about that, but were also using Controllers for some third party components, so I would have to implement a higher component for the controller as well, also i would have to handle unregisters.

Seems like i would have to rebuild a lot of rhf logic than, was hoping for just getting a stable api for those keys

[hyungjunk]

For me, I found that a field that shouldn't be registered in the form was added to the submission data and wanted to find out what inputs are really registered. A component where unexpected input field included was rendered conditionally and it seemed fine before running a test code. I ended up adding more guard condition to render the component and now it works fine. ButI thought it might be helpful if that input field is actually registered or is a bug in test code. I guess some might wonder it for similar reason who are new to RHF like me.

[msageryd]

I might be biased coming from Final-Form. I saw the register function in RHF and was happy that it matched the concept I already was used to.

But it's always good to simplify stuff. Maybe I have overcomplivated this. I wil do some testing in a branch and see where it takes me.

As of now I do the following:

• register all fields from start
• generating validation functions to use with the registration
• generating condition check functions to go with my conditionWatcher (conditions are like cross field validations in my concept)

I will try the following instead:

• skip registration and just populate defaultValues with all my fields
• create validation functions upon mounting (I don't know how to connect the validations, though)
• handle my conditions within each onChange-handler

But I'm not sure how to do this:

• useController and Controller does not take validation as an argument. How do I connect my validation function to the field without using the register-function?
• can I use setValue() for setting a value of a field that is not registered or mounted?

[bluebill1049]

useController and Controller does not take validation as an argument. How do I connect my validation function to the field without using the register-function?

rules props?

can I use setValue() for setting a value of a field that is not registered or mounted?

yes, unregister to remove.

[msageryd]

Oh, sorry. I had missed that the rules object was equivalent to the options object on register
Thanks.

[msageryd]

Haha, that was easy.
I have removed my "pre-registration" and moved validator-creation to the inputComponent. Everything works as it should.

Thank you @bluebill1049 for leading me to a better path. I think two things drove me to the overcomplicated pre-registration concept.

1. The background for my ported code
2. The very name of the function. register seems like something you have to do.

@Moshyfawn I'll take it all back. My post above about registration is not how I see it anymore =)

[bluebill1049]

no worries. Awesome to hear things work out 👍