DEV Community: Babatunde Adeniran

What Exactly Is Serverless? A Simple Explanation for Beginners

Babatunde Adeniran — Wed, 10 Dec 2025 14:32:30 +0000

It is not uncommon for people to think that there are no application servers when they hear the term "serverless." A serverless application does not mean the absence of servers. Servers actually exist, but the difference is that you do not have the responsibility of managing them.

In a serverless application, your primary concern is your code and how well it performs. How the servers process your business logic is none of your business because AWS takes care of this. AWS does the heavy lifting by handling the patching and scaling of servers under the hood.

Now, let’s simplify this by explaining it in a beginner-friendly manner.

Serverless, what does it really mean?

Serverless means:

Absence of server provisioning and management: In other words, you will never have to install server updates, handle an EC2 instance, or SSH into a machine.
Automatic application scaling: Your application scaling is handled by AWS regardless of the number of requests you send through.
Cost effectiveness: There are no idle costs as you are only charged for what you use. You don’t get charged if your application doesn’t run.
High availability: Multi-AZ redundancy is taken care of by AWS.

Serverless is just efficient cloud computing.

Building Blocks of Serverless on AWS

There are so many AWS services that can be combined to build serverless applications on AWS. They include:

AWS Lambda: This is the heart of serverless on AWS. With this, you can run code without the need to provision servers. You are only saddled with the responsibility of uploading code, and AWS handles running this code in response to events like changes in the database, file uploads, and API requests.
API Gateway: This helps us create serverless REST or WebSocket API’s. With these API’s we can do many things, such as triggering lambda functions and handling user authentication. It is a weapon for building backend services.
S3: This is for serverless storage. It is an AWS-managed service that helps with the storage of videos and images. It can also be used to host static web pages.
AWS DynamoDB: I wrote about DynamoDB and the 'Access Patterns' Mindset in an earlier article. It is a serverless and fully managed database engine that scales automatically and is capable of handling millions of reads and writes every second.
AWS SQS and EventBridge: This helps with serverless event management and messaging. With these, we can efficiently build a complex infrastructure that communicates with each other and connects very well. These two make it possible to architect reliable and scalable workflows.

When should you use Serverless?

To build APIs
To run scheduled tasks
For Webhooks
To process files
For script automation
ETL jobs.

Basically, serverless is a great fit for event-driven workload. It is also a great fit for beginners with little or no idea of servers and DevOps processes. It is important to clarify that serverless does not mean you won’t handle architecture decisions, cost tracking, logging, and monitoring. These are still operational responsibilities you have to handle.

Wrapping Up!

Serverless is a big shift in how major cloud applications are built. So, it isn’t just a trend. It focuses greatly on scalability so that you don’t have to worry about capacity provisioning. Serverless focuses on speed and not configuration. It places great focus on cost reduction and business value. As a cloud beginner, it is a good starting point because it naturally teaches you event-driven design, and it allows you to deploy applications without much setup.

With serverless, you build more and do less infrastructure management.

RDS vs DynamoDB: When do I Choose Which?

Babatunde Adeniran — Thu, 30 Oct 2025 14:44:40 +0000

Choosing a database that matches your workload and architecture is one of the major decisions you have to make when developing an application. In AWS, this decision may not be straightforward as there are many options to choose from, with each option having its core strength and what it is optimised for. Amazon RDS and Amazon DynamoDB are some of the options to choose from when building with AWS. Both database systems are fully managed by AWS. They are both scalable, easy to set up and operate. However, they work best for different workloads.

Another big difference between RDS and DynamoDB is that they are optimised for different thinking models. In an earlier article, I discussed the DynamoDB Access Patterns’ Mindset and why it is important not to approach DynamoDB with a relational mindset. In the same vein, you shouldn’t approach Amazon RDS like you would approach a NoSQL engine like DynamoDB. While DynamoDB is schemaless, RDS relies heavily on database schemas and relationships between entities. Therefore, you shouldn’t treat it like you would treat DynamoDB because you will run into performance issues if you do.

How do I decide which one to use?

In very simple terms and in practical language, DynamoDB should be used for data that is driven by access patterns. Use DynamoDB if your workload requires low-latency and predictable access patterns. Conversely, RDS should be your choice if your data is structured, relationships between data are important, and there are joins, transactions, and schemas.

RDS is for relational data.

DynamoDB is for access-pattern-driven data.

How are they different?

The big difference between RDS and DynamoDB is in how data is modelled.

In relational thinking, tables and relationships are designed first, and new query patterns can be established subsequently. Relational databases work best for ERPs, Human Resource systems, traditional business applications, and financial systems. If you choose to work with RDS, you have to handle how your connections are managed.

In DynamoDB’s access-pattern thinking, our database is modelled for the queries needed by our application. Therefore, performance and scalability are not issues you need to worry about. This makes DynamoDB ideal for serverless systems, retail carts, high-traffic mobile or web applications, streaming apps, and gaming apps.

When should I choose RDS?

For complex queries
For strong ACID (Atomicity, Consistency, Isolation, Durability) guarantees.
When you need joins and need to establish relationships between data.
SQL is ideal for reporting and analytics requirements because it syncs well with Business Intelligence tools.

Are you working on a logistics application, bank transactions, human resources or payroll system, or inventory systems? Think RDS.

When should I choose DynamoDB?

When building a low-latency application that requires fast reads and writes.
Serverless architecture - Lambda, SQS, etc.
If your application scales massively.
For predictable access patterns.

Are you working on leaderboards, real-time booking applications, shopping cart sessions, or an API rate-limiting system? Think DynamoDB.

Can I use both?

The short answer is yes. Some systems use both RDS and DynamoDB. These modern systems use Amazon RDS to carry out analytics and reporting and use DynamoDB for high-volume applications with real-time data.

With this hybrid arrangement, we can both carry out complex reporting and implement fast and low-cost operational workloads.

Therefore, in such an arrangement, RDS is for business analysis and interpretation, while DynamoDB is for write speed.

Wrapping Up!

Whether you choose RDS, DynamoDB or both depends on the system you are working on, the data you have, your technical expertise and how well you understand access patterns and the relationships between data entities.

For structured, relational data that requires flexible queries, use RDS.

For low-latency, highly scalable applications with an established access pattern, use DynamoDB.

As a competent engineer, your choice of database should hinge on suitability with the workload at hand and not on what you are most comfortable with.

DynamoDB: The 'Access Patterns' Mindset

Babatunde Adeniran — Wed, 22 Oct 2025 17:17:57 +0000

It is well known that software development is a lifelong learning process. At the start of my career, most of my early interactions involved SQL databases. I used many SQL administrative tools, such as DBeaver, SQLiteStudio, and MySQL Workbench. When I first began working with DynamoDB, I didn’t realise early enough that I needed a mindset shift, and I am sure quite a few developers fell into a similar trap. In designing my DynamoDB table structure, I treated queries and access patterns as afterthoughts and focused more on mappings and relationships between items and entities, just as I would with a relational database. Persistently applying these old SQL habits often led me to deal with inefficient scans, which was deeply frustrating.

When working with DynamoDB, you need to shift your mindset, especially if you have prior experience with relational database systems. The key focus when creating a DynamoDB table should primarily be on access patterns rather than data structure.

The goal of this article is to shed light on what “designing for access patterns” means. I will explain its importance and why you cannot tap into the numerous benefits of DynamoDB without this mindset shift.

How does DynamoDB differ from Relational Database systems?

For starters, and for the benefit of those who do not know what DynamoDB is, it is a NoSQL database that is highly available and performant. As a user, you do not have to worry about patching and maintenance; AWS handles this. Amazon DynamoDB is a fully managed database capable of processing millions of requests per second.

With Relational databases like PostgreSQL, MySQL, and MariaDB, data can be queried in many ways. SQL-based databases are heavily dependent on JOINS and indexes, and this makes it easier to avoid data duplication. DynamoDB operates differently. As mentioned ab initio, DynamoDB is for workloads that need a high level of performance and scalability. Regardless of the number of item rows (can scale to trillions), reads and writes must be processed at a fast pace, irrespective of the database size. This is achieved by avoiding unnecessary item scans (which could be costly) and quick lookup of table items with the Primary Key.

Look at it this way, in Relational databases, you create tables, and your database must adjust itself to whatever queries you feed it to give you a result. On the flip side, in DynamoDB, your database and table won’t conform to your queries; your queries must adapt to your database based on the data models and access patterns you have defined.

DynamoDB’s access pattern mindset:

“These are the queries I have: what access patterns and data models should I create?”

Relational database:

“What queries can I write with the table/tables I have?”

When working with DynamoDB, it is best practice to list our entry points or access patterns before building. Without specifying and identifying these patterns, we wouldn't be able to outline the Primary Key, Sort Key, Local Secondary Index (LSI), and Global Secondary Index (GSI) that we need.

Understanding Primary Keys and Indexes

The Primary Key and Indexes are at the core of DynamoDB access patterns. For example, if we were to build a simple e-commerce backend of users and orders using a relational database, we would need to set up various tables for Users, Orders, Items, etc. With DynamoDB, we can model this efficiently in just one table thanks to the Primary Keys and Indexes.

Primary Key

You must first understand how to choose a Primary Key for your DynamoDB table before any further discussions on access patterns. In choosing a Primary Key, there are two options to select from.

Partition Key: This has to be unique for every row/item on the database. A unique partition key guarantees data distribution. E.g. for a user table, a good choice for a partition key would be the user_id (it could be a random UUID) because of its high cardinality. We can have several other attributes, such as name, age, address, etc.

Partition Key + Sort Key: The combination has to be unique for every item/row on the database. For example, in a users-orders table, the user_id is an ideal candidate for the partition key, and the orders_id can serve as the sort key. However, it is important to emphasise that when we have a composite primary key, data grouping is done on the partition key. So, a user can have numerous orders, as seen with user_id 5456789094 below.

So, we see the second and third items have the same partition keys but different sort keys, and their combination creates a unique primary key.

LSI (Local Secondary Index)

This is the first of the 2 kinds of indexes. It gives us another sort key for querying our DynamoDB table while maintaining the same partition key. We cannot define an LSI after the table has been created, and we can have up to 5 LSIs per table. At the moment, we can only do a query on user_id and order_id. We haven’t devised a means to do a query on user_id and order_item. The LSI makes it possible to perform this query. Therefore, we can get all the items ordered by a particular user.

GSI (Global Secondary Index)

What if we wanted to get the items that are in a particular order? At the moment, there is no way to do this, and that’s where GSIs come in. This gives us an alternate primary key that is different from the primary key we defined in our base table definition. We can create a GSI after initial table creation, and it makes it faster to query on non-key attributes. To get the item in an order, we can specify the order_id as the new partition key and the item as the new sort key. The user_id, order_quantity, name, and address become the attributes.

Wrapping Up!

When working with DynamoDB, data modelling is more about access patterns and query entry points than tables and how they are related. It's more about how your application reads and writes data. Adopting the access pattern mindset makes it possible to enjoy the immense benefits of DynamoDB as a serverless and scalable database.

Formik & React (Part 3): Validation with yup & Streamlining Code

Babatunde Adeniran — Sun, 09 Mar 2025 13:07:45 +0000

So far, we have managed the state of our order submission form, validated our form fields, displayed error messages,handled form submission, and tracked visited fields. However, there is an even better way to carry out form validation, and that is through the use of a library known as yup. With yup, we can eliminate manual interference from our validate function.

Validation with yup

We start by installing yup and importing it into our OrdersForm component. yup allows us to define an object schema validation that can be assigned to a yup object schema. This object will contain the validation rules for our form fields (name, email, and quantity).

import "./order.css"
import { useFormik } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}


const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})

After this, the schema can be fed into the useFormik hook replacing the validate function that we previously used.

 const formik = useFormik({
    initialValues,
    onSubmit,
    validationSchema
  })

So, we can remove our custom validation and our updated code becomes:

import "./order.css"
import { useFormik } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}


const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})


export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validationSchema
  })


  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.name}
          />
          {formik.touched.name && formik.errors.name ? (
            <div className="error">{formik.errors.name}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.email}
          />
          {formik.touched.email && formik.errors.email ? (
            <div className="error">{formik.errors.email}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.quantity}
          />
          {formik.touched.quantity && formik.errors.quantity ? (
            <div className="error">{formik.errors.quantity}</div>
          ) : null}
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

Condensing logic and Refactoring for clarity

Although our form works as it should at the moment, it is possible to optimize our code structure and minimize redundancy. If we closely examine our name, email, and quantity form fields, we see that several props (onChange, onBlur, and value) are being repeated. This repetition violates the DRY (Don't Repeat Yourself) principle. To improve efficiency, we can abstract the common configuration from each field in our form.

A more streamlined approach is to use a helper method that dynamically applies these props as needed. Formik provides the formik.getFieldProps() method, which simplifies this process by accepting the field's name as its argument and automatically handling its state and events.

import "./order.css"
import { useFormik } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}

const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})


export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validationSchema
  })

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            {...formik.getFieldProps('name')}
          />
          {formik.touched.name && formik.errors.name ? (
            <div className="error">{formik.errors.name}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            {...formik.getFieldProps('email')}

          />
          {formik.touched.email && formik.errors.email ? (
            <div className="error">{formik.errors.email}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            {...formik.getFieldProps('quantity')}
          />
          {formik.touched.quantity && formik.errors.quantity ? (
            <div className="error">{formik.errors.quantity}</div>
          ) : null}
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

So, three lines of code in each form field is replaced with a single line.

While the formik.getFieldProps() helper method helps reduce redundant code, we still need to manually pass it to each input field. This means that if our form has ten fields, we would have to call formik.getFieldProps() ten times, which can become repetitive.

To simplify this further, Formik offers built-in components that help reduce verbosity and improve readability. These include the Formik, Form, Field, and ErrorMessage components, which streamline form handling and validation.

The Formik component can serve as a replacement for the useFormik hook in our code. Previously, we passed initialValues, onSubmit, and validationSchema as an object argument within the useFormik hook. Now, instead of using useFormik, we will pass these configurations as props directly to the Formik component.

Before making this change, we need to update our imports by replacing useFormik with Formik.

import "./order.css"
import { Formik } from "formik"
import * as Yup from "yup"

Next, we remove the useFormik call and wrap our entire form with the Formik component, passing the necessary props directly to it.

import "./order.css"
import { Formik } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}

const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})


export const OrdersForm = () => {
  return (
    <Formik initialValues={initialValues} validationSchema={validationSchema} onSubmit={onSubmit}>
      <div className="form-container">
        <h2>Order Submission Form</h2>
        <form onSubmit={formik.handleSubmit}>
          <div className="form-group">
            <label htmlFor='name'>Name:</label>
            <input
              type="text"
              name="name"
              id='name'
              {...formik.getFieldProps('name')}
            />
            {formik.touched.name && formik.errors.name ? (
              <div className="error">{formik.errors.name}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='email'>Email:</label>
            <input
              type="email"
              name="email"
              id='email'
              {...formik.getFieldProps('email')}

            />
            {formik.touched.email && formik.errors.email ? (
              <div className="error">{formik.errors.email}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='quantity'>Order Quantity:</label>
            <input
              type="number"
              name="quantity"
              id='quantity'
              required
              {...formik.getFieldProps('quantity')}
            />
            {formik.touched.quantity && formik.errors.quantity ? (
              <div className="error">{formik.errors.quantity}</div>
            ) : null}
          </div>

          <button type="submit" className="submit-btn">
            Submit Order
          </button>
        </form>
      </div>
    </Formik>
  )
}

We need to wrap the entire form with the Formik component to enable the use of additional components that simplify our form code. This allows us to introduce the Form component along with other necessary Formik components.

Next, we import the Form component and replace the standard HTML <form> element with it. Additionally, we remove the onSubmit prop from the Form tag. Internally, the Form component acts as a wrapper around the native <form> element, automatically integrating with Formik’s handleSubmit method.

import "./order.css"
import { Formik, Form } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}

const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})


export const OrdersForm = () => {
  return (
    <Formik initialValues={initialValues} validationSchema={validationSchema} onSubmit={onSubmit}>
      <div className="form-container">
        <h2>Order Submission Form</h2>
        <Form>
          <div className="form-group">
            <label htmlFor='name'>Name:</label>
            <input
              type="text"
              name="name"
              id='name'
              {...formik.getFieldProps('name')}
            />
            {formik.touched.name && formik.errors.name ? (
              <div className="error">{formik.errors.name}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='email'>Email:</label>
            <input
              type="email"
              name="email"
              id='email'
              {...formik.getFieldProps('email')}

            />
            {formik.touched.email && formik.errors.email ? (
              <div className="error">{formik.errors.email}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='quantity'>Order Quantity:</label>
            <input
              type="number"
              name="quantity"
              id='quantity'
              required
              {...formik.getFieldProps('quantity')}
            />
            {formik.touched.quantity && formik.errors.quantity ? (
              <div className="error">{formik.errors.quantity}</div>
            ) : null}
          </div>

          <button type="submit" className="submit-btn">
            Submit Order
          </button>
        </Form>
      </div>
    </Formik>
  )
}

Next, we introduce the Field component to simplify form field handling. Currently, we are using the getFieldProps helper method for each field, passing its corresponding name as an argument. However, we can further abstract this process to make our code cleaner and more efficient.

To achieve this, we import Field from Formik and replace our existing <input> elements with the Field component. This allows us to remove the getFieldProps helper method from each field, streamlining our form implementation. Our updated code now looks like this:

import "./order.css"
import { Formik, Form, Field } from "formik"
import * as Yup from "yup"


const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}

const validationSchema = Yup.object({
  name: Yup.string().required("Name is required"),
  email: Yup.string().email("Invalid email format").required("Email is required"),
  quantity: Yup.number().required("Quantity is required")
})


export const OrdersForm = () => {
  return (
    <Formik initialValues={initialValues} validationSchema={validationSchema} onSubmit={onSubmit}>
      <div className="form-container">
        <h2>Order Submission Form</h2>
        <Form>
          <div className="form-group">
            <label htmlFor='name'>Name:</label>
            <Field
              type="text"
              name="name"
              id='name'
            />
            {formik.touched.name && formik.errors.name ? (
              <div className="error">{formik.errors.name}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='email'>Email:</label>
            <Field
              type="email"
              name="email"
              id='email'
            />
            {formik.touched.email && formik.errors.email ? (
              <div className="error">{formik.errors.email}</div>
            ) : null}
          </div>

          <div className="form-group">
            <label htmlFor='quantity'>Order Quantity:</label>
            <Field
              type="number"
              name="quantity"
              id='quantity'
              required
            />
            {formik.touched.quantity && formik.errors.quantity ? (
              <div className="error">{formik.errors.quantity}</div>
            ) : null}
          </div>

          <button type="submit" className="submit-btn">
            Submit Order
          </button>
        </Form>
      </div>
    </Formik>
  )
}

Our form errors are still referencing formik, which was previously invoked through the useFormik hook that we have now removed. To address this, we will use the ErrorMessage component.

Currently, we are manually checking whether a field has been visited and whether an error exists before displaying the error message. Since we repeat this process for all three form fields, it introduces unnecessary redundancy. The ErrorMessage component helps eliminate this repetition.

As with the other Formik components, we first import ErrorMessage from Formik. Then, we replace our existing error messages with the ErrorMessage component, passing a name prop that matches the corresponding Field component’s name attribute.

We've successfully reduced the amount of code significantly and introduced yup for creating a validation schema. In the next article, we'll explore how to disable the submit button, load saved data, and reset the form data.

Formik & React (Part 2): Enhancing Validation & Error Handling

Babatunde Adeniran — Mon, 03 Mar 2025 17:28:57 +0000

In our previous article, we introduced Formik and explored how the useFormik hook simplifies form state management, form submission, and validation. However, there are still a few crucial improvements needed to enhance the user experience.

While we have implemented basic validation, there’s room for improvement. Currently, our form does not display error messages or keep track of fields that have already been visited—both of which are essential for a better user experience.

In this article, we’ll address these issues and take our form handling to the next level.

Let’s dive in!

Displaying Error Messages

We already have a validate function that checks for errors in our form fields (name, email, and quantity) and returns corresponding error messages based on our validation rules and conditions. However, we still need a way to display these error messages to the user.

As we’ve established, the formik object returned by the useFormik hook contains various helper methods and useful properties for managing our form. So far, we’ve explored initialValues, onSubmit, and validate.

The validate function helps us retrieve error messages, but how do we access them? Recall that formik.values contains key-value pairs for our name, email, and quantity form fields. Similarly, Formik provides an errors property, which follows the same structure as formik.values—it’s an object with key-value pairs for our form fields, holding their corresponding validation errors.

Let’s log formik.errors to the console and see what it contains.

  const formik = useFormik({
    initialValues,
    onSubmit,
    validate
  })
  console.log("Form errors", formik.errors)

Typically, formik.errors returns an empty object when the page mounts.

However, when we alter the initialValues, the errors object is populated with keys that are similar to that of formik.values from our previous article. We would also see that the value of each error field is the error message we defined in our validate function.

What Formik does under the hood is to run the validate function when the form field changes. The formik.errors object is then populated with error messages based on the rules outlined in the validate function.

Next, we conditionally render error messages from the formik.errors object in JSX.

import "./order.css"
import { useFormik } from "formik"



const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}
const validate = (values) => {
  const errors = {}
  if (!values.name) {
    errors.name = "Name is required"
  }
  if (!values.email) {
    errors.email = "Email is required"
  } else if (
    !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(values.email)
  ) {
    errors.email = "Invalid email address"
  }
  if (!values.quantity) {
    errors.quantity = "Quantity is required"
  }
  return errors
}

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validate
  })

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            value={formik.values.name}
          />
          {formik.errors.name ? (
            <div className="error">{formik.errors.name}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            value={formik.values.email}
          />
          {formik.errors.email ? (
            <div className="error">{formik.errors.email}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            value={formik.values.quantity}
          />
          {formik.errors.quantity ? (
            <div className="error">{formik.errors.quantity}</div>
          ) : null}
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

We would also add an error class to our order.css file.

.form-container {
    width: 350px;
    margin: 40px auto;
    padding: 20px;
    border: 1px solid #ccc;
    border-radius: 8px;
    background-color: #f9f9f9;
    text-align: center;
  }

  h2 {
    margin-bottom: 20px;
  }

  .form-group {
    margin-bottom: 15px;
    text-align: left;
  }

  label {
    display: block;
    font-weight: bold;
    margin-bottom: 5px;
  }

  input {
    width: 100%;
    padding: 8px;
    border: 1px solid #ccc;
    border-radius: 4px;
  }

  .submit-btn {
    width: 100%;
    padding: 10px;
    background-color: #007bff;
    color: white;
    border: none;
    border-radius: 4px;
    font-size: 16px;
    cursor: pointer;
  }

  .submit-btn:hover {
    background-color: #0056b3;
  }

  .error {
    color: red;
    margin-top: 5px;
  }

Although the error messages are displayed correctly, there is still an issue to fix. Currently, error messages for all three fields appear even when we interact with just one input field. This is not an ideal user experience, let's correct it.

Visited Fields

Although the error messages are visible to users, we have to keep track of visited fields so that error messages are not displayed on inputs or fields that are yet to be visited. As it stands, every keyboard event triggers the validate function to be called and this means the form.errors object containing the error messages for name, email, and quantity will be populated at every instance. We only want to display error messages for the field the user has interacted with, and it even makes more sense to display error messages for a field after the user has finished typing in that field.

The onBlur prop tracks which fields have been visited. Adding it to our input fields will resolve this issue. Formik also provides a helper method called handleBlur, which we pass to the onBlur prop.

Formik saves the details of already visited fields in the touched object. The touched object has a similar structure to the formik.errors and formik.values objects.

import "./order.css"
import { useFormik } from "formik"



const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}
const validate = (values) => {
  const errors = {}
  if (!values.name) {
    errors.name = "Name is required"
  }
  if (!values.email) {
    errors.email = "Email is required"
  } else if (
    !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(values.email)
  ) {
    errors.email = "Invalid email address"
  }
  if (!values.quantity) {
    errors.quantity = "Quantity is required"
  }
  return errors
}

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validate
  })

  console.log("Visited form fields", formik.touched)

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.name}
          />
          {formik.errors.name ? (
            <div className="error">{formik.errors.name}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.email}
          />
          {formik.errors.email ? (
            <div className="error">{formik.errors.email}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.quantity}
          />
          {formik.errors.quantity ? (
            <div className="error">{formik.errors.quantity}</div>
          ) : null}
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

If we check the logs for the visited fields on page load, we should see an empty object indicating that none of the fields have been visited.

Let's click in and out of the email field

We can see that the touched object is no longer empty—the email field has been marked as visited. The same applies to the name and quantity fields when touched. The details of the formik.touched object can then be used to dynamically render error messages.

import "./order.css"
import { useFormik } from "formik"



const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values)
}
const validate = (values) => {
  const errors = {}
  if (!values.name) {
    errors.name = "Name is required"
  }
  if (!values.email) {
    errors.email = "Email is required"
  } else if (
    !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(values.email)
  ) {
    errors.email = "Invalid email address"
  }
  if (!values.quantity) {
    errors.quantity = "Quantity is required"
  }
  return errors
}

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validate
  })


  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.name}
          />
          {formik.touched.name && formik.errors.name ? (
            <div className="error">{formik.errors.name}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.email}
          />
          {formik.touched.email && formik.errors.email ? (
            <div className="error">{formik.errors.email}</div>
          ) : null}
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            onBlur={formik.handleBlur}
            value={formik.values.quantity}
          />
          {formik.touched.quantity && formik.errors.quantity ? (
            <div className="error">{formik.errors.quantity}</div>
          ) : null}
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

There are other ways we can define our form validation rules. We will look at that next.

Formik & React: Writing Cleaner, More Efficient Forms

Babatunde Adeniran — Sat, 01 Mar 2025 22:59:28 +0000

The importance of forms in business applications cannot be overemphasized. We use forms to accomplish many tasks and facilitate various processes, such as user registration, user sign-in, feedback collection, and order creation. Because forms are crucial to most web interactions, it is essential to ensure a seamless user experience through effective development.

When creating forms, developers take on numerous responsibilities, including field validation, efficient handling of form data, comprehensive error management, and an optimized form submission process.

In this article, I will explain how we can achieve all these with Formik, a highly useful library for managing forms in React and React Native.

Formik simplifies form handling by managing form data, validation, submission, and error messages efficiently. While React provides multiple approaches to handling forms, Formik abstracts the complex and tedious parts, allowing developers to build advanced forms with ease. It is both scalable and performant, making it an excellent choice for form management in React applications.

We start with a simple presentational React.js form component without any functionality. The goal is to implement form state management, handle form submission, validate inputs, and display error messages. The form is designed for submitting orders for an imaginary company, Love & Light Pizzas Ltd. The order submission form has three fields: name, email, and order quantity. It will also include a submit button.

import "./order.css"

export const OrdersForm = () => {
  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form >
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
          />
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
          />
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
          />
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

.form-container {
    width: 350px;
    margin: 40px auto;
    padding: 20px;
    border: 1px solid #ccc;
    border-radius: 8px;
    background-color: #f9f9f9;
    text-align: center;
  }

  h2 {
    margin-bottom: 20px;
  }

  .form-group {
    margin-bottom: 15px;
    text-align: left;
  }

  label {
    display: block;
    font-weight: bold;
    margin-bottom: 5px;
  }

  input {
    width: 100%;
    padding: 8px;
    border: 1px solid #ccc;
    border-radius: 4px;
  }

  .submit-btn {
    width: 100%;
    padding: 10px;
    background-color: #007bff;
    color: white;
    border: none;
    border-radius: 4px;
    font-size: 16px;
    cursor: pointer;
  }

  .submit-btn:hover {
    background-color: #0056b3;
  }

After installing Formik, our next step is to import the useFormik hook which the library provides. Since hooks are simply functions, they need to be called within the component. The useFormik hook returns an object containing a variety of methods and properties that can be used within the form. With this Formik object, it becomes easier to achieve our aim of handling form submission, managing the state of the form, and validating input error messages.

FORM STATE MANAGEMENT

We already know that state is an object that determines how a component renders and behaves. At the moment, our form component is an uncontrolled component, which means it is a traditional HTML form input whose value we cannot manage directly. Our order form has three fields, but as it stands, we are not keeping track of the form field values. When we enter something into the input fields, the field value changes. In React, when there are changes in values, we use state variables to keep track of those changes. So, we need state variables for the name, email, and order quantity inputs. Together, these are referred to as the form state.

In Formik, the form state is an object that maintains the value of individual form fields. Therefore, it is crucial to understand how Formik helps manage the form state when form field values change.

We first pass a property called initial values in the object configuration. It is an object that contains the initial values of our form fields. The properties of the initialValues object must correspond with the name attribute of our form inputs.

To track changes in individual form inputs, we add an onChange and value prop to each input. This is similar to basic form handling in React.js, where we assign the state property as the input’s value and handle the onChange event by creating an event handler. With Formik, we use formik.handleChange to handle this event. Additionally, we can sync the value of the input with the state property by accessing formik.values.nameAttribute, as shown below.

import "./order.css"
import { useFormik } from "formik"

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues: {
      name: "",
      email: "",
      quantity: 0
    }
  })
  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form >
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            value={formik.values.name}
          />
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            value={formik.values.email}
          />
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            value={formik.values.quantity}
          />
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

When we log the formik.values object in the console, we would see that it is structured such that the keys are the name attributes of the form fields, and as we type into individual fields, the changes are reflected in each input value.

We see that at every point in time, formik.values reflects the application state.

HANDLING FORM SUBMISSION

So far, we have discussed how the form values are tracked and extracted. However, we have not yet covered how the values are handled when the user clicks the submit button. There are two steps involved in form submission with Formik.

The first step is to specify the onSubmit handler on the <form> tag, just as we listened to change events on form inputs using the onChange handler. Typically, the Formik helper method we previously defined provides a method for handling form submission, called the handleSubmit method.

For the second step, we return to our useFormik hook configuration and pass a second property called onSubmit. By default, the onSubmit method receives the state of the form as its argument. The values argument in the onSubmit method is a reference to formik.values. The onSubmit method is triggered as soon as the submit button is clicked.

import "./order.css"
import { useFormik } from "formik"

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues: {
      name: "",
      email: "",
      quantity: 0
    },
    onSubmit: (values) => {
      console.log(values, "Form data")
    }
  })

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            value={formik.values.name}
          />
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            value={formik.values.email}
          />
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            value={formik.values.quantity}
          />
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

We see that the logs after the submit button is clicked are in sync with the content of the form.

HANDLING FORM VALIDATION

As it stands, we can manage the state of our order form and submit data by clicking a button. However, we have not yet validated our form fields to filter form values based on established rules.

With Formik, we can define a validation function assigned to the validate property, which will be our third property in the useFormik hook configuration. Like the onSubmit property, the validate function receives the values object as an argument by default. There are certain conditions that the validate function must satisfy, one of these is that it must return an object. We assign this object to a variable and return it.

  validate: (values) => {
      const errors: any = {}
      return errors
    }

Another condition that must be fulfilled is that the keys of the values and errors objects must be in sync. Currently, we have values.name, values.email, and values.quantity. Similarly, we will have errors.name, errors.email, and errors.quantity. Additionally, the values of the keys defined in the errors object must be strings that convey the correct error message.

import "./order.css"
import { useFormik } from "formik"

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues: {
      name: "",
      email: "",
      quantity: 0
    },
    onSubmit: (values) => {
      console.log(values, "Form data")
    },
    validate: (values) => {
      const errors = {}
      if (!values.name) {
        errors.name = "Name is required"
      }
      if (!values.email) {
        errors.email = "Email is required"
      } else if (
        !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(values.email)
      ) {
        errors.email = "Invalid email address"
      }
      if (!values.quantity) {
        errors.quantity = "Quantity is required"
      }
      return errors
    }
  })

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            value={formik.values.name}
          />
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            value={formik.values.email}
          />
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            value={formik.values.quantity}
          />
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

Now, let's refactor this code to improve the readability of the userFormik hook.

import "./order.css"
import { useFormik } from "formik"



const initialValues = {
  name: "",
  email: "",
  quantity: 0
}

const onSubmit = (values) => {
  console.log(values, "Form data")
}
const validate = (values) => {
  const errors = {}
  if (!values.name) {
    errors.name = "Name is required"
  }
  if (!values.email) {
    errors.email = "Email is required"
  } else if (
    !/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i.test(values.email)
  ) {
    errors.email = "Invalid email address"
  }
  if (!values.quantity) {
    errors.quantity = "Quantity is required"
  }
  return errors
}

export const OrdersForm = () => {
  const formik = useFormik({
    initialValues,
    onSubmit,
    validate

  })

  return (
    <div className="form-container">
      <h2>Order Submission Form</h2>
      <form onSubmit={formik.handleSubmit}>
        <div className="form-group">
          <label htmlFor='name'>Name:</label>
          <input
            type="text"
            name="name"
            id='name'
            required
            onChange={formik.handleChange}
            value={formik.values.name}
          />
        </div>

        <div className="form-group">
          <label htmlFor='email'>Email:</label>
          <input
            type="email"
            name="email"
            id='email'
            required
            onChange={formik.handleChange}
            value={formik.values.email}
          />
        </div>

        <div className="form-group">
          <label htmlFor='quantity'>Order Quantity:</label>
          <input
            type="number"
            name="quantity"
            id='quantity'
            required
            onChange={formik.handleChange}
            value={formik.values.quantity}
          />
        </div>

        <button type="submit" className="submit-btn">
          Submit Order
        </button>
      </form>
    </div>
  )
}

In the next article, we will cover how to display these error messages, identify visited fields, define a validation schema with Yup, and reduce boilerplate to improve reusability.