Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson

Already subscribed? Sign In


    Prevent Submitting Invalid Data from an Elm Form

    Enrico BuonannoEnrico Buonanno


    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson


    Instructor: 00:01 Now, let's see how we can use this approach in a real application to ensure that a form doesn't submit invalid data. The first thing to do is change our form and add the attribute noValidate, set to true. This will prevent the browser from performing any native validation.

    00:19 Now, let me go to main.elm file, and import the validation module, exposing all the functions. The most important thing I want to ensure is that the form doesn't submit invalid data. I'll go to the update function, where the the submit message is being handled.

    00:40 Rather than calling the submit function, I will call another function, saying submitIfValid. Let me implement this here. What I want to do here is run through the isEmail validator, and run model.message through the isNotEmpty validator.

    01:05 Then we'll have to ensure that both results are OK. I can do this with pattern matching. I can put these two into a tuple. If this is OK with a valid email, and OK with a valid message, then I'll return the model and submit.

    01:37 The model, and in all other cases, at least one of the results is an error. In this case, I'll return the model, and command none. Notice, however, that here, we want to put the status to in process, but of course, we only want to do this if the model is valid.

    01:57 Let me actually put this here, and here, we just return submitIsValid model. There's a slightly more elegant way to write the same. I could change the submit function to take the email and message separately.

    02:21 Here, this would be just email and message. Then I would use the result mapTo function. mapTo takes a binary function -- that's why I just refactored submit to take two arguments -- then the two arguments to the submit function, which are wrapped into a result.

    02:46 I could put this into a variable called submissionResult. Then let me switch the submission result. This would now be an OK wrapping a command, in which case, I return the tuple with the updated model and the command. The command goes here.

    03:21 Or an error, which I'm going to ignore, in which case we're not going to send a command. I'm missing some parentheses around my arguments here. Now, it compiles. Let me add some type annotations for clarity.

    03:40 Submit takes a string, the email, and a second string, the message, and returns a command of message. Here, when we pass model email to isEmail, what we get is a result of string string, which we wrap the email, assuming it's valid, in an OK.

    04:10 The submit function is plain, so to speak, but the arguments are wrapped in a result. What mapTo does, it will provide the arguments to the function, assuming that they are OK. The type of submission result is result string, command message.

    04:31 If any of these validations has failed, we will get the error here. If they are both OK, submit will be evaluated, and we will get the resulting command here. submitIfValid takes the model, and returns the usual tuple required of the update function, which has a potentially updated model and a command message.

    04:59 Let me test the application. If I click submit, nothing happens. If I say hello and hello, hello is not a valid email, of course. Nothing happens. If I say and hello, then my request is submitted.