Using .addEventListener with Forms: ‘Submit’ vs. ‘Click’ Event Listener

Why we should use the default method created for manipulating form data, the ‘Submit’ event listener.

At this point you may have some fundamental understanding of the functionality of the .addEventListener method within Javascript. If not, I would recommend starting with another reading. (Try this!)

When we attempt to manipulate the user data that is input into a form, we are looking to capture that data at a particular “event” and then use it in some fashion, maybe a simple console.log(data); or something more involved like a function adding that data to a database. At either level, our javascript script listens for the declared event to happen and, when it does, returns the result of your desired manipulation.

Using the ‘Click’ Event Listener:

This is an event listener that listens for a user mouse click event to trigger a callback function. This is a great functionality for individual buttons throughout your HTML but it is a less than ideal listener for our forms.

Let’s build out a ‘click’ event listener and see why it is not the optimal choice for use with forms.

Click Event Listener on a HTML Form Element

This ‘click’ function is attached to a form element (assigned to the constant variable of ‘newRamenForm’) to submit a new ramen item to a menu bar on the user-facing page. This click functionality is attached to an API POST request, hence the creation of a new object with the input values (let’s not worry about that part for this reading).

By implementing the ‘click’ event listener on the form, the main problem arises when we try to enter any data or ‘click’ any area within the form structure. The event listener records the click and immediately runs all of the code following, causing errors or incomplete POST requests to occur (see below).

POST Errors since the Event Listener Runs the POST Request Immediately

This is not good, and is the wrong functionality for our form! What should we use? You guessed it, the ‘submit’ event listener.

Using the “Submit” Event Listener:

When building the functionality of a form through Javascript, the code itself provides a fantastic way to hear what is submitted through our form. Quite literally, the ‘submit’ event listener!

The event listener is built in the same manner, attaching to the HTML form element (or declared variable holding the form element).

Above we see that we are passing the ‘submit’ event into our listener instead of the ‘click’ event from earlier. This event specifically listens for when the input element with ‘type= ‘submit’ ’ is used within the form (it is attached to the built in form ‘button’). Rather than running the code block withing the event listener on each click , we are able to click through our entire form to enter our data fields. We are not immediately running the event listener functionality, phew!

Let’s fill out our form and see what happens when we click the input field, our ‘button’, to submit our information.

The ‘Create’ area is our Input ‘Button’

Oh no! Our page fully refreshes. Why is that happening?

Well, forms were designed to take input data and send it off to the corresponding server. It then refreshes the page and makes the form ready to receive more information. Convenient if that is the only functionality needed but we need the user to input all of their information and update the HTML and server.

How can we preven this? We do so with the first item within the listener: event.preventDefault( ).

use a variable within your listener (‘e’) and call the preventDefault method on the same variable

With this method in place, we are effectively telling the submit listener to stop before it refreshes the entire page. ‘Do not perform your default functionality, instead do this: (whatever follows)’. From here, we can build out our full form functionality to work however desired for the page. All of the code within that code block will then run when that submit is triggered on the form. It actually works!

Conclusion

From this comparison, it should be clear that utilizing the specially designed event listener for your forms is the most effective, and likely most common, option for you to use. Could you write all of the extra code necessarily to singularly target your event listener to a particular button and manipulate the form data? Sure, I guess if you have all of that time and nothing better to do.

In terms of speed, ease, and overall functionality, the ‘Submit’ event listener is the ideal listener for form data manipulation and should become your standard practice when building forms. Try it out for yourself and see how much more productive you can be when you utilize the right listeners for the right HTML elements.