DEV Community: Favour Afolayan

AI isn't taking our jobs — It's taking our illusions

Favour Afolayan — Tue, 03 Feb 2026 17:17:41 +0000

There’s a growing sentiment that software engineers shouldn’t tie their identity too closely to their work. On the surface, that sounds healthy. But in practice, it’s more complicated.

If most of your adult life has been spent learning, practicing, and becoming genuinely good at one thing, it’s only natural that it becomes part of how you see yourself. We see this shift all the time—people redefine themselves when they get married, have kids, or take on new responsibilities. Identity evolves with focus.

For a long time, software development rewarded deep attention to code: patterns, architecture, edge cases, and craftsmanship. That focus shaped not just our careers, but our sense of value.

Now we’re in a moment where generative AI can produce high-quality code, surface edge cases, and move at a speed that years of experience alone sometimes can’t match. That realization is unsettling. It feels similar to what elite athletes experience near retirement—when the skill they’ve spent their lives perfecting no longer guarantees relevance.

Some reflections from this shift

We were fortunate to get good at something

Not everyone gets the opportunity to spend years honing a valuable skill and be rewarded for it. Many people never become particularly good at what they do. That perspective matters, especially now.
The learning didn’t lose value—it got leveraged

The same discipline we once poured into mastering languages and frameworks should now go into mastering these tools. Concepts that used to take years to internalize can now be explored, tested, and understood in weeks.
Feeling behind is a normal response

Things are moving fast. Not everyone will keep up at the same pace, and that’s okay. This is another moment of professional molting—uncomfortable, but necessary.
Coding was never the whole job

Even before AI, writing code was only part of the role. Context, trade-offs, judgment, communication, and decision-making have always mattered more than raw syntax.
No role is immune

Every job is being pressured to justify its value—even executive roles. Software engineering isn’t special in that regard; it’s just more visible right now.
AI is leverage, not replacement

Giving an experienced engineer AI tools is like giving someone used to a Pentium 4 a modern MacBook Pro. The person didn’t change—their leverage did.
Tools still need orchestration

AI decentralizes access to powerful capabilities, but tools don’t decide what to build, why it matters, or when it’s wrong. Humans still do that work.

A reminder about perspective

At moments of rapid change, pessimism can feel intellectually safer than optimism. But safety isn’t the same as progress.

As Elon Musk put it at Davos:

“For quality of life, it is actually better to err on the side of being an optimist and wrong rather than being a pessimist and right.”

That perspective matters here. The choice isn’t between naïve optimism and informed realism—it’s between freezing in fear and moving forward with intention.

A reframing worth considering

If you feel your relevance or job security being pried from your hands, you might actually be fortunate, that discomfort isn’t necessarily a warning—it may be an invitation, that tension is a signal that it’s time to molt—time to shed an identity built purely on execution and move toward higher-purpose work.

Not everyone gets a forced moment of reinvention. Some coast until they’re obsolete. Others evolve while the pressure is still survivable.

Moments like this strip away the parts of our identity that were overly attached to tools or speed and push us toward higher-leverage work: clearer thinking, better judgment, stronger context-setting, and real responsibility. It’s uncomfortable because growth usually is—but comfort was never where progress lived.

Closing thought

AI didn’t suddenly make our experience useless. It exposed which parts of our value were tied to execution speed—and which parts were tied to understanding.

The future isn’t about competing with tools. It’s about learning how to direct them well—and accepting the responsibility that comes with that.

How to create a custom table component with React and Typescript (Part 2)

Favour Afolayan — Wed, 09 Oct 2024 08:37:57 +0000

Introduction

Yay! 🎉 You've made it to the final part of this two-part series! If you haven't already checked out Part 1, stop right here and go through that first. Don't worry, we'll wait until you’re back! 😄

In Part 1, we built the CustomTable component. You can see it in action here.

In this second part, we’ll be extending the component to add some new features. Here's what we'll be working towards:

To support this, the CustomTable component will need some enhancements:

The ability to format the rendered value—e.g., rendering a number with proper formatting.
Flexibility to allow users to provide custom templates for rendering rows, giving them control over how each column is displayed.

Let's dive into building the first feature.

Extending the Column Interface

We’ll start by adding a format method to the Column interface to control how specific columns render their values.

interface Column<T> {
  id: keyof T;
  label: string;
  format?: (value: string | number) => string;
}

This optional format method will be used to format data when necessary. Let’s see how this works with an example from the Country.tsx file. We’ll add a format method to the population column.

const columns: Column<Country>[] = [
  { id: "name", label: "Name" },
  { id: "code", label: "ISO\u00a0Code" },
  {
    id: "population",
    label: "Population",
    format: (value) => new Intl.NumberFormat("en-US").format(value as number),
  },
  {
    id: "size",
    label: "Size\u00a0(km\u00b2)",
  },
  {
    id: "density",
    label: "Density",
  },
];

Here, we’re using the JavaScript Intl.NumberFormat method to format the population as a number. You can learn more about this method here.

Next, we need to update our CustomTable component to check for the format function and apply it when it exists.

<TableBody>
  {rows.map((row, index) => (
    <TableRow hover tabIndex={-1} key={index}>
      {columns.map((column, index) => (
        <TableCell key={index}>
          {column.format
            ? column.format(row[column.id] as string)
            : (row[column.id] as string)}
        </TableCell>
      ))}
    </TableRow>
  ))}
</TableBody>

With this modification, the population column now renders with the appropriate formatting. You can see it in action here.

Supporting Custom Templates

Now, let's implement the next feature: allowing custom templates for rendering columns. To do this, we’ll add support for passing JSX as a children prop or using render props, giving consumers full control over how each cell is rendered.

First, we’ll extend the Props interface to include an optional children prop.

interface Props<T> {
  rows: T[];
  columns: Column<T>[];
  children?: (row: T, column: Column<T>) => React.ReactNode;
}

Next, we’ll modify our CustomTable component to support this new prop while preserving the existing behavior.

<TableRow>
  {columns.map((column, index) => (
    <TableCell key={index}>
      {children
        ? children(row, column)
        : column.format
        ? column.format(row[column.id] as string)
        : row[column.id]}
    </TableCell>
  ))}
</TableRow>

This ensures that if the children prop is passed, the custom template is used; otherwise, we fall back to the default behavior.

Let’s also refactor the code to make it more reusable:

const getFormattedValue = (column, row) => {
  const value = row[column.id];
  return column.format ? column.format(value) : value as string;
};

const getRowTemplate = (row, column, children) => {
  return children ? children(row, column) : getFormattedValue(column, row);
};

Custom Row Component

Now let’s build a custom row component in the Countries.tsx file. We’ll create a CustomRow component to handle special rendering logic.

interface RowProps {
  row: Country;
  column: Column<Country>;
}

const CustomRow = ({ row, column }: RowProps) => {
  const value = row[column.id];
  if (column.format) {
    return <span>{column.format(value as string)}</span>;
  }
  return <span>{value}</span>;
};

Then, we’ll update Countries.tsx to pass this CustomRow component to CustomTable.

const Countries = () => (
  <CustomTable columns={columns} rows={rows}>
    {(row, column) => <CustomRow column={column} row={row} />}
  </CustomTable>
);

For People.tsx, which doesn’t need any special templates, we can simply render the table without the children prop.

const People = () => <CustomTable columns={columns} rows={rows} />;

Improvements

One improvement we can make is the use of array indexes as keys, which can cause issues. Instead, let’s enforce the use of a unique rowKey for each row.

We’ll extend the Props interface to require a rowKey.

interface Props<T> {
  rowKey: keyof T;
  rows: T[];
  columns: Column<T>[];
  children?: (row: T, column: Column<T>) => React.JSX.Element | string;
  onRowClick?: (row: T) => void;
}

Now, each consumer of CustomTable must provide a rowKey to ensure stable rendering.

<CustomTable
  rowKey="code"
  rows={rows}
  onRowClick={handleRowClick}
  columns={columns}
>
  {(row, column) => <CustomRow column={column} row={row} />}
</CustomTable>

Final Code

Check out the full code here.

Conclusion

In this article, we extended our custom CustomTable component by adding formatting options and the ability to pass custom templates for columns. These features give us greater control over how data is rendered in tables, while also making the component flexible and reusable for different use cases.

We also improved the component by enforcing a rowKey prop to avoid using array indexes as keys, ensuring more efficient and stable rendering.

I hope you found this guide helpful! Feel free to share your thoughts in the comments section.

Thanks for sticking with me through this journey! 🙌

How to build a custom React table component with Typescript (Part 1)

Favour Afolayan — Sun, 16 Jun 2024 20:29:44 +0000

Introduction

The purpose of this article is to show you in a simple way, how to create a fully-typed, reusable Table component. For this, we will be using the Material UI (MUI) Library React table component: https://mui.com/material-ui/react-table to move fast without writing any styling but this could be applied to any table component library

A few things to help you understand how the MUI Library Table component works:

Table Head - renders a that holds the headings for each column of the table
Table Body - renders a that holds the rows that render the data for the table
Pagination (optional) - library-provided pagination component - we won't cover it because it's not our focus in this article

Let's look at the basic components that make each of the parts of a table as mentioned above:

Table Head

This is a component that renders the <th></th> element for each column and wraps it with the right html tags to construct a table header. Each column of the table has a heading <th></th>. So let's define the shape of each column so we can build it out:

interface Column {
  id: string;
  label: string;
}

Let's model the Column type and create the columns array that we will use to create the Table Header:

const columns: Column[] = [
  { id: "name", label: "Name" },
  { id: "email", label: "Email address" },
  {
    id: "phoneNumber",
    label: "Phone Number",
  },
  {
    id: "age",
    label: "Age",
  },
];

Now, let's create the table header:

<TableHead>
  <TableRow>
    {columns.map((column) => (
      <TableCell key={column.id}>{column.label}</TableCell>
    ))}
  </TableRow>
</TableHead>

And this will take the labels of each column provided to render this:

<thead>
  <tr>
    <th>Name</th>
    <th>Email address</th>
    <th>Phone Number</th>
    <th>Age</th>
  </tr>
</thead>

Table Body

The body of our table is really not different from the html table body. We will import the TableBody component from MUI - this renders the <tbody></tbody> element. And then we just provide the rows of the data that it would need to construct the <td></td> for each row of the table.

To achieve this, we will have an interface that mirrors the structure of the data we want to render. In our case, we will model a Table of Person data:

interface Person {
  name: string;
  email: string;
  age: number;
  phoneNumber: string;
}

And let's create some sample data to use with it:

const rows: Person[] = [
  {
    name: "John Doe",
    email: "john.doe@example.com",
    age: 25,
    phoneNumber: "+1234567890",
  },
  {
    name: "Jane Smith",
    email: "jane.smith@example.com",
    age: 30,
    phoneNumber: "+1987654321",
  },
  {
    name: "Alice Johnson",
    email: "alice.johnson@example.com",
    age: 35,
    phoneNumber: "+1122334455",
  },
];

Now, let's create the table body:

<TableBody>
  {rows.map((row) => (
    <TableRow key={row.name}>
      {columns.map((column) => (
        <TableCell key={column.id}>{row[column.id]}</TableCell>
      ))}
    </TableRow>
  ))}
</TableBody>

And this will take each object in the array we provided to render this:

<tbody>
  <tr>
    <td>John Doe</td>
    <td>john.doe@example.com</td>
    <td>25</td>
    <td>+1234567890</td>
  </tr>
  ...more rows as is provided in the array
</tbody>

And now, we can combine it all to render the whole table.

<TableContainer>
  <Table>
    <TableHead>
      <TableRow>
        {columns.map((column) => (
          <TableCell key={column.id}>{column.label}</TableCell>
        ))}
      </TableRow>
    </TableHead>
    <TableBody>
      {rows.map((row) => (
        <TableRow key={row.name}>
          {columns.map((column) => (
            <TableCell key={column.id}>{row[column.id]}</TableCell>
          ))}
        </TableRow>
      ))}
    </TableBody>
  </Table>
</TableContainer>

You can play around with the code here or click here to view how it looks in the browser

P.S. You can click through the links on the page to see all the tables. If you check the contents of each component, you will notice similarities between them. Actually, the major difference is the structure of the data and the columns of the table. This shows an opportunity to refactor our code to reduce duplication by creating a reusable table component

But before we proceed to do this, if you look at this part of the TableBody inside Person.tsx here, you will notice there is a typescript warning there.

This is because to access an object using the index notation in typescript, you have to use an index that matches an existing property of the object. In our case, we defined column.id as a string and that's why we are getting this error: No index signature with a parameter of type 'string' was found on type 'Data'..

Since the id property of each column we have matches each property of the objects we provided in the array of rows, we can easily change the type of our Column.id to match this.

interface Column {
  id: keyof Person;
  label: string;
}

And now with this simple change, for each column object i.e. { id: 'name', label: 'Name' }, we can use the id it to access each Person object in the array of rows.

Here is what our final code looks like:

And with the wave of our TS wand, we can see that the error has vanished into thin air 😀

And with that fix, we are ready to proceed to create a component we can resuse to render the People and Countries pages respectively and re-use as many things as we can.

Create a Table component

Before we discuss how I think we should start approaching this, I would like to point out the problem first and then we can look at a quick solution we can consider:
If you take a look at our Countries.tsx and People.tsx files, you will notice that the visible difference is just table header labels and the structure of the objects in the rows array.
This means we can abstract away the repetitve lines of code and reuse them from inside a component.

As discussed earlier, since our table is made up of two parts (Header and Body), we will start by breaking this component into these two parts.

To make our CustomTable component configurable from outside it, we have to make provision to allow this using Props. If you find Props strange, You can visit the React Documentation to read up on this and then come back to this article.

Since this is a Typescript project, here is what I like to do first, define the interface of our Props

The interface for a Person is this:

interface Column {
  id: keyof Person;
  label: string;
}

And the one for a Country is this:

interface Column {
  id: keyof Country;
  label: string;
}

A quick look at the above code will reveal that the only difference is the type of the id inside each column. We need to find a way to create a Column that would be generic enough to handle any type. And that's where Typescript Generics will come handy as it allows us to create a dynamic types that can be re-usable without being tied to a particular type:
Here is what I mean by that:

interface Column<T> {
  id: keyof T;
  label: string;
}

We just created a Column interface that expects anyone using it to provide the type to it and it can use it to add type safety wherever it is used.

And for our rows, since it's just an array of objects, it's pretty straightforward too.
it would just be this:

type Row = T[];

And now, we can combine the two to form the shape of the prop to pass to the CustomTable

interface Props<T> {
  columns: Column<T>[];
  rows: T[];
}

Since we have got that out of the way, let's use this to create a reusable CustomTable component:

Let's start by creating a file: table.tsx.
P.S You can give yours any name of your choice
Next, we will add the data types we declared above at the top of the file.

export interface Column<T> {
  id: keyof T;
  label: string;
}

interface Props<T> {
  columns: Column<T>[];
  rows: T[];
}

NOTE: we added the export statement to the Column interface because we need to use it inside the Countries.tsx and People.tsx files to provide type inference for the rows and columns arrays

Also, there is no point creating a dedicated type for the rows property since it's just an array of the type provided i.e. T[] and that's why I used it directly.

Next, we want to create the function that would be exported as the component. We will also use the props provided to the component to access the rows and columns.

export default function CustomTable<T>(props: Props<T>) {
  const { columns, rows } = props;

  return (
    <Paper>
      <TableContainer>
        <Table>
          <TableHead>
            <TableRow>
              {columns.map((column, index) => (
                <TableCell key={index}>{column.label}</TableCell>
              ))}
            </TableRow>
          </TableHead>
          <TableBody>
            {rows.map((row, index) => {
              return (
                <TableRow key={index}>
                  {columns.map((column, index) => {
                    return <TableCell key={index}>{row[column.id]}</TableCell>;
                  })}
                </TableRow>
              );
            })}
          </TableBody>
        </Table>
      </TableContainer>
    </Paper>
  );
}

NOTE: I used the index as the keys of the array I mapped through here because I am sure the items are not going to change during each render. If you want to know why using array indexes as keys could be a bad idea, you can read about it here

Now, we can use the component we created to re-build our two tables Countries.tsx and People.tsx.

People.tsx

import CustomTable, { Column } from "./custom-table";

interface Person {
  name: string;
  email: string;
  age: number;
  phoneNumber: string;
}

const columns: Column<Person>[] = [
  { id: "name", label: "Name" },
  { id: "email", label: "Email address" },
  {
    id: "phoneNumber",
    label: "Phone Number",
  },
  {
    id: "age",
    label: "Age",
  },
];

const rows: Person[] = [
  {
    name: "John Doe",
    email: "john.doe@example.com",
    age: 25,
    phoneNumber: "+1234567890",
  },
  {
    name: "Jane Smith",
    email: "jane.smith@example.com",
    age: 30,
    phoneNumber: "+1987654321",
  },
  {
    name: "Alice Johnson",
    email: "alice.johnson@example.com",
    age: 35,
    phoneNumber: "+1122334455",
  },
];

export default function People() {
  return <CustomTable columns={columns} rows={rows} />;
}

Countries.tsx

import CustomTable, { Column } from "./custom-table";

interface Country {
  name: string;
  code: string;
  population: number;
  size: number;
  density: number;
}

const columns: Column<Country>[] = [
  { id: "name", label: "Name" },
  { id: "code", label: "ISO\u00a0Code" },
  {
    id: "population",
    label: "Population",
  },
  {
    id: "size",
    label: "Size\u00a0(km\u00b2)",
  },
  {
    id: "density",
    label: "Density",
  },
];
const rows: Country[] = [
  {
    name: "India",
    code: "IN",
    population: 1324171354,
    size: 3287263,
    density: 1324171354 / 3287263, // ideally, should be computed dynamically by dividing each population by size,
  },
  {
    name: "China",
    code: "CN",
    population: 1403500365,
    size: 9596961,
    density: 1403500365 / 9596961,
  },
  {
    name: "Italy",
    code: "IT",
    population: 60483973,
    size: 301340,
    density: 60483973 / 301340,
  },
];

export default function Countries() {
  return <CustomTable columns={columns} rows={rows} />;
}

Here is the final code if you want to check it out:

Now we can render a million different tables, all we have to do is provide the rows and the column configuration.

Extending the table functionality

Now, what we have created so far works well for almost every table if it's just to render some data which is what most tables do. But imagine if you had to render your table rows in somewhat similar fashion to this table.

To be able to support this behavior, we have to extend the possibilities of our CustomTable component but I won't cover that right now.

Conclusion

In this article, we've taken a detailed look at how to create a fully-typed, reusable Table component leveraging the styling the Material UI (MUI) Library in React provides. We started by understanding the basic structure of a table, focusing on the Table Head and Table Body components. We explored how to define and use TypeScript interfaces to model our data, ensuring type safety and reducing errors.

We walked through the creation of a simple table, then moved on to build a more complex, reusable CustomTable component. This component uses TypeScript generics to handle different data types, making it flexible and versatile for various use cases. By creating a CustomTable, we streamlined our code, eliminating redundancy and making it easier to manage and extend.

We also discussed how to handle TypeScript warnings and errors, ensuring our code remains clean and maintainable. Finally, we demonstrated how to implement this reusable component in different contexts, such as the People and Countries tables.

This approach not only saves time but also enhances code readability and maintainability. The reusable component can be extended further to support more advanced features and customizations, which we will cover in part two of this series.

I hope you found this guide helpful and that you learned something new about creating reusable components in React with TypeScript. Please feel free to leave your comments and questions below. Thanks for reading!

Targeted Ads: A rare, good experience

Favour Afolayan — Sat, 24 Jul 2021 13:57:08 +0000

On this week's episode of tech is just an enabler.
I want to share something I have come across this week that I find interesting.

So you know how banks, - I live in Nigeria - So I can say something about how banks around here send you targeted emails for salary advance almost everytime - Access Bank does this to me a lot.

Anyways, there is this platform I use https://app.letsdeel.com to receive payments. They handle everything for managing contracts. From drawing up contracts, signing it, generating invoices, remittances to any destination account in the entire universe, they even support payments in crypto. You should check them out if you are looking for something really nice to manage your contractors or you need somewhere to get your funds moved across to your local bank accounts.

Let me get right on before I head down the path where I keep sounding like this is a promo article for Deel.

I was supposed to receive payment for last month's invoice some few days ago but I got word from the company I work with that the payment was going to come in a bit later than expected. Ideally, the payment should have been made to Deel already by the company that way, it enables Deel to make remittance to my account the exact day and date I have on the contract.
But since this month's didn't arrive already and they couldn't credit me, I got an email subtly letting me know that while I was waiting for the payment, I could apply for an advance if I needed it.

I wasn't surprised when the email came in, but I was really impressed and was all smiles, laying on my bed reading it when it came in. The timing was perfect because when I was expecting to get an email that I received a payment, I got one instead telling me about an advance payment option they had.

For me, it just reminds me of the following:

Building a product is the happy and simple part. Marketing it is another ball game entirely.
Just like people we meet everyday, we remember products for the tastes they leave in our mouths.
Data is powerful and could be used to great effects.

Another side to this is having to deal with data privacy and it just makes me wonder the good and amazing things companies could do with the user data they have access to. I have seen videos on the internet and responses to polls that suggest that people really don't mind targeted Ads/emails suggesting to them, stuffs to buy based on their needs or spending/shopping patterns. But for companies to be able to serve useful stuffs, they need to keep collecting data about their users and basically trusting them to do the right thing with the data.

Using React.useMemo for optimization and logic reuse

Favour Afolayan — Sat, 24 Jul 2021 11:31:54 +0000

VueJS, other than being reported to having a low learning curve, its reactivity system is arguably the most important concept in it.
At the heart of its reactivity system is the concept of computed properties:

What is a computed property?

In layman's terms, a computed property is simply an expression that returns a particular value by computing it from some variables/dependencies.

Let's see a vue js example:

<div id="example">
  <p>Original message: "{{ message }}"</p>
  <p>Computed reversed message: "{{ reversedMessage }}"</p>
</div>

var vm = new Vue({
  el: '#example',
  data: {
    message: 'Hello'
  },
  computed: {
    // a computed getter
    reversedMessage: function () {
      // `this` points to the vm instance
      return this.message.split('').reverse().join('')
    }
  }
})

// originalMessage = 'Hello'
// reversedMessage = 'olleH'

This simple, yet clean concept can be used to encapsulate long or expensive logic that needs to be re-calculated when some variables change. From the example above, if the value of message changes, Vue recalculates the value of reversedMessage and returns the new value based off of that.
Importantly, it caches/memoizes the value until any dependency changes.

Bringing the idea into react

One of the biggest frustrations I have had with React codebases has always been having expensive or some lines of code that should go into a function embedded within the template/markdown of a component and I am super excited to find out that React.useMemo can easily be used to clean this up.

Let's modify the reversedMessage example above with some new requirements:

The message length must be > 5
Show the reversed message in uppercase

Implementing this without useMemo

import { useMemo, useState } from "react";

export default function App() {
  const [message, setMessage] = useState("");

  return (
    <div>
      <h2>Reversed Message Component</h2>
      <input
        value={message}
        onChange={(event) => setMessage(event.target.value)}
      />

      <p>Original Message: {message}</p>
      <p>Reversed Message: 
      {message && message.length > 5 
 ? message.split("").reverse().join("").toUpperCase(): ''}</p>
    </div>
  );
}

Some drawbacks with this implementation:

If this was an expensive logic, it is not reusable
The template will keep increasing with every new modification to the requirement.
It is not clean.

Imagine completing this and after a week, management added a new requirement:

show the number of characters inputed
if the characters provided is a palindrome, let's show a message to the user.

Now, we go back to that lengthy section and add more logic to it and it becomes more complex to read and understand. I am sure you are probably thinking, dude! just tuck this behind a function and rest. Yes, that is somewhat what we will be doing with useMemo but even better, we will make it into a computed property that can be reused for anything else.

Implementing with useMemo

import "./styles.css";

import { useMemo, useState } from "react";

export default function App() {
  const [message, setMessage] = useState("");

  const reversedMessage = useMemo(() => {
    if (message.length > 5) {
      // we can keep extending this functionality to any length
      return message.split("").reverse().join("").toUpperCase();
    }

    return "";
  }, [message]);

  return (
    <div>
      <h2>Reversed Message Component</h2>
      <input
        value={message}
        onChange={(event) => setMessage(event.target.value)}
      />

      <p>Original Message: {message}</p>
      <p>
        Reversed Message:
        {reversedMessage}
      </p>
    </div>
  );
}

Now the reversedMessage variable can be used to do different things within that component and we get the advantage of memoization right out of the box from React. This ensures that the part of the component using the reversedMessage gets the latest value every time and React doesn't re-compute it every time except when any of the dependencies listed in the array changes.

You can read more about useMemo and other optimization techniques in React from the Official React Documentation

Build a simple and reusable Vue JS radio button component

Favour Afolayan — Mon, 14 Dec 2020 21:02:23 +0000

In this article, I want to show you how to DRY up a piece of repeated code into pieces of reusable components.

App.vue

<template>
 <div>
  <UserDecision v-model="decision" />
 </div>
</template>

<script>
 import Vue from 'vue';

 import UserDecision from './UserDecision.vue';

 export default {
  components: { UserDecision },
  data: () => ({
   decision: '',
  })
 }

</script>

UserDecision.vue


 <template>
    <div class="user-decision">
        <label for="Yes">
            <input type="radio" name="radio" value="Yes" id="Yes" 
             @change="$emit('input', 'Yes')" />
            Yes
        </label>
        <label for="No">
            <input type="radio" name="radio" value="No" id="No" 
            @change="$emit('input', 'No')" />
            No</label
        >
        <label for="Undecided">
            <input
                type="radio"is
                name="radio"
                value="Undecided"
                id="Undecided"
                @change="$emit('input', 'Undecided')"
            />Undecided
        </label>
    </div>
 </template>

<script>
 import Vue from 'vue';

 export default {} 
</script>

<style>
 .user-decision {
  width: 60%;
  margin: 20px auto;
  padding: 15px 20px;
  border: 1px solid black;
  border-radius: 8px;

  display: flex;
  justify-content: space-between;
}
</style>

If you look at this code, this works fine if you don't think there would ever be the need for more implementations of such.

So for the purpose of reusability, I will show you how we can refactor this, to make it easy and simple to reuse.

The first level of refactoring I see we can do here is inside the UserDecison.vue component file. A careful look at that file will reveal that the input, label elements are repeated. Let's DRY it up.

BaseRadioButtonGroup.vue

 <template>
  <div class="radio-button-group">
   <label :for="option" v-for="option in options">
    <input type="radio" name="radio-input" :value="option" 
 :id="option" 
    @change="$emit('input', option)" />
    {{ option }}
   </label>
  </div>
 </template>

<script>
 import Vue from 'vue';

 export default {
  name: 'BaseRadioButtonGroup',
  props: {
    options: {
     required: true,
     type: Array
    }
  }
 }
</script>

<style>
 .radio-button-group {
  width: 60%;
  margin: 20px auto;
  padding: 15px 20px;
  border: 1px solid black;
  border-radius: 8px;

  display: flex;
  justify-content: space-between;
}
</style>

Now to use our new, usage-agnostic component we have renamed 'BaseRadioButtonGroup', let's go back to the App.vue file.

App.vue

<template>
 <div>
  <BaseRadioButtonGroup v-model="decision" :options="options" />
 </div>
</template>

<script>
 import Vue from 'vue';

 import BaseRadioButtonGroup from './BaseRadioButtonGroup.vue';

 export default {
  components: { UserDecision },
  data: () => ({
   decision: '',
   options: ['Yes', 'No', 'Undecided']
  })
 }

</script>

What we have done so far is fine, but if you look at the BaseRadioButtonGroup component, we can even further break down its content into a smaller component that would give us more flexibility. Let me show you what I mean.

BaseRadioButtonGroup.vue

 <template>
 <div class="radio-button-group">
  <label :for="option" v-for="option in options" :key="option">
   <input type="radio" name="radio-input" :value="option" :id="option" 
    @change="$emit('input', option)" />
    {{ option }}
  </label>
 </div>
 </template>

<script>
 import Vue from 'vue';

 export default {
  name: 'BaseRadioButtonGroup',
  props: {
    options: {
     required: true,
     type: Array
    }
  }
 }
</script>

<style>
 .radio-button-group {
  width: 60%;
  margin: 20px auto;
  padding: 15px 20px;
  border: 1px solid black;
  border-radius: 8px;

  display: flex;
  justify-content: space-between;
}
</style>

BaseRadioButton.vue

 <template>
  <label :for="option">
   <input type="radio" name="radio-input" :value="option" :id="option" 
    @change="$emit('input', option)" />
    {{ option }}
  </label>
 </div>
 </template>

<script>
 import Vue from 'vue';

 export default {
  name: 'BaseRadioButton',
  props: {
    option: {
     required: true,
     type: string
    }
  }
 }
</script>

We have extracted this into a component that is decoupled, can be re-used, easily styled and customized, any time in the future.

Now, let's update the BaseRadioButtonGroup component to reflect the change we made.

BaseRadioButtonGroup.vue

 <template>
 <div class="radio-button-group">
  <BaseRadioButton v-for="option in options" :option="option" :key="option" @input="inputEventHandler" />
 </div>
 </template>

<script>
 import Vue from 'vue';

 import BaseRadioButton from './BaseRadioButton.vue';

 export default {
  name: 'BaseRadioButtonGroup',
  components: { BaseRadioButton },
  props: {
    options: {
     required: true,
     type: Array
    }
  },
  methods: {
   inputEventHandler(value) {
     this.$emit('input', value);
   }
  }
 }
</script>

<style>
 .radio-button-group {
  width: 60%;
  margin: 20px auto;
  padding: 15px 20px;
  border: 1px solid black;
  border-radius: 8px;

  display: flex;
  justify-content: space-between;
}
</style>

Now, because the event is two levels down, we had to handle it at each level of the component to ensure it is emitted to the parent component to ensure the v-model is kept in sync. i.e. the BaseRadioButton emits an input event, that the BaseRadioButtonGroup component listens to and finally emits to the v-model inside the App.vue file.

For the purpose of writing less code and getting the same behaviour, we can get rid of the method by emitting the input event straight to the App.vue file from down inside the BaseRadioButton component.

Let me quickly show you what I mean.

BaseRadioButton.vue

 <template>
  <label :for="option">
   <input type="radio" name="radio-input" :value="option" :id="option" 
    @change="$parent.$emit('input', option)" />
    {{ option }}
  </label>
 </div>
 </template>

With the $parent.$emit property, the event will keep bubbling up the component tree until it gets inside the App.vue where the v-model property will listen to it.

Now, we can get rid of the method we created to emit the event inside the BaseRadioButtonGroup component.

BaseRadioButtonGroup.vue

 <template>
 <div class="radio-button-group">
  <BaseRadioButton v-for="option in options" :option="option" :key="option" />
 </div>
 </template>

<script>
 import Vue from 'vue';

 import BaseRadioButton from './BaseRadioButton.vue';

 export default {
  name: 'BaseRadioButtonGroup',
  components: { BaseRadioButton },
  props: {
    options: {
     required: true,
     type: Array
    }
  },
 }
</script>

Now, that we have two components that can be used together or singly. To render N-number of radio buttons, all we need to do is to pass an array of the options to the BaseRadioButtonGroup component and it would work fine. And if we need more control over every single radio button, we can equally use the BaseRadioButton component.

You can play with the final code here

DEV Community: Favour Afolayan

AI isn't taking our jobs — It's taking our illusions

Some reflections from this shift

We were fortunate to get good at something

The learning didn’t lose value—it got leveraged

Feeling behind is a normal response

Coding was never the whole job

No role is immune

AI is leverage, not replacement

Tools still need orchestration

A reminder about perspective

A reframing worth considering

Closing thought

How to create a custom table component with React and Typescript (Part 2)

Introduction

Extending the Column Interface

Supporting Custom Templates

Custom Row Component

Improvements

Final Code

Conclusion

How to build a custom React table component with Typescript (Part 1)

Introduction

Table Head

Table Body

Create a Table component

People.tsx

Countries.tsx

Extending the table functionality

Conclusion

Targeted Ads: A rare, good experience

Using React.useMemo for optimization and logic reuse

What is a computed property?

Bringing the idea into react

Implementing this without useMemo

Implementing with useMemo

Build a simple and reusable Vue JS radio button component

App.vue

UserDecision.vue

BaseRadioButtonGroup.vue

App.vue

BaseRadioButtonGroup.vue

BaseRadioButton.vue

BaseRadioButtonGroup.vue

BaseRadioButton.vue

BaseRadioButtonGroup.vue