Template Literal Types in TypeScript: From Strings to Rules

👉 Watch on YouTube

There is a stage in learning TypeScript where basic typing is no longer the hard part.

You already know generics. You already know utility types. You may even be comfortable with infer.

Then a different kind of problem starts showing up: strings that are not really “just strings.”

They have a structure.

They follow naming conventions, domain rules, and repeated patterns that the team understands mentally but the compiler still sees as plain text.

That is the exact shift this video focuses on.

Template literal types matter because they let TypeScript model those string rules directly instead of forcing you to enumerate every allowed value by hand.

The real problem is implicit structure

The video makes an important point early: the issue is not that strings are bad.

The issue is that many systems hide rules inside strings without teaching those rules to the type system.

That usually leads to code where:

• valid names exist only in developer memory
• typos look like normal strings until runtime
• adding a new variant means updating several disconnected places
• the compiler cannot help because the contract is too broad

This is why patterned strings become fragile.

They often look flexible, but they are really undocumented mini-languages.

Template literal types turn patterns into contracts

At the center of the video is a simple but powerful idea: describe the rule, not the final list of values.

If a spacing token is always made from a property and a direction, you can model that relationship directly.

type Property = "padding" | "margin";
type Direction = "top" | "right" | "bottom" | "left";

type SpacingProperty = `${Property}-${Direction}`;

Now TypeScript can derive:

• padding-top
• padding-right
• margin-bottom
• margin-left

And it can reject invalid combinations like "padding-center".

That is the design win.

You are no longer listing outcomes.

You are modeling how valid outcomes are built.

This scales better than manual unions

You could write the whole union by hand.

For a small demo, that works.

But the moment a domain grows, manual unions become a maintenance problem in the same way duplicated interfaces do.

If you add a new direction like center, the type above updates automatically. If you add another property, every valid combination appears without retyping the matrix.

That is what the video means when it says the system starts to understand the pattern.

And once the compiler understands the pattern, many future changes stop depending on human memory.

Template literal types cross-multiply unions

One useful idea to expand beyond the video comes directly from the TypeScript handbook: when you interpolate unions inside a template literal type, TypeScript generates every possible combination.

type Entity = "user" | "product" | "order";
type Event = "changed" | "deleted";

type EntityEvent =
  `on${Capitalize<Entity>}${Capitalize<Event>}`;

That produces a union like:

• onUserChanged
• onUserDeleted
• onProductChanged
• onOrderDeleted

This cross-product behavior is what makes template literal types so expressive for naming conventions, cache keys, routing ids, event names, CSS-like tokens, and similar domains.

Event names are where this becomes obviously useful

The video moves from spacing tokens to domain events, and that is where the practical payoff gets clearer.

A lot of codebases contain event names like:

• onUserChanged
• onProductDeleted
• onOrderChanged

Usually these live as loose strings scattered across the codebase.

That feels easy at first, but it creates a weak contract.

With template literal types, you can derive those names from real domain pieces.

type Entity = "user" | "product" | "order";
type EventType = "changed" | "deleted";

type DomainEvent =
  `on${Capitalize<Entity>}${Capitalize<EventType>}`;

Now adding invoice to Entity automatically adds onInvoiceChanged and onInvoiceDeleted.

That is more than autocomplete.

It is a better source of truth.

String helpers make these rules more expressive

The built-in helpers Uppercase, Lowercase, Capitalize, and Uncapitalize make this pattern much more practical in real code.

They let you normalize the generated strings instead of hardcoding every casing rule yourself.

type Entity = "user" | "product";
type Action = "created" | "deleted";

type AuditKey = `${Uppercase<Entity>}_${Uppercase<Action>}`;
// "USER_CREATED" | "USER_DELETED" | ...

That matters because many real systems already use naming formats for analytics events, configuration keys, cache ids, and message topics.

Template literal types let those formats become part of the type model instead of staying hidden in conventions docs.

The deeper payoff is pattern matching at the type level

The video hints at an even more interesting idea: once TypeScript can generate structured strings, it can also help analyze them.

This is where template literal types connect naturally with generics, indexed access types, and infer.

The official docs show a classic example with watched object events:

type PropEventSource<Type> = {
  on<Key extends string & keyof Type>(
    eventName: `${Key}Changed`,
    callback: (newValue: Type[Key]) => void,
  ): void;
};

That design does two useful things at once:

• it restricts the event name to a valid pattern
• it infers the callback payload from the matching property

So "ageChanged" gives you a number, while "firstNameChanged" gives you a string.

That is a big step up from “typed strings.”

It is relationship modeling.

Mapped types make the pattern even stronger

Another useful expansion is to combine template literal types with mapped types and key remapping.

type Getters<Type> = {
  [Key in keyof Type as `get${Capitalize<string & Key>}`]: () => Type[Key];
};

Now an object like this:

interface User {
  name: string;
  age: number;
}

Can produce a derived API like this:

type UserGetters = Getters<User>;
// { getName: () => string; getAge: () => number }

This is the same philosophy the video argues for.

Do not hand-maintain a pile of related names when the naming rule itself can be encoded once.

There is still an important limit

Template literal types are powerful, but they are not a free pass to build giant type-level parsers for everything.

Two limits matter in practice.

First, very large unions can explode in size and become hard to read or slow to work with.

Second, some strings are genuinely too dynamic to model precisely at compile time.

That means the mature question is not “can I encode this?”

It is “does encoding this improve the contract enough to be worth the complexity?”

When the answer is yes, template literal types can remove a lot of fragile string logic. When the answer is no, a plain string plus runtime validation may be the more honest tool.

The maintainability win is the real story

The video presents template literal types as a way to model rules, and that is exactly the right framing.

Their value is not that they make the code look advanced.

Their value is that they move a convention out of human memory and into the compiler.

Once the rule is explicit, TypeScript can:

• generate valid combinations automatically
• reject invalid combinations early
• keep related names aligned as the domain evolves
• make refactors safer because one rule updates many outputs

That is why this feature matters.

It turns strings from a weak boundary into something the type system can actually reason about.

The takeaway

Template literal types are useful because they help TypeScript describe structured text as structured text.

They let you move from:

• memorizing allowed strings
• copying long unions by hand
• hoping naming conventions stay consistent

To:

• encoding the naming rule once
• deriving valid strings automatically
• letting the compiler protect the pattern

That is not just clever typing.

It is better design.

And when your domain contains strings that are really rules in disguise, template literal types are one of the clearest ways to make that design visible.