Using the debugger keyword to take a closer look at the submit event.
My previous post looked at using debugger to slow down time to better understand what is happening to live variables in our code. Now I’d like to take a closer look at how using debugger to expose information about events.
We can listen for events and execute JS code whenever one happens — this could be a click, submitting a form, or hovering a mouse over an element. If you need a refresher of events, here’s a great little app made by Will Bush that showcases some of the event listeners that can be used to trigger a change in the DOM.
This is a simple chore list app, where I can name chores and assign them to different members of my household! When they are done, they can be removed from the list.
When I create a new task, it should create a new entry in my backend: a JSON server API hosted locally.
I broke it
Somehow I broke my app! It won’t show me the tasks properly once I submit them. I can see a weird thing involving brackets instead.
Let’s see if we can get it working again.
I’ll place the debugger keyword in my code at the point where I click ‘Create New Task’, as this seems to be the place where I’m having an issue.
Here I have an event listener, attached to my form element (formEl) listening out for a ‘submit’ event. (When the user clicks on the ‘Create New Task’ button.)
When using a form to send information to the backend, it’s useful to use a ‘submit’ event listener so we have access to all the elements within the form.
I passed the event as a parameter to an anonymous function, which in turn is passed to the event listener.
As the default action of a submit event is to refresh a webpage, I’m calling preventDefault() on the event, so I don’t get a page refresh.
I want to take the values entered into the form, and send them to my backend as an object with the keys ‘text’ and ‘name’. The ‘text’ key will be populated by whatever the user types into the “Task Description” input and the ‘name’ will be populated by the “Who should do it?” input.
To trigger the debugger I click the button, which calls the event listener function, and the app pauses. While my page is paused in debugger, I can access the event in the console tab of Dev Tools, and see what kind of event it was, what the target of the event is, and if there are any other elements I can access the values of… It’s worth getting to know this event and explore what information you can use from it.
While my app is paused in debugger, I have access to the submit event. I can now explore the event by typing ‘event’ into the console. This will show me what kind of event was triggered, the target, and a whole bunch of other information.
Here I can see that typing event.target is returning the form element! If I open up the expandable menu, I can see the list of child elements the form has. This list is like an array and starts at 0. So if I type:
event.target<input required name="task" type="text" id="new-task-description" placeholder="description">event.target<input required name="person" type="text" id="task-doer" placeholder="who?">
I can access the inputs on the form!
While my app is paused in debugger, I also have access to any of the global variables I set in my local file. For example, as I have saved the form element into the variable formEl, I can type :
into the console to view the element. I have given each input of the form a name attribute, so I can also use that to access the input:
formEl.task // returns the first input<input required name="task" type="text" id="new-task-description" placeholder="description">formEl.person //returns the second input<input required name="person" type="text" id="task-doer" placeholder="who?">
Let’s have a quick look back at my source code:
I’m currently sending back this to my backend:
<input required name="task" type="text" id="new-task-description" placeholder="description">
Ahhhh! This is why my tasks were being rendered in such a weird way! I’m sending back whole HTML elements, which we don’t want being saved in our db.json file. I want to send back whatever has been typed into the form inputs. How do I access that?
In the console, I typed a full stop after the form element’s name attribute. This brings an autocorrect menu of all the attributes available to play with! You can access the parent element, the height, size… and here, I’m looking for value. This should return whatever has been typed into the input…
So that’s what was missing from my code! I’ll make the changes now…
I‘ll test the behaviour…
That looks right!
Hopefully, this has been a helpful demo of how you can use the debugger keyword in your code to pause your app and take a closer look into what is happening and how to use the event to access useful DOM elements and values. Give me a clap if you found this useful, and please comment below any questions or clarifications you need. Have you got any more debugger top tips?