You are building a reusable component. You start with a simple, elegant component — maybe a basic expander — that fits a single use case. But as requirements grow, so does the component.

You add more and more inputs, and before you know it, you’ve created a “monster” — a complex piece of code packed with features, customization options, and countless inputs.

There’s a better way.

The Trap of “Input Overload”

When we want to add a new feature, the most common instinct is to add another input() . For example, if you want your expander’s header to be clickable to toggle the content, you might add

@Component({
  ...
  selector: 'app-expander'
  ...
})
export class ExpanderComponent {
  ...
  readonly useHeaderAsToggle = input(false);
  ...
}

However, this approach quickly leads to several problems:

• Maintainability Nightmares: You end up with components that are 1,000 lines long, filled with if statements and spaghetti code that is nearly impossible to understand. Even for this simple example you need conditional styling for clickable headers, conditional event handlers, and perhaps conditional markup.
• Unreadable HTML: If your component supports 50 features, the consumer might have to manage 50 different inputs in their template, making the HTML impossible to read.
• Poor Logic Separation: Features that belong to a sub-part (like the header) are being managed by the parent (the expander), which doesn’t make architectural sense.

To demonstrate the last point — look at this code:

<app-expander [useHeaderAsToggle]="true">
  <span expander-header>The Composite Components Pattern</span>
</app-expander>

The behavior applies to the header…
but the configuration sits on the parent.

So when reading the template, you’re forced to “jump” between elements to understand what’s going on.

That’s a design smell.

What are Composite Components?

The Composite Components pattern shifts the focus from “packing features in” to composing features together. The idea is simple:

• The main component stays small
• Features live in separate units (directives / sub-components)
• Consumers combine them as needed

Practical Example: The Expander Header Toggle

Instead of adding another input, we move the behavior into a directive.

@Directive({
  selector: '[expander-header][toggle]', // Requires both attributes to apply
  host: {
      '[style.cursor]': '"pointer"', 
      '(click)': 'onClick()'
  }
})
export class ExpanderHeaderToggleDirective {
  // Inject the parent expander component to access its logic
  private expander = inject(ExpanderComponent, { optional: true });


  // Handle the click event to call the expander's toggle method
  onClick() {
    this.expander?.toggle();
  }
}

Usage Becomes:

<app-expander>
  <span expander-header toggle>The Composite Components Pattern</span>
</app-expander>

What Did We Gain?

• No new inputs
• No changes to the main component
• Feature is fully encapsulated
• The expander stays clean and focused.

Real-World Inspiration: Angular Material

This isn’t a new or niche pattern; it has been used by Angular Material since its inception.

• <mat-form-field> : This component doesn’t have a massive list of inputs for labels, hints, or icons. Instead, you compose it using directives like matInput, <mat-label>, and matSuffix.
• <mat-card>: A card is a package of sub-components like <mat-card-header> and directives like matCardAvater . This allows the main card component to have very few inputs while remaining incredibly flexible.

Why You Should Use This Pattern

1. Encapsulation: Every feature lives in its own file.
2. Flexibility: Users can mix and match exactly which features they need for a specific instance.
3. Clean APIs: Your main component doesn’t get cluttered with irrelevant inputs.
4. Standardization: This pattern is becoming the standard for modern component libraries and is heavily utilized in newer packages like Angular Aria (often paired with headless component patterns).

By adopting composite components, you can build a robust library where features play nicely together without turning your codebase into a monster. In the long run, this allows you to maintain the same codebase across many different projects with ease.

What’s next

If this resonates, I go much deeper into this pattern — including advanced composition techniques and real-world examples — in my new Udemy course, Building Reusable Components in Angular — The Missing Guide.

It’s a hands-on deep dive into composable components, content projection, templates, and the patterns behind real-world component libraries.

I Hate repeating myself.
Again…
I Hate repeating myself.
Especially in code.

Repeating logic is one thing we all know is bad. In software, they train us to encapsulate, reuse, to abstract. Our techers even give us achronyms so the lesson sticks — DRY (Don’t Repeat Yourself… don’t repeat yourself). Every modern paradigms since OOP has tried to solve the same problem: how to package logic so it can be reused — with classes, functions, closures… whatever.

And yet, when working with Angular’s Reactive Forms, I keep running into the same situation: repeating validation logic for the same combinations of fields. Literal copy-paste. Over and over again.

A Familiar Case

Take this example. in one of my projects, I have many (many…) different forms where two fields always appear together:

readonly status: TaskStatus; // 'upcoming' | 'ongoing' | 'completed';
readonly dueDate: string; // ISO date string

And the logic is always the same:

• status is required
• If status === 'completed', dueDate should be read-only
• Otherwise, dueDate must be a date in the future

Now, technically, I could create a nested control that encapsulates this logic and reuse it. But that comes with a cost: it pollutes the model with structure that exists purely for technical reasons.

What I really want is this:

• Keep the form model flat
• Apply cross-field validation
• Reuse the logic
• No duplication

Reusable Schemas in Signal Forms

Signal Forms introduces the concept of a schema.
A schema doesn’t describe just validation — it describes form logic. Validation, metadata, readonly rules — it all lives under the same umbrella.

(In the example above, “readonly when completed” isn’t validation per se, but in Signal Forms it’s still part of the schema.)

So how do we make that logic reusable?

Step 1: Define a focused Interface

First, we define an interface that represents only the fields involved in the shared logic:

export interface TodoItem {
  readonly status: TaskStatus;
  readonly dueDate: string; // ISO date string
}

Important detail:
The form model does not need to explicitly declare that it implements this interface.

TypeScript uses structural typing. If a form has these two properties with the correct types, it implicitly matches this interface — whether it “knows” it or not.

Step 2: Define the Schema

Now, let’s define the schema as a reusable function. We do it using the schema function.

export function todoItemSchema() {
  return schema<TodoItem>((path) => {
    required(path.status);
    readonly(path.dueDate, 
        ctx => ctx.valueOf(path.status) === 'completed');    
    validate(path.dueDate, (ctx) =>
        new Date(ctx.value()).valueOf() > Date.now()
          ? null
          : { 
              kind: 'dueDateInPast', 
              message: 'Due date must be in the future.' 
            },
    );
  });
}

This schema defines three rules:

1. The status field is required
2. The dueDate field is readonly if the value of the status field is equal to completed
3. The dueDate field value has to be in the future.

One subtle but important detail:
The third rule only applies when the field is not read-only. In Signal Forms, read-only fields do not participate in validation.

Step 3. Reusing the schema

Now let’s say we have a larger model that includes these two fields, plus others:

export interface UserStory {
    readonly displayName: string;
    readonly assignedTo: string;
    readonly estimationPoints: number;
    readonly reviewer: string;
    readonly status: TaskStatus;
    readonly dueDate: string; // ISO date string
}

And we create a writeable signal of this type:

 readonly story = signal<UserStory>({
    displayName: 'Implement Signal Forms',
    assignedTo: 'Alice Johnson',
    estimationPoints: 5,
    reviewer: 'Bob Smith',
    status: 'ongoing',
    dueDate: '2024-07-15'
  });

Now we wrap it with a signal form:

protected readonly storyForm = form<UserStory>(this.story, path => {
    required(path.displayName);
    required(path.assignedTo);
    max(path.estimationPoints, 10);
    required(path.reviewer);
}

We have added some validation rules to all the other fields.

We can use the apply function to apply our reusable schema to this form — literally adding all its rules to the rules that already exist in this forms schema:

protected readonly storyForm = form<UserStory>(this.story, path => {
    required(path.displayName);
    required(path.assignedTo);
    max(path.estimationPoints, 10);
    required(path.reviewer);

    // one line - all rules applied
    apply(path, todoItemSchema()); 
  });

That’s it.

No nesting,
No duplication,
Same logic reused everywhere.

Final Thoughts

This feature isn’t flashy — and that’s exactly why I like it. It reflects what Signal Forms does well

Reusablity is at the core of its architecture.

It’s built for reusablity from the ground up.

And this is just one example. There are many other places where Signal Forms quietly makes reuse easier and cleaner. I cover most of them in my course Modern Angular with Signals, where I spend about three hours just on Signal Forms (That’s how much I love this new feature).

It’s obvoius that the guys at the Angular team have put a lot of thought into the signal forms feature. What came out is a work of art.

In my courses, I get this question a lot:

“How do I connect Signal Forms to a Signal Store”

In a Signal Store, (as in most services) state is exposed as read-only signals.
That’s intentional. Consumers can read, but updates must go through store methods.

Signal Forms, on the other hand, expect a writable signal. They assume they are allowed to call set() freely.

So things dont line up.

Why direct binding is a problem

Today, NgRx signal store has a withLinkedState feature. This feature allows you to add a writeable signal to the core state, so it can be updated directly.

That’s problematic. If we pass a service writeable signal directly to a form, we immediately lose something important.

The form can now:

• Mutate state directly
• Bypass store methods
• Skip validation, normalization, or multi-field coordination
• Generate state transitions the store never “approved”

Sometimes that’s unacceptable.

Maybe the form edits only part of the state… Maybe updating one field requires updating others to keep the model consistent… Maybe updates must be atomic…

We also lose the ability to use other store extensions that rely on their own updaters, for example, the withEntities custom feature depends on the updateEntity updater. So if you want to add an entity and be able to edit it in a form — that would be a problem.

Another example is withDevtools from The NgRx toolkit . It allows inspecting store state using browser devtools, but it requires updates to go through updateState instead of patchState, so metadata about the change can be recorded.

If the form could directly modify your state… If, theoretically, the state could be exposed as a writeable signal, that updater function would be bypassed entirely.

So what we’re really looking for is this:

we want the form to rely on model state held in the store, while still controling how updates flow back to the store.
The store must stay in charge.

Duplex Unidirectional Flow

Instead of two-way binding we want two unidirectional flows.

1. When the store state changes, the new state should flow into the form so the fields reflect it — that’s the easy part.

2. When the form state changes, the new value should flow back into the store through custom logic that we control — That’s the tricky part.

The easy case (and why it’s not always enough)

If the store should update only when the user submits the form, the solution is straightforward.

• You keep the form model local to the component holding the form.
• On submit, you call the store method.

This is exactly where linkedSignal shines — something I covered in a previous article.

But there’s another scenario I keep seeing.

The harder case: continuous sync, controlled updates

Sometimes, you do want the form and the store to stay in sync while the user types.

But still:

• Updates must go through store methods
• Update logic must remain explicit
• No hidden mutation paths
• No effects quietly “watching” and reacting

That combination doesn’t come built in.

So I built a small utility for it.

Introducing: Projected signal

If you want to see the code, there’s a demo app in this GitHub repository

The core idea is simple:

• Reading comes from the store
• Writing goes back to the store
• To the outside world, it still behaves like a writable signal

I call this a projected signal.

It “projects” store state outward as a signal, while “projecting” updates inward through store APIs.

That separation is the key.

What a projected signal looks like

A projected signal is defined by two things:

1. A computation — how to read from the store
2. An update function — how writes are handled

readonly projected = projectedSignal({
  computation: () => this.store.xy(),
  update: value => this.store.setXY(value)
});

The projectedSignal function returns a ProjectedSignal<T> which extends WritableSignal<T>. So all practical purposes, it is a WritableSignal.

But there’s a catch

This writeable signal does not store it’s own value. It assumes entity manages the state and acts purely as a proxy.

Internally, it wraps the computation in a computed signal so it stays up to date. When someone calls set() or update(), the logic is delegated to the provided updater.

From the store’s point of view, nothing changed — all updates still go through explicit methods.

No mutation.
No bypass.

Why Signal Forms work with this

Signal Forms don’t need to know about stores.

They only require one thing:
a signal they are allowed to write to.

ProjectedSignal<T> intentionally extends WritableSignal<T>.

That single design choice is what allows this to work:

readonly form = form(this.projected, path => {
  max(path.x, 20),
  max(path.y, 20)
});

The form writes.
The projected signal intercepts.
The store decides what actually changes.

The actual data flow

When the user edits the form, the flow is very explicit:

• The Form Updates
• ProjectedSignal.set is called
• The store method is called
• In this specific example: Devtools and logging occurs
• Store state changes
• The projected signal updates
• The form updates
• The UI updates

And most importantly:

No Effects

No Hidden Observers

Just unidirectional data flow — even during live editing.

Why this stays boring (in a good way)

This utility doesn’t introduce a new paradigm.

It doesn’t replace stores.
It doesn’t modify forms.
It doesn’t add lifecycle hooks or side channels.

It simply restores a boundary that forms tend to blur:

Forms describe user intent. Stores decide how state changes.

A projected signal is just the adapter between the two.

Final thought

I see this pattern often enough that I wanted it to be explicit, reusable, and boring.

That’s usually a good sign.

I’d genuinely love to hear what you think about this approach — 
especially if you’ve solved this problem differently.

A Simple Search for a UID Turns Into Something Else

In one of my latest projects, I started from a clean base and needed a unique ID generator. It happened many times in the past, but this time the customer specifically asked to minimize using open‑source packages. So I decided to check whether TypeScript had a native way to generate IDs. Surprisingly, it did.

I discovered the global crypto object. This constant exists in modern JavaScript runtimes but many developers (myself included) barely touched it. Most of us assume anything cryptographic requires a library, but the browser and Node both ship with a built‑in cryptography API capable of generating “crypto-safe” random values.

Turns out it can also produce secure UUIDs. I found crypto.randomUUID(). So of course, I hovered over the function definition… and that’s when the real surprise hit me.

A Surprising intellisense

Hovering over the function, I expected the usual: randomUUID(): string

Instead, VSCode casually shows me this:

The return type looks like a template literal from JavaScript , except it’s not a value, it’s a type…

How is this even a thing?

Putting the Curious Type to the Test

Naturally, I had to poke it a little. I created a variable with a template type and fed it a matching string.

TypeScript nodded politely.

Then I removed a hyphen.

Error!

The compiler — not a regex, not a linter — was validating the shape of the string. At compile time.

This was no longer about UUIDs. This was a whole new door I didn’t know TypeScript even had.

What Can Go Inside Those ${} Slots?

So then the question was: what can you even put inside these ${} placeholders? Turns out you can put more than I initially expected.

It starts, with the expected:

• literal strings? sure.
• numbers? works just fine.
• booleans? also valid.

I tried all three. TypeScript happily converted numbers and booleans to their string forms inside the template.

It also works with built‑in string manipulation helpers like Uppercase<>, Lowercase<>, and Capitalize<>. These let you transform parts of the template. For example, you can enforce that a value always starts with an uppercase letter or that a segment must be uppercase:

And for Dessert…

I decided to try something else: what happens if I use unions inside these templates?

That immediately reminded me of an old annoyance I had when working with CSS types. At the time, I wanted to create a property type that listed all possible border properties in CSS — things like border-top-width, border-right-color, and so on.

Back then, the only real option was to manually write a giant union of strings or rely on external helpers. Neither approach felt elegant.

So this time, standing in front of TypeScript’s template literal types, I wondered: can I finally generate that whole family of strings using unions?

Instead of typing each one manually, you write:

type BorderSide = "top" | "right" | "bottom" | "left";
type BorderProp = "width" | "style" | "color";

type BorderProperty = `border-${BorderSide}-${BorderProp}`;

Now you can define a variable of that type and hover over it…

You gotta love Typescript…

A Small Conclusion

After reading more about it, I found out something almost anticlimactic: this isn’t new at all. In fact, template literal types have been part of TypeScript since version 4.1 — released back in 2020. So while many readers may already know and use them, somehow… I completely missed them.

Maybe they never came up in my day‑to‑day work. Maybe I never hovered over the right function signature. Either way, the feature was there all along. But if I missed it, maybe you did too?

In the previous article, I told you how I stumbled into the discovery that Signal Forms don’t just validate — they actually broadcast metadata straight into the UI. min, max, required, length limits… all flowing into components without me adding a single attribute in the template.

That little surprise left us with a question hanging in the air:

Can we create our own metadata keys — and make Angular treat them exactly like the built-in ones?

The short answer is yes.
The interesting part is how.

And to understand that, we need to zoom into something Angular quietly builds for us behind the scenes.

The Field State

Whenever you create a form, Angular builds a tree of field wrappers called FieldTree. As the name suggests, it mirrors the structure of your form model: each FieldTree holds child FieldTrees — a tree of fields inside a tree of fields.

But there’s a twist:
each FieldTree is also a function.
Call it, and you get a FieldState object loaded with signals describing the field’s current state:

• dirty: Signal<boolean>
• touched: Signal<boolean>
• invalid: Signal<boolean>

…and many more.

So far, nothing unusual. But inside this object lives something much more interesting — something that unlocks the whole mystery.

The Metadata Function

The state also includes a function called metadata. You give it one parameter — a “Key” (tell you about it in a sec) and it returns the value of a metadata property.

The “Keys” are a little like InjectionToken. Just like inject() returns a value of type T based on a token of type InjectionToken<T>, metadata() returns a Signal<T>based on a MetadataKey<T>. Why Signal? Because field metadata properties can change just like everything else in the form. And we want to be able to react to these changes.

To summarize — here’s a little code

readonly data = signal({x: 1});
readonly myForm = form(this.data, path => {
  max(path.x, 10)
})

readonly xFieldTree = this.myForm.x;
readonly xState = this.xFieldTree();
readonly maxValue = this.xState.metadata(MAX); // Signal<number | undefined>

Now maxValue() is yours to display in the template — an automatic hint telling the user what keeps your validator happy.

Can I create my own Keys?

Of course you can, that’s the whole point of this article.

You can create your own MetadataKey<T> just like you can create a custom InjectionToken<T>.
But there is one complication:

Aggregation.

To put it simply — Imagine two validators, and both set different min values to the same field. The first one sets the min value to 5, and another sets it to 6.

What is the effective minimum value? 6, right? Because if the field’s value is 6 or above — both validators are happy. If the field’s value is 5, only one validator is happy, and the other one returns an error. So if you want to present a hint that tells the user what values she may enter in the field so that both validators are happy — this value would have to be the largest of the two.

But what about a max value validator? Now it’s the other way around. If one validator requires a max value of 8 and the other requires max value of 9, then the effective max value is 8. and that’s the value of the MAX metadata property.

So metadata keys need to know how to combine multiple values. This logic is embedded in the key itself. So when you create a new metadata key, you choose a factory method that builds the key with the correct embedded aggregation logic.

Angular gives you various factory functions to choose from.

const MAX_WORDS = minMetadataKey(); // key where the aggregated value is the minimum of all values
const MIN_WORDS = maxMetadataKey(); // key where the aggregated value is the maximum of all values

And if you want full control there’sreducedMetadataKey where you simply provide your own logic.

So now you know how to create metadata property keys. (or more precisely— an AggregateMetadataKey<T>)

You also know how to get the effective value of this metadata property for each field.

Which brings us to the last secret.

How do you set these values?

To write values into a metadata key, you use the function aggregateMetadata(). It takes 3 parameters:

1. The path (representing the field)
2. The property metadata Key
3. A function that computes the value from the field context

Why a function?
Why does everything have to be a function in signalForms?
Why can’t they just take a normal value and keep it simple?

Well… That’s because signals are functions, and metadata needs to be reactive too. And sometimes metadata depends on other fields. For example you can set the minimum number of words in one field depending on the value of another field.

Cool, isn’t it? Even if it’s a bit complex.

Writing a Custom Validator with Metadata

Say you want a reusable validator called minWords, and you want it flexible enough to accept:

• A simple number, or
• A function that calculates the number based on other fields

Here’s the signature:

export function minWords(
  path: SchemaPath<string>, 
  minValue: number | LogicFn<string, number>) {
...
}

The first parameter is a path that indicates which field should be validated. It has to be a string field (which makes sense if we are going to count the words in this field) — hence SchemaPath<string> — it’s a path that points to a field of type string.

The second parameter is either a number, or a function that calculates a number from the context of that field.

inside, before you call the validate function to perform the actual validation, you publish the metadata.

So your reusable custom validator will look like this:

export function minWords(
  path: SchemaPath<string>, 
  minValue: number | LogicFn<string, number>) {

  aggregateMetadata(path, MIN_WORDS, (ctx) =>
    typeof minValue === 'number' ? minValue : minValue(ctx)
  );

  validate(path, ctx => {
    // validation logic that either returns undefined or customError
  }
}

And that’s it.

By the way, if you peek into the source code, you’ll see that the built-in validators (min, required, pattern, maxLength) all follow this exact structure.

And The best thing

For me, the real magic happens once you start treating every part of your field as metadata. Suddenly your forms gain structure, consistency, and a level of reuse that’s hard to unsee once you try it.

If you want to explore this pattern end-to-end — with real components, a real form, and the full metadata flow — I break it down in my online digital course: Modern Angular with Signals — The Missing Guide. It’s the most complete walkthrough I’ve created so far.

Honestly, working with the new Signal Forms has been a real pleasure. You can feel how much thought went into the design — every piece fits together, every feature has a purpose, and the whole system feels both powerful and elegant. It’s one of those rare additions to Angular that just “clicks” the moment you start building with it.

It Started with a Weird Compilation Error

Angular 21 was just released, and like everybody, I wanted to try out the most exciting feature — Signal Forms. I started with the simplest setup I could think of: just one numeric field called rating. I added min and max validators. Nothing fancy.

readonly model = signal({
    rating: 3
  });

readonly ratingForm = form(this.model, f => {
    min(f.rating, 1);
    max(f.rating, 5);
  })

I created a range slider and added the usual min and max attributes there too (because I wanted the UI to reflect the legal range).

<div class="field">
    <label>Rating</label>
    <div class="control">
      <input type="range" min="1" max="5" 
            [field]="ratingForm.rating" />
      <span>{{ model().rating }}</span>
    </div>
  </div>

Only to discover that Angular simply refused to compile. And I got this strange error:

It wouldn’t let me set those attributes at all. I removed them because I had no choice. And that’s when things got strange.

When the UI Knows Things You Never Told It

With the attributes removed, I expected the range input to fall back to default browser behavior. But instead, the slider automatically used the values from my validators.

Just to be sure it wasn’t a coincidence, I changed the validation range to something unusual like -10 to 10.

It still worked. Perfectly. So I opened DevTools to see what was going on. And there it was: the min and max attributes did exist, just not because I set them. The directive had injected them into the DOM.

Somehow, the slider was reflecting validation logic that lived deep inside a function I wrote.

The Validator Knows… but How Does the Directive Know?

But that raised a deeper question.

A validator is just a function. It receives a value and returns an error — or doesn’t. The parameters I pass into that validator are hidden inside its closure. So how does the directive know them? How does it extract { min: -10, max: 10 } out of a function call it never sees?

And if Angular can do this for built‑in validators… can it do it for custom validators too? Could I create a validator that enforces a minimum of 50 words and have that “50” become metadata that components can read and use?

And one last question. If I write my own custom range selection control that is based on marking “stars”, can it also receive this information automatically from the [field]directive?

Ding Dong, The ControlValueAccessor is gone

With ControlValueAccessorout of the picture, building a custom control became almost effortless. I wanted to test whether schema metadata — like the max value I used earlier—would automatically flow into my own component the same way it did with the range slider.

All I needed was a component with an input model called value

export class StarRating {
  readonly value = model.required<number>();
}

That’s already enough for the [field] directive to wire the form control to my component. But I wanted to go further: could a metadata value like max be passed into my component as well?

So I added an input called max. Since I wanted to allow undefined as a valid state, I defined it like this:

export class StarRating {
  readonly value = model.required<number>();

  readonly max = input<number | undefined>(undefined);

  readonly stars = computed(() => 
    Array.from({ length: this.max() ?? 5}, (_, i) => i + 1));

}

Now stars becomes a computed signal holding an array from 1 to max, letting the template iterate and display filled or empty stars depending on their index and the current value.

@for(i of stars(); track i) {
    <mat-icon (click)="value.set(i)">
        @if(i <= value()) {
            star
        } @else {
            star_outline
        }
    </mat-icon>
}

Finally, the big test: would Angular pass the max metadata value into my component automatically? I set the validator to max(f.rating, 7) and… well, the result speaks for itself.

export class App {
  readonly model = signal({
    rating: 3
  });

  readonly ratingForm = form(this.model, f => {
    max(f.rating, 7);
  })
}

It worked.

Peeking Under the Hood

But how does it really work?

Curiosity won. I opened the Angular source code.

What I found is that Signal Forms validators don’t just validate — they also publish structured metadata onto the field object. Each validator function has two parts:

export function max<...>(path: SchemaPath<...>,
  maxValue: number | LogicFn<...>) {
  // ...
  aggregateMetadata(path, MAX, ({state}) => state.metadata(MAX_MEMO)!());
  validate(path, (ctx) => {
    // ...
    const max = ctx.state.metadata(MAX_MEMO)!();
    // ...
    const value = ctx.value();
    const numValue = !value && value !== 0 ? NaN : Number(value); // Treat `''` and `null` as `NaN`
    if (numValue > max) {
        // ...
        return maxError(max, {message: getOption(config?.message, ctx)});
    }
    return undefined;
  });

1. A metadata installer, which stores values under a specific key (like MAX) using a function called aggregateMetadata.
2. The actual validation logic, defined in the validate function, which checks the condition and returns either an error or undefined.

The [field] directive simply reads this metadata and passes it on to the host control — no magic, no reflection, no guessing. And that’s how the range input knew exactly what min and max to use..

Final Thoughts

The only real question left is this: can we define our own custom metadata keys — and have Angular pass them along to our controls just as effortlessly?

The short answer is absolutely yes.
But that’s a rabbit hole I’ll save for the next article.

When Angular 14 introduced the inject function, it looked simple enough. A tiny helper that lets you grab a dependency without writing a constructor or a decorator. Nice and clean. But something about it didn’t sit quietly in my mind.

You see, Angular’s dependency‑injection system always works in relation to the “consumer” (the thing asking for the service). One component might get one instance of Service A, while another gets something completely different, simply because each one starts from its own injector and walks upward through the hierarchy until it finds a provider.

And that leads to a pretty wild realization:

For inject to behave correctly, it has to know who is calling it.

In over 25 years of writing JavaScript, I’ve had countless moments where I desperately wished I could write a function that asks, “Hey, who just called me?” And every single time, the answer was the same: you can’t. JavaScript simply doesn’t give you that power. No hidden API, no magical stack inspector, nothing.

So when I saw inject behaving as if it did know its caller… the question lingered:

How the heck are they doing that?

How indeed…

I remember sitting there, watching the Angular 14 keynote on YouTube, coffee in hand, when the thought hit me hard. If inject depends entirely on the current injector, then it must somehow know exactly which component or function is calling it.

And that didn’t make sense. Not in JavaScript. Not in anything I’d seen in 25 years.

So I stared at the screen and asked myself a question:

Did the Angular team… cheat?

Because if they didn’t, then they must’ve invented a trick the rest of us never had.

2 minutes after the keynote ended, I was searching through the Angular’s GitHub repository for the answer.

Digging into the code

First, I went straight to the inject function itself. Here’s the actual implementation:

export function inject<T>(token: InjectionToken<T> | Constructor<T>): T {
  const currentInjector = getCurrentInjector();
  if (!currentInjector) {
    throw new Error('Current injector is not set.');
  }

  ///...

  return currentInjector.retrieve(token as InjectionToken<T>, options);
}

Nothing fancy. It just grabs something called the current injector. But that immediately raised a question: What exactly is this “current injector”? Does it somehow magically depend on the caller?

So I kept digging.

let _currentInjector: Injector | undefined | null = undefined;

export function getCurrentInjector(): Injector | undefined | null {
  return _currentInjector;
}

Wait… what?
A global variable?
No call‑stack inspection. No sneaky runtime trick. Just a single global pointer sitting quietly in memory.

Which means one thing: before anyone can call inject, someone must set this variable. And sure enough, I found the function responsible:

export function setCurrentInjector(
  injector: Injector | null | undefined,
): Injector | undefined | null {
  const former = _currentInjector;
  _currentInjector = injector;
  return former;
}

This function is what makes everything possible. It swaps in a new injector, hands back the previous one, and lets its caller restore everything later.

Finally, the last piece:

export function runInInjectionContext<ReturnT>(injector: Injector, fn: () => ReturnT): ReturnT {
  // ...
  const prevInjector = setCurrentInjector(injector);
  // ...
  try {
    return fn();
  } finally {
    setCurrentInjector(prevInjector);
  }
}

This function temporarily switches the global injector, runs your callback, and then puts everything back exactly where it was.

So what Angular actually builds is a shadow stack: a parallel injector stack that lives alongside the real JavaScript call stack. Whenever inject runs, it simply looks at that global pointer and assumes, "Yep, that’s the injector of whoever called me."

It works. It’s clever. And yes… it’s a little bit dirty.

Conclusion

Now that I understood the implementation, the limitations suddenly felt less like a design choice and more like a direct consequence of the implementation itself.

inject isn’t a magic spell you can cast whenever you feel like it. It’s more like walking through a door that only exists for a brief moment, and only if someone else remembered to open it for you.

Angular opens that door automatically during component creation. It opens it again when the router runs resolvers, when guards execute, and in a few other well‑controlled moments. But outside those moments? The door simply isn’t there. Call inject from an event handler, or from a random callback, and Angular just stares back at you: “Sorry… no injector.”

Angular calls that fleeting moment an Injection Context . This term refers to “the tiny slice of time where the global _currentInjector is pointing at the right place”.

And if you want to run a function that uses inject deep inside its logic, you have to create that moment yourself. In simple terms: you need to inject the right `Injector`, hold onto it, and then create a temporary "injection context" while the code runs.

Something like this:

export class MyComponent {
  readonly myInjector = inject(Injector);

  onClick() {
       runInInjectionContenxt(this.myInjector, () => {
         // do something that relies on the `inject` function
       })
  }
}

The Bigger Picture

It may feel like a dirty trick: a global variable, a shadow stack, a door that opens for only a split second. But this tiny mechanism became the cornerstone of the entire Angular renaissance. Modern Angular leans heavily on inject and the injection context, and signals rely on it completely. Without this trick, none of the new reactive primitives would work the way they do.

So yes, it’s a hack. But it’s also the quiet engine driving the most important shift Angular has made in years — and the reason signals now sit at the center of the modern Angular platform.

Sometimes you inject a signal from a service, and it’s read-only, but you still want the user to edit it inside your component.

@Component({
  selector: 'user-editor',
  template: `
    <input [(ngModel)]="?">
  `
})
export class UserEditor {
    readonly user = inject(UserService).userSignal; // Signal<User>
    readonly username = computed(() => this.user().name); // Signal<string>

}

How do you make that happen without breaking immutability?

That’s where linkedSignal() comes in.

Linked Signal to the rescue

Linked Signal creates a local writable signal that stays in sync with the original one, so you can use it for two-way binding with the familiar banana-in-a-box syntax [(model)].

@Component({
  selector: 'user-editor',
  template: `
    <input [(ngModel)]="editableUsername">
  `
})
export class UserEditor {
    readonly user = inject(UserService).userSignal; // Signal<User>
    readonly username = computed(() => this.user().name); // Signal<string>
    readonly editableUsername = linkedSignal(() => this.username());
}

- Keeps your parent state immutable
- Allows local edits in the child
- Feels natural for Angular developers

That’s the beauty of linkedSignal. It bridges Angular’s modern signal world with the old-school simplicity of banana-in-a-box syntax.

Value Source

Now the linked signal may hold a value that’s either coming from the service or modified locally by the user.
But how do you tell which one it is?

You can use a computed signal to compare the original value with the current value of the linked signal:

readonly valueSource = computed(() => 
 this.username() === this.editableUsername()
 ? 'remote'
 : 'local');

The valueSource signal now tells you whether the current value is local (changed by the user) or remote (still matches the service).

If you found this useful, follow me for more posts about Angular Signals, NgRx Signal Store, and building scalable Angular apps.