DEV Community: NickM

React displayName Without Strings: A C#-Inspired TypeScript Proxy Trick

NickM — Fri, 10 Jul 2026 04:12:50 +0000

It started with a very small problem.

In our React component library, we wanted every component to have a nice displayName.

So we did the obvious thing:

Component.displayName = "Component";

Simple. Clear. Boring.

And then reality arrived.

From time to time, developers renamed components. Maybe Button became IconButton. Maybe UserCard became CustomerCard.

But the displayName string?

That stayed behind.

CustomerCard.displayName = "UserCard";

Technically everything still worked.

But debugging became slightly cursed.

React DevTools showed outdated names, logs became misleading, and the code looked correct enough that nobody noticed immediately.

So I started thinking:

How can we force the name to stay in sync with the actual symbol?

Because the real problem was not displayName.

The real problem was this:

"Component"

A string literal does not participate in refactoring.

Your IDE can rename the function. TypeScript can check the types. But that string just sits there, smiling suspiciously.

So the question became more general:

What are the possible ways to get the name of a symbol in a reliable manner?

First attempt: `keyof`

The first simple helper looked like this:

export function publicNameOf<T_Type>(key: keyof T_Type): typeof key
{
    return key;
}

And it kind of works.

For example:

type User =
{
    name: string;
    age: number;
};

const name = publicNameOf<User>("name");

At least now TypeScript checks that "name" is actually a key of User.

If I write this:

const name = publicNameOf<User>("firstName");

TypeScript complains.

That is already better than a completely random string.

But it still has a few problems.

First, it only works with direct members.

publicNameOf<User>("profile");

That is fine, but it does not naturally express something nested like:

user.profile.avatar.url

Second, it still requires a string literal.

So if the actual member is renamed, your IDE may not update this:

publicNameOf<User>("oldName");

TypeScript may catch it later, depending on the type. But it is still not the same as pointing at the member using normal language syntax.

Third, keyof is still a type-level list of accessible keys.

That matters especially for classes.

For example:

class UserService
{
    public start()
    {
    }

    private stop()
    {
    }
}

type UserServiceKey = keyof UserService;

UserServiceKey contains "start", but it does not contain "stop".

And that makes sense. From the outside, stop is not part of the public shape of UserService.

But there is an important nuance here.

Inside the class, TypeScript does allow you to access private members. The language already knows whether a particular member access is legal depending on where that access is written.

So sometimes the problem is not:

Give me all public keys of this type.

Sometimes the problem is:

Let me point at this member using the same syntax I would normally use in code.

That is a different goal.

And keyof is not quite that.

What I actually wanted

What I wanted was something closer to C# expression trees.

In C#, you can write something like:

Expression<Func<User, object>> expression = user => user.Profile.Avatar.Url;

And then inspect the expression to understand which member path was used.

I wanted a TypeScript version of that idea.

Something like:

($) => $.Component;

Where $ is some object that has the member I want to point at.

The important part is this:

$.Component

That is not a string.

That is a real property access expression.

So rename refactoring has a chance to follow it.

Of course, TypeScript does not have C# expression trees.

But JavaScript has Proxy.

And sometimes that is enough.

The proxy trick

The idea is surprisingly simple.

We create a fake object.

Every time someone accesses a property on it, we record that property name.

Then we return the same fake object again, so the selector can continue walking deeper.

export type RuntimeSelector<T_Target, T_Member = any> =
    (target: T_Target) => T_Member;

export function runtimePathOf
<
    T_Target,
    T_Member = any
>
(
    selector: RuntimeSelector<T_Target, T_Member>
)
    : string[]
{
    const path: string[] = [];

    const pathProxy: string[] = new Proxy
    (
        path,
        {
            get: (target, key) =>
            {
                target.push(key.toString());

                return pathProxy;
            }
        }
    );

    selector(pathProxy as T_Target);

    return path;
}

Now we can do this:

const path = runtimePathOf<User>
(
    user => user.profile.avatar.url
);

And the result is:

["profile", "avatar", "url"]

No AST parsing.

No decorators.

No compiler plugin.

Just a runtime proxy pretending to be your object.

Getting only the final name

For the original displayName problem, I did not need the full path.

I only needed the last segment.

So I added a tiny wrapper:

export function runtimeNameOf
<
    T_Target,
    T_Member = any
>
(
    selector: RuntimeSelector<T_Target, T_Member>
)
    : string
{
    const path = runtimePathOf(selector);

    return path[path.length - 1] ?? "";
}

Now this:

const name = runtimeNameOf<User>
(
    user => user.profile.avatar.url
);

Returns:

"url"

And this:

const name = runtimeNameOf<$>($ => $.Component);

Returns:

"Component"

What about private members?

This is also where the earlier keyof limitation becomes interesting.

The proxy helper does not bypass TypeScript privacy rules.

It still follows normal TypeScript access rules at the place where the selector is written.

So outside a class, this would still be illegal if stop is private.

But inside the class, where TypeScript allows private access, the selector can point at the private member using normal syntax:

class UserService
{
    private stop()
    {
    }

    public getPrivateMethodName()
    {
        return runtimeNameOf<UserService>(service => service.stop);
    }
}

That is something keyof UserService does not give you.

keyof UserService describes the public instance shape.

The selector approach is different: it lets you write a member access expression and lets TypeScript decide whether that access is valid from that location.

So this is not a way to break privacy.

It is a way to follow the language rules instead of asking for a public list of keys.

Back to the component

So now we have the general tool:

runtimeNameOf<$>($ => $.Component);

The next question is:

What should $ actually be?

We need $ to be some type that contains Component.

Where does Component live?

In my case, it is exported from the current module.

And TypeScript can get the type of a module very easily:

typeof import(".")

That gives us the type shape of the current module exports.

So the final version becomes:

Component.displayName = runtimeNameOf<typeof import(".")>
(
    $ => $.Component
);

Now Component is referenced through a real property access expression.

If the exported component is renamed, the selector can be updated by normal refactoring tools.

Instead of this fragile version:

Component.displayName = "Component";

We now have this:

Component.displayName = runtimeNameOf<typeof import(".")>
(
    $ => $.Component
);

The string is no longer manually written.

It is derived from the property access.

That was the whole point.

What this is not

This is not real reflection.

It does not inspect TypeScript types at runtime.

It does not know anything magical about your source code.

It simply runs a function against a proxy and records which properties were accessed.

So this works:

runtimePathOf<User>
(
    user => user.profile.avatar.url
);

But this is not the kind of thing you should do:

runtimePathOf<User>
(
    user => user.getProfile().avatar.url
);

Because now you are calling a function on a proxy.

Our proxy only handles property access. It does not behave like a real User.

This helper is meant only for simple property selectors.

The bundler question

There is one important bundler caveat.

The TypeScript type argument is erased:

runtimeNameOf<typeof import(".")>
(
    $ => $.Component
);

becomes ordinary JavaScript:

runtimeNameOf($ => $.Component);

So the bundler is not protecting this because it understands typeof import(".").

It simply sees a lambda with a property access.

Normal minification may rename the local parameter:

$ => $.Component

into something like:

n => n.Component

That is fine. The proxy still sees the property key "Component".

The dangerous case is property mangling:

n => n.Component

could become:

n => n.a

Then the proxy would record "a" instead of "Component".

Most common bundler setups do not mangle arbitrary property names by default. They usually mangle local variables and function names, not public-looking property accesses.

So this approach is not protected by TypeScript metadata at runtime.

It is mostly safe because normal bundlers do not rewrite property keys like .Component unless property mangling is explicitly enabled.

So the practical rule is:

This technique avoids function-name minification problems. It is safe for normal public exports in typical bundler setups, but you should still check your production bundle if you use aggressive mangling.

Final result

So the final API is very small:

export type RuntimeSelector<T_Target, T_Member = any> =
    (target: T_Target) => T_Member;

export function runtimePathOf
<
    T_Target,
    T_Member = any
>
(
    selector: RuntimeSelector<T_Target, T_Member>
)
    : string[]
{
    const path: string[] = [];

    const pathProxy: string[] = new Proxy
    (
        path,
        {
            get: (target, key) =>
            {
                target.push(key.toString());

                return pathProxy;
            }
        }
    );

    selector(pathProxy as T_Target);

    return path;
}

export function runtimeNameOf
<
    T_Target,
    T_Member = any
>
(
    selector: RuntimeSelector<T_Target, T_Member>
)
    : string
{
    const path = runtimePathOf(selector);

    return path[path.length - 1] ?? "";
}

And the usage is:

Component.displayName = runtimeNameOf<typeof import(".")>
(
    $ => $.Component
);

A tiny helper.

A tiny proxy.

And one less stale string literal in the codebase.

Where this idea could go next

This tiny helper only records property access, but the general idea can grow into something much bigger.

A good mental model here is Entity Framework Core in C#.

EF Core can take expression trees, inspect what you wrote, and turn that structure into SQL queries. That is not what this helper does, and JavaScript proxies are not the same thing as C# expression trees.

But the direction is similar: developer-friendly syntax on the outside, metadata on the inside.

Once the object passed into the selector is fake, it does not have to behave exactly like the real object.

It can expose an extended API.

For example, a query builder could return special expression objects from property access and attach comparison helpers to them:

query<User>
(
    user => user.age.$gt(18)
);

Or it could use symbols to avoid colliding with real domain members:

query<User>
(
    user => user.age[Query.greaterThan](18)
);

At that point, user.age is not really a number at runtime. It is an expression node that represents the age field. Calling $gt(18) or [Query.greaterThan](18) can record a comparison and turn it into query metadata.

That is a different API design from runtimeNameOf, but it comes from the same core idea:

Give developers a typed object-shaped surface, run their selector against controlled proxy objects, and convert the interaction into metadata.

So no, this is not full C# expression trees, and it is not EF Core for TypeScript out of the box. JavaScript will not let a proxy directly intercept operators like >, ===, or &&.

But with an extended API, helpers, or symbol-based methods, this pattern could become the foundation for something much more query-like.

Conclusion

This is one of those TypeScript tricks that is not exactly "real reflection", but still solves a very real problem.

We wanted component display names to stay in sync with actual component symbols.

A simple string was too fragile.

keyof helped a little, but still required manually passing a string and only described the public key shape.

A proxy-based selector gave us a nicer middle ground:

$ => $.Component

It is still runtime JavaScript.

It is still small and understandable.

But now the important part is written as a real property access, so TypeScript and refactoring tools can help us.

And honestly, that is good enough for me.

I Like Enums. My Teammate Preferred Literals. TypeScript Let Us Have Both.

NickM — Mon, 06 Jul 2026 04:57:11 +0000

I recently reviewed a contribution to a shared React module where one developer used const objects instead of enums for accepted prop values.

My first reaction was simple:

Why not enums?

I like enums for this kind of thing. Maybe too much.

For me, an enum is a clear and determined way to declare a list of accepted values. It says: here is the list, this is the source of truth, use these values everywhere.

For example:

enum ButtonVariant
{
    Primary = "primary",
    Secondary = "secondary",
    Danger = "danger"
}

Then a component prop can be typed like this:

type ButtonProps =
{
    variant: ButtonVariant;
};

And consumers use it like this:

<Button variant={ButtonVariant.Primary} />

I like that. It is explicit. It is easy to search. It is easy to rename. And if the actual value ever needs to change, I can change it in one place.

For example, if "primary" needs to become "main", I update the enum declaration:

enum ButtonVariant
{
    Primary = "main",
    Secondary = "secondary",
    Danger = "danger"
}

The usages stay connected:

<Button variant={ButtonVariant.Primary} />

No walking through the whole codebase and manually replacing string literals.

So, naturally, I asked why the module used a const object instead.

The Const Object Approach

The approach looked something like this:

const ButtonVariant =
{
    Primary: "primary",
    Secondary: "secondary",
    Danger: "danger"
} as const;

type ButtonVariant = (typeof ButtonVariant)[keyof typeof ButtonVariant];

This is a common TypeScript pattern.

The object stores the runtime values, and the type extracts a union of those values:

type ButtonVariant =
(
    "primary"
        |
    "secondary"
        |
    "danger"
);

Then the prop can be typed like this:

type ButtonProps =
{
    variant: ButtonVariant;
};

And consumers can pass literal values directly:

<Button variant="primary" />

The answer from the developer was fair.

In React components, literal values are often just nicer to use:

<Button variant="primary" />

No extra import.

Readable JSX.

Good IntelliSense.

Less ceremony for consumers of the component.

And honestly, I get it.

This is especially true in UI libraries. When someone writes JSX, they usually want a prop to feel lightweight. Importing an enum just to pass one prop can feel a bit heavy.

So there was a small design conflict:

<Button variant={ButtonVariant.Primary} />

vs.

<Button variant="primary" />

Why I Still Wanted Enums

I still wanted enums to be the source of truth.

The const object approach is practical, but for me enums still have a few important advantages.

First, enum is a built-in TypeScript language feature. It is not an emulation of enum-like behavior with an object. So if TypeScript improves enums in the future, enum-based code can naturally benefit from that. Objects are still just objects. It is a different paradigm.

Second, I do not see a strong optimization argument against enums here.

One of the points was that const object values are simple and can be optimized well by JavaScript engines.

That is true, but enum usage is not a real problem for this use case either. At runtime, a string enum access is still just a stable property access:

ButtonVariant.Primary

A const object is also an object with properties. So for a React prop value like this, I do not think this is the place where performance will be decided.

In practice, both approaches are simple enough here.

Third, objects can do more than just declare values. They can contain expressions, computed values, or even cause side effects during initialization.

const ButtonVariant =
{
    Primary: getPrimaryVariant(),
    Secondary: "secondary",
    Danger: "danger"
} as const;

Maybe sometimes this is useful, but for declaring a fixed list of accepted values, I actually prefer the limitation of enums. With enums, TypeScript keeps the declaration much more strict and obvious.

enum ButtonVariant
{
    Primary = "primary",
    Secondary = "secondary",
    Danger = "danger"
}

That is exactly what I want here: a clear list of allowed values.

But I also did not want to make the React component worse to use.

Because the other developer had a good point too:

<Button variant="primary" />

This is nice in JSX. No extra import. Easy to read. Autocomplete still helps.

So I started looking for a compromise:

Can we declare the accepted values as an enum, but allow consumers to pass either enum members or literal values?

Turns out, yes.

The Goal

Given this enum:

enum ButtonVariant
{
    Primary = "primary",
    Secondary = "secondary",
    Danger = "danger"
}

I wanted both of these to be valid:

<Button variant={ButtonVariant.Primary} />
<Button variant="primary" />

But this should still be rejected:

<Button variant="random" />

So the prop type should accept:

ButtonVariant.Primary
    |
ButtonVariant.Secondary
    |
ButtonVariant.Danger

and also:

"primary"
    |
"secondary"
    |
"danger"

That became the idea behind SoftEnum.

I called it SoftEnum because the enum stays the source of truth, but the API is softer about what it accepts.

The Type

Here is the helper:

export type ExtractEnumValuesAsLiterals
<
    T_Enum extends Record<string, string | number>,
    T_Keys extends keyof T_Enum = keyof T_Enum
> =
(
    T_Enum[T_Keys] extends `${infer T_Value}`
        ? T_Value
        : never
);

export type SoftEnum
<
    T_Enum extends Record<string, string | number>,
    T_Keys extends keyof T_Enum = keyof T_Enum
> =
(
    ExtractEnumValuesAsLiterals<T_Enum, T_Keys>
        |
    T_Enum[T_Keys]
);

Now the component can use the enum as the source of truth:

type ButtonProps =
{
    variant: SoftEnum<typeof ButtonVariant>;
};

And both styles are accepted:

<Button variant={ButtonVariant.Primary} />
<Button variant="primary" />

But invalid values are still rejected:

<Button variant="random" /> // Type error

Why Not Just Use the Enum Type?

If the prop is typed directly as the enum:

type ButtonProps =
{
    variant: ButtonVariant;
};

Then this is fine:

<Button variant={ButtonVariant.Primary} />

But this is not:

<Button variant="primary" />

Even though the runtime value of ButtonVariant.Primary is "primary", TypeScript still treats the enum member as its own enum member type.

That is useful in many cases, but here it makes the JSX API stricter than we want.

Why the Template Literal Inference Works

The interesting part is this:

T_Enum[T_Keys] extends `${infer T_Value}`
    ? T_Value
    : never

This extracts the underlying literal value from the enum member type.

For string enums:

enum ButtonVariant
{
    Primary = "primary",
    Secondary = "secondary"
}

type ButtonVariantValues = ExtractEnumValuesAsLiterals<typeof ButtonVariant>;

The result is:

"primary"
    |
"secondary"

Then SoftEnum combines that with the original enum member types:

type ButtonVariantInput = SoftEnum<typeof ButtonVariant>;

Conceptually, it becomes:

ButtonVariant.Primary
    |
ButtonVariant.Secondary
    |
"primary"
    |
"secondary"

That means users can choose either style.

It Also Works With Numeric Enums

This helper is not only for string enums.

For example:

enum Status
{
    Active,
    Disabled
}

This works:

const status1: SoftEnum<typeof Status> = Status.Active; // valid

const status2: SoftEnum<typeof Status> = 0;             // valid

const status3: SoftEnum<typeof Status> = "0";           // invalid

That last line is important.

The helper does not turn numeric enum values into strings. It extracts the numeric literal value.

So for numeric enums, SoftEnum<typeof Status> accepts:

Status.Active | Status.Disabled | 0 | 1

not:

"0" | "1"

Narrowing to Specific Enum Keys

The second generic parameter makes it possible to allow only part of an enum.

type PrimaryOrSecondaryOnly = SoftEnum
<
    typeof ButtonVariant,
    "Primary" | "Secondary"
>;

Now the accepted values are only:

ButtonVariant.Primary
    |
ButtonVariant.Secondary
    |
"primary"
    |
"secondary"

This can be useful when one component supports only a subset of shared enum values.

The Compromise

This gave us a nice middle ground.

The library can still declare accepted values with enums:

enum ButtonVariant
{
    Primary = "primary",
    Secondary = "secondary",
    Danger = "danger"
}

So the enum remains the source of truth.

But consumers can still write lightweight JSX:

<Button variant="primary" />

Or explicit enum-based code:

<Button variant={ButtonVariant.Primary} />

Both are type-safe.

Both are valid.

And invalid values are still rejected.

Final Thoughts

I still like enums.

They are a real TypeScript feature, not just an object pattern. They are explicit, searchable, refactor-friendly, and they give me one clear place where accepted values are declared.

But I also understand why literal values feel better in many React APIs. JSX is supposed to be easy to read and easy to write. Forcing imports for every simple prop value can make a component library feel heavier than it needs to be.

SoftEnum is a small type-level compromise:

export type SoftEnum
<
    T_Enum extends Record<string, string | number>,
    T_Keys extends keyof T_Enum = keyof T_Enum
> =
(
    ExtractEnumValuesAsLiterals<T_Enum, T_Keys>
        |
    T_Enum[T_Keys]
);

It lets library authors keep enums as the source of truth, while component consumers can use simple literals when that feels more natural.

Not every API needs to pick one side forever.

Sometimes the nicest developer experience is just letting both styles coexist safely.

TypeScript Infers the Last Overload... So I Changed the Order

NickM — Wed, 01 Jul 2026 19:46:10 +0000

Once I was working with i18next and wanted to get better inference from translation keys.

Usually, with translation libraries, we pass keys as strings:

translate("user.profile.title");

And strings are fine... until they are not.

I wanted something closer in spirit to C# expression trees. Not real expression trees, of course — JavaScript does not have those. But something like this:

translate($ => $.user.profile.title);

Under the hood, this could be handled with a Proxy, reading the full member-access path at runtime.

Why even bother?

Because a lambda selector can give you much better DX than a plain string:

you can navigate to the source JSON/schema field;
you can navigate to the translation schema definition;
you can rename fields with editor refactoring;
you can get autocomplete through the whole translation tree.

Cool idea. But then I had to answer a very annoying TypeScript question.

I needed to take an existing function type from i18next, replace one of its argument types, and preserve the rest of the API.

Sounds simple enough, right?

Except that function type had several call signatures.

In other words: overloads.

And that led me to the real question:

Can we extract all call signatures from an overloaded function type, transform them, and build the overloaded type back?

I searched around and mostly found hardcoded overload tables, like “support up to 5 overloads”, “support up to 10 overloads”, etc.

That was not exactly what I wanted.

So I started experimenting.

The first wall: TypeScript infers only one overload

Let’s start with a tiny helper:

type InferCallSignature<T_Callable> =
(
    T_Callable extends (...args: infer T_Parameters) => infer T_Result
        ? ((...parameters: T_Parameters) => T_Result)
        : never
);

Nothing special here. If T_Callable is callable, infer its parameters and return type, then rebuild a normal function type.

Now let’s try it with an overloaded callable type:

type A =
{
    (): void;
    (a: number): string;
    (a: string, b: number): boolean;
};


type B = InferCallSignature<A>;
//   ^? type B = (a: string, b: number) => boolean

TypeScript inferred only one call signature.

More specifically, it inferred the last call signature.

That is the documented behavior for overloaded functions: when inferring from an overloaded type, TypeScript uses the last signature.

So at first glance, we are stuck.

We can get this:

type B = (a: string, b: number) => boolean;

But not this:

type All =
(
    (() => void)
        | 
    ((a: number) => string)
        | 
    ((a: string, b: number) => boolean)
);

And without such a union, we cannot easily transform every overload.

Then I tried an intersection

At this point, I started thinking about order.

We already know call-signature order matters: TypeScript infers from the last overload. So I wanted to poke the only thing I could still poke: intersection order.

That is what made me try something that looked completely redundant: intersecting the overloaded type with one of its existing call signatures.

But I did not only try this order:

declare const aLeft: A & ((a: string, b: number) => boolean);

I also tried the opposite order:

declare const aRight: ((a: string, b: number) => boolean) & A;

And that order is the important part.

Logically, neither type should change much.

A already has this signature:

(a: string, b: number): boolean;

So all of these should behave the same when called:

declare const a: A;

a();
a(123);
a("hello", 1);

aLeft();
aLeft(123);
aLeft("hello", 1);

aRight();
aRight(123);
aRight("hello", 1);

And they do.

But then I checked IntelliSense.

For plain A, VS Code showed the first overload as:

a(): void

For this version:

type Left = A & ((a: string, b: number) => boolean);

it still looked functionally the same as A: the same call signatures, in the same order.

But for the opposite order:

type Right = ((a: string, b: number) => boolean) & A;

VS Code showed the first overload as:

aRight(a: string, b: number): boolean

Wait.

The left operand of & was placed in front of the right operand in the call-signature order.

That was the interesting part.

The call surface looked the same, but the overload order changed. And even more importantly, A & Signature was not behaving the same as Signature & A for overload ordering.

Why order matters

Remember the previous limitation:

TypeScript infers from the last call signature.

So if intersections can change overload order, maybe we can control what infer sees.

Let’s test it:

type LastCallSignature = InferCallSignature
<
    ((a: string, b: number) => boolean) & A
>;

//   ^? type LastCallSignature = (a: number) => string

And there it is.

Before the intersection, TypeScript inferred:

(a: string, b: number) => boolean

After intersecting that same signature back into A, TypeScript inferred:

(a: number) => string

So the trick is:

TypeScript infers the last overload. Intersections can change the overload alignment. Therefore, intersections can change what TypeScript infers.

That is the whole door.

Once I saw that, extracting all call signatures became possible.

The plan

If TypeScript gives us only one call signature at a time, we can do this recursively:

Infer the currently visible last call signature.
Add that signature into an intersection alignment.
Let TypeScript expose another signature on the next pass.
Repeat until the alignment already satisfies the original callable type.

The utility type

Here is the full version:

type InternalCallSignatures<T_Callable, T_Alignment> =
(
    ({ [key in keyof T_Callable]: T_Callable[key] } & T_Alignment) extends T_Callable
        ? never
        : T_Callable extends (...args: infer T_Parameters) => infer T_Result
            ?
            (
                ((...parameters: T_Parameters) => T_Result)
                    |
                InternalCallSignatures
                <
                    T_Alignment & T_Callable,
                    ((...parameters: T_Parameters) => T_Result) & T_Alignment
                >
            )
            : never
);

export type CallSignatures<T_Callable> =
    InternalCallSignatures<T_Callable, {}>;

Let’s unpack it.

T_Callable is the callable type we are currently inspecting.

T_Alignment is the accumulated intersection of signatures we have already discovered. Think of it as a type-level alignment state. It influences which overload TypeScript will infer next.

This part is the stop condition:

({ [key in keyof T_Callable]: T_Callable[key] } & T_Alignment) extends T_Callable
    ? never
    : ...

In human words:

Does the current alignment already satisfy the callable shape we are inspecting?

If yes, we are done, so we return never.

If not, we infer one more call signature:

T_Callable extends (...args: infer T_Parameters) => infer T_Result
    ? ((...parameters: T_Parameters) => T_Result)
    : never

And then recurse:

InternalCallSignatures
<
    T_Alignment & T_Callable,
    ((...parameters: T_Parameters) => T_Result) & T_Alignment
>

On every step, we return the inferred signature as part of a union, and we extend the alignment with that signature.

The mapped type here:

{ [key in keyof T_Callable]: T_Callable[key] }

may look useless, but it helps normalize the non-callable/object part of the type before checking it together with the current alignment.

The result

Now let’s try it with our overloaded type:

type A =
{
    (): void;
    (a: number): string;
    (a: string, b: number): boolean;
};


type AllCallSignatures = CallSignatures<A>;

And the result is:

type AllCallSignatures =
(
    (() => void)
        | 
    ((a: number) => string)
        | 
    ((a: string, b: number) => boolean)
);

Beautiful.

Now the overloads are not trapped inside an overloaded callable type anymore.

They are a union.

And unions are much easier to transform.

Transforming the signatures

For example, let’s wrap every return type into Promise:

type PromisifySignature<T_Signature> =
(
    T_Signature extends (...args: infer T_Parameters) => infer T_Result
        ? (...parameters: T_Parameters) => Promise<T_Result>
        : never
);

Because conditional types distribute over unions, this works naturally:

type AsyncCallSignatures = PromisifySignature<CallSignatures<A>>;

Result:

type AsyncCallSignatures =
(
    (() => Promise<void>)
        | 
    ((a: number) => Promise<string>)
        | 
    ((a: string, b: number) => Promise<boolean>)
);

Now we can convert the union back into an intersection:

type UnionToIntersection<T_Union> =
(
    (
        T_Union extends unknown
            ? (value: T_Union) => void
            : never
    ) extends (value: infer T_Intersection) => void
        ? T_Intersection
        : never
);

And build an overloaded callable type again:

type AsyncA = UnionToIntersection<AsyncCallSignatures>;

Usage:

declare const asyncA: AsyncA;

const result1 = asyncA();
//    ^? Promise<void>

const result2 = asyncA(123);
//    ^? Promise<string>

const result3 = asyncA("hello", 1);
//    ^? Promise<boolean>

So now the full pipeline is:

// overloads -> union -> transform -> intersection -> overloads again

Back to the original problem

In my i18next experiment, this meant I could theoretically take overloaded function signatures, replace one argument type, and preserve the rest of the overload behavior.

The important part was not i18next itself.

The important part was realizing this:

If you can turn overloads into a union, you can operate on them like data.

And the key that made it possible was surprisingly small:

TypeScript infers the last overload, but intersections can change overload order.

Final note

This is definitely a type-system trick, not an official “overload reflection API”.

It relies on how TypeScript currently evaluates overloaded and intersected callable types. So if you use something like this in a library, test it carefully with the TypeScript versions you support.

Still, I think it is a beautiful little trick.

I started with translation keys and ended up learning that & can do much more than just merge object types.

Sometimes TypeScript is weird in exactly the right way.

DEV Community: NickM

React displayName Without Strings: A C#-Inspired TypeScript Proxy Trick

First attempt: keyof

What I actually wanted

The proxy trick

Getting only the final name

What about private members?

Back to the component

What this is not

The bundler question

Final result

Where this idea could go next

Conclusion

I Like Enums. My Teammate Preferred Literals. TypeScript Let Us Have Both.

The Const Object Approach

Why I Still Wanted Enums

The Goal

The Type

Why Not Just Use the Enum Type?

Why the Template Literal Inference Works

It Also Works With Numeric Enums

Narrowing to Specific Enum Keys

The Compromise

Final Thoughts

TypeScript Infers the Last Overload... So I Changed the Order

The first wall: TypeScript infers only one overload

Then I tried an intersection

Why order matters

The plan

The utility type

The result

Transforming the signatures

Back to the original problem

Final note

First attempt: `keyof`