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


    Validate Errors onBlur in an Elm Form

    Enrico BuonannoEnrico Buonanno

    It's poor user experience to only be told if an input is invalid after the form gets submitted. However, it is also best to let the user finish his input before validation occurs.

    Thus, in this lesson, we'll learn how to validate user inputs onBlur



    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 Generally, I think it's nice to validate on blur as well, so when the user leaves a field, consider this example. Here, I type an email. Then I type hello, which is not a valid password, but now I didn't get any feedback that it's not a valid password.

    00:18 I'm going to type hello again. Then, when I submit, only then do I get feedback that that password is not good enough. Then I have to go back and change it and change the confirmed password as well.

    00:32 We can add validation on blur. Let's just import the onBlur function. Then we'll need the respective messages.

    00:50 Then let's go to the view where we raise these messages.

    01:08 Finally, we need to handle these new messages in the applet function. Let me duplicate this. This will be blur email, there's no payload. All we want to do is perform validation. It's not onChange, but let's assume we have a new type of event, onBlur. Let me go to my validation module and define this onBlur event. Then I need to handle this when I validate.

    01:41 What we want to do is exactly the same on submit. In a sense, when the user leaves the field, he's committed to that value, so we can actually force the validation. Now, back in my Main.elm file, let me add cases for the remaining message types.

    02:30 Let's see what happens now. Let me type an invalid email and an invalid password. Now it says, "Your password isn't strong enough." Before I spend the time to retype the password, let me fix it first. Then I can say hello1 again. Before I go to submit, let me fix the email as well. Now I have a successful submission.

    03:03 Notice that if I look at my applet function now, it's actually pretty long. That's because we are now handling two message types for each input. Because the type of validation we want to do on input and on blur is different, there's no easy way to unify these messages.

    03:18 There is a benefit in terms of user experience, but there is definitely a cost in terms of writing and maintaining the code. Also notice that even though the validation that we perform on blur is exactly the same as we do on submit, we still need to validate on submit because it might be that the user clicks submit without having visited all the fields.