DEV Community: Yahaya Oyinkansola

Lessons Learnt Building a Frontend Mentor Project (Part 2)

Yahaya Oyinkansola — Thu, 09 Jul 2026 11:56:57 +0000

If you would like to check out the part 1 of this article, you can read it here, this article is a continuation with another project. In this one, I am sharing what I learnt while building the Easybank landing page.

The best way to grow as a developer, even in this age of AI, is to build projects. Thanks to frontend mentor, they have provided a platform for experienced and newbie developers to build projects that will help them grow and expand their skillsets and knowledge.

To be honest, when I started building this project, I didn't have much expectations for it as taught I won't learn much because building a landing page is not a hard thing for me to do with my current skill level, but it was not until I had a mindset shift that you don't just build projects because you want to build them, you should aim to learn something from it so as to improve your knowledge on how things work as a developer.

Taking this approach to build projects has profound benefits as you would see that even building a simple to-do app or social profile card can teach you a lot when you build it to learn a specific thing. For me, building this project was to help me improve my knowledge of how to use React, and also incorporate TypeScript to write better JavaScript code that is less prone to errors.

Here are the lessons I learnt building this project:

1. Estimating how long it takes to build something

One thing I learnt when it comes to estimation is that life happens and things will definitely not go as planned, so it's important you learn how to adapt and still show up, no matter what. Also, for your estimates to stand a chance of working, you need to gather all the necessary information required to build the project, I am talking about colors, fonts, spacing dimensions etc, don't just rush and open your code editor, I have learnt this the hard way, take out time to plan the project first, understanding what is required to make the project easier to build.

The last thing I will say here is anytime you fixed a deadline you couldn't meet up to, instead of giving up, try and understand why things didn't go as planned (Maybe your estimate was not realistic enough, guilty person here 😅), and make improvements, that's how to keep getting better.

2. Importing images in a React application

Since I learnt React, I have always struggled with understanding how images are used in a React application, it just seemed like a big deal to me, but while making some research, I learnt 2 things:

When an image doesn't change frequently e.g a logo, it's best to put that image in the public folder
When an image is likely to change from time to time e.g an image for a blog article, it makes sense to put that image in the src folder, so it compiles with the code at build time. (let me know if you have a different idea about this).

These 2 lessons helped me understand where to put images, and import them in my code. I put my logo in the public folder and put the images for the blog articles in the src folder because the image for a blog article can always change

3. Showing the active state of a link using a linear gradient

I needed to show a gradient line on links whenever it's hovered on, it was a nice challenge to test my CSS knowledge. Initially, I taught it was going to be a big deal as I am not that much of a CSS fan, but it was not so difficult as my knowledge of CSS helped me get the result I was looking for. Here was what I did

4. Typescript by default doesn't support non-code files

One of the reasons I like building things from scratch is because it helps you understand what's going on under the hood. In React, I didn't realize that TypeScript cannot handle files that are not code related like images, you have to create a TypeScript Declaration file (e.g images.d.ts) before it knows what to do when it encounters those kind of assets. In my application, red lines kept showing where I imported images and css files

It was until I made research on the problem and learnt about TypeScript declaration files, thanks to ChatGPT, that I was able to come up with a solution. A TypeScript declaration file tells TypeScript how to handle certain type of files so that it doesn't throw errors, so I created 2 TypeScript declaration files to tell TypeScript how to handle images and css files

Note: If you use Vite to create a React project, it comes with a TypeScript declaration file by default called vite-env.d.ts which has all the declaration needed for most file types, but I deleted mine by mistake, don't ask 😂, I thought it wasn't necessary, but it was good I did that as I wouldn't have learnt this lesson.

Conclusion

Learning these concepts have helped me improve my knowledge about React and how to use TypeScript in a React application, and has given me more confidence to build complex web applications. Here is a live preview of the project.

As a beginner or even expert React developer, what lessons have you learnt that gave you that aha moment while learning and building projects with React?

Typing Object Keys in TypeScript with keyof typeof

Yahaya Oyinkansola — Mon, 29 Jun 2026 16:14:25 +0000

TypeScript is great at catching mistakes before they reach your users, but sometimes, it catches things that don't feel like mistakes at all. You write what looks like perfectly reasonable code, and TypeScript pushes back with an error about types being too broad. One of the most common places this happens is when you try using a variable as an index in an object.

While building a client invoice web application, I ran into this problem. I had a config object mapping invoice statuses to Tailwind CSS classes, and I wanted to look up the right styles based on a status prop but TypeScript refused. The fix turned out to be two small keywords: keyof typeof.

In this article, I will explain what the problem was, what those keywords do, and why this pattern is worth reaching for whenever you're working with objects in TypeScript with a specific object structure.

The Problem

I have a status badge component and a config object mapping statuses to Tailwind classes:

const statusConfig = {
  Paid: {
    dot: "bg-emerald-400",
    bg: "bg-emerald-50",
    text: "text-emerald-600",
  },
  Pending: {
    dot: "bg-amber-400",
    bg: "bg-amber-50",
    text: "text-amber-600",
  },
  Draft: {
    dot: "bg-slate-400",
    bg: "bg-slate-100",
    text: "text-slate-500",
  },
};

export default function App() {
   function StatusBadge({ status }: { status: string }) {
     const cfg = statusConfig[status];
     return cfg;
   }

   console.log(StatusBadge("Pending")); // TypeScript shows an error

   return (
      <h1>Content goes here</h1>
   )
}

This is the error TypeScript throws:

status has an implicit type of 'any' because expression of type 'string' can't be used to index type '{ Paid: ...; Pending: ...; Draft: ...; }'

The issue is that status is typed as a string which is too broad. TypeScript can't guarantee that an arbitrary string will match any of the 3 keys in the statusConfig object. The fix is to use the keyof typeof type in TypeScript.

keyof typeof

The keyof typeof operator extracts the keys of an object as a union type

keyof typeof statusConfig;
// Equivalent to: "Paid" | "Pending" | "Draft"

typeof statusConfig – This tells TypeScript to get the type of the data in question, which in this case is an object
keyof – This tells TypeScript to extract all the keys from the object as union types. It will convert the keys in the object into a set of possible options. This way, TypeScript has an idea of the shape of the statusConfig object.

Applying this in the StatusBadge component:

function StatusBadge({ status }: { status: keyof typeof statusConfig }) {
  const cfg = statusConfig[status]; // It now works perfectly
  return cfg;
}

You could also save this as a type variable to make the code more readable:

type statusType = keyof typeof statusConfig;

function StatusBadge({ status }: { status: statusType }) {
  const cfg = statusConfig[status];
  return cfg;
}

Now TypeScript knows that status can only ever be "Paid", "Pending", or "Draft", so indexing into statusConfig is safe.

Why Not Just Use a Type Alias?

You could manually define a type like this:

type Status = "Paid" | "Pending" | "Draft";

And just use that directly, but this will create a maintenance burden. If you were to add or rename a key in statusConfig, you have to update the type separately as well. With keyof typeof, the type is derived directly from the object, so it always in sync as the keys are generated automatically for you, making development faster and less error prone.

keyof typeof is the right tool whenever you need to accept a dynamic value for an object, and you are not sure what that value is. It's a small trick but makes TypeScript work with your data instead of fighting against it.

Conclusion

Type errors like this one can feel like TypeScript getting in your way, but they're usually pointing at something real. In this case, that a plain string is too vague to safely index a specific object. keyof typeof gives you a way to be precise without writing out types by hand, keeping your code both safe and easy to maintain.

Understanding the use of the React Compiler

Yahaya Oyinkansola — Thu, 11 Jun 2026 15:55:45 +0000

If you’ve been learning React for a while, you’ve probably come across hooks that help optimize your application such as useMemo() and useCallback() and might have wondered: "Do I really need these hooks?", "Where are they useful?" etc. In React 19, the React Compiler was introduced and it's work is to help you optimize your application automatically. This raises a question where if React can automatically optimize an application, why should I bother learning how to optimize my app manually with hooks like useMemo()?. Let me break down why you would still need to do manual optimization and what the React Compiler was created to solve in a simple, beginner friendly way.

What Is the React Compiler?

The React Compiler is a new optimization tool developed by the React Team. It's goal is simple:

Automatically make your React app faster without you writing extra optimization code.

Traditionally, React re-renders a component each time the state changes. This is usually fine, but if you have a component that does a lot of work, this can make your app very slow during re-renders. The React Compiler steps in to:

Detect unnecessary re-calculations
Memoize values and functions automatically
Prevent avoidable re-renders

So instead of you writing:

const filteredItems = useMemo(() => filterItems(items), [items]);

The compiler handles it for you behind the scenes.

Why is this such a big deal?

This changes how we write code in React, it helps us avoid over-optimizing our code when it might not need any optimization. Most developers that learn about useCallback() or useMemo() tend to overuse them (guilty party here 😅), resulting in the application behaving much slower instead of faster, hence the need for the React compiler as it optimizes the code where necessary. The React Compiler also provides the following benefits:

1. Less boilerplate code

You don’t have to wrap your optimization logic in useMemo() or useCallback().

2. Fewer mistakes

Manual memoization is easy to get wrong:

Missing dependencies
Over optimization
Breaking logic accidentally etc.

The React Compiler reduces all these risks.

3. Cleaner and more readable code

Instead of thinking about optimization early, you can focus on:

Building features
Writing clean components
Understanding React fundamentals

So does this mean using optimization hooks like useCallback() and useMemo() are no longer necessary?, Absolutely not!. The React Compiler just changes how often you use them, not whether you should learn them or not.

Why You Still Need to Learn `useMemo()` and `useCallback()`

You should understand that these hooks exist for a reason and where created to solve a problem:

Prevent expensive re-calculations (useMemo())
Prevent unnecessary function re-creation (useCallback())

If you don't understand why re-renders happen and how React compares values together to know what needs to update in the UI, you will struggle to optimize your code, and trust what the React Compiler is doing. In other words, you will be in a blackbox, thinking everything been done is magic, and no one likes being in that kind of situation.

The React Compiler isn't magic, it's a tool for building performant React applications easily, but you still need to understand how to optimize a web application. This is necessary because:

Some older projects don't use the React Compiler
Some edge cases may not be optimized
You might need manual control in complex scenarios

Having proper knowledge of how to optimize your React application gives you a huge advantage.

Final Thoughts

The React Compiler is a big step forward. It removes a lot of the pain around performance optimization and lets you focus on building great applications, but it doesn’t replace understanding. As a developer, you still need to learn what useMemo() and useCallback() are actually doing, ensure you don't overuse them and focus on building more on building features before doing any optimization to avoid premature optimization. At the end of the day,

Tools can make things easier, but understanding is what makes you effective.

Cleaner React Logic: Refactoring My Waitlist Submission Flow

Yahaya Oyinkansola — Thu, 04 Jun 2026 12:31:55 +0000

This article is a continuation of the article I wrote on the RLS policy issue I solved with Supabase.

After I had fixed the RLS policy issue, I discovered that the way I structured my code was wrong. Semantically, it looked sort of correct but it was logically wrong. Here's a live preview of the project so you get what I mean.

When a user clicks the "Join early access" button, a function called subscribeEmail() is fired. This initially didn't look like a problem as I only considered the fact that users will be clicking the button once when they want to sign up for the waitlist, I didn't take into account that users could click the button multiple times (This could have been avoided if I disable the button once they click on it), but even though I were to disable the button, if the user clicks on the button again after the disabled property is removed, I will still encounter the same issue.

Here's the code:

"use client";

import { useState } from "react";
import { subscribeEmail } from "@/lib/supabase";

export default function WaitList() {
  const [email, setEmail] = useState("");
  const [status, setStatus] = useState<
    "idle" | "loading" | "success" | "error"
  >("idle");

  const handleSubmit = async (e: React.SubmitEvent<HTMLFormElement>) => {
    e.preventDefault();

    setStatus("loading");
    const { error } = await subscribeEmail(email);

    if (error) {
      setStatus("error");
    } else {
      setStatus("success");
      setEmail("");
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Enter your email address"
        required
      />
      <button
        type="submit"
        disabled={status === "loading"}
      >
        {status === "loading" ? "Joining..." : "Get Early Access"}
      </button>
    </form>
  );

Doing it this way makes it unavoidable to keep calling subScribeEmail() when the button is clicked as all the logic is tied to that function. Calling this function will mean the user keeps trying to add themselves to the db, even though they might already be added, before attempting to send them a confirmation email. What I was looking to accomplish is resending the user a confirmation email only when it fails.

To solve this problem, I rewrote the entire logic for the waitlist functionality. First of all, when the user enters their email and clicks the "Join early access" button, I first check if their email already exists. If it does, that means they have been added to the waitlist, else, they haven't yet joined

import {
  getUserEmail,
  subscribeEmail,
  updateEmailStatus,
} from "@/lib/supabase";
import { sendConfirmationEmail } from "@/utils";

const handleSubmit = async (e: React.SubmitEvent<HTMLFormElement>) => {
  e.preventDefault();

  setStatus("loading");

  const { data, error } = await getUserEmail(email);

  if (data.length === 0) {
    // User has not been added to the waitlist
    const { error } = await subscribeEmail(email);

    if (error) {
      setStatus("error");
      toast.error(error);
      return false;
    }

    setStatus("success");
    setEmail("");

    return true;
  }

  // If it reaches here, then they have been added
  const { error: emailConfirmationError } = await sendConfirmationEmail(email);

  if (emailConfirmationError) {
    setStatus("error");
    return false;
  }

  const { error: emailStatusError } = await updateEmailStatus(
    email,
    "delivered",
  );

  if (emailStatusError) {
    setStatus("error");
    return false;
  }

  setStatus("success");
  setEmail("");
};

This way, I am able to know the state of the user, whether they have been added or not, and know which code to execute. There is one last scenario to consider here, what if the user has been added to the db and a confirmation email was sent to them but they still submit the form?. To combat that issue, I simply display a message indicating that they have already been added to the DB, and the confirmation email has been sent to them.

Solving this problem made me realize the importance of thinking through the problem you are trying to solve before writing any line of code. Being able to understand what you are trying to do is more important than just opening your editor to write code. Once you understand the problem you are trying to solve and do some research on it, you will definitely arrive at a solution.

Fixing an email confirmation problem in Supabase

Yahaya Oyinkansola — Wed, 20 May 2026 13:05:25 +0000

There’s a special kind of frustration reserved for bugs that produce no errors. Your code runs; the logic executes as expected, but you aren’t getting the output you expect, and things aren’t functioning as they are supposed to. This was an issue I had with a column in my database. I was sending a confirmation email to users when they registered for a waitlist, but each time I add them to the database, and try sending them a confirmation email, it won’t work. In this article, I will discuss how I was able to fix this. Turns out the problem was actually quite simple but hard to decipher.

My goal was straightforward: Send the user a confirmation email when they are successfully added to the waitlist, and then update the email_status column in the database to reflect the status of the email delivery. The 3 possible delivery states are pending, delivered, and failed. This was simple enough in theory, but not in application. After the email was sent successfully, the email_status column stubbornly stayed on pending; no error was thrown, no warning, just silence. The issue wasn’t that the email wasn’t sending or even failed to send in some cases, but that the email_status column wasn’t reflecting the delivery status of the email. After days and almost a week of debugging this issue, I figured out the problem was a missing RLS Policy for UPDATE Operations.

RLS Policy in Supabase

If you are unfamiliar with how Supabase works, you must create something called an RLS (Row Level Security) Policy to be able to run specific operations on a table. Having these policies set up tells Supabase you are authorized to perform actions on a table to modify its data. These operations include updating a table, deleting data from a table, adding data to a table, etc.

The RLS policy is a security feature designed by Supabase to ensure no one can just run any kind of operation on a table, and it also gives developers the ability to control who is allowed to do what. I didn’t understand this early enough and kept thinking maybe something was wrong with my SQL query or the function that executes the Supabase operation. The RLS policy is deny-by-default, which means that if there’s no policy explicitly permitting an operation, that operation is silently blocked. So in my own case, my INSERT query worked because I had a policy for it set up, but my UPDATE query failed because there wasn’t any policy set up for that operation.

Here’s how you add an update policy in Supabase for users that are authenticated via SQL:

CREATE POLICY "Allow update for authenticated users"
  ON users
  FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

It’s the same format when you want to add a policy for other operations, like SELECT

CREATE POLICY "policy-name"
  ON "tablename"
  FOR SELECT
  USING true

In my own case though, I didn’t have any authenticated users since it was just a waitlist, so what I did was to set the value of USING and CHECK to true to allow the query pass. In a normal scenario, it is authenticated users that should be able to perform operations against your database and not just anyone.

CREATE POLICY "update email status"
  ON waitlist
  FOR UPDATE
  USING true
  WITH CHECK true;

You can also create policies from your Supabase dashboard if you don’t want to write any code; they make the process very easy. When you enter the dashboard, select the table editor, look for the 3 dots beside your table, select it, and choose the View Policies option to create or disable policies for that table.

Tip: Always ensure you have policies set up for every operation you intend to perform. SELECT, INSERT, UPDATE, and DELETE all need their own policies. Don’t assume 1 covers the rest.

With this set-up, I was able to resolve the issue, and now whatever the result of the email delivery was, the email_status column updates to reflect that, giving me the feedback I need to either resend the email or tell the user to try again later.

Conclusion

Supabase is a great service for building full-stack apps. I highly recommend it. You just have to understand how it works so you don’t get blocked by issues like RLS policy. In case you or anyone gets an issue similar to this, this is most likely the solution: a missing RLS policy not set up in your table. It’s easy to forget setting an RLS policy, especially if you are coming from a MySQL background. I never had to do this with MySQL, so it took some getting used to.

I am Oyinkansola, a front-end developer building engaging web experiences and performant websites for car dealerships, helping them turn online visitors into showroom customers. I also share insights and lessons learnt around projects I am building, as well as insights about front-end development. You can connect with me on X and LinkedIn. I love connecting with developers and tech people.

A Simple Guide to Idempotency

Yahaya Oyinkansola — Tue, 24 Mar 2026 17:14:05 +0000

Have you ever been on a checkout page, clicked the "Pay Now" button, and nothing happened?. Your first instinct might be to click it again, or maybe three more times to be sure it went through. In a poorly designed system, those extra clicks could mean you get charged four times for the same pair of shoes. In a well-designed system, no matter how many times you smash that button, you are only charged once. This reliability is thanks to a concept called Idempotency.

What exactly is Idempotency?

Idempotency is a safety guarantee that ensures making the same request multiple times has the exact same result as making it just once. Think of it like an elevator button, If you enter an elevator and press the "5" button, the elevator knows to go to the fifth floor. If you get impatient and press the "5" button ten more times, the elevator doesn't go to the fifth floor ten times; it simply stays committed to the original destination. The outcome remains the same regardless of the extra presses.

Why is this so Important?

In the world of software and APIs, things don't always go smoothly:

Wrong data gets sent to the user
A mobile connection drops as soon as you hit "Submit"
A server takes a second too long to respond etc.

When these hiccups happen, the system might automatically retry the request, or the user might manually click the button again. Without idempotency, these "retries" can cause unintended side effects such as:

Duplicate payments
Unexpected results the user shouldn't see and
Data corruption.

When I first came across this issue, I thought the developer isn't the only one to be blamed, users too should be more careful, but that is wrong. You can't expect people to always be careful, making mistakes is part of human nature, moreover, people are impatient, including developers. When users don't get any response from your application after performing an action, it's normal for them to try again as no feedback was given. This is why as a developer, you are not just building intuitive UI's, you also need to consider how your app works from a UX perspective.

The Role of User Experience (UX)

While the heavy lifting happens behind the scenes on the server, the front-end plays a huge role in preventing issues such as double payment before it reaches the server. A great user experience keeps the user informed so they don't feel the need to take an action twice, this can be done through:

Providing Visual Feedback: Disabling a button and showing a "Processing..." message, or a loading spinner indicating something is being processed behind the scenes.
Clear Progress Bars: Showing the user exactly where they are in the process.
Success Confirmations: Immediately moving the user to a "Thank You" or "Successful payment" page so there's no doubt the action was completed.

When you factor in the user experience your application provides, it becomes easier to prevent this mistakes from occurring in your application, and this allows users trust your application more. Now I am not saying UX is simply enough to implement Idempotency, it definitely isn't, but it helps prevent some issues if done right, not everything is necessarily a back-end problem, the front-end too can handle some things.

Conclusion

Idempotency might sound like a complex technical term, but it’s really just about predictability. Whether you are building a task manager or a massive e-commerce platform, ensuring that an action can only happen once, even if it's done twice is the key to building software people can trust.

In a world where technology is constantly moving fast and people love things to be done quickly, Idempotency is a concept to keep at the back of your mind as a developer (whether front-end, back-end or full-stack) to ensure your apps work properly without unexpected errors and behaviors.

I am Oyinkansola, a front end developer helping service-based business attract their ideal customers online through well engineered websites. I also share my work and insights on X and LinkedIn if you like to check me out over there as well.

A Guide to Precise Age Calculation in React

Yahaya Oyinkansola — Thu, 19 Mar 2026 18:44:52 +0000

Have you ever visited a site that told you your exact age in days, months and years?, most likely not (lol), so I will introduce you to one today thanks to this project from Front End Mentor. I'll be explaining the underlying logic behind calculating a person's age in days, months and years using React and a date library that makes it easy to work with dates.

Here's a live preview of the project: Link.

I assume you already have knowledge of React (basic understanding is fine), so I will skip over installation and setting up a React project.

The Core Idea

Calculating a person's age means finding the difference between two dates: The person's birth date and today’s date, but because months have different lengths (and leap years exist), it’s not as simple as subtracting years directly. If you have ever worked with dates before, you know how stressful they can be.

I personally hate working with dates 😅, as they get complicated and confusing quickly. Due to the difficulty involved in using dates, solutions have been built to make working with them easier; one such solution is the dayjs library. I particularly love this library because of the helpful methods it provides for retrieving date information. It also allows you to combine methods together to form your own date validation logic. We would use this library to perform the age calculation.

Building The Age Calculation Logic

Let's create a React component for the UI of the form

import { useState } from "react";

function App() {
  const [formValues, setFormValues] = useState({
    day: "",
    month: "",
    year: "",
  });

  const [output, setOutput] = useState({
    day: "",
    month: "",
    year: "",
  });

  function handleFormValues(e) {
    setFormValues((prevState) => {
      return {
        ...prevState,
        [e.target.name]: e.target.value,
      };
    });
  }

  return (
    <>
      <main className="age-container">
        <form>
          <div className="form-container">
            <div className="input-group">
              <label htmlFor="day">Day</label>

              <input
                type="text"
                id="day"
                name="day"
                value={formValues.day}
                onChange={handleFormValues}
                placeholder="DD"
              />
            </div>

            <div className="input-group">
              <label htmlFor="month">Month</label>

              <input
                type="text"
                id="month"
                name="month"
                value={formValues.month}
                onChange={handleFormValues}
                placeholder="MM"
              />
            </div>

            <div className="input-group">
              <label htmlFor="year">Year</label>

              <input
                type="text"
                id="year"
                name="year"
                value={formValues.year}
                onChange={handleFormValues}
                placeholder="YYYY"
              />
            </div>
          </div>

          <button type="submit" className="submit-btn">
            Calculate
          </button>
        </form>

        <div id="result">
          <h2>
            <span>{output.year}</span> years
          </h2>

          <h2>
            <span>{output.month}</span> months
          </h2>

          <h2>
            <span>{output.day}</span> days
          </h2>
        </div>
      </main>
    </>
  );
}

export default App;

I will skip styling the form, and validating the inputs, they are not important for this article.

Inside our component, let's handle the logic to calculate the users age when they submit the form.

import { useState } from "react";
import dayjs from "dayjs";
import customParseFormat from "dayjs/plugin/customParseFormat";

dayjs.extend(customParseFormat);

function App() {
  const [formValues, setFormValues] = useState({ ... });
  const [output, setOutput] = useState({ ... });

  function handleFormValues(e) { ... }

  function handleSubmit(e) {
    e.preventDefault();

    const { day, month, year } = formValues;

    let noOfMonths = 0;
    let noOfDays = 0;
    const currentDate = dayjs();
    const inputDate = dayjs(`${year}-${month}-${day}`);
    const checkValidDate = dayjs(
      `${year}-${month}-${day}`,
      "YYYY-MM-DD",
      true,
    ).isValid();

    if (!checkValidDate) {
      return new Error("Date is Invalid")
    }

    if (inputDate.month() > currentDate.month()) {
      noOfMonths = 12 - (inputDate.month() - currentDate.month());
    } else {
      noOfMonths = currentDate.month() - inputDate.month();
    }

    if (inputDate.date() > currentDate.date()) {
      noOfDays =
        inputDate.daysInMonth() - (inputDate.date() + currentDate.date());
    } else {
      noOfDays = inputDate.date() - currentDate.date();
    }

    const yearDiff = Math.abs(inputDate.diff(currentDate, "year"));
    const monthDiff = Math.abs(noOfMonths);
    const dayDiff = Math.abs(noOfDays);

    setOutput((prevState) => {
      const newOutput = {
        ...prevState,
        day: dayDiff,
        month: monthDiff,
        year: yearDiff,
      };

      return newOutput;
    });
  }

  return (
    <>
      <main className="age-container">
        <form onSubmit={handleSubmit}>...</form>
        <div id="result">
          <h2>
            <span>{output.year}</span> years
          </h2>

          <h2>
            <span>{output.month}</span> months
          </h2>

          <h2>
            <span>{output.day}</span> days
          </h2>
        </div>
      </main>
    </>
  );
}

export default App;

What’s Happening Here?

We first import the dayjs library and a plugin to extend the functionality of dayjs.

Why is this plugin necessary?

By default, day.js can only parse standard date formats (like ISO strings), but it cannot parse custom date formats e.g "February 20th, 2026", this is where the customParseFormat plugin comes in. With this plugin, we can extend the functionality of dayjs to parse custom dates. Even though we imported this plugin, this particular line is important

dayjs.extend(customParseFormat);

This line tells dayjs to enable this plugin and add its features to the core library. Without it, the plugin has no effect and we won't be able to parse any custom date.

Secondly, we assign the current date gotten from calling dayjs() into a variable to have one instance of that function call we can use multiple times.
We pass the day, month and year values gotten from our form into dayjs() to convert the date into a day.js date object we can work with.
We then check if the date passed in by the user is valid, if it isn't, we return an error and stop the remaining code from executing.

The main logic starts when we want to calculate how old a user is in months and days.

How no of months is calculated

If the user's birth month is greater than the current month, that means they have not yet reached their birth month, so we can't just minus the current month from the user's birth month alone. To get the right month value, we first minus the current month from the user's birth month, then substract the result from 12 (12 being the total number of months in a year).

If the user's birth month is less than or equal to the current month, this means they have already passed their birth month or the current month is their birth month, so we can just substract the current month from their birth month directly.

Once we've gotten the right month value, we store it in the noOfMonths variable.

How no of days is calculated

Moving over to calculating the users age in days, if the day of the user's birthday is greater than the day of the current date, that also means they haven't reached their birthday yet, so we add the day of the user's birthday to the day of the current date and minus it from the number of days that month has, because months have different no of days in them e.g february (28), March (31) etc, so doing it like this ensures we are considering the correct amount of days a month has. If the day of the users birthday is not greater than the day of the current date, we just minus the day of the users birthday from the day of the current date. We store the result of this calculation inside the noOfDays variable.

Calculating the Year

Calculating the year is the simplest thing we have to do, we just minus the users birth year from the current year to get how old they are in years. I wish the rest where this straight forward!.

After running all these calculations, we use the abs() function to convert negative values to positive equivalents before outputting the result in the UI.

Now I know this might have been confusing for you, day of the users birthday, month of the current month 😂😂, what's this guy even saying?, it took me a while to understand it as well, so it's perfectly fine if you're not getting it. This is why I said working with dates is confusing and frustrating, but that's why libraries like dayjs makes this a bit simpler but you still have to do some calculations, but imagine doing this calculation using JavaScript's Date() object?, it will most likely be 10x harder.

Conclusion

This basically is the whole process involved in calculating a users age in days, months and years. Age calculation doesn't have to be a difficult task, with the right logic and a helping hand from libraries like day.js, you can turn a tedious math problem into a simple solution.

Thanks for sticking to the end (if you did). I am Oyinkansola, a front end developer helping service-based businesses attract their ideal customers online through well engineered websites. You can check out my Portfolio and follow me on X and LinkedIn.

Lessons Learnt Building a Frontend Mentor Project

Yahaya Oyinkansola — Wed, 15 Oct 2025 11:00:09 +0000

One of the best ways I’ve found to sharpen my frontend development skills is by building real projects, and no better way to do that than with Frontend Mentor. A while back, I built a Newsletter form project where users can sign up for a newsletter (like on a landing page). At first glance, it looked simple, but I ended up learning quite a lot along the way.

In this article, I am going to share the challenges I faced and the lessons I learnt while working on this project. Here's the live link and GitHub repo to check it out.

1. Discovering the `<picture>` Element

One of my favorite discoveries was the <picture> element. The UI of the form had 2 images, one for desktop and one for mobile, so I needed to display the right image depending on the users screen. One solution might have been to use 2 <img /> tags and render the appropriate image using media queries, but I decided to look for a better solution, and that's when I came across the <picture> element.

The <picture> element allowed me specify different image sources using a <source> element, based on the users screen width. For example, I could show a wide desktop image for larger screens and a smaller, optimized one for mobile.

<picture>
  <source srcset="desktop-image.png" media="(min-width: 80em)"></source>

  <img src="mobile-image.svg" alt="" />
</picture>

This did not only save me time, but also made my code cleaner and more responsive. It was a reminder that sometimes, the best solutions are already built into HTML, you don't have to use CSS or JavaScript to implement certain features, you just need to discover the appropriate HTML tag.

2. Practicing the BEM Naming Convention

Another big win was putting the BEM (Block, Element, Modifier) naming convention into practice for my CSS.

Usually, I write class names based on what comes to mind in the moment, which eventually made my CSS look messy and hard to maintain. With BEM, my class names became more structured and predictable. For example, instead of writing something vague like .error, I had a class called .newsletter__input--error. This made it clear where the class belonged, what it targeted, and how it was different from other elements.

BEM might feel a little verbose, and is definitely not compulsory for every project, but the clarity and scalability it brings are worth it, especially in bigger projects.

3. Leveling Up with TypeScript

This was my first real attempt building a project with TypeScript. I decided to code the logic part of the project in TypeScript, and it was a real eye-opener. At first, it felt strict and annoying honestly as the compiler kept throwing errors, but I quickly realized it was helping me avoid mistakes I wouldn’t have easily caught.

Here are a few TypeScript lessons I learnt:

Type Assertion – I came across an issue where TypeScript couldn’t figure out an element was an input element, and because of this, I couldn't access some of the properties it had. To solve this problem, I used type assertion to specify the element was of the type HTMLInputElement so TypeScript would know what type the element is. This is due to the fact that TypeScript doesn't look at your HTML, only JS code, that's why you need to explicitly define what type an element is. This gave me more confidence in how I was using that element.
```
const element = document.querySelector(".newsletter__input") as HTMLInputElement;
```
Optional Chaining (?.) – This was a lifesaver. Instead of worrying if an element existed or not, I used optional chaining to safely check before running operations. If the element didn’t exist, the code wouldn’t execute, and more importantly, the app wouldn’t break. Note that optional chaining is not a TypeScript specific feature, it can also be used in JavaScript, but I discovered it with TypeScript.

const newsletterForm = document.querySelector(".newsletter__form");

newsletterForm?.addEventListener("submit", e => {
  // Content here
})

These small lessons added up and made me feel much more comfortable working with TypeScript, reinforcing the fact that it’s a powerful tool for writing safer and more maintainable code.

Final Thoughts

What looked like a simple Frontend Mentor challenge turned out to be a great learning experience. I walked away with new knowledge of the <picture> element, more discipline in how I write CSS thanks to BEM, and stronger TypeScript skills.

The best part?, each lesson I learnt is something I can apply in future projects, whether it’s building responsive layouts, organizing my styles better, or writing more reliable JavaScript.

If you’re also working through Frontend Mentor projects or any project really, I encourage you to treat it as an opportunity to experiment with new tools and best practices. You’ll be surprised how much you can learn, even from the simple challenges.

If you are reading my content for the first time, I am oyinkansola, a frontend developer helping small businesses build clean and responsive websites that help them grow online. You can also find me on LinkedIn and X, and also check out my portfolio

How I Discovered TypeScript’s Record Utility Type (And How It Solved My Problem)

Yahaya Oyinkansola — Wed, 24 Sep 2025 07:35:36 +0000

Ever ran into errors in TypeScript and it took you hours to figure out?, that was me recently while building a personal project. In this article, I want to go over how I solved a TypeScript problem in my React application using one of TypeScript's pre-defined types.

While working on one of my personal projects, I ran into a TypeScript error that got me confused. I had a component that rendered a list of tasks grouped by the date they were added, the tasks were coming in as a prop called taskslist which is an object, and I converted that object into an array using Object.entries() so I can loop over it and display each task on the screen.

const Todos = ({ taskslist }) => {
  return (
    <>
      {Object.entries(taskslist).map(([date, tasks], index) => (
        <section key={index}>
          <TodoHeader date={date} noOfTasks={tasks.length} />
          <div>
            {tasks.map((task, index) => (
              <TodoItem key={index} task={task} />
            ))}
          </div>
        </section>
      ))}
    </>
  );
};

Everything worked at runtime, but I kept getting this error from TypeScript

// unknown being tasks
Property 'length' does not exist on type 'unknown'.

TypeScript didn’t know tasks was an array because Object.entries() returns data in the form [string, any][] or [string, unknown][] if in strict mode, so the compiler couldn’t infer that tasks had a length property or a map method.

The Solution

After making some research and analyzing my code, I realized the problem wasn’t Object.entries itself, but that I never explained to TypeScript the shape of taskslist. To fix this, I needed to be explicit about how taskslist is defined, that’s when I discovered the Record type.

What is Record?

Record is a built-in utility type in TypeScript. It's a cleaner way of specifying how the shape of an Object looks when we have keys and values that are predictable. It's syntax looks like this:

Record<KeyType, ValueType>

It basically says:

I want an object whose keys are of type KeyType, and whose values are of type ValueType.

For example:

type UserRoles = Record<string, string>;

const roles: UserRoles = {
  alice: "admin",
  bob: "editor",
};

This is equivalent to writing:

type UserRoles = {
  [key: string]: string;
};

Applying Record to My Problem

In my case, I wanted taskslist to be an object where:

The keys are strings representing dates like "2025-09-16".
The values are an array of tasks.

So I defined my types like this:

type Task = {
  id: number;
  title: string;
  ...
};

type TodosProps = {
  taskslist: Record<string, Task[]>;
};

then updated my component:

const Todos = ({ taskslist }: TodosProps) => {
  return (
    <>
      {Object.entries(taskslist).map(([date, tasks], index) => (
        <section key={index}>
          <TodoHeader date={date} noOfTasks={tasks.length} />
          <div>
            {tasks.map((task, index) => (
              <TodoItem key={index} task={task} />
            ))}
          </div>
        </section>
      ))}
    </>
  );
};

Now, TypeScript instantly knew that tasks was of the type Task[], and hence, gave no more errors about length or map.

I liked this solution because it provided me with 3 things
Clarity – Anyone reading the code, including me, can immediately understand the shape of taskslist.

Safety – If I accidentally try to pass in the wrong type, TypeScript will catch it.

Reusability – I can reuse the Task type in other parts of my app without duplication.

Conclusion

Learning about Record felt like unlocking a small but powerful superpower in TypeScript. Instead of fighting the compiler, I was able to guide it with the right information, and it rewarded me with better type safety and cleaner code.

If you’ve ever run into a situation where TypeScript doesn’t understand the shape of an object, give Record a try, it might be the missing piece that makes your app work as expected.

I am oyinkansola, a frontend developer helping productivity coaches build clean websites and tools that make their work easier. You can connect with me on LinkedIn and X.

What's that one TypeScript type that helped you solve a problem?

How I Applied an Higher Order Array Method In a Project

Yahaya Oyinkansola — Wed, 17 Sep 2025 18:11:58 +0000

One of the most exciting parts of being a programmer is when you finally get to apply a concept you’ve learnt in a real-world scenario. In JavaScript, I learnt about higher order array methods like map() and filter(), but more importantly, how chaining them together might produce more sophisticated results. It is one thing to know how these methods work, and another to solve an actual problem with them.

That’s exactly what happened while I was building the multi-step form project from Frontend Mentor. I discovered a practical use case for chaining higher order array methods together, specifically map().

Here's a live demo of the project. Let's get into the nitty gritty

The Challenge

In the 3rd step of the form, users are to select add-ons for their subscription plan. The application has two billing types (Monthly & Yearly) which is being selected from the 2nd step with a toggle, so when the billing type changes, the price for the add-ons should immediately reflect the billing type selected, but there was an issue.

The issue was that whenever the toggle changed, the state that held the users selected add-ons did not immediately reflect the price change, except if they re-select it again, which isn't very efficient. I needed a way to automatically update the state whenever the billing type changes so it reflects in the UI.

My Approach

Here’s how I was able to solve the problem:

Loop through the users selected add-ons – I used .map() on the selectedAddons state which is an array
Find the matching add-on from the default list – After mapping through the array, I used the findIndex() method to go through an array of pre-defined add-ons to find each addon that matches the users selected own.
Update the price dynamically with the index – This is where the chaining happens. I built a new array with .map() to update the prices of the users selected add-ons
React to state changes – I used useEffect() to listen for changes in the radioChecked state (the toggle). Whenever it changed, the code in the steps above runs, updating the state and re-rendering the UI

With this approach, the user doesn't have to re-select their add-ons before the price updates

The Code

Here’s a simplified version of the code that brought it all together:


import { useState, useEffect } from 'react';

// Addons is an array of objects
const addons = [];

export default function App() {

const [selectedAddons, setSelectedAddons] = useState([]);

useEffect(() => {
  const updateSelectedAddons = selectedAddons.map(selectedAddon => addons.findIndex(addon => addon.name === selectedAddon.name)).map(index => {
return {
      ...addon,
      price: radioChecked ? addons[index].monthlyPrice 
        : addons[index].yearlyPrice
    };
})

setSelectedAddons(updateSelectedAddons);
}, [radioChecked]);
}

With just a few lines of code, .map() and useEffect() worked hand-in-hand to keep the UI consistent and responsive to user actions.

Conclusion

This experience made me realize that concepts stick better when you apply them. I had studied .map() and other higher order array functions before, but it was while building this project I understood how they can be applied to solve a problem. This is exactly what programming is about, solving problems.

If you’re learning JavaScript (or any programming language), I encourage you to:

Build projects, even small ones.
Look for opportunities to connect new concepts to real problems.
Don’t just read the theory, apply it.

What concept have you recently learnt as a developer that you applied in a project?

I am oyinkansola, a frontend developer building solutions for non technical businesses, and sharing what I learn along the way, while helping developers write better and smarter code. You can connect with me on LinkedIn and X. Here's a live preview of the project, as well as the GitHub repo.

A TypeScript Fix For Handling Events in React

Yahaya Oyinkansola — Mon, 19 May 2025 12:11:25 +0000

Introduction

Building projects is always a great way to learn and upskill yourself as a developer. While building a project with Front End Mentor using React and TypeScript, I encountered a TypeScript problem in handling a change event which I want to share how I was able to solve.

Prerequisites

Basic understanding of React & TypeScript

In React, when you want to keep track of changes made on an input element, you have to make that input element a controlled input by passing a state to the value prop and handle the updating of that state in a method. Here's an example

import { useState } from "react";

function App() {
  const [fields, setFields] = useState({
    name: "",
    email: "",
  });

  function updateFields(event) {
    setFields((prevFields) => {
      return { ...prevFields, [event.target.name]: event.target.value };
    });
  }

  return (
    <form>
      <input
        type="text"
        name="name"
        value={fields.name}
        onChange={(e) => updateFields(e)}
      />

      <input
        type="email"
        name="email"
        value={fields.email}
        onChange={(e) => updateFields(e)}
      />
    </form>
  );
}

export default App;

Anytime we type inside any input field, the state updates and the update is immediately reflected in the input box. This works fine, but here is the same function written in TypeScript

You will notice a red error line on the event parameter, TypeScript is saying event has an implicit type of any because it doesn't know the specific kind of event we are running. This might be surprising to you because If you look at the JSX Markup, you would expect TypeScript to know we are calling the change event from an input element, but TypeScript doesn't, why?

TypeScript does not look at the JSX Markup of your component, it only looks at your method definitions

This means TypeScript doesn't care about your JSX structure, it only looks at your method definition to know what to do, so it's your responsibility to provide TypeScript with all the necessary information it needs. Since TypeScript doesn't look at our JSX, it needs to know the kind of event we are listening for which is a change event, let's indicate that in our code.

Now the error is gone, anytime you want to specify an event type, you write the event name using PascalCase style. We now have another issue in our code, TypeScript doesn't know what the name and value properties are, why is that?, TypeScript is aware we are calling a change event but it doesn't know which element is calling that change event. At first, this might look stressful, with JavaScript, I don't have to do all this explicit declarations, but understand that the whole point of using TypeScript is to explictly define everything you do in other to make your code scale better, and less prone to errors, so we have to define the type of element that fires off the change event

<HTMLInputElement> tells TypeScript the ChangeEvent is fired from an input element. You now see the errors are gone because TypeScript has more information about what event.target is, so it knows the name and value properties comes from an input element.

As a quick disclaimer, updateFields() will still run even though all these errors we solved are there, but it's only going to work in development. By the time you want to build your project for production, it won't compile.

Conclusion

That's it!, this was how I was able to solve the issues I had with TypeScript while building this web app in React. The same idea works for other types of events as well, you indicate what type of event you are running and tell TypeScript the HTML element that runs the event so that as you write certain properties or methods the element has, it is aware of them. Here's the live url of the project as well as the Github repo if you want to check them out. I am also on X and Linkedin if you want to connect with me. I am open for freelance work too, here's my portfolio.

Why I want to be a Front-End Developer

Yahaya Oyinkansola — Fri, 31 Jan 2025 10:11:17 +0000

Being a developer gives you the unfair advantage of building not just websites and web applications, but tools that solve your problems and that of other people, it's one reason I decided to be a developer, and on that Journey, I am currently working on being a solid front-end developer. In this article, I want to share the reasons why I decided to be a front-end developer, and what I aim to achieve in this software development industry.

Since I was small, I have always liked building stuff, and when I came across web development, I was totally hooked, I started learning how websites are created and how the web works, and that's how I got into this field. I decided to be a front-end developer because I love building beautiful, interactive, and user-friendly websites that enhance people’s digital experiences, the ability to turn designs into functional web applications excites me, and I am always learning to improve my skillset with modern tools and technologies to increase the value I can offer potential clients and businesses.

In other for me to become a highly skilled front-end developer, I realized I needed to participate in hackathons or internships, and I was glad I came across a good internship called HNG Internship. This internship happens every year and I have been participating in it for about 4 years now, this internship always shows me where I am lacking in my skillset, where I am good at and how to work productively as a developer. You can check it out with the link above (The internship has already started for the year, so the next batch might be towards end of the year). One benefit about this Internship is that they make people job ready through series of tasks from easy to complex, and put them in their job talent pool amongst other skilled developers in technologies such as React, NextJS, Vue etc. You can check out some of their React developers and VueJS developers to see the kind of talents they have.

My journey so far as a front-end developer has been an interesting one, I wrote an article about it which you can read here, I have learnt a lot of lessons about building websites and doing work for clients, I always taught building websites was what mattered most, but I never understood that delivering value is what matters, the website is just a means to that end. Thanks to working on some real world projects and the experience gained over the past few years, I have learnt how to work on projects and deliver the Job in the most efficient way possible. All these has helped me become a better developer with good problem solving skills.

My big aim as a software developer is to become a full stack developer that is well knowledgeable in both front-end and back-end technologies to build fully fledged web applications.

Conclusion

One thing I will like to stress on is that you should always have a strong why behind what you are doing, else when challenges come, it will be hard for you to get passed those challenges. My aim in the end is to become a proficient frontend developer who can build large and scalable web applications, HNG internship is just one of the ways I am going about doing that, at the same time, I am improving my skillset from building projects, finding ways to collaborate with other devs and learning new technologies.

DEV Community: Yahaya Oyinkansola

Lessons Learnt Building a Frontend Mentor Project (Part 2)

1. Estimating how long it takes to build something

2. Importing images in a React application

3. Showing the active state of a link using a linear gradient

4. Typescript by default doesn't support non-code files

Conclusion

Typing Object Keys in TypeScript with keyof typeof

The Problem

keyof typeof

Why Not Just Use a Type Alias?

Conclusion

Understanding the use of the React Compiler

What Is the React Compiler?

Why is this such a big deal?

1. Less boilerplate code

2. Fewer mistakes

3. Cleaner and more readable code

Why You Still Need to Learn useMemo() and useCallback()

Final Thoughts

Cleaner React Logic: Refactoring My Waitlist Submission Flow

Fixing an email confirmation problem in Supabase

RLS Policy in Supabase

Conclusion

A Simple Guide to Idempotency

What exactly is Idempotency?

Why is this so Important?

The Role of User Experience (UX)

Conclusion

A Guide to Precise Age Calculation in React

The Core Idea

Building The Age Calculation Logic

What’s Happening Here?

Why is this plugin necessary?

How no of months is calculated

How no of days is calculated

Calculating the Year

Conclusion

Lessons Learnt Building a Frontend Mentor Project

1. Discovering the <picture> Element

2. Practicing the BEM Naming Convention

3. Leveling Up with TypeScript

Final Thoughts

How I Discovered TypeScript’s Record Utility Type (And How It Solved My Problem)

The Solution

What is Record?

Applying Record to My Problem

Conclusion

How I Applied an Higher Order Array Method In a Project

The Challenge

My Approach

The Code

Conclusion

A TypeScript Fix For Handling Events in React

Introduction

Prerequisites

Conclusion

Why I want to be a Front-End Developer

Conclusion

Why You Still Need to Learn `useMemo()` and `useCallback()`

1. Discovering the `<picture>` Element