Form Validation with Branded Types
In this exercise, we're going to look at brands as a way of ensuring your code is logically correct on the type level.
We have a few functions here: onSubmitHandler
, createUserOnAPI
, and validateValues
. You can think of these as being called in sequence.
First of all, onSubmitHandler
is ki
Transcript
0:00 In this exercise, we're going to look at brands as a way of understanding the logic and making sure that the logic is totally safe in your application code. We have a few functions here. We have onSubmit handler, create a User on API, and validate values.
0:16 You can think of these as being called in sequence. First of all, onSubmit handler is the public API here. It's the thing that we would pass to our form, for instance, to extract out the raw values of email string and password string. This is basically what the user calls in order to validate that stuff.
0:36 From there, we grab those values. We put them into the validate values function. What happens here is it checks that email and password are correct. If it is an email, then we know that it's going to be an email essentially. If it doesn't include an @ symbol, then we error, "Email invalid." If the password isn't long enough, then we error there, too. We return those values.
1:00 Then we take those validated values and pass them in to create a User on API. Here we have email, email and password, password. This is going to be erroring because types of property email are incompatible and passwords are not valid either.
1:17 I want you to think about how you would change this function, the validate values function, not any of its runtime stuff. Just a couple of types here in order to make sure that what gets returned from validated values or validate values is what we think it is. We want to make sure that what gets returned from here is a password and an email.