Check out a free preview of the full Introduction to Elm, v2 course

The "Custom Types Solution" Lesson is part of the full, Introduction to Elm, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Richard live-codes the solution to the Custom Types exercise.


Transcript from the "Custom Types Solution" Lesson

>> Richard Feldman: So, here's our one and only TODO. When the user inputs a username, update it in the model. We'll look at how the email input below does this. Okay, so if we delete this, and we compare these two fields on the form. So we've got right here, Username, Email, and Password.

And each of these has a sort placeholder in there, so placeholder Username, placeholder Email, placeholder Password. And then they've got a value which corresponds to the form.username and, which Elm is gonna fill that in with whatever value is currently in the model. And then we see that email has onInput EnteredEmail, but the Username branch does not.

So we're gonna put something in there, onInput EnteredUsername. onInput by the way, so now that we're in solutions mode, I can actually explain what some of these things do. onInput essentially is an event that fires whenever the user types into a text box or, when they edit it in some other way.

For example, you can right-click and hit cut, you can right-click and hit paste. There are various ways other than typing on the keyboard that you can edit an input field. onInput is so named because the event name that actually gets broadcast from download is called input. It's like quote input, that's the name of the event.

This sometimes surprises people coming from React, because Raact calls this onChange. I think the reason they did that was that they didn't like the name onInput, but Elm went with what the browser went with. So it's called onInput because that's what the browser calls it. We didn't rename it to onChange.

There's a separate change event that only fires when it loses focus, but that's a separate event in Elm's terminology. So onInput is a very common thing that you end up using in practice for handling things like user input where you wanna handle keystrokes as well as,
>> Richard Feldman: When they edit, cut, and edit, paste and all that good stuff.

Okay, onInput is also a function which expects a function. So onClick wanted just a message, but onInput actually wants a string to message function. Because it's going to be sending you the string that the user is typing in, in other words, in JavaScript parlance. Now this right here is not going to compile.

If I go back over here into elm make and I run this again, it's gonna say NAMING ERROR, I cannot find EnteredUsername constructor. These names seem close though, EnteredEmail, Username, EnteredPassword. Well, that's helpful, but unfortunately, it's not that I mistyped it, it's just that, that thing does not exist.

So let's go make it exist. So if I go back up here in my Msg custom type, we have EnteredEmail which holds onto a string, we have EnteredPassword which holds onto a string. Just gonna go ahead and add another one for EnteredUsername. And once again, we want that to hold on to a string.

So this is sort of a, again, description of what happened, right? User entered an email, user entered a password, user entered a username, excellent. All right, so now we're done, right? No, what is this? Missing patterns, this case does not have branches for all possibilities. So it's got EnteredEmail, EnteredPassword, SubmittedForm, this is gonna be the case inspection on our update.

Missing possibilities include EnteredUsername. So we did add it to our message type, but we forgot to actually implement it. I would have to crash if I saw one of those. Add branches for them. Okay, fair enough, fair enough. All right, how do we add the branch for that?

Well, we've got some nice modeling here in the form of EnteredEmail and EnteredPassword. We can just basically copy and paste what we did that, and do the same thing because we want this fundamentally to work the same way. So we'll say EnteredUsername, give the string that's held in there, the name of username.

And then, we've got this updateForm helper function, I'm not gonna jump into the implementation of that, although it's not really doing a whole lot. Except to note that, we can just sort of look at the pattern of this code and say, okay, it takes a form and then it's doing a record update on that form to put whatever changed value we have into the form.

So it's just storing it. So form username = username, everything else is the same. Recompile, hey, success and let's see if it actually worked. So I'm going to register as rtfeldman. Email is This is not my real email address, don't send email there. Password is going to be blah blah.

I don't mind saying that out loud because this is my local server so it's not like anyone can hack me. And let's sign up and promptly get a server error. Unfortunately, as much as Elm can help with problems on the front-end, it still can't prevent things from breaking on the back-end.

But at least now we are able to successfully type something in here, type in the email, and have it successfully send the form to the server. Whereas before it was just always clearing that thing out.

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