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

Allow setting initialTouched for a whole form. #129

Open
genu opened this issue Feb 10, 2025 · 3 comments
Open

Allow setting initialTouched for a whole form. #129

genu opened this issue Feb 10, 2025 · 3 comments
Labels
✨ enhancement New feature or request 🧠 think-tank Needs more discussion and opinions to iron out the fine details

Comments

@genu
Copy link
Contributor

genu commented Feb 10, 2025

Is your feature request related to a problem? Please describe.
Currently, initialTouched can only be set explicitly for fields. I'm wondering if we should expand the support to allow setting a whole form as touched.

I think we also want to allow a partial schema to be set for initialTouched. Currently the whole schema needs to be set as true/false if using initialTouched

Describe the solution you'd like

useForm({
  initialTouched: true // Sets all of the fields as touched
})

Describe alternatives you've considered
We have to explicitly set every field as touched right now.

@genu genu added the ✨ enhancement New feature or request label Feb 10, 2025
@logaretm
Copy link
Member

I don't mind this but the problem is now you are setting an expectation that any field will pop up in the form will be set to touched. So the main question is: "at what point should a field stop getting that initial touched state?" Think of repeater fields and conditional fields as well.

Maybe after mounted? but users could add fields after fetching the initial state as well, so I think unless we can address these questions and cases, we cannot go ahead with this.

What do you think?

@logaretm logaretm added the 🧠 think-tank Needs more discussion and opinions to iron out the fine details label Feb 11, 2025
@genu
Copy link
Contributor Author

genu commented Feb 12, 2025

hmm, thanks for the breakdown.

It is kind of tricky. I supposed an executive decision doesn't need to be made at this point. We can close this for now or leave open for further conversation and tracking.

@logaretm
Copy link
Member

logaretm commented Feb 13, 2025

Happy to keep it open, to clarify the "think tank" just means opinions are needed on how this should work.

For future discussions, I have thought of the following questions that we need to answer:

What is the timing scope for initialTouched

This is the question I asked earlier. Assuming the user sets the initial touched to true. The question is "when" should a field receive that initial touched. And more importantly, when it should not to.

We need to take the following into account:

  • Repeater fields that gets added, should these receive the initial touched?
  • Conditional fields that pop after mount or at some point in user journey. Should these receive the initial touched?

We can make a decision and say "no", but I'm curious to your expectations with these.

Why do you need to set the initial touched in first place?

I guess you can tell me more about your use-case. But the purpose of touched tells you that the user has interacted with that specific form control or form as a whole. Why (as a developer) do you need to alter the initial behavior?

I have been thinking about removing it all together actually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or request 🧠 think-tank Needs more discussion and opinions to iron out the fine details
Projects
None yet
Development

No branches or pull requests

2 participants