Data strucutre of Form Validation error message

Learn
1

Hi,
I have a form with 3 fields, name, phone, email.
I am using rtfeldman/elm-validate.

After struggling with record, I finally ended up with Dict String (Maybe String). String representing the name of the field and Maybe String the occurence of an error message.

Does it sound good to you?
Thanks.

1 Like
2

Looking at the documentation, elm-validate’s validate would already seem to return a record (or whatever else you pass it), as in the example at the start of the documentation.

Using a Dict doesn’t sound ideal as you lose some type safety.

Maybe you could post a bit more of your code so we can see what you’ve done. It would be easier to make concrete suggestions then…

3

That doesnt sound bad. In some cases I could imagine a Dict String error as being ideal.

But if its a really simple form that you know will be static, you could hardcode all this stuff.

type alias Model =
    { name : String
    , nameError : Maybe String
    , phone : String
    , phoneError : Maybe String
    ..
    }

If thats not how you want to go, which may make sense in some cases, you could also bundle all Field stuff together.

type alias Field =
    { value : String
    , error : Maybe String
    , validations : List (String -> Maybe String)
    }

type alias Model =
    { fields : Dict String Field }
1 Like
4

I am just interested here in the case of validate returns List error

validate: 
    Validator error subject
    -> subject
    -> Result ( List error) (Valid subject)

And then how to store this data i.e. in which data structure.

What should it be when there is an error for the field name and no error for the other fields?

The function validate runs on individual field when lose_focused or on_change event (under certain circumstances) are fired but also on all the fields of the form when the submit button is pressed.

I started with the nested record below and found out it is hard to manage.

type alias StudentForm =
    { emailError : Maybe String
    , nameError : Maybe String
    , phoneError : Maybe String
    }

Finally I looked at the Dict module, and it looks not so bad for storing and manipulating these error messages.

5

Personally, I’m a big fan of a data structure that looks roughly like this when modeling data that can be validated:

type Validated a
  = Initial -- Field is neither valid nor invalid on initial render
  | Valid a -- We can turn the valid raw string into a custom value `a`
  | Invalid String String -- We track both the raw string and the error message

You can wrap any field in it, including fields that get transformed to fancier types:

type Model =
  { name : Validated String
  , phone : Validated PhoneNumber
  , email : Validated Email
  }

I walked through data modeling a multi-step form with validation in this discourse thread. I also created an executable example on Ellie that uses this.

3 Likes
6

Yep, your designed structure is very similar to elm-validate package.

7

That does look similar! My inspiration was Eric Gjertsen’s elm-validation package which unfortunately has not been updated to 0.19 yet.

8

I like lhis ~

I like that ~

I would use them both ~

type alias Field = 
    { value : Validated String
    , validations : List (String -> Maybe String) 
    }

EDIT

I finally ended up with:

type FieldValue a 
    = Initial -- Initial render  
    | Raw a -- The field is holding a neither valid or invalid value
    | Valid a -- The field is holding a valid value
    | Invalid String String -- The field is holding an invalid value and its error message

I put validators apart, it works like a charm for each scenario.
Thanks!

9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.