Ember Octane Fundamentals

Handling Form Submit

Ember Octane Fundamentals

Check out a free preview of the full Ember Octane Fundamentals course

The "Handling Form Submit" Lesson is part of the full, Ember Octane Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Mike adds code to get the user id for the form submission, prevent the default behavior during the submit event, and log the user id. Mike then fields questions about event timing and adding custom global code.


Transcript from the "Handling Form Submit" Lesson

>> Mike North: So for now this seems like it should do, so I'm gonna to save that, and I'm gonna click this sign-in button. Let me go to my console here, click, all right, I'm in my debugger, so there's my DOM event. And if I look at the target, it is a form element, so looking good so far, so I could console.log something here.

>> Mike North: Let's actually do something with this, let's say I want the target.
>> Mike North: And because I use JSDoc comments, you can see that VS code knows that this is an HTMLFormElement.
>> Mike North: So that's the form element, and I want to querySelector to get the select, so that should be the currently selected user.

>> Mike North: And we'll try to console.log that out, and let's get rid of the debugger for now. Console, clear it, Sample McData, sign in, all right, let me change the setting here. I want to preserve the log, reload, clear it out, Sample McData, sign in. Okay, so here's what's happening, UserId is 2, so my console log succeeds.

Then I see this thing I'm used to seeing when my Ember app boots up. Anyone have an idea what's going on here?
>> Mike North: Can somebody tell me the default behavior when I submit a form?
>> Speaker 2: Bubbled.
>> Speaker 3: Postback?
>> Mike North: Sorry, what?
>> Speaker 3: The postback?
>> Mike North: I mean, it makes a get request.

>> Speaker 4: Refresh the page?
>> Mike North: Yeah, it results in the page reloading, in fact, I see Navigated to login? So it's similar to clicking on an a tag, a vanilla HTML link, it's causing a page load. That's the default behavior of a form submit event, we need to prevent this.

And the way to do this, this is just the way the DOM API works, preventDefault. We're saying, look, we're handing this submit event, don't handle this the way vanilla HTML submit events are handled. So if we reload this, clear the console, sign in, change the user, sign in, change it back, sign in, we can see that we're getting stuff logged out, yes?

>> Speaker 5: So native DOM events versus the action helper fire at different times? Action helper fires after all the native DOM, like onClick-type stuff, Next up, where does this sit?
>> Mike North: Yep, this is equivalent to addEventListener, and there are some subtle differences. I don't wanna get too deep into the weeds there, because it's DOM API errata, but it is equivalent.

The mechanism by which it operates is addEventListener, it's different than onClick equals action, which you're used to in classic Ember. You will not see the action helper or modifier used anywhere in this app, we're just using the on modifier. This is the path forward that will give us some benefits, particularly around things like rehydration, right?

>> Mike North: There are benefits, I'm not ready to get into it yet, I will look for an opportunity later on, yes?
>> Speaker 6: Say, Mike, do you think it could be a problem if you have to remember to put that preventDefault in every form-related component you make?
>> Mike North: Yep.
>> Speaker 6: You'd be putting that at the top level in some kind of initializer or something to say, at the body tag, just, by default, don't refresh the page when a form's submitted, or is that bad practice?

>> Mike North: It is possible to do that, I would say that it is a bad practice. Anytime you do something like that that has massive ramifications throughout your app, you're setting yourself up for potential unexpected behavior later on. There are community libraries that will give you helpers that you can use in this space here, which would let you kind of call this function, call onLoginFormSubmit, but also preventDefault.

So you'd kind of wrap that functions, so you'd see right in your template that in this specific case, this is prevented. I will give you that it might make sense, I can't really come up with a case where preventing default would be a bad thing for a form tag.

But in other places, it might totally be a bad thing, maybe file uploads or something. There's certain times when maybe you do need to do a true multipart form submit. But I definitely err on the side of doing these modifications at specific call sites. I want as little global customization as possible cuz then whoever contributes to your app, they have to familiarized themselves with all of the little tweaks and adjustments.

You sort of altered your world from what people expect it to be.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now