DEV Community: Sergey Egorov

Conditional TypeScript Generics in React Components

Sergey Egorov — Fri, 09 Jan 2026 14:01:41 +0000

In my previous article here I promised to continue the discussion of TypeScript generics - a topic that I consider especially important when working with React components.

In that article we covered the basic definitions of generic components and looked at a simple example of when and why generics can be useful. In this post we will take the next step and focus on conditional generics and how they can be applied in real-world React components.

Here I would like to look at an example from my real project I worked on, which showed me just how elegant and powerful generic types can be.

Let's consider a selection component that allows us to select one or a few options depending on props.

First, let's look at the interfaces and types of the component without generics, treating them as a kind of component contract:

// Just an interface of option structure
interface Option {
  id: number;
  name: string;
}

// It's your value type
type Value = Option[] | Option | undefined;

// And component props interface
interface Props {
  value?: Value;
  options?: Option[];
  multiple?: boolean;
  onChange?: (value: Value) => void;
}

I want you to pay attention to the fact that when using this component, you are not fully safe with value types, because TypeScript doesn't know whether the component is used in multiple selection mode or not. This happens because we allow our value to be either an array or a single object.

As a result, when using this component, value?: Value and onChange?: (value: Value) => void are always available in both states, independent of multiple?: boolean. This is not strict enough, and I would like to have a guarantee that if multiple is set to false, value must be a single object, and if it is true, value must be an array.

So, let me start implementing generics in our Props interface.

We still have the same option interface:

interface Option {
  id: number;
  name: string;
}

Now, take a look at the enhanced Props interface with O and M types:

interface Props<
  O extends Option,
  M extends boolean | undefined = undefined
> {
  value?: M extends undefined | false ? O | undefined : O[];
  options?: O[];
  multiple?: M;
  onChange?: (
    values: M extends undefined | false ? O | undefined : O[]
  ) => void;
}

In our Props interface we defined two new generic types:

1. O type extends Option - represents the option type
2. M type extends boolean | undefined — represents the multiple flag and defaults to undefined

Let's consider M as follows:

M is undefined if the multiple prop is not provided
M is false if the multiple prop is false
M is true if the multiple prop is true

3. value now has type
M extends undefined | false ? O | undefined : O[];

Value is O if the multiple flag is false
Value is O[] if the multiple flag is true

4. The same rule is also accepted for onChange callback function param values

To be honest, I do not like that we repeat this construction twice
M extends undefined | false ? O | undefined : O[];

I would prefer to create a separate generic type for it:

type Value<O, M> = M extends undefined | false ? O | undefined : O[];

And then use it in our Props interface:

interface Props<O extends Option, M extends boolean | undefined = undefined> {
  value?: Value<O, M>;
  options?: O[];
  multiple?: M;
  onChange?: (values: Value<O, M>) => void;
}

The final step is to extend the component itself with the generics, which is also very important.

export const SelectionExample = <
  O extends Option,
  M extends boolean | undefined = undefined
>({
  value = undefined,
  multiple = false,
  onChange = () => undefined,
  options = [],
}: Props<O, M>) => {
  const isOptionSelected = (option: O): boolean => {
    // Implementation of isOptionSelected here using value and multiple
    return false;
  };

  const handleOptionClick = (option: O) => {
    if (multiple) {
      // Implementation of handleOptionClick for multiple selection here using onChange
    } else {
      // Implementation of handleOptionClick for single selection here using onChange
    }
  };

  return (
    <div>
      {options.map((option) => {
        const selected = isOptionSelected(option);
        return (
          <Item
            key={option.id}
            selected={selected}
            option={option}
            onClick={handleOptionClick}
          />
        );
      })}
    </div>
  );
};

Please pay attention to the fact that in the component itself we also need to define the generic types and pass them into Props.

export const SelectionExample = <
  O extends Option,
  M extends boolean | undefined = undefined
>
...
}: Props<O, M>) => {

The benefits of this approach are still not clear until we try to use this component. So, let's move on to that.

The first case is when we use the component with multiple selection so we expect TypeScript to allow us to pass only an array to the value property. At the same time, in the onChange callback, we can also expect to receive the selected array.

export const UsageExample = () => {
  return (
    <>
      <h1>Multiple selection</h1>
      <SelectionExample
        options={options}
        // multiple is switched on
        multiple={true}
        // value expects an array of options
        value={[options[0], options[1]]}
        onChange={(values) => {
          // values is the selected options array
          console.log(values);
        }}
      />
  );
};

The single selection:

export const UsageExample = () => {
  return (
    <>
      <h1>Single selection</h1>
      <SelectionExample
        options={options}
        // multiple is switched off
        multiple={false}
        // value expects an option object
        value={options[0]}
        onChange={(value) => {
          // value is the selected option
          console.log(value);
        }}
      />
    </>
  );
};

And now let’s look at what happens if we try to use the component incorrectly:

export const UsageExample = () => {
  return (
    <>
      <h1>Wrong usage</h1>
      <SelectionExample
        options={options}
        // multiple is switched OFF now
        multiple={false}
        // value expects an object of Option
        value={[options[0], options[1]]} // TS ERROR: because multiple is switched off
        onChange={(values) => {
          // values has type Option | undefined
          console.log(values);
        }}
      />
    </>
  );
};

I know this article may have pushed you to go deepper into TypeScript features. However, I believe you would be satisfied once you finish your own similar implementation and realise how much more powerful your component has become.

TypeScript Generics in React Components.

Sergey Egorov — Thu, 08 Jan 2026 15:25:27 +0000

Generics are not something you use in React components every day. However, in certain cases the allow you to write components that are both flexible and type-safe.

Let's consider a few common approaches to describe a component with TypeScript

// Just FC component with no props
const Component = () => (<div>Hey ya!!!</div>)

Another one:

// FC component with props
interface Props{
  name: string;
}

const Component: React.FC<Props> = ({ name })=>(<div>Hey {name} ya!!!</div>)

For some time now React.FC is not a perfect way to describe a React component. The motivation is React.FC does not support generics in the way we might need, however, in my view it's not a reason. How often do you really need generics in your components? Hardly ever. In my own practice I continue using React.FC due to readability.

Another way to describe a functional component with no React.FC is just to specify the props type directly

// FC component with simple props
interface Props{
  name: string;
}

const Component = ({ name }:Props)=>(<div>Hey {name} ya!!!</div>)

Now nothing stops us from passing a generic type into props, but the cases above do not require any generics to pass. Let's consider a case when it is really needed.

Here is a situation when we have a DTO with an array received from an API. There are many properties inside. One of them is a property with the value that we need. Our component does not know the name of that property which should be fairly common. We can use a common approach for that with a callback function that must return a name, however, it would be great if, inside that callback, we know that type of data that was provided into the component.

Simple example. We have a ResponseDTO type

interface ResponseDTO{
  id: number;
  name: string;
}

and a component that works with this specific type of DTO

interface ExampleProps {
  data: ResponseDTO[];
  getName: (item: ResponseDTO) => string;
}

export const Example = ({
  data,
  getName = (item: ResponseDTO) => item.name,
}: ExampleProps) => {
  return (
    <div>
      {data.map((item) => (
        <div key={getName(item)}>{getName(item)}</div>
      ))}
    </div>
  );
};

Look at getName property here. In this case it's not necessary because the interface is explicit. Our component knows everything about the data structure. And we can safely use the name property from our DTO.

Now imagine. We have many different DTOs with different parameters and one of those can be considered as a name. Here generics open the gates of opportunities for us.

First we need to update our Props interface

interface Props<T> {
  data: T[];
  getName: (item: T) => string;
}

Why Props<T> needs the generic parameter? The type T must be declared on the Props interface because this is where the relationship between the incoming data and the callback is defined. Without this TS would have no way to ensure that the items inside data and the parameter of getName refer to the same type.

This way we say that we do not know which data will come to our component but it's not any. Now let's look at our component.

export const NameViewer = <T,>({ data, getName }: Props<T>) => {
  return (
    <>
      Look at the names:
      {data.map((item) => (
        <div key={getName(item)}>{getName(item)}</div>
      ))}
    </>
  );
};

Nothing special, right? We just iterate over an array unknown to this component and display values considered as names.

Note: In .tsx files, generic parameters in arrow functions may conflict with JSX syntax. Writing <T,> (with a trailing comma) disambiguates the syntax and allows TypeScript to correctly parse it as a generic declaration rather than a JSX tag.

Let's try to use this component.

const unknownTypeData = [
  { id: 1, nameProp: 'John' },
  { id: 2, nameProp: 'Jane' },
];

const anotherUnknownTypeData = ['Foo', 'Bar'];

export const BusinessComponent = () => {
  return (
    <div>
      <NameViewer
        data={unknownTypeData}
        getName={(item) => item.nameProp}
      />
      <NameViewer
        data={anotherUnknownTypeData}
        getName={(item) => item}
      />
    </div>
  );
};

NameViewer now can accept any types of data that you might want to iterate.

I have just shown you a very simple but compact and useful example. It's only a small drop in the sea of generics. My next article will extend your knowledge with conditional generics that are also very useful. See you.

How to extend enum in TypeScript

Sergey Egorov — Thu, 15 Sep 2022 15:17:33 +0000

From time to time you need to extend an enum in TypeScript, however, we can't use extends construction like in case of interface.

enum MySuperEnum {
  ONE,
  TWO
}

enum MyMoreSuperEnum extends MySuperEnum // This is wrong

Of course, we can create one more enum and then create union type:

enum MySuperEnumExtender {
  THREE
}

type MyUnionType = MySuperEnum | MySuperEnumExtender;

What we can get and why this approach is not good? MyUnionType is a type, we can't use it like enum to call its props.

So what we can do then?

First of all, we should use another and more preferable way of enum implementation with const. Why?

// describe an enum object
const  MySuperEnum = {
  ONE: 'ONE',
  TWO: 'TWO'
} as const

// create the MySuperEnum type
type MySuperEnum = typeof MySuperEnum[keyof typeof MySuperEnum];

What is as const? Please click to find out more.

Cool! Now our MySuperEnum is defined in a different way!

It is time to create new MyMoreSuperEnum that will be extended with MySuperEnum.

// describe an enum object
const  MyMoreSuperEnum = {
  ...MySuperEnum,
  THREE: 'THREE'
} as const

// create the MyMoreSuperEnum type
type MyMoreSuperEnum = typeof MyMoreSuperEnum[keyof typeof MyMoreSuperEnum];

Profit. Hope this trick will be useful for you.