DEV Community: Si Le

Handle form and validation with React

Si Le — Sat, 13 Jun 2020 04:24:48 +0000

Overview

Handling form is an extremely common usecase for web applications. In this post, let's explore a way to handle form inputs and validations using React without using a third-party library.

Requirements

We will cover the most popular functionalities that will apply for most usecases:

An onSubmit callback for components using the form.
Validation for single input (front-end only).
Validation onSubmit, not onBlur.
Reset form.

How does it work?

We will create a Form context that will hold all the states and define all state interactions for all form inputs.

When an input is mounted, certain information passed in these inputs will be used to supply to the Form context.

When an input within the form context changes, it will submit its new value to form context. Form context receives the values and changes its state to new value and pass it down to the input (controlled input).

When the form is submitted, it will run through all the validations that was registered when the input mounted and set the errors for specific fields. Those will then be passed down to the right input and rendered accordingly.

The figure below summarizes the responsibilities for each type of component.

Implementation

Form State

This form state needs to be able to hold 3 pieces of information:

Form data - for user's input data.
Validations - for field specific validations.
Errors - for field specific errors.

I think this object should be sufficient to work with.



const FORM_STATE = {
  data: {},
  validators: {},
  errors: {},
}

We will also make a convention that every input must have a unique name prop to identify itself. It is similar to how a regular HTML5 form input has name property.

It is important for the name to be unique because we will use them as keys in our state structure.

For example, an input with the name first_name will be store in FORM_STATE as follow:



{
  data: {
    first_name: "John",
  },
  validators: {
    first_name: [fn()],
  },
  errors: {
    first_name: ["error message"],
  }
}

Form Context

To inject form state and methods to every components that want to subscribe to it, we will use context provider pattern. You can read more about context here.

In my understanding, context is a wrapper that inject props into any child component that subscribe to it through a consumer. There is a convenient way to subscribe to context by using useContext hook.

We will also create an HOC to encapsulate the context subscription logic in one place so that our input can be as purely UI as possible. In other words, inputs are presentational components that will only listen to prop changes. Form context is the container that will hold most of the logic.

Form Methods

Let's go through step by step how form context should behave.

Registration

When an input is mounted, it should register itself with form context. On registration, we simply will copy validators from that input to store inside form context.

When an input is unmounted, we should clear its validations, errors, and any data associated with that input. Here's the registration function.



const registerInput = ({ name, validators }) => {
  setFormState(state => {
    return {
      ...state,
      validators: {
        ...state.validators,
        [name]: validators || []
      },
      // clear any errors
      errors: {
        ...state.errors,
        [name]: []
      }
    };
  });

  // returning unregister method
  return () => {
    setFormState(state => {
      // copy state to avoid mutating it
      const { data, errors, validators: currentValidators } = { ...state };

      // clear field data, validations and errors
      delete data[name];
      delete errors[name];
      delete currentValidators[name];

      return {
        data,
        errors,
        validators: currentValidators
      };
    });
  };
};

The registration function will return a function to unregister this input. It will only remove that input with the same name.

Input data control

Controlled inputs require us to use an onChange function to set a value somewhere, either in a redux store or in a state. In our form, we will hijack it and set a value in our form context before passing up the value. That way, the input itself is more flexible, although, it does come with some confusion. I'll explain this point later on.

When an input changes, we simply set its value to our form context's data object. Here is the implementation.



  const setFieldValue = (name, value) => {
    setFormState(state => {
      return {
        ...state,
        data: {
          ...state.data,
          [name]: value
        },
        errors: {
          ...state.errors,
          [name]: []
        }
      };
    });
  };

In addition to setting the input's data, we also clear its own errors under the assumption that if there was an error when the form submitted, user must have seen the inline errors. Now they're correcting the value for that field.

Submission and validation

Next, we have the validation and submission part of the form. The process is simple. When the user click submits, we'll run through every validator in form context, call the validator with 2 arguments:

The value of the input.
The data object as a whole.

Why do we pass data objects into validators? Technically, we don't have to, but I think it's nice to have the validator aware of the whole form data. That way, we can perform cross input validation if we want.

If all validators return empty messages. It's good. The form will call onSubmit callback.

If ANY validator returns an error message, we'll set the errors hash with that input's name and error messages. The form is now invalid and onSubmit callback will not be called.

Let's take a look at the implementation.



  const validate = () => {
    const { validators } = formState;

    // always reset form errors
    // in case there was form errors from backend
    setFormState(state => ({
      ...state,
      errors: {}
    }));

    if (isEmpty(validators)) {
      return true;
    }

    const formErrors = Object.entries(validators).reduce(
      (errors, [name, validators]) => {
        const { data } = formState;
        const messages = validators.reduce((result, validator) => {
          const value = data[name];
          const err = validator(value, data);
          return [...result, ...err];
        }, []);

        if (messages.length > 0) {
          errors[name] = messages;
        }

        return errors;
      },
      {}
    );

    if (isEmpty(formErrors)) {
      return true;
    }

    setFormState(state => ({
      ...state,
      errors: formErrors
    }));

    return false;
  };

It's important to note that we're running through all validators and collect all errors before returning. Otherwise, when users have errors in 2 fields, they'll have to fix one, submit, get another error, and fix the second field.

That's it! We've got our form context ready. Here's the full code below.

Form HOC

Now that we have form context, we will make an wrapper to inject those context methods into any input component. This is optional because you can always use a context hook. Though, I think it's convenient.

The HOC will handle input registration, filtering errors and input value, and set data in form context.

First, let's subscribe to form context with useContext hook.



const { 
  errors, 
  data, 
  setFieldValue, 
  registerInput 
} = useContext(
  FormContext
);

After that, we'll register to Form context with useEffect.



useEffect(
  () =>
    registerInput({
      name: props.name,
      validators: props.validators
    }),
  []
);

We also return the unregistration function, so when this input is unmounted, it will not affect the form data or its validations anymore.

Then, we need to get the right input value and error for the wrapped input.



const inputValue = data[props.name];
const inputErrors = errors[props.name] || [];

Error will always be an array of error messages. An empty error array means there are no errors.

Lastly, we need to hijack the onChange callback so we can store this wrapped input's value to form context.



const onChange = val => {
  setFieldValue(props.name, val);
  if (props.onChange) {
    props.onChange(val);
  }
};

Here is the entire implementation.

Text Input

Finally, something usable. Let's make a text input using our form. Our input will have the following:

A label
The input itself
Any errors
onChange callback

It will receive in errors and value from form context. Based on form context, it will render accordingly. This is quite simple to implement.

Here's the implementation.

All together now!

We've arrived at the end! Yay! Let's put together a sign-up form as an example.



<Form onSubmit={data => console.log(data)}>
  <TextInput
    name="first_name"
    validators={[requiredValidator]}
    placeholder="John"
    label="First Name"
  />
  <TextInput
    name="last_name"
    validators={[requiredValidator]}
    placeholder="Smith"
    label="Last Name"
  />
  // .... truncate
  <button className="submit-btn" type="submit">
    Register!
  </button>
  <button className="submit-btn danger" type="reset">
    Reset
  </button>
</Form>

We'll simply log out the data for now. We'll also put in a few validators to make sure that it works. Let's take a look at a sample validator.



const requiredValidator = val => {
  if (!val) {
    return ["This field is required"];
  }

  return [];
};

Try clicking submit and reset to see how it works!

Thank you for reading to this point. I hope this is useful. Let me know your thoughts and comments :)

Form in action

Simple JWT Authentication with Golang (Part 3)

Si Le — Sat, 01 Jun 2019 23:11:09 +0000

This is part three of a three-part series tutorial that builds a small but complete JWT authentication solution for internal API (most concepts can also be applied to build JWT auth for public API).

Part 1 — Public/secret key generation and storage
Part 2 —Build a CLI to create/retrieve App object
Part 3 — Build the JWT authentication middleware

https://jwt.io

Overview

This is the last part of the tutorial series, we will finally write methods to authenticate requests with JWT token in Authorization header. There are two parts to this.

JWT Authentication functions
Example of middleware using JWT authentication

JWT Authentication

In this part, we will use a JWT library to provide a way for us to parse and encode JWT token. There are a few of them and you can select your favourite one at jwt.io. In this project, I chose jwt-go. I’ve used it before so I’m more familiar with it than others.

I think it's good to wrap jwt-go in my own class and expose only what I need to use. It has three main benefits.

I don't have to remember the documentation for the library until I need another thing from it since everything I need is written by me and documented myself.
It’s a great way to learn how to use the library and actually understand its interface.
Other parts of the code don’t need to be aware of the library so we can switch to another one relatively easy.

Parse JWT Token

ParseJWT takes a token and a secret key to verify the signature of the token and returns a Claims object. We use the most common signing method, HMAC, to sign the token. There are other ones in the library that you can use. They’re all defined as constants, so it’s quite convenient and readable.

Next, we check if the token is properly generated with token.Valid and return the claims wrapped under our own Claimstype. I handled some errors. However, I think one thing we can do is to wrap those errors in our own errors and propagate them up. The errors package is great for this. You can find it here.

There are many opinions on error handling. I was lazy and simply propagate the errors straight up. I think wrapping it to preserve the stack trace and provide more details will be helpful when we need to debug. One thing to note is since this package is meant to be a library package, we should not log anything out.

Encode JWT Token

EncodingJWT is quite straight forward. Again, I’m simply pushing the errors up the stack and not handle them here. It takes two arguments, a secret key, and a Claims object. We use jwt.NewWithClaims to create a new Token object. Then, we use SignedString to generate the token string.

Most of the time, we need to attach something to the token as we generate them. That’s why I only want to expose NewWithClaims method and always create a Claims object. If we don’t want to have any claims, we simply make an empty Claims object to pass in. That way, we don’t have to make 2 different methods and remember the difference between the two.

How to use it in a middleware

Now that we have the JWT auth service, how do we use it to authenticate a request from the client? If you’ve read all three parts of the tutorial, you will know that we store all the client credentials as App . That means the client needs to be registered with us before sending a request to our service.

Each client should have a public/secret key pair. The public key will be used to identify the client with the API. Using the public key, we can get the secret for the client from our database. The client used its secret key to generate a JWT token to send to the API in the Authorization header in this format: Bearer asdfasdfadsf . Therefore, we need the same secret key to verify the token.

The process is as follow:

Extract the token from the request header.
Parse it with the secret key. If we get claims back, it means the token is valid. We proceed with the request.
Otherwise, we don’t let the user proceed and return a Forbidden status code.

I excluded the part where you need to get the public/secret key pair from the database. This is an example, not a 100% implementation. If you want to identify each client, then you’ll need to query the database to find a public/secret key pair that the client registered before making a request. On the other hand, if there is only one client (in the case of an internal web service) then you probably don’t need to identify it. In addition, there are many things you might want to do when you receive a request from the client. For example, you may need to get the user’s ID or email to do authorization. Middleware/handler logic varies depends on your use case.

Conclusion

And there you have it, implementation of JWT authentication using Golang for web services. You can find all the code here. If you have any suggestions, I’d love to listen. If you have any questions, please leave your comment below and I’ll do my best to answer. I really hope you find this tutorial series helpful. Thank you so much for reading it till the end. Cheers!

Simple JWT Authentication with Golang (Part 2)

Si Le — Tue, 16 Apr 2019 05:22:12 +0000

This is part two of a three-part series tutorial that builds a small but complete JWT authentication solution for internal API (most concepts can also be applied to build JWT auth for public API).

Part 1 — Public/secret key generation and storage
Part 2 — Build a CLI to create/retrieve App object
Part 3 — Build the JWT authentication middleware

https://jwt.io

Overview

In this part, we will build a mini CLI that helps us do the following:

Retrieve the App (a set of public/secret key pair) object stored in our Postgres database by the public key.
Generate a random key string to use as a master key.
Create a new App object.

The CLI

We will use Cobra, a CLI framework package, to quickly generate the basics of our CLI. Let’s get it.

go get -u github.com/spf13/cobra/cobra

We will make a cmd package for all of our commands. Well, there’s only one for now. Let’s organize properly anyways. Here’s is our folder structure.

├── cmd
│ ├── app.go
│ ├── key.go
│ └── root.go
├── internal
│ └── app
│ ├── app.go
│ ├── create.go
│ └── get.go
└── main.go

In root.go we combine all our commands under the one main command.

Root command will be called when you run go run main.go As you can see, we already have two subcommands, keyCmd and appCmd . We will call Execute in main.go's main function later on.

🔑 Key Command

We will write keyCmd first because it’s a lot simpler than appCmd . This command will generate a 32-bits key and print it to the screen.

Cobra’s command type has a few properties that we can use. However, the main ones are Use, Short, Long, and Run. The first property, Use , is crucial to identify how to call this command. In this case, we will call go run main.go key to use this command. Short and Long properties are simply descriptions of the command in short form which will be displayed in the help section of the parent command or long description when we call --help on the command itself. Run is pretty self-explanatory. It runs the function that we passed in. The function should take 2 arguments which first is the command itself, and second is the arguments of the command.

We don’t use any arguments in this case since we always want to generate a 32-bits key and print it out.

🔐 App Command

This command will generate a credential key pairs, store them in the database and print out the keys. It can also fetch an App given its public key. It’s very useful when you have an internal API and want to give access to internal clients only. It can also be modified to work as an API endpoint.

There are a few things going on here. First, we have another “rootCmd”, which in this case, the app command. This app command will be the root for two commands create and get . There are a few new things here compare to key command earlier. We use Args property as a validation mechanism to enforce certain rules. In bothcreate and get , we want to have at least one argument. They are [name] and [public_key] respectively.

Second, we use a flag to take in a database URL connection. For simplicity, I defined var db string as a package variable. However, please feel free to refactor it to be contained in a struct or so. It’s important that we know where to connect to the database so we’ll make --db flag required. To bind a flag, we will call .StringVarP(destination *string, longFlag string, shortFlag string, defaultValue string, description string). As for .PersistentFlag() , we make the flag persistent because we bind it on the app command and not on create or get . A persistent flag will make the flag available even when you call child commands. Otherwise, flags are available under local scope only and you won’t be able to access var db value. Here are the complete commands.

go run main.go app --db [dbURL] create [name]
go run main.go app --db [dbURL] get [public\_key]

Now that we have the commands set up. Let’s dive into the handlers.

The handlers are small because we delegate most of the work to other services that will do the work for us. Those services are concerned with how to create an App object given the information from the commands. These handlers are only responsible for calling those services. In addition, we will also have a data access layer that will take care of saving all of the information to the database.

Layers for the CLI

Since the data access layer is quite long with SQL commands, I’d recommend you to take a look at the GitHub repo itself. It’s under goliauth/internal/app/app.go . For now, we will focus on the two service functions that are used to create and get an App object.

💁🏻‍♂️ Services Layer

Welcome to our CLI service. Here we have the CreateApp function that will… create an app, obviously. We begin by generating 2 random keys to be used as a public and secret key. Then, we encrypt the secret key and pass along the app’s name from our command to form an App struct. When everything is properly formed, we call .Create to instruct the data access layer to save all the information to the database given the URL.

Next, we have GetApp function that will find our credentials given a public key. Using the public key, we can query the database and returns an App object that will contain an encrypted key. We will proceed to turn that key into bytes. Then, we decrypt that key an assign it back to the App object for reading. Finally, we will read it from the command and print it out.

Voila, that’s all there is to the CLI. Let’s see if it works

See higher resolution at https://asciinema.org/a/241101

Full Github repo is here https://github.com/omnisyle/goliauth

Thank you for reading to the end!

Simple JWT Authentication for Golang (Part 1)

Si Le — Mon, 01 Apr 2019 03:54:51 +0000

When it comes to an API, we need authentication for users to access their information. JWT is widely used for API authentication because of its stateless nature. In this tutorial series, I will share with you what I’ve learned when I implemented JWT authentication.

There are three parts in this tutorial

Part 1 — Public/secret key generation and storage
Part 2 — Build a CLI to create/retrieve App object
Part 3 — Build the JWT authentication middleware

https://jwt.io

For this tutorial, we’ll use the following tools:

Golang 1.11 Darwin
Postgres
JWT library recommended by jwt.io: github.com/dgrijalva/jwt-go
Golang built-in crypto packages
Developer (very important: please feed some coffee fuel before use)

Assumptions:

You know AES encryption (just enough to use, no need to read the research papers)

Disclaimer: All the codes here are not 100% mine. It’s a compilation from multiple sources such as open-source projects, go documentation, etc.

I will include the resources I used at the end of the tutorial. For now, let’s dive in.

⚙️ The process

To authenticate with our API, every request must include a public key and a JWT token in its headers. The JWT token is a bearer token in “Authorization” header. The process to authenticate a request is as follow:

When our API receives the request, we check for its public key header.
We use that public key to check if the app trying to access our API is registered in our database.
If we found the app using its public key, we will use its secret key (also stored in our database) to verify its JWT signature.
Otherwise, we return status 401 to the client.

The whole process can be visualized like this

JWT Authentication Flow for our API

🗝 The key couple

For any apps that want to use our API, we need to give them a secret and public key to authenticate. To do this, we will generate two random 16 bytes keys and store it in our database. To protect the secret keys, we will use AES encryption to encrypt the key before we write it to the database.

Why encryption? The secret key is an app’s password, it needs to be protected. However, unlike passwords, we will need the original value to verify the JWT signature. Therefore, encryption is a better solution to store the secret keys in our database.

There are two parts we need to use AES encryption. First, we need a master secret key on our side. We will use the same secret to encrypt all secret keys. Second, for each secret key, we will include a salt (or iv in this case) to vary the final encrypted key. The final data struct will look something like this:

// App is a generated public/secret key pair
type App struct {
  Id int  
  Name string
  EncryptedSecretKey string
  PublicKey string
  CreatedAt time.Time
  UpdatedAt time.Time
}

Now we only need to write a SQL command to create an App table with those columns

Next, we will write a function to generate a random key string. This function will generate a 32 bytes random string to be used as a public key or secret key. Basically, we’ll call it twice to get the original values for both keys. You can change the number of bytes to adjust the length of the key. One thing to note is fmt.Sprintf("%x", key) will print out 2 characters per byte (documentation), so you will get a string twice the length of the byte array. In our case, it will generate a string of 64 characters. Read more about go strings here.

🔒 Encryption

To store our secret key securely in the database, we will have a master key used to encrypt every secret key with an Initial Value (IV, or nonce, or salt, whatever you’d like to call it). The master key will be stored as an environment variable (for simplicity). The length of the master key is important to determine whether the final encrypted value is an AES128, 192 or 256. The master key must be 32, 48 or 64 characters long, corresponding to AES128, 192, and 256.

In this tutorial, we will use AES256-GCM to encrypt our secret key. Go has a built-in aes package that can do the job for us. Here are our Encrypt and Decrypt functions.

First is our Encrypt function. I’ve separated it from our Decrypt function below so we have everything we need in one file. The process can be simplified as follow:

Get the master secret key.
Make a new AES cipher block.
Make a new GCM cipher block which returns an AEAD object.
Generate a random IV with the same size of the required nonce length (default to 12 bytes). This IV will be prepended to the final key.
Finally, “Seal” the nonce and in the key to an encrypted value to a destination (dst). That’s why we use the nonce as the destination. It will append the encrypted key to the nonce. Here for reference.

Seal(dst, nonce, plaintext, additionalData []byte) []byte)

🔓 Decryption

Similar to our encryption process, we will utilize go’s built-in packages to decrypt encrypted keys stored in our database to be used in JWT signature verification. Here is our function.

Again, here’s the summary of our process.

Get the master secret key.
Make a new AES cipher block.
Make a new GCM cipher block which returns an AEAD object.
Verify the encrypted key’s length.
Finally, “Open” the encrypted key by passing in nil for the destination, then the nonce which was prepended in the final key, then the actual encrypted key bytes (the latter part), and nil for extra data.

Open(dst, nonce, ciphertext, additionalData [][byte](https://golang.org/pkg/builtin/#byte)) ([][byte](https://golang.org/pkg/builtin/#byte), [error](https://golang.org/pkg/builtin/#error)

That’s it for our encryption functions. Here is the final code on Github. I hope this is helpful 😁.

Resources

Firebase Firestore Initial Payload with onSnapshot

Si Le — Thu, 06 Sep 2018 18:42:19 +0000

Firebase Firestore Initial Payload with onSnapshot

Image from https://firebase.google.com/images/social.png

NOTE : This approach only works for web because Firestore doesn’t offer caching for web. On iOS and Android, you must take another approach to handle initial payload and subsequent updates due to caching. The first response from a subscription on iOS or Android will come from cache. Second response is new updates from Firestore and subsequent responses are updates/create/destroy only.

I’ve been using Firebase for a while now. One of the problems I’ve had with Firebase is this weird behaviour when you want to subscribe to a query, it returns the whole result on the first call and returns new/updated documents afterward.

Let’s say I want to ignore the initial load and only listen to new changes. That’s just purely subscription. How do you know which one is the first call?

Firebase doesn’t provide any ways to check whether the result set is the first one. I’ve tried stackoverflow to see if anybody encountered the same problem. This thread is promising:

Stackoverflow Thread https://stackoverflow.com/questions/49798693/differentate-between-first-time-querysnapshot-and-change-listener-in-firestore

Looks like the first query snapshot only contains added event. Sure, but what if you want to listen to new document events too? Do you have to handle the first added event the same as subsequent added events?

In my case, I want to ignore the first payload altogether and only listen to new updates. A new update can be an added event other other events. Therefore, checking whether it’s an added event for first payload doesn’t work.

What if I can count the number of invocation of the callback function and ignore the first invocation all together? Here’s a generic function wrapper that count the number of times the wrapped function is called.

createFnCounter() takes 2 arguments, first is the function being wrapped, and second is the number of invocation needed before the wrapped function is called. Therefore, createFnCounter(foo, 1) will only call foo on the second call. I’m pretty sure some names in this function can be more explicit but you get the idea (in case you want to discuss, I’m down for it).

How do you use this function? I have a collection named activities that contains all the activities happened to my chat channels collection. When a user sent a message to another user, there’s a new activity created/modified to notify the chat client, it’s saying, “Hey, there’s a new activity on this channel, do your thing”. The client received the event, and does its things. When the client initialize, I subscribe to activities collection as follow.

Let’s incorporate createFnCounter to only receive updates and ignore initial payload.

Too verbose, I know, but 6 months from now when I look back at this code, I’ll know what happened.

What if I want to get that initial payload too but do something different with it? Well, here we go

There you go, now you have a way to distinguish between initial load and subsequent updates when subscribing to documents on Firestore. Have other methods? Let me know!

Thanks for reading! ≈