Thanks to Pham Huu Hien and the excellent solutions provided in the Angular Challenges series, we have a clear look at how to leverage the Signal Graph within Angular DevTools. Angular offers an incredible suite of tools for developers, and today I’ll showcase the Signal Graph by walking through the resolution of Challenge #50.

The Scenario: A Bug in the MacBook Configurator

In Challenge #50, the goal is to debug a strange behavior in an effect.

The application is a simple checkout page for a MacBook. Users can upgrade their machine with extras like more drive space, RAM, or a better GPU. The requirement is simple: display an alert whenever at least one checkbox is checked.

The Bug

The current implementation doesn’t work as expected. While it seems to work initially, your team discovered a flaw:

• If you check the first checkbox (“Drive”), the alert appears.
• However, while “Drive” is checked, checking or unchecking the other two boxes (“RAM” or “GPU”) does not trigger the alert.

Why is the effect ignoring the other signals?

The Initial Implementation

Here is the code causing the issue:

effect(() => {
  if (this.drive() || this.ram() || this.gpu()) {
    alert('Price increased!');
  }
});

We have three signals. When this.drive() is true, the effect seems to "lose track" of the other two.

Visualizing the Issue with Angular DevTools

To debug this, we can use the Angular DevTools extension, which includes a powerful Signal Graph representation.

Note: If you haven’t installed Angular DevTools yet, you can download the Chrome extension here.

Once installed, launch the application:

npx nx serve signal-bug-in-effect

Open your browser’s Developer Tools (F12), select the Angular tab, and navigate to the Signal Graph section.

Analyzing the Graph

Initially, when no checkboxes are checked, you will see that the effect is linked to all three signals: drive, ram, and gpu. (red arrows below)

Now, click the first checkbox (Drive). The graph updates, and you’ll notice something strange: the effect is now only listening to drive. The connection lines to ram and gpu have disappeared!

Why is this happening? (Dynamic Dependency Tracking)

This happens because of how Angular Signals track dependencies. Angular effects are dynamic. They only register a dependency for signals that are actually read during the execution of the effect.

Look at the condition again: if (this.drive() || this.ram() || this.gpu())

Because of JavaScript short-circuiting, if this.drive() returns true, the browser never evaluates the rest of the expression. Since this.ram() and this.gpu() are never called, the effect "unsubscribes" from them to save resources. Angular assumes that since you didn't read them, you don't care about their changes.

The Solution: Explicit Dependency Registration

To fix this, we need to ensure the effect reads all three signals regardless of their values. The best practice is to “register” your signals at the top of the effect before any conditional logic.

effect(() => {
  // Read all signals upfront to register them as dependencies
  const drive = this.drive();
  const ram = this.ram();
  const gpu = this.gpu();

  if (drive || ram || gpu) {
    alert('Price increased!');
  }
});

A good rule of thumb: Always explicitly define your signal dependencies at the top of an effect. This makes the code easier to read, easier to debug, and ensures your logic stays reactive to every change you intend to track.

Now, if you check the Signal Graph again, you will see the effect remains linked to all three signals, regardless of their boolean state.

I hope this helps you understand the “magic” behind signal tracking.

✨ “Hungry for more? Dive into more hands-on practice with the Angular Challenges suite here. Happy coding! ✨

Debugging Angular Signals: A Guide to the Signal Graph DevTool was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever done this?

git stash -m "current task"
git checkout hotfix-branch
# fix bug
git checkout main
git stash pop

It works.

But it’s fragile.

• Your IDE undo history is gone
• Your dev server restarts
• Build artifacts disappear
• Multiple stashes become unmanageable
• You mentally context-switch twice

This is not a productivity workflow.

The Real Problem

Git assumes you only work in one working directory at a time.

Modern development doesn’t.

You:

• Handle hotfixes
• Review PRs
• Work on features
• Run AI tools generating code
• Experiment in parallel

Trying to serialize all that into one directory creates friction.

The Hidden Gem: Git Worktree

Git allows multiple working directories connected to the same repository.

Instead of switching branches, you add a new directory:

git worktree add ../my-project-hotfix hotfix-branch

Now you have:

• Your feature branch open
• A hotfix branch in another folder
• Independent IDE windows
• Independent dev servers
• Zero interference

No stash. No resets. No friction.

Useful Commands

git worktree list
git worktree remove <path>
git worktree prune

The Pro Setup: Bare Repository

If you want a clean setup:

git clone --bare https://github.com/user/my-repo.git my-repo
cd my-repo
git worktree add main
git worktree add feature-xyz

Structure:

my-repo/
├── HEAD (bare repo)
├── main/
└── feature-xyz/

Think of the bare repo as the Git brain, and each worktree as an independent body.

Each worktree:

• Has its own node_modules
• Has its own build output
• Has its own process lifecycle

This eliminates parent/child directory confusion.

The 10x Workflow: Multi-LLM Parallelism

Here’s where it becomes powerful.

Each worktree is fully independent.

You can:

• Worktree A → Manually fix a bug
• Worktree B → Let Claude generate documentation
• Worktree C → Let Copilot generate tests
• Worktree D → Refactor with Gemini

Instead of waiting for AI to finish, you work in parallel.

You eliminate idle time.

You transform development from sequential to concurrent.

That’s where the real productivity gain comes from.

Cleaning Up

Proper way:

git worktree remove ../my-project-hotfix

Quick way (if deleted manually):

git worktree prune

Modern IDEs like VS Code now support worktrees natively in the Source Control panel.

Conclusion

Git Worktree are not a trick.

They are a structural productivity upgrade.

With modern AI workflows, running everything in one directory is an artificial limitation.

Parallel work is the future.

And Git already supports it. 💪

Enjoy building faster…

Have you ever written something like this?

@Component({
  template: `<button (click)="closeDialog($event)">Close</button>`
})
export class Dialog {
  public closeDialog(event: Event) {
    event.stopPropagation();
    // ... do some action
  }
}

It works… but you can do better. Let’s uncover a hidden gem in Angular.

The secret EventManagerPlugin API

Here’s the definition from Angular’s documentation:

abstract class EventManagerPlugin {
  constructor(_doc: any): EventManagerPlugin;
  manager: EventManager;
  abstract supports(eventName: string): boolean;
  abstract addEventListener(
    element: HTMLElement,
    eventName: string,
    handler: Function,
    options?: ListenerOptions
  ): Function;
}

Every time you write something like (click)="...", Angular uses its EventManager to find a matching plugin that “supports” that event.

That means: you can create your own.

That’s all for today, enjoy this discovery 😁.

…

Don’t worry, I will not let you do it alone. Let’s refactor our example to see how it works in practice.

Building a .stop Event Plugin

Let’s create a plugin that automatically stops event propagation whenever we add .stop to an event name.

import { EventManagerPlugin } from '@angular/platform-browser';

export class StopEventPlugin extends EventManagerPlugin {
  protected readonly modifier = '.stop';

  supports(event: string): boolean {
    return event.includes(this.modifier);
  }

  addEventListener(element: HTMLElement, event: string, handler: Function): Function {
    return this.manager.addEventListener(element, this.unwrap(event), (e: Event): void => {
      e.stopPropagation();
      handler(e);
    });
  }

  private unwrap(event: string): string {
    return event
      .split('.')
      .filter((v) => !this.modifier.includes(v))
      .join('.');
  }
}

With this implementation, we tell Angular that whenever it encounters (click.stop), it should execute the logic inside addEventListener — calling e.stopPropagation() before running the provided handler.

However, this code alone won’t work out of the box. We need to provide it to our Angular app.

Providing it in your app

To activate the plugin globally, provide it at the root of your app:

import { EVENT_MANAGER_PLUGINS, makeEnvironmentProviders, EnvironmentProviders } from '@angular/core';
import { StopEventPlugin } from './stop-event.plugin';

export function provideEventPlugins(): EnvironmentProviders {
  return makeEnvironmentProviders([
    {
      provide: EVENT_MANAGER_PLUGINS,
      multi: true,
      useClass: StopEventPlugin,
    },
  ]);
}

Then, call it inside your main.ts:

bootstrapApplication(AppComponent, {
  providers: [provideEventPlugins()],
});

Done ✅

Now we can rewrite the introduction example as follow:

@Component({
  template: `<button (click.stop)="closeDialog()">Close</button>`
})
export class Dialog {
  public closeDialog() {
    // ... do some action
  }
}

Isn’t that nice and beautiful?

WebStorm tip 🧠

If you’re using WebStorm, .stop won’t be recognized by the TypeScript compiler.
You can fix that by adding a web-types.json file at the root of your project:

{
  "$schema": "https://raw.githubusercontent.com/JetBrains/web-types/master/v2-preview/web-types.json",
  "name": "my-custom-events",
  "framework": "angular",
  "version": "1.0.0",
  "contributions": {
    "js": {
      "ng-custom-events": [
        {
          "name": "Custom modifiers for declarative events handling",
          "pattern": {
            "template": [
              { "items": { "path": "/js/events" } },
              {
                "items": "ng-event-plugins-modifiers",
                "template": [".", "#...", "#item:modifiers"],
                "repeat": true
              }
            ]
          },
          "ng-event-plugins-modifiers": [{ "name": "stop" }]
        }
      ]
    }
  }
}

Now WebStorm will autocomplete (click.stop) like a native event modifier.

Bonus ideas 💡

Once you understand the pattern, you can build more modifiers such as:

• .prevent → calls event.preventDefault()
• .outside → runs the handler outside of zone.js
• or any other plugin that fits your needs.

The power is in your hands.

✨ That’s it — now you know one of Angular’s most powerful and least-known extension points.

If you enjoyed this, check out my other deep dives into Angular internals
Everything about ng-content or How Angular Dependency Injection works under the hood.

If you’ve ever built a reusable Angular component and wished you could just drop content inside instead of passing endless inputs(), then you want to master <ng-content>.

Let’s talk about content projection — how it works, how to use multiple slots, what’s pretty new with default fallbacks, and that mysterious ngProjectAs.

What is <ng-content>

Content projection lets a component open a hole in its template — a place where the parent component can inject content.

@Component({
  selector: 'app-card',
  template: `
    <div class="card">
      <ng-content/>
    </div>
  `
})
export class CardComponent {}

Then use it like this:

<app-card>
  <h2>Angular Content Projection</h2>
  <p>Reusable components made easy.</p>
  <my-child-comp/>
</app-card>

Everything between <app-card> and </app-card> gets projected inside <ng-content>.

That’s it. You just made a content container.
Think of it as the Angular way of saying: “whatever’s inside me, put it right here.”

Multiple <ng-content> slots

Sometimes one slot isn’t enough.
You want a header, a footer, and a body.
Angular’s solution: use multiple <ng-content> elements with a select attribute.

@Component({
  selector: 'my-comp-dialog',
  template: `
    <div class="dialog">
      <div class="dialog-header">
        <ng-content select="[header]"/>
      </div>
      <div class="dialog-body">
        <ng-content/>
      </div>
      <div class="dialog-footer">
        <ng-content select="[footer]"/>
      </div>
    </div>
  `
})
export class Dialog {}

Usage:

<my-comp-dialog>
  <div header><h3>John Doe</h3></div>
  <p>Frontend Engineer at Angular Corp.</p>
  <div footer><button>Edit</button></div>
</my-comp-dialog>

Each <ng-content> acts like a target — Angular matches elements from the parent template using CSS selectors.

• [header] → goes to the header slot
• [footer] → goes to the footer slot
• Everything else → goes to the default slot

Notes: You can create a ng-content with multiple select and be very creative

<ng-content select="[header], ng-template[MyDirective], .my-css-class"/>
<ng-content select="button[myCompanyButton]:not([addToDefaultFooter])"/>

Default fallback content (Angular v18+)

What if no one provides content for a slot?

In Angular 18+, <ng-content> can include default content directly inside.
If nothing is projected, Angular renders the fallback.

@Component({
  selector: 'my-comp-dialog',
  template: `
    <div class="dialog-header">
      <ng-content select="[header]">Default Title</ng-content>
    </div>
    <div class="dialog-body">
      <ng-content>Default body content</ng-content>
    </div>
    <div class="dialog-footer">
      <ng-content select="[footer]">
        <button>Upgrade</button>
      </ng-content>
    </div>
  `
})
export class Dialog {}

Usage:

<my-comp-dialog>
  <div header><h2>Custom Header</h2></div>
</my-comp-dialog>

Output:

• Header → custom
• Body → “Default body content”
• Footer → <button>Upgrade</button>

Fallbacks make your components safer by default — they “just work” even when users forget to project content.

Extra: ngProjectAs

Case 1

You may run into this: your child component expects a specific selector, but your parent uses something else.

@Component({
  selector: 'my-comp-dialog',
  template: `
    <ng-content select="card-title"/>
    <ng-content/>
  `
})
export class Dialog {}

To match select="card-title", you’d normally have to write:

<my-comp-dialog>
  <card-title>Angular FTW</card-title>
</my-comp-dialog>

…but that’s not ideal. You probably want to use a semantic <h2> instead.

Here’s where ngProjectAs comes in:

<my-comp-dialog>
  <h2 ngProjectAs="card-title">Angular FTW</h2>
  <p>Now it works 🎉</p>
</my-comp-dialog>

It doesn’t change the DOM — just the projection logic.
You keep semantic HTML and satisfy your slot selectors.

Case 2

You have a two-level projection

@Component({
  selector: 'my-parent-dialog',
  template: `
    <h1>Parent Dialog</h1>
    <my-child-dialog>
      <ng-content select="[body]" ngProjectAs="[dialog-body]"/>
    </my-child-dialog>
  `
})
export class ParentDialog {}

@Component({
  selector: 'my-child-dialog',
  template: `
    <h2>Child Dialog</h2>
    <ng-content select="[dialog-body]"/>
  `
})
export class ChildDialog {}

Usage:

<my-parent-dialog>
  <div body>body of dialog</div>
</my-parent-dialog>

You will get the following result:

You now have all the tools to create beautiful and customizable components. No more excuses.

If you are using Nx, you might have already encountered this issue. This Eslint rule comes from the package @nx/enforce-module-boundaries developed by the Nx team.

If you don’t know or you are not using Nx, this article can still be valuable and you might learn something from it.

Context

Nx is a workspace organizer. You will create folders called libraries to organize your code, and you will expose components and functions to be used outside of the library. This error happens when you try to lazy import an element and at the same time you eager import another element from the same library.

In this article, we will see what this error really means and the side effect that this error is preventing. Lastly we will see how to resolve it.

Setup

First let’s create a small example to better illustrate the issue.

We create a dashboard application with the following architecture:

In the apps folder, we have our application entry point. AppComponent is the root component.

In the libs folder, we have one library called users containing two components:

• UsersDashboardComponent is a table listing all users. (It uses Angular Material MatTable.)
• UserComponent is a component displaying an icon and the user’s fullname. (It uses MatIcon)
• index.ts is our library entry point where both component are exposed.

// index.ts
export { UserComponent } from './lib/user.component';
export { default } from './lib/users-dashboard.component';

AppComponent is eager referencing UserComponent and it’s lazy-loading UsersDashboardComponent as shown below:

import {
  UserComponent,
  type User,
} from '@angular-challenges/static-dynamic-import/users';
// ^Where the ESlint error is shown!!!


@Component({
  imports: [UserComponent, RouterOutlet],
  template: `
    Author:
    <sdi-user [user]="author" />
    <router-outlet />
  `,
   ...
})
export class AppComponent {
  author: User = {...};
}

Where the router is defined as follow:

provideRouter([
  {
    path: '',
    loadComponent: () =>
      import('@angular-challenges/static-dynamic-import/users'),
  },
]),

We can now clearly see that users library is loaded statically and dynamically.

However at serve/build time, Typescript is not showing errors and the application is running correctly. So, why do we need to create an ESlint error to guard us from this issue and what is the side effect of importing a library statically and dynamically at the same time ?

Side-Effect

To better understand the issue, we will inspect the bundle of the application’s build. The tool source-map-explorer will be of great help.

Let’s build our application using the production configuration and setting sourceMap to true.

After the build has completed, we can see this summary printed in the console:

Let’s explore what is inside the main bundle by opening the chunk inside source-map-explorer by re-running the following command:

npx source-map-explorer [PATH_DIST_FOLDER]/*.js

This command will give you the following visualization:

By opening the source-map of the main chunk, we can see that MatTable and MatIcon are bundled in the same chunk, although MatTable is only used inside UserDashboardComponent which is lazy-loaded. We would have expected that this component would be bundled inside the lazy-loaded one.

This small example clearly shows that the compiler is bundling the entire library inside the main bundle despite using only a small portion of it.

Solution

The solution is straight forward. We only have to create a new library and move our UserComponent. We will now have two libraries. One which will be lazy loaded, and a shared one which can be eager loaded anywhere in our code.

Let’s rebuild our refactored application.

and rerun source-map-explorer

The compiler divided our component successfully. MatTable is now located inside the lazy-loaded component and it will not increase the main bundle unnecessarily.

If you want to play with this example and try it on your own, I created a challenge inside AngularChallenges.

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

Static imports of lazy-loaded libraries are forbidden. was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dependency Injection (DI) is one of the most beloved and powerful features of Angular, and it happens to be my personal favorite as well. Understanding and mastering it can elevate your Angular skills and grant you superpowers.

In this article, I will explain what Dependency Injection is and delve into how it operates within Angular to provide a profound understanding.

What is a Dependency Injection

Let’s start by examining an example that doesn’t use Dependency Injection:

@Component({
   //...
})
export class AppComponent {
  service = new RootService();
}

In this example, we directly instantiate the RootService using the new keyword, resulting in a hardcoded dependency and a tight coupling between AppComponent and RootService. While this approach does work, it lacks flexibility, testability, and scalability in the long run, making it less maintainable.

Now, let’s consider the same example using Dependency Injection, where you’ll recognise a well-known Angular code snippet:

@Component({
   //...
})
export class AppComponent {
  service = inject(RootService);
// constructor(private service: RootService) {}
}

Notes: you can use either the constructor or the inject function, as both methods have the same underlying implementation.

As we can see, AppComponent is no longer directly responsible for instantiating RootService. Instead, it delegates this task to an external source, which is responsible for either returning an existing instance or creating a new instance of the requested service.

We can simplify the code for this external source, which might look like this:

export const inject = (searchClass: Class) => {
  const dependance = find(searchClass)
  if(dependance) {
    return dependance;
  } else {
    return new searchClass();
  }
}

In this example, AppComponent doesn’t need to have knowledge about RootService. This reduces the coupling between classes and their dependencies, making the code more maintainable, testable, and reusable.

In Angular, this external source is referred to as an Injector. And its implementation can be compared to a dictionary of records. The structure of a record looks like this:

record:{
 //...
 [index]:{
   key: class RootService,
   value: {
    factory: ƒ RootService_Factory(t),
    value: {}
   }
 //...
}

The Injector stores information about all injectable classes, which includes anything with a decorator such as @Injectable, @Component, @Pipe, and @Directive.

Returning to the previous example, when AppComponent requests RootService, the Injector iterates over its records to locate the requested token. Once found, the Injector returns the value if it's not undefined, indicating that the service has already been instantiated. Otherwise, the Injector creates a new instance using the factory function.

As you can observe, the record is simply an object, and the value can be easily overridden. For example, if we write the following code:

@Component({
   //...
   providers: [{ provide: RootService, useClass: OtherService }]
})
export class AppComponent {
  service = inject(RootService);
}

The Injector will override the value property within the RootService record:

record:{
 //...
 [index]:{
   key: class RootService,
   value: {
    factory: ƒ OtherService_Factory(t),
    value: {}
   }
 //...
}

This means that when AppComponent requests RootService, the Injector will provide a new instance of OtherService.

Note: This example simplifies how Angular’s Dependency Injection works, but it illustrates the underlying DI principle.

The next section delves into more advanced aspects, revealing the inner workings of Angular’s DI system.

Angular Dependency Injection

Angular has two categories of Injectors:

1. EnvironmentInjector: This category includes all global injectable classes provided through the router, modules, or using the providedIn: 'root' keyword.
2. NodeInjector: This category contains all local injectable classes found in each component or template.

It’s important to note that each small piece of a view containing injectable classes (referred to as LView) has its own NodeInjector, and within this NodeInjector, we can locate all services provided within the component provider array or any directives used within that LView.

LView !== Component

Creation of EnvironmentInjector Tree

When we bootstrap the application, the bootstrapApplication function is called in our main.ts file. This function takes two parameters:

• The root Component
• A list of providers

bootstrapApplication(AppComponent, {
  providers: [GlobalService],
})

Under the hood, this function will create three EnvironmentInjectors chained together:

• NullInjector: This is the end of the road. Its sole purpose is to throw an error: “NullInjectorError: No provider for …!!!”
• PlatformInjector: It contains a list of tokens that inform Angular about the platform the application is running on, such as browser, server, web worker, etc.

Example: this is where the InjectionToken DOCUMENT is created. For instance, if you are on a browser, this token will return window.document, whereas on a server, Angular will build and provide a DOM using Domino. It's crucial to always work with the DOCUMENT token by injecting it instead of using window.document. This ensures compatibility if you ever need to render your application from a server.

import { DOCUMENT } from '@angular/common';

@Component()
export class FooComponent {
  document = inject(DOCUMENT) // ✅
  document = window.document // ❌
}

• RootInjector: This is the most well-known of the three. It’s where all our global services (injectables set as root) are stored.

Notes: If we refer back to the earlier example, the GlobalService instance will be located within this injector.

All three of these injectors are chained together.

Creation of NodeInjector Tree

In this section, we will explore examples that you likely encounter in your daily projects. The first part aims to provide a better understanding of how the NodeInjector tree is created. (The NodeInjectorTree is similar to the ComponentTree but not strictly identical.)

We will then see how Angular determines which dependencies to retrieve or create.

Note: In this article, we will not discuss modules since most applications are expected to transition to standalone. Furthermore, all new Angular applications will be set to standalone by default starting from v17.

Tree Creation

Let’s examine what a NodeInjectorTree looks like. We’ll begin with a very simple example: a Parent with one Child.

@Component({
  template: `<child />`,
  imports: [ChildComponent],
})
export class ParentComponent {}

@Component({})
export class ChildComponent {}

This results in the following tree:

Since ParentComponent and ChildComponent are annotated with @Component, it means they are injectable. Thus, each component is stored within its own NodeInjector as follows. It's important to note that ChildComponent can inject ParentComponent, but it cannot inject itself, as this would create a circular dependency.

Now, let’s add another child to the parent:

@Component({
  template: `
    <child />
    <child />
   `,
  imports: [ChildComponent],
})
export class ParentComponent {}

@Component({})
export class ChildComponent {}

The structure of both trees remains similar.

However, let’s see what happens when we encapsulate one child into a div with a directive on it.

@Directive({
  selector: '[foo]',
  standalone: true,
})
export class FooDirective {}

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [ChildComponent, FooDirective],
  template: `
    <div foo>
      <child />
    </div>
    <child />
  `,
})
export class ParentComponent {}

Now the InjectorTree begins to diverge from the ComponentTree. A new Injector has appeared. Since FooDirective is a type of @Directive, it means it's injectable, and the first ChildComponent can inject it.

From this example, we can see that a NodeInjector is not associated with a Component but with an LView (Logical View).

With these three examples, you have all you need to understand how the InjectorTree is built.

(Note: Routing and ActivatedRoute will be explained in a follow-up article.)

Now, let’s explore different ways of providing an injectable service and how Angular locates the instance you are injecting.

Component provider

Within the component decorator, you have a property called providers that allows you to provide an Injectable class, as illustrated below:

@Component({
  template: `...`,
  providers: [MyComponentService],
})
export class MyComponent {}

The service provided inside the decorator will be stored within the records of the NodeInjector of MyComponent. Please note that providing your service does not instantiate it. A service is instantiated only when it is injected.

Let’s now examine which instance is returned with two concrete examples:

Example 1:

@Component({
  template: `
    <child />
    <child />
   `,
  imports: [ChildComponent],
})
export class ParentComponent {}

@Component({
  providers: [MyService]
})
export class ChildComponent {
  myService = inject(MyService);
}

This results in the following NodeInjectorTree:

As we can see, MyService is present inside both ChildInjectors. When Angular creates the first ChildComponent class, it will request MyService from the DI system. The DI system will start by searching inside the record of ChildInjector, which looks like this:

record:{
 //...
 [index]:{
   key: class MyService,
   value: {
    factory: ƒ MyService_Factory(t),
    value: undefined
   }
 //...
}

Angular will iterate over all dictionary entries of the Injector to check if the key MyService is present. Since MyService is present inside this NodeInjector, it will then check if it has already been instantiated, which is not the case since the value is undefined. In this case, a new instance of MyService will be created and returned.

If the key wasn’t present inside the record, the DI system will move to the next Injector until finding it or reaching the NullInjector, which will throw an error and terminate the application.

The same process will repeat for the second instance of ChildComponent. Angular will start searching inside its own NodeInjector, find the key inside the record, and since MyService has not been instantiated, a new instance will be created.

Example 2:

Now, let’s provide MyService inside ParentComponent instead of inside ChildComponent.

@Component({
  providers: [MyService]
  template: `
    <child />
    <child />
   `,
  imports: [ChildComponent],
})
export class ParentComponent {}

@Component({})
export class ChildComponent {
  myService = inject(MyService);
}

Now, MyService is located inside the record of ParentInjector.

This time, when Angular creates the first ChildComponent, it won't find the key of MyService inside the record of ChildInjector. Angular will then move up to the next Injector, which is ParentInjector. The record of ParentInjector looks like this:

record:{
 //...
 [index]:{
   key: class MyService,
   value: {
    factory: ƒ MyService_Factory(t),
    value: undefined
   }
 //...
}

Since MyService has not been instantiated yet, a new instance will be created and returned.

However, things are different when the second ChildComponent is created. Angular will traverse the NodeInjectorTree until reaching ParentInjector. But this time, the ParentInjector looks like this:

record:{
 //...
 [index]:{
   key: class MyService,
   value: {
    factory: ƒ MyService_Factory(t),
    value: MyService {
      prop1: 'xxx'
      // ...
    }
   }
 //...
}

The value of MyService is no longer undefined. The DI System will return this instance to the second ChildComponent. This means that both ChildComponents are sharing the same instance of MyService, unlike in the previous example.

Note: If ParentComponent was injecting MyService, the same instance would be shared among all three components.

ProvidedIn: ‘root’

The providedIn: 'root' is one of the most commonly used injectable designs within Angular applications, but not everyone fully understands the implications of these two words. This chapter aims to provide a clear explanation.

Let’s create a very basic application with a parent and a child:

@Component({
  template: `<child />`,
  imports: [ChildComponent],
})
export class ParentComponent {}

@Component({})
export class ChildComponent {
  service = inject(RootService);
}

@Injectable({ providedIn: 'root' })
export class RootService {}

When we examine the NodeInjectorTree, we find that RootService is not present in any of the records. This is because Angular does not include it in any Injector until a component actually injects it.

Note: In the context of lazy-loaded routes, RootService may get tree-shaken and bundled outside the main bundle. This topic is beyond the scope of this article, but you can read more about it below.

Mastering Injectable Services: A Comprehensive Guide

When Angular creates ChildComponent, it searches for RootService starting from the ChildInjector and moving up the tree, eventually reaching the EnvironmentInjectorTree and more precisely, the RootInjector.

Note: The exact implementation is more complex, but for the sake of simplicity, we’ll provide a high-level explanation here.

When the DI system reaches the RootInjector, it searches for the RootService key, similar to any other NodeInjector. However, it doesn't find it there either. Unlike NodeInjectors, before moving to the next EnvironmentInjector, it compares the scope of the Injector with the scope of the service being injected.

The code below is a portion of the get function of the RootInjector: (If you want to see the full function, you can go here)

let record: Record<T>|undefined|null = this.records.get(token);
if (record === undefined) {
  // No record, but maybe the token is scoped to this injector. Look for an injectable
  // def with a scope matching this injector.
  const def = couldBeInjectableType(token) && getInjectableDef(token);
  if (def && this.injectableDefInScope(def)) {
    // Found an injectable def and it's scoped to this injector. Pretend as if it was here
    // all along.
    record = makeRecord(injectableDefOrInjectorDefFactory(token), NOT_YET);
  } else {
    record = null;
  }
  this.records.set(token, record);
}

First, it attempts to retrieve the record of the searched token. If there is no record, it checks if the service has an InjectableDef (the providedIn property). If the service has one and if the scope matches the scope of the current EnvironmentInjector (root in our case), a new record is created and added to the Injector, then a new instance is returned.

The next time a component requests RootService, the record will be present, and the same instance will be returned.

Note: While less common, if you want to provide your service inside the PlatformInjector, you can set your Injectable to providedIn: 'platform'.

Warning: In practice, setting the providedIn: 'root' property for your Injectable service signifies that your service will be a singleton. However, if you provide your service within the providers property of one of your components, this service will be added to the record of the NodeInjector of that component. Let's see an example to better understand this:

@Component({})
export class ChildComponent {
  service = inject(RootService);
}

@Component({
  providers: [RootService]
})
export class FooComponent {
  service = inject(RootService);
}

@Component({
  template: `
    <child />
    <foo />
  `,
  imports: [ChildComponent, FooComponent],
})
export class ParentComponent {}

// injectable service
@Injectable({ providedIn: 'root' })
export class RootService {}

Here, we have a providedIn: 'root' RootService, which is injected inside both FooComponent and ChildComponent. However, we provide RootService inside the NodeInjector of FooComponent. This gives us the following graph:

ChildComponent will have an instance of the service located inside the RootInjector, whereas FooComponent will have the one from its own Injector. This can be misleading because by observing the service, one might assume that both components share the same global instance, which is not the case in this example.

In summary, providedIn: 'root' is only information for Angular to create a record inside RootInjector and only if the service reaches that point while searching for it inside the InjectorTree.

I really hope that the Dependency Injection System of Angular will no longer hold any secrets for you. You should now be able to harness its power to create exceptional applications and understand whether an instance of a service will be shared or unique.

You can expect me to write follow-up articles on the following subjects:

• Dependency Injection inside Routed Components
• Injection Flags: Host, Self, SkipSelf, and Optional
• All the options for overriding within the DI: useClass, useValue, useFactory, useExisting

If you would like to learn about anything else, please don’t hesitate to leave a comment.

If you want to improve your Angular skill, go check out Angular Challenges. It groups a set of challenges about Angular and its ecosystem.

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

How Angular Dependency Injection works under the hood was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

A pull request was recently merged and will be available in the upcoming major version v17. This pull request represents the first step towards fine-grained reactivity and signal-based components.

If you want to read more, click the pull request below:

perf(core): Update LView consumer to only mark component for check by atscott · Pull Request #52302 · angular/angular

The goal of this change is to refresh ONLY the component where the change occurred, but there are a couple of requirements:

• All your components need to use OnPush.
• The change has to be triggered by a Signal.

Let’s take a step back and explain why we need OnPush and Signals to benefit from local change detection.

How Change Detection Works

Angular employs Zone.js to detect changes and trigger a new render. Since Zone.js doesn’t track where a change occurred, Angular performs a top-to-bottom re-evaluate. This means that Angular refreshes the RootComponent down to all ChildComponents. This operation is fast but costly since Angular rerenders all components even if only a small change occurred.

Meanwhile, ChangeDetectionStrategy.OnPush was introduced to optimize the change detection cycle. When a component is marked for check, all its ancestors are also marked for check. Then Angular triggers a top-down cycle and only refreshes the marked components.

In v16, Angular introduced Signals, a new reactive API. This API allows Angular to precisely determine where a change is occurring. Angular can now identify which components need to be refreshed. A Signal marks the component as dirty but not its ancestors. When Angular performs its top-down change detection cycle, only that specific component will be refreshed.

Notes:

• Angular still needs to perform a top-down change detection to maintain backward compatibility with previous versions and with components not using Signals, relying on Zone.js instead.
• Currently, Angular cannot achieve more granularity than per-component because it might disrupt how non-signal components are refreshed. In the future, the goal is to be more granular, but it will never be as granular as the binding. Refer to the RFC for more details.

Conclusion:

Now you should understand why this change will benefit applications that leverage the use of Signals and OnPush.

1. Signals allow Angular to precisely pinpoint where the change occurred and mark only the affected component as dirty.
2. OnPush is necessary because Angular still requires a top-down change detection, and it only refreshes OnPush components when marked for check. All Default components will still be rerefreshed.

Thomas 🅰️🇨🇵 on Twitter: "A short video to better visualise how the new Local Change Detection can improve your application if you are using OnPush + Signals 🔥 pic.twitter.com/CLhCJRow7A / Twitter"

A short video to better visualise how the new Local Change Detection can improve your application if you are using OnPush + Signals 🔥 pic.twitter.com/CLhCJRow7A

Update your application to v17 and start using Signals, as this is just the beginning of how Signals can enhance your Angular application.

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

Thanks to Enea for reviewing it.

The other day, one of my coworkers detected a strange behavior inside our application. When he added RouterLinkActive to a link, the application stopped rendering. However when the directive was removed, the application worked correctly.

Instead of immediately reading the solution, I created a challenge inside AngularChallenges for those who want to try resolving and understanding the source of the bug first. After that, you can come back to this article to compare your solution with mine and understand what went wrong.

To better understand the problem, below is a small reproduction of the issue:

interface MenuItem {
  path: string;
  name: string;
}

@Component({
  selector: 'app-nav',
  standalone: true,
  imports: [RouterLink, NgFor, RouterLinkActive],
  template: `
    <ng-container *ngFor="let menu of menus">
      <a
        [routerLink]="menu.path"
        [routerLinkActive]="isSelected"
          >
        {{ menu.name }}
      </a>
    </ng-container>
  `,
})
export class NavigationComponent {
  @Input() menus!: MenuItem[];
}

@Component({
  standalone: true,
  imports: [NavigationComponent, NgIf, AsyncPipe],
  template: `
    <ng-container *ngIf="info$ | async as info">
      <ng-container *ngIf="info !== null; else noInfo">
        <app-nav [menus]="getMenu(info)" />
      </ng-container>
    </ng-container>

    <ng-template #noInfo>
      <app-nav [menus]="getMenu('')" />
    </ng-template>
  `,
})
export class MainNavigationComponent {
  private fakeBackend = inject(FakeServiceService);

  readonly info$ = this.fakeBackend.getInfoFromBackend();

  getMenu(prop: string) {
    return [
      { path: '/foo', name: `Foo ${prop}` },
      { path: '/bar', name: `Bar ${prop}` },
    ];
  }
}

MainNavigationComponent will display NavigationComponent and pass a list of MenuItem as an argument depending on the return of an HTTP request. When our HTTP request returns, we call the getMenu function with an empty string if there is no info, or with info if it’s not empty.

NavigationComponent will iterate over MenuItem and create a link for each item using RouterLink and RouterLinkActive for routing.

At first sight, this code seems correct, but applying RouterLinkActive to each link breaks the rendering with no errors in the console.

What could be happening? 🤯

To better understand the issue, let’s break down RouterLinkActive with the code that is causing the infinite rendering loop:

import { Directive } from '@angular/core';

@Directive({
  selector: '[fake]',
  standalone: true,
})
export class FakeRouterLinkActiveDirective {
  constructor(private readonly cdr: ChangeDetectorRef) {
    queueMicrotask(() => {
      this.cdr.markForCheck();
    });
  }
}

Inside RouterLinkActive, we call this.cdr.markForCheck() to mark our component as dirty. However, we make this function call within a different micro task. Once our current macro task ends, Angular will trigger a new change detection cycle within the following micro task.

Having this information, can you spot the issue now ?

Since Angular runs a new change detection cycle, the framework rechecks every binding, causing new function calls. This means that the getMenu function inside our MainNavigationComponent will be called again, and it returns a new instance of MenuItems.

But that’s not all.

NavigationComponent iterates over the array using the NgFor directive. As a new instance of MenuItem is passed as an Input to the component, NgFor recreates its list. NgFor destroys all DOM elements inside the list and recreates them. This causes the recreation of the RouterLinkActive instance, leading to another round of change detection, and this will be infinite.

We can avoid this by using the trackBy function inside the NgFor directive. This function tracks one property on the element, and checks if that property still exists within the new array. NgFor will only DESTROY or CREATE an element if the property no longer exists or did not exist previously. Adding the trackBy function in our case will correct the issue of infinite re-rendering.

If you are always forgetting the trackBy function, I invite you to read this article.

Make TrackBy Easy to Use!

However, even if the trackBy function resolves this error, creating a new instance of MenuItem at each change detection cycle is bad practice.

One way of avoiding this would be to create a menuItem class property, but this would create imperative code and lead to spaghetti code.

The best way is to take a more declarative approach. Let’s see how to refactor the code in a more declarative way:

@Component({
  standalone: true,
  imports: [NavigationComponent, AsyncPipe],
  template: ` <app-nav [menus]="(menus$ | async) ?? []" /> `,
})
export class MainNavigationComponent {
  private fakeBackend = inject(FakeServiceService);

  readonly menus$ = this.fakeBackend
    .getInfoFromBackend()
    .pipe(map((info) => this.getMenu(info ?? '')));

  getMenu(prop: string) {
    return [
      { path: '/foo', name: `Foo ${prop}` },
      { path: '/bar', name: `Bar ${prop}` },
    ];
  }
}

Our menus$ property is now defined in a single place, and will update when getInfoFromBackend returns. menu$ will not get recomputed at each change detection cycle and only a single instance will be created during the entire lifetime of MainNavigationComponent. The code looks simpler, doesn’t it ?

You have probably heard that calling functions inside templates is a bad practice, and in most cases, it is. While you can call a function to access nested properties of an object, that should be one of the only exceptions. Try to avoid calling functions inside your template bindings, or be sure to really understand what you are doing and all the side effects that can be created by this function call. When attempting to mutate data through a function call, it should trigger a warning inside your head. Most of the time, there is a better declarative approach to your problem. Declarative programming is a different state of mind, but you should aim for it. Persist, and your code will become clearer and simpler, and both your coworkers and your future self will thank you for that.

I hope this article sheds some light on the consequences of calling functions within template bindings.

Notes: In the future, Angular with “signal” will reduce that risk. With “signal” being memoized, it will save you from recreating new instances. 🔥

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

Function calls inside template are dangerous! was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Angular, you can create dynamic components using the NgComponentOutlet directive. However when your component has inputs, it was cumbersome to pass them through. In version 16.2.0-next.4, a new feature has been introduced, allowing you to bind your inputs much more easily.

In this article, we will explore how to achieve input binding in previous versions of Angular and the new approach introduced in version 16.2.0-next.4. Additionally, we will demonstrate another method to create dynamic components.

Before v16.2.0-next.4

Prior to version 16.2.0-next.4, you had to create an injector to set up your inputs and inject it into your dynamic component to access them.

Let’s look at an example to better understand this process.

First we need an InjectionToken for better type safety:

interface TitleInputs {
  title: string;
  subTitle: string;
}

const INPUTS = new InjectionToken<TitleInputs>('title inputs');

Now in our component we can create a custom injector to set up our inputs.

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [NgComponentOutlet],
  template: `
    <ng-template *ngComponentOutlet="template; injector: customInjector" />
  `,
})
export class AppComponent implements OnInit {
  template = OldTitleComponent;

  titleInputs = {
    title: 'Inputs for Component outlets',
    subTitle: `That's awesome`,
  };

  customInjector = Injector.create({
    providers: [{ provide: INPUTS, useValue: this.titleInputs }],
  });
}

Finally, in OldTitleComponent , we can inject our token to retrieve our inputs.

@Component({
  selector: 'app-title',
  standalone: true,
  template: `OldWay: {{ inputs.title }} {{ inputs.subTitle }}`,
})
export class OldTitleComponent {
  inputs = inject(INPUTS);
}

This solution doesn’t feel very natural but there was no other way available at that time.

After v16.2.0-next.4

Now, since input binding has been implemented, we can simply pass our inputs object to our directive and retrieve our inputs using the @Input decorator, as we would expect it to be.

Let’s see this in action.

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [NgComponentOutlet],
  template: `
    <ng-template *ngComponentOutlet="template; inputs: titleInputs" />
  `,
})
export class AppComponent implements OnInit {
  template = TitleComponent;

  titleInputs = {
    title: 'Inputs for Component outlets',
    subTitle: `That's awesome`,
  };
}

@Component({
  selector: 'app-title',
  standalone: true,
  template: `NewWay: {{ title }} {{ subTitle }}`,
})
export class TitleComponent{
  @Input() title!: string;
  @Input() subTitle?: string;
}

So much simpler, isn’t it?

Moreover, if any inputs change inside the titleInputs object, TitleComponent will be notified. 👍

Note: Inputs binding is not typed. Anything can be pass to inputs property.

Using CreateComponent

In Angular, there’s another API to dynamically create components. Instead of doing it inside the template, you can achieve it in the TypeScript part using the createComponent function.

@Component({
  selector: 'app-root',
  standalone: true,
  template: ``,
})
export class AppComponent implements OnInit {
  ref = inject(ViewContainerRef);
  envInjector = inject(EnvironmentInjector);

  ngOnInit(): void {
    const comp = this.ref.createComponent(TitleComponent, {
      environmentInjector: this.envInjector,
    });
    comp.setInput('title', 'Inputs with createComponent');
    comp.setInput('subTitle', 'Still works!');
  }
}

To bind inputs, you need to use the setInput function. While you could do comp.instance.title = `...` , if your input change, TitleComponent will not be notified.

Note: NgComponentOutlet is using createComponent and setInput under the hood. 😉

Enjoy creating dynamic component in an easier way !! 🚀

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

New input binding for NgComponentOutlet was originally published in ngconf on Medium, where people are continuing the conversation by highlighting and responding to this story.

share and ShareReplay are two RxJs operators that we always struggle to use correctly. We know that we can reach for them when we want to multicast a costly observable or cache a value that will be used at multiple places. But what are the key differences between both, and what is the refCount flag and how can we leverage its behavior?

In this article, I will try to explain them for you so that you will not need to ask this question again.

Example 1

I posted the following question on Twitter which unfortunately received zero responses. This really highlights the lack of understanding regarding share and shareReplay.

Thomas 🅰️🇨🇵 on Twitter: "#angularQuizz:Do you know #Rxjs share / shareReplay: refcount ? Below are 3 snapshots: 👉 share👉 shareReplay: refcount=true👉 shareReplay: refcount=falseCan you guess what will be displayed on the screen after 10s ? Good luck, that's not easy 🤯 pic.twitter.com/UMwTsIHHRI / Twitter"

angularQuizz:Do you know #Rxjs share / shareReplay: refcount ? Below are 3 snapshots: 👉 share👉 shareReplay: refcount=true👉 shareReplay: refcount=falseCan you guess what will be displayed on the screen after 10s ? Good luck, that's not easy 🤯 pic.twitter.com/UMwTsIHHRI

The exercice looks like this:

@Component({
  selector: 'app-count',
  standalone: true,
  imports: [NgIf, AsyncPipe],
  template: `
    <ng-container *ngIf="flag"> {{ count1$ | async }} </ng-container>
    <ng-container *ngIf="!flag"> {{ count2$ | async }} </ng-container>
  `,
})
export class CountComponent implements OnInit {
  flag = true;

  readonly count$ = interval(1000).pipe(
    take(7),
    shareReplay({ bufferSize: 1, refCount: false }) // 👈 line: 15
  );

  readonly count1$ = this.count$.pipe(
    take(3),
    map((c) => `count1: ${c}`)
  );
  readonly count2$ = this.count$.pipe(
    take(3),
    map((c) => `count2: ${c}`)
  );

  ngOnInit(): void {
    setTimeout(() => {
      this.flag = false;
    }, 5500);
  }
}

Note: This code snippet is written using Angular, but the behavior of both operator is the same outside the framework.

When the flag is true, we subscribe to count1$and after 3 emissions, the observable completes. Then after 5500ms, the flag is set to false and we subscribe to count2$ which also completes after 3 emissions. Both observables are chained with count$.

The goal is to predict the result displayed on the screen after 10s, depending on the operator used in line 15.

Share

Let’s start with the share operator.

The share operator will multicast each value emitted by the source observable, which means we won’t re-execute the source observable for each new subscription.

Moreover, when the count of subscribers drops to 0, the source observable will be unsubscribed.

Inside this operator, we use a Subject as a connector between the source observable and the subscribers. This means that every late subscriber will NOT have access to the previously emitted data.

You should use this operator if you know that you will not use previously emitted data and are only interested in upcoming ones.

Solution

If we go back to our example:

1. count$ will be triggered when count1$ subscribes to it.
2. After count$ emits 3 values, count1$ completes due to the take(3) operator. Consequently count$ will also complete since the number of subscribers drops to 0 and the inner Subject will reset.
3. After 5500ms count2$ starts. It will subscribe to count$ and count$ will start emitting from the beginning.
4. Since we have a take(3) on the observable, the final answer is 3.

ShareReplay with refCount: true

Both share and shareReplay operators behave almost the same: ShareReplay use share under the hood. The crucial difference lies in the connector: shareReplay uses a ReplaySubject instead of a Subject. This distinction becomes significant when dealing with late subscribers, as they will have access to previously emitted data.

Another difference is the ability to toggle the refCount flag. When refCount=true, it allows unsubscribing from the source observable when the subscriber count drops to 0. The share operator’s refCount flag is defaulted to true.

In this scenario with refCount set to true, the source observable will get unsubscribed when the subscriber count drops to 0.

Solution

If we go back to our exemple:

1. count$ will be triggered when count1$ subscribes to it.
2. After count$ emits 3 times, count1$ completes due to the take(3) operator. Consequently count$ will also complete since the number of subscribers drops to 0 and the refCount flag is set to true.
3. After 5500ms count2$ starts, it will subscribe to count$ again and count$ will start emitting from the beginning.
4. Since we have a take(3) on the observable, the final answer is 3. In this example, both share and shareReplay behave exactly the same. However, we will see more examples below to understand the differences between them.

ShareReplay with refCount: false

As explained above, setting the refCount flag to false will keep the source observable alive even if the subscriber count drops to 0.

This is dangerous because if the source observable never completes, this can create memory leaks.

However in some cases, you may not want to re-execute the source observable if a new subscriber subscribes, such as in the case of an HTTP request.

Solution

If we go back to our exemple:

1. count$ will be triggered when count1$ subscribes to it.
2. After count$ emits 3 times, count1$ completes due to the take(3) operator, BUT count$ will NOT complete and continue to emit a value every 1s.
3. After 5500ms count2$ starts, it will subscribe to count$ and receive the last emitted value which is 4.
4. Since we have a take(3) on the observable, the final answer is 6.

Note: Since all observables completes, we don’t have any memory leaks issues

Example 2

Let’s take another example to better understand the difference between share and shareReplay. This distinction becomes more evident when we apply the operators to an observable that never completes, such as a BehaviorSubject.

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [NgIf, AsyncPipe],
  template: `
    <ng-container *ngIf="!flagFinalize">
      <ng-container> {{ count1$ | async }} </ng-container>
      <ng-container *ngIf="flag"> {{ count2$ | async }} </ng-container>
    </ng-container>
    <button (click)="flagFinalize = !flagFinalize">FINALIZE</button>
    <button (click)="subject.next(subject.value + 1)">INCREMENT</button>
  `,
})
export class AppComponent implements OnInit {
  flag = false;
  flagFinalize = false;

  subject = new BehaviorSubject(0);

  readonly count$ = this.subject.pipe(
    tap({
      next: (t) => console.log('I get next value of count', t),
      complete: () => console.log('complete count'),
      finalize: () => console.log('finalize count'),
    }),
    share() // 👈
  );

  readonly count1$ = this.count$.pipe(
    tap({
      next: (t) => console.log('I get next value of count1', t),
      complete: () => console.log('complete count1'),
      finalize: () => console.log('finalize count1'),
    }),
    map((c) => `count1: ${c}`)
  );
  readonly count2$ = this.count$.pipe(
    tap({
      next: (t) => console.log('I get next value count2', t),
      complete: () => console.log('complete count2'),
      finalize: () => console.log('finalize count2'),
    }),
    map((c) => `count2: ${c}`)
  );

  ngOnInit(): void {
    setTimeout(() => {
      this.flag = true;
    }, 1000);
  }
}

This time we are using a BehaviorSubject and we have an INCREMENT button to emit a value to the Subject.

Additionally, we have added a tap operator to log the next, complete and finalize events.

The FINALIZE button allows us to unsubscribe from the count1$ and count2$ observables.

Scenario

When the app is loaded, count1$ subscribes to count$, and after 1s count2$ also subscribes to count1$.

Next, we click once on the INCREMENT button, and finally we click on the FINALIZE button.

Before reading the article further, I invite you to try to guess what the behavior of this scenario will be with each operator. Once you are done, compare your ideas with the solution.

Share

1. When count1$ subscribes to count$, the count$ observable will start emitting values and count1$ will receive the initial value 0.
2. In this scenario, count1$ doesn’t complete so the number of subscribers will not drop to 0, and count$ will not complete either.
3. After 1s, count2$ starts subscribing to count$, but since we are using the share operator, the inner observable is a Subject which will not replay the previous emitted value. Therefore count2$ will not receive any value.
4. We now click on the INCREMENT button, and both count1$ and count2$ will be notified with the value 1.
5. Finally we click on the FINALIZE button, and both count1$ and count2$ will get unsubscribed (due to the asyncPipe) and finalized. Since the share operator unsubscribes the source when all subscribers drop to 0, count$ will finalize as well.

ShareReplay with refCount: true

We replace the share operator with shareReplay({bufferSize: 1, refCount: true})

1. same behavior as previously
2. same thing
3. After 1s, count2$ starts subscribing to count$. However this time, count2$ gets the previous emitted value (0 in our case), because shareReplay uses a ReplaySubject as the connector. This is the significant difference between both operators

4 and 5 are identical since the refCount flag is set to true.

ShareReplay with refCount: false

1 to 4 is identical to the previous scenario, and all differences are seen in point 5 when we unsubscribe from the subscribers.

5. When we click on the FINALIZE button, count1$ and count2$ will be unsubscribed correctly due to the asyncPipe. However count$ will not finalize because shareReplay will not unsubscribe the inner source and count$ will continue to exist indefinitely, which might cause a memory leak.

Important note: If you have noticed, I said that this might cause a memory leak. If you lose the reference to your running observable, such as when destroying a component, a new count$ observable will be instantiated next time you initialize the particular component. This can lead to memory leaks.

In the above example, switching back the flag, count1$ and count2$ will resubscribe to the existing observable. shareReplay with refCount set to false is useful when you don’t want to re-execute a costly observable like an HTTP request. You can set your shared observable in a global service and inject it anywhere in your application. The instance will never be unsubscribed, but when new subscribers subscribe to the observable, they will use the existing instance.

Note: We often see the shorthand synthax replaySubject(1), which is the shorthand for replaySubject({bufferSize: 1, refCount: false}). So you need to be careful about using this synthax. You will more often reach for refCount set to true to avoid memory leak issues.

Example 3

In the last example, we will use a source observable that completes, similar to an HTTP request. To simplify the example, we will use the of operator.

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [NgIf, AsyncPipe],
  template: `
    <ng-container> {{ request1$ | async }} </ng-container>
    <ng-container *ngIf="flag"> {{ request2$ | async }} </ng-container>
  `,
})
export class AppComponent implements OnInit {
  flag = false;

  readonly http$ = of('trigger http request').pipe(
    tap({
      next: (t) => console.log('http response', t),
      complete: () => console.log('complete http'),
      finalize: () => console.log('finalize http'),
    }),
    share() // 👈
  );

  readonly request1$ = this.http$.pipe(
    tap({
      next: (t) => console.log('request1 response', t),
      complete: () => console.log('complete request1'),
      finalize: () => console.log('finalize request1'),
    }),
    map((c) => `request1: ${c}`)
  );
  readonly request2$ = this.http$.pipe(
    tap({
      next: (t) => console.log('request2 response', t),
      complete: () => console.log('complete request2'),
      finalize: () => console.log('finalize request2'),
    }),
    map((c) => `request2: ${c}`)
  );

  ngOnInit(): void {
    setTimeout(() => {
      this.flag = true;
    }, 1000);
  }
}

Scenario

When we load the component, we trigger a first HTTP request using the observable http$. After 1s, we want to get the result of the same request. To achieve this, we consider using either share or shareReplay operator to cache the result.

Same exercice as previously, I encourage you to think first before reading the solution below.

Share

1. request1$ subscribes to http$ which triggers an HTTP call. Once the response comes back, the HTTP call completes, causing http$ and request1$ to complete as well.
2. After 1s, request2$ subscribes to http$ hoping to get the result of the same HTTP call. However, since share uses a Subject under the hood, nothing is cached, and http$ is re-executed, resulting in a new HTTP call.

ShareReplay

In this scenario, the refCount doesn’t change the behavior since the source observable (http$) completes on its own, irrespective of the number of subscribers.

1. same as previously
2. After 1s, request2$ subscribes to http$ but this time, shareReplay uses a ReplaySubject as the connector, allowing it to store the last value emitted by http$. Therefore http$doesn’t need to be re-executed, and request2$ received the cached value without triggering a new HTTP call.

Note: Be careful when using shareReplay inside a global service behind a http call. Each new subscriber will receive the cached value and the HTTP request will NEVER fire again. As a result, your data will NEVER get refreshed.

Conclusion

In summary, shareReplay is useful in scenarios where you want to cache and replay the last emitted value of an observable, especially in situations like HTTP requests, to avoid unnecessary re-execution and improve performance. But be careful, this is useful inside a component scope, generally not within the global scope.

You need to think carefully about the refCount flag when using shareReplay on observables that don’t complete on their own.

share is useful when you want to multicast a long-living observable and you don’t need to access previously emitted data.

As you can see, understanding exactly how this two operators work under the hood can help you improve your application’s performance.

I hope you now have a better understanding of the differences between share and shareReplay and the importance of the refCount flag. With this knowledge, you should be able to use them correctly and truly understand what is happening behind the scenes.

You can find me on Medium, Twitter or Github. Don’t hesitate to reach out to me if you have any questions.

Share / ShareReplay / RefCount was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.