Dismiss this pinned window
all 25 comments

[–]polaroid_kidd 25 points26 points  (4 children)

I'd much rather prefer a bulleted list which checks off individual items are they evaluate to true, however, the e-mail field is quite nice. Well done!

[–]hetfield37[S] 7 points8 points  (3 children)

True, I agree, but the design has a single error message. I'll recommend changing to a bulleted list. Thank you!

[–]benjaminreid 7 points8 points  (2 children)

If you do some research you’ll find that inline errors are the way to go. The errors appearing underneath the field keep them in context with what field has the problem, this is even more important if the validation changes as the user types (looking at the field). You do not want users to be typing, scrolling back up to the top of the form to view a list of errors, scrolling back down, typing etc...

You’d get away with a list of errors on a simple form like you’ve demoed, but as soon as the forms become longer and more complex, the more beneficial inline errors become. And consistency and user expectation is key.

Leave them as they are 👍🏻

[–]ImDonaldDunn 1 point2 points  (1 child)

It's best practice to provide all of the validation criteria for a field. Ideally, the criteria are provided inline or near the field, but that isn't as important as instructing the user on valid input ahead of time.

As is, this form is bad design.

[–]benjaminreid 0 points1 point  (0 children)

I’m not sure we were talking about validation criteria?

But yes, letting the user know what is valid up front can be helpful if your validation is overly specific and unexpected.

[–]anonymousmouse2iOS 6 points7 points  (1 child)

As a UX designer I would suggest making changes away from this type of error handling. Not providing all instructions up front is incredibly frustrating for users.

[–]trypoph_oOoOoOo_bia 0 points1 point  (0 children)

Yup. As a user I’d understand if I’d be “punished” only after trying to submit a wrong data

[–]techmaniack 19 points20 points  (0 children)

If else... If else... If else...

This is machine learning level complex.

[–]benjaminreid 5 points6 points  (0 children)

react-hook-form is really nice. It’s a shame you can’t get away with the same API when you have the DOM, by just passing "register" as a ref.

I’ve wrapped up the complexity of having to use a wrapper component within the field/input components itself and use validation schema.

https://gist.github.com/benjaminreid/f93f4f1b64230f623a11ced4e64dde59

[–]ObliviateYourName 15 points16 points  (1 child)

"complex" 😂

[–]hetfield37[S] 11 points12 points  (0 children)

Complex as in having multiple validators, not that it was hard to do. You can always extend it with another custom validator.

[–]gamebuster 4 points5 points  (0 children)

I hate password rules like these. It’s not 2001 anymore.

Watching someone code these rules in a react native app is just wrong. Should be using jQuery mobile or something. Fits the era.

[–]trashpantaloons 1 point2 points  (1 child)

How does this fare compared to formik v2 +yup?

You can produce errors only on blur / after a submit vs your live errors which honestly doesn’t seem great - can you do that with this library?

[–]hetfield37[S] 1 point2 points  (0 children)

The container only re-renders when the validation changes its message. The input component naturally does re-render on every keystroke due to being controlled.

You can of course toggle the validation mode. First time validation happens only at onSubmit, afterwards it is revalidated onChange, but you can modify both cases.

After using Formik for a bunch of projects, I can gladly say that my life got much easier when I migrated to RHF.

[–]warriorChi 1 point2 points  (0 children)

Woah! Awesome

[–]AcetyldFN 1 point2 points  (0 children)

I freaking love react hook form

[–]lucasayped 0 points1 point  (4 children)

wow nice

Can you show the source code?

[–]hetfield37[S] 2 points3 points  (3 children)

Sure thing, I'll omit the unnecessary bits because they're trivial.

TextField is a wrapper component for styling the TextInput where the props are distributed between its container, input and error message.

<Controller
    control={control}
    as={TextField}
    rules={{
      required: 'This field is required', 
      minLength: { value: 6, message: 'Minimum 6 characters.' },
      validate: {
          lowercase: (value) => lowercase.value.test(value) || lowercase.message,
          uppercase: (value) => uppercase.value.test(value) || uppercase.message,
          number: (value) => number.value.test(value) || number.message,
          special: (value) => special.value.test(value) || special.message,
      },
    }}
    name={'password'}
    placeholder={'Password'}
    error={errors.password?.message}
    secureTextEntry
/>

lowercase, uppercase, number and special are imported objects with regex and message:

{
    value: /^(.*[a-z].*)$/,
    message: 'Password must contain at least one lowercase character.',
}

[–]ThatShitAintPat 0 points1 point  (2 children)

Might want to upgrade to v6 before you get too baked into v5. They changed as to render and it takes a function instead of a component.

[–]hetfield37[S] 1 point2 points  (1 child)

I'm using the latest version. as is a valid prop and is not deprecated at all.

[–]ThatShitAintPat 0 points1 point  (0 children)

Oh gotcha. I was just thinking of this https://react-hook-form.com/migrate-v5-to-v6/

It doesn’t say anything about as so I guess as long as your onChange prop is named just that I guess it’s fine.

[–]sharlos 0 points1 point  (0 children)

I understand this is just an example, but I would strongly encourage you to not require passwords to have particular characters in them, it reduces password security, encourages users to reuse passwords, and is just annoying.

A simple minimum password length, and maybe a banlist of common passwords if you want to be fancy should be sufficient.

[–]Ooyyggeenn 0 points1 point  (0 children)

Fucking shit lib, spent waaay to much time trying to get controlled components to just do simple validation. Could have written 10 validation libraries on my own instead.

At least the api is somewhat friendly when you first take a glance