To reset a form or to resetForm?
As Hamlet wonders himself in the famous play by William Shakespeare, I was found in a similar situation (not involving death or suicide) where I had to find a method to reset a form in Angular.
Reactive forms in Angular are very popular among developers because they are scalable, reusable and testable. As I come from an AngularJS background, I traditionally use template-driven forms which I am more comfortable with. Recently, I came across a use case where I had to reset the values of such a form dynamically. This blog post describes the problems faced and the findings discovered during the implementation of the solution.
Submit a form
A common scenario when you want to submit a form is to enable/disable the submit button according to the validation of form fields. As you can see below in the first form called Toggle submit, the button Submit is disabled until a value is entered in the Name field which is required. The state of the submit button is dictated from the validation result of form fields.
In my case, the approach was totally different. The Submit button was always enabled and did not depend on the result of field validation. Any validation errors were shown to the user after submitting the form, as you can see in the second form named Always submit.
Both approaches look good to me. Personally, I think that for new applications it is a matter of preference on how you implement form submission and for existing ones what experience you deliver to your users already. Suppose that all your forms follow the Toggle submit workflow, you should keep creating new ones with the same pattern.
For example at Plexscape, users of Plex.Earth are used to click the submit button straight away without caring about validations up front. So our web applications that complement Plex.Earth, follow the same principle.
In that way, you provide the same unique UX to your users across your whole application ecosystem.
Reset a form
Each form has also a Reset button that clears the field values when clicked. Let’s first try to submit and reset the first form and see what is going to happen.
Great! Everything works as expected. Now, let’s do the same with the second one.
Hmm….This does not seem right. The validation error message Name is required is still shown on the form even if we have reset the form.
Let’s try to demystify what is going on. We will start by inspecting the template of the two forms. If you take a look at the reset button of the first form, Toggle submit, you will notice that it calls a method resetForm() on the click event of the button.
Similarly the second form, Always submit, calls a methodreset().
Both methods are called on the heroForm object.
Documentation is your best friend
What are those methods? Why are there different methods for resetting a form? Which one should we use? When you start asking yourself such questions, it is time to check the official documentation at angular.io. If you don’t have any luck on finding what you are looking for, then start to dig through Angular source code.
I like to read the Angular source code anyway. It is still the best way to learn how things work internally!
Let’s head over to the official Angular documentation and check the API of the NgForm. We are looking for reset andresetForm methods.
Aha! There is a resetForm method. At this point, we can verify that the reset button of the second form should call this method because the appearance state of the validation message depends on the submitted state of the form.
We finally solved our problem but we did not find any reset method after all. That’s weird, let’s keep looking. Click on the View Source <> button and you will be redirected to the source code of the resetForm method.
Wait….Here is a reset method that is called internally from the resetForm. Interesting…But what is this.form? If you go further up in the variable declarations you will see that it is an object of typeFormGroup. If we go to the FormGroup API we will find the documentation of the reset method.
So resetForm is the same as reset but with the difference that affects thesubmitted state of the form.
Conclusion
One can tell that I should go for the resetForm approach from the start and not bother to use the reset method at all. That is a reasonable statement but I like to justify for the things that I use and alternatives that I can use. It feels better and makes me confident about what to use when.
Consider also the possibility that it may lead to confusion if you have to call a reset method from the component.
Hard to tell which method is which, isn’t it?. Intellisense shows the two methods on the same object, even if they refer to different types, NgForm and FormGroup. Why is that? Recall from official Angular documentation that
The top-level form in your component is
FormGroup
In this case, each component has one and only one form which implies that they are top-level forms.
That was it! Thanks very much for reading my article. I hope it sheds some light on when to use each of the reset form methods.
Have you experienced any similar situation? Which method do you prefer? Let me know on the comments below!
