DEV Community: Enea Jahollari

[Boost]

Enea Jahollari — Mon, 03 Nov 2025 15:43:16 +0000

Brandon Roberts for Analog

Nov 3 '25

Announcing AnalogJS 2.0 ⚡️

#webdev #angular

Comments 5

4 min read

A sweet spot between signals and observables 🍬

Enea Jahollari — Fri, 18 Aug 2023 15:48:46 +0000

In collaboration with Chau Tran.

The migration wave to signals is real, state management libraries have started to add support to support both observables and signals.

This is my shot together with Chau to combine observables and signals into one.

Little history

Angular has had observables since the beginning and the devs are used to it and have used it in almost every part of their apps.

Angular's reactivity was tied to rxjs (except zone.js automagic change detection)!

Then, SIGNALS 🚦 came! They changed everything! The way we see the templates, change detection and reactivity in Angular in general!

Who would have thought Angular recommends calling functions in the template?!

@Component({
    template: `<div>Count: {{ count() }}</div>`
})
export class MyCmp {
    count = signal(0);
}

(I did LOL! Read more here: It’s ok to use function calls in Angular templates!)

Signals are great! But we are used to rxjs patterns in Angular, our services are tied to rxjs subjects, observables, operators and everything else!

Example scenario

I have a GalleryComponent that retrieves some data from the API and it depends on an id (retrieved from route params) and global form filters.

@Component({
    template: `
        <div *ngIf="data$ | async as data">
            {{ data | json }}
        </div>
    `
})
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);

    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));

    data$ = combineLatest([
        this.filterService.filters$,
        this.galleryId$
    ]).pipe(
        switchMap(([filters, id]) => 
            this.galleryService.getGalleryItems(id, filters)
        )
    );

    favoritesCount$ = this.data$.pipe(map(data => getFavoritesCount(data)));
}

I want to use signals in the template for better performance, and because they are the future?! BUT, I don't want to get rid of rxjs, I see them as complementary to each other!

Angular helper functions way

First thing I do is use toSignal to wrap my data$ observable.

data = toSignal(this.data$, { initialValue: [] });

Now I can use my data directly in the template as a signal without needing async pipe! Great!

Because favoritesCount$ depends only on data$ I can convert that one into a signal too. Computed is the perfect fit for this!

- favoritesCount$ = this.data$.pipe(map(data => getFavoritesCount(data)));
+ favoritesCount = computed(() => getFavoritesCount(this.data()));

Perfect!

I go and update my GlobalFilterService from BehaviorSubjects or RxAngular / ComponentStore to use signals!

And, now I cannot use my filters (that is now a signal) anymore in the combineLatest! Let's convert it back to observable in order to use it inside combineLatest again!

Let's use toObservable from Angular.

@Component()
export class GalleryComponent {
    ...
    private filterService = inject(GlobalFilterService);

+   filters$ = toObservable(this.filterService.filters);

    data$ = combineLatest([
-       this.filterService.filters$,
+       this.filters$,
        this.galleryId$
    ]).pipe(...);
}

Great until now! The thing is, I need to add an input to the component! This input will be used in the api call! So, I create it using a setter and a BehaviorSubject.

showStars$ = new BehaviorSubject(false);

@Input({ required: true }) set showStars(x: boolean) {
    this.showStars$.next(x);
}

We can easily use that one in the combineLatest because it's just an observable! But I also need to use that in the template, so I use the toSignal again to convert it!

showStars = toSignal(this.showStars$);

Great again! The thing is Angular RFC showed us that a new kind of input may be coming RFC;

So we may want to prepare when they come, to easy refactor to them, so what we may think is, let's make the setter set the value to a signal rather than a BehaviorSubject and from there convert it to an observable.

And we get something like:

showStars = signal(false);
showStars$ = toObservable(this.showStars);

@Input({ required: true }) set showStars(x: boolean) {
    this.showStars.set(x);
}

The result of everything would look like this:

@Component()
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);

    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));
    filters$ = toObservable(this.filterService.filters);

    showStars = signal(false);
    showStars$ = toObservable(this.showStars);
    @Input({ required: true }) set showStars(x: boolean) {
        this.showStars.set(x);
    }

    data$ = combineLatest([
        this.filters$,
        this.galleryId$,
        this.showStars$
    ]).pipe(
        switchMap(([filters, id, showStars]) => 
            this.galleryService.getGalleryItems(id, filters, showStars)
        )
    );

    data = toSignal(this.data$, { initialValue: [] });

    favoritesCount = computed(() => getFavoritesCount(this.data()));
}

All this back and forth and decision dilemma because we just need to put the value in the combineLatest and be ready for tomorrow's Angular.

What if we had a better alternative, something that also takes signals into consideration?

Chau's initial shot

Chau is one of the first devs who I talked to about the new Signals, and he was really hyped about it! He had been thinking about these patterns a lot! And showed me a solution he had created for combining signals with observables.

The usage (different example from the initial one) looks like this:

githubUsers = computed$(
    this.query,
    pipe(
      debounceTime(500),
      switchMap((query) => api.getUsers(query)),
      startWith([])
    )
);

// or with explicit initial value

readonly githubUsers = computed$(
    this.query,
    [], // initial value
    pipe(
      debounceTime(500),
      switchMap((query) => api.getUsers(query))
    )
);

computed$ is a primitive where the first argument can be a signal, an observable or a promise, and the second arg can be either an initialValue or a pipe operator where we can pass all our rxjs operators. The operators would fire everytime the signal or observable changed!

Find the whole implementation here:
https://gist.github.com/eneajaho/dd74aeecb877069129e269f912e6e472

What does computed$ solve? Let's re-assess what we have and what we want to achieve:

We want our githubUsers to be a Signal so we can use it on the template without AsyncPipe
We have a query which is a Signal that reacts to a search input. The query value is used to call Github API for users
We want to debounce the rate of which we call the Github API > Please don't go and create a debounceSignal(). Use RxJS for asynchronous operations.

@angular/core/rxjs-interop provides two other primitives: toSignal() and toObservable() to solve this for us

githubUsers = toSignal(
    toObservable(this.query).pipe(
        debounceTime(500),
        switchMap((query) => api.getUsers(query))
    ),
    { initialValue: [] }
);

This approach works fine but the back-and-forth between toSignal and toObservable can be messy quickly. This is where computed$ comes in. But it only works with a single source.

My shot

Because I had more than one source that were of different types (both signals and observables), I took Chau's computed and converted the initial argument to be an array of sources (that could be either signals or observables). As a first time fixing Typescript types, I think it went really well! Find the implementation here.

https://gist.github.com/eneajaho/53c0eca983c1800c4df9a5517bdb07a3

If I take the inital example I had before, and apply the updated computed$ (now called computedFrom) approach, it would look like this:

@Component()
export class GalleryComponent {
    private route = inject(ActivatedRoute);
    private galleryService = inject(GalleryService);
    private filterService = inject(GlobalFilterService);

    galleryId$ = this.route.paramMap.pipe(map(p => p.get('id')!));

    showStars = signal(false);

    @Input({ required: true }) set showStars(x: boolean) {
        this.showStars.set(x);
    }

    data = computedFrom(
        [this.filterService.filters, this.showStars, this.galleryId$],
        [], // initial value
        pipe(
            switchMap(([filters, showStars, id]) =>
                this.galleryService.getGalleryItems(id, filters, showStars)
            )
        )
    );


    favoritesCount = computed(() => getFavoritesCount(this.data()));
}

As we can see, there's no need to convert things back and forth to combine signals and observable together!

As I said before, this is fully typed. And there's one catch, if we don't pass an intial value our signal would be of type Signal<T | undefined> and if we pass an initial value it would be of type Signal<T>.

I think this is important (passing an initial value) in cases when we have to use this signal in the template or in other computations, because we first have to check if our signal has a value or not.

Example with favoritesCount:

favoritesCount = computed(() => {
    const data = this.data();
    if (data === undefined) return 0;
    return getFavoritesCount(data);
});

Chau's bazooka

I go back to Chau with my solution, he initially likes it! And goes to improve it! Comes back saying that a flaw of my solution is the initialValue.

So, if I don't provide an operator, the intial value of computedFrom will be of type any. But we don't want that, because we have values, and at least we should get back the values of our sources inside an array.

Let's take an example to better understand it:

// Signal with default value
const first = signal(1); 
// Observable that emits first value synchronously
const second$ = of(1); 
// Observable that emits first value asynchronously
const third$ = timer(5000); 

const combined = computedFrom(
    [first, second$, third$],
);

My implementation would return Signal<any> and it's value would be undefined! Bad right? Yes, of course.

We at least want to get something like this:

const combined = computedFrom(
    [first, second$, third$],
);

// typeof combined - Signal<[number, number, number]>

While this other example would return Signal<number> and the value would be 0.

const combined = computedFrom(
    [first, second$, third$],
    0, // initial value
);

But, Chau thinks that explicit initialValue is redundant because:

Signals already have initial values
Observables can emit values synchronously

He believes only Observables which emit values asynchronously should have their initial values explicitly defined. In the above example, only the third$ source needs an initial value.

const combined = computedFrom(
    [first, second$, third$.pipe(startWith(0))],
    pipe(map(([f, s, t]) => f + s + t))
);

// if we have only one operator we can write it directly like: 
const combined = computedFrom(
    [first, second$, third$.pipe(startWith(0))],
    map(([f, s, t]) => f + s + t)
);

Last but not least, Chau's version of computedFrom() does also accept a Dictionary just like combineLatest() does. Which is a big plus in some scenarios I'd say.

const combined = computedFrom(
    {
        first: first, 
        second: second$, 
        third: third$.pipe(startWith(0))
    },
    map(({first, second, third}) => first + second + third)
);

Find Chau's computedFrom implementation here: https://gist.github.com/eneajaho/33a30bcf217c28b89c95517c07b94266

To sum up

I also like Chau’s solution now! And have been using it in some places and it’s great!

You can use the computedFrom function by installing ngxtension 🪄.

*Go give it a try and let us know in the comments or tweet about it! 🙌 *

For other discussions regarding signals, observables and libs also take a look at RxAngular github repo.

Thanks for reading!

I tweet and blog a lot about Angular (latest news, signals, videos, podcasts, updates, RFCs, pull requests and so much more). 💎

If you want to learn more about Modern Angular features like standalone, signals, functional guards, interceptors, ssr, hydration, new inject method, Directive Composition API, NgOptimizedImage, feel free to take a look at our Modern Angular Workshop from Push-Based.io 💎

If this article was interesting and useful to you, and you want to learn more about Angular, give me a follow at @Enea_Jahollari or dev.to. 📖

I’d appreciate it if you would support me by buying me a coffee ☕️. Thank you in advance 🙌

Create configurable Angular guards

Enea Jahollari — Wed, 09 Aug 2023 23:03:27 +0000

When building web application, from time to time we have to protect routes from unauthorized access. In Angular, we can do this by using router guards.

This is not an intro to Angular guards, so if you are not familiar with them, you can read more about them in the official documentation.

In this article, we will see how we can create configurable Angular guards. We will create a guard that will check if the logged in user has a specific role, and if not, it will redirect the user to an unauthorized page.

We will use a fake AuthService that will have a method to check if the logged in user has a specific role.

// auth.service.ts
export const ROLES = {
  ADMIN: 'ADMIN',
  MANAGER: 'MANAGER',
};

@Injectable({ providedIn: 'root' })
export class AuthService {
  userRole = ROLES.ADMIN;

  hasRole(role: string): boolean {
    return this.userRole === role;
  }
}

Before Angular 14 we had class based guards, and a basic solution for our problem would be to create a class based guard for each role and apply it to the routes that we want to protect.

But, this solution is not very flexible, because we have to create a new guard for each role, and if we want to add a new role, we have to create a new guard and apply it to the routes that we want to protect.

This is not very convenient, and it can lead to code duplication.

It would look something like this:

// admin.guard.ts
@Injectable({ providedIn: 'root' })
export class AdminGuard implements CanActivate {
  authService = inject(AuthService);
  router = inject(Router);

  canActivate(): boolean | UrlTree {
    const hasAccess = this.authService.hasRole(ROLES.ADMIN);
    return hasAccess ? true : this.router.createUrlTree(['/unauthorized']);
  }
}

// manager.guard.ts
@Injectable({ providedIn: 'root' })
export class ManagerGuard implements CanActivate {
  authService = inject(AuthService);
  router = inject(Router);

  canActivate(): boolean | UrlTree {
    const hasAccess = this.authService.hasRole(ROLES.MANAGER);
    return hasAccess ? true : this.router.createUrlTree(['/unauthorized']);
  }
}

And then we would apply the guards to the routes that we want to protect:

// routes.ts
export const routes: Routes = [
  { path: 'home', component: HomeComponent },
  { path: 'admin', component: AdminComponent, canActivate: [AdminGuard] },
  { path: 'manager', component: ManagerComponent, canActivate: [ManagerGuard] },
  { path: 'unauthorized', component: NotAuthorizedComponent },
];

As we can see, we have a lot of duplicated code! Let's improve this by creating a configurable guard.

Configurable class-based guard

Angular Router provides a data field in the route that we can use to pass data to the guard. We can use this data field to pass the role that we want to check. This way, we can create a single guard that will check the role that we pass in the data field.

// role.guard.ts
@Injectable({ providedIn: 'root' })
export class RoleGuard implements CanActivate {
  authService = inject(AuthService);
  router = inject(Router);

  canActivate(route: ActivatedRouteSnapshot): boolean | UrlTree {
    // Get the role from the route data
    const role = route.data.role;
    const hasAccess = this.authService.hasRole(role);
    return hasAccess ? true : this.router.createUrlTree(['/unauthorized']);
  }
}

And then we would apply the guard to the routes that we want to protect:

// routes.ts
export const routes: Routes = [
  { path: 'home', component: HomeComponent },
  { 
    path: 'admin', 
    component: AdminComponent, 
    canActivate: [RoleGuard], 
    data: { role: ROLES.ADMIN },
  },
  { 
    path: 'manager', 
    component: ManagerComponent,
    canActivate: [RoleGuard],
    data: { role: ROLES.MANAGER },
  },
  { path: 'unauthorized', component: NotAuthorizedComponent },
];

The code is much cleaner now, and we don't have any duplicated code. But, the only issue with this approach is that is not typechecked. We can pass any string in the data field, and the guard will not complain. We can improve this creating an interface for the data field, and then we can use this interface to type the data field.

interface RoleGuardData {
  role: 'ADMIN' | 'MANAGER'; // We can add more roles here or infer them from the AuthService
}

// And then we can use this interface to type the data field:

export const routes: Routes = [
  { 
    // ...
    data: { role: ROLES.MANAGER } as RoleGuardData,
  },
];

Now, if we try to pass a string that is not a valid role, we will get a type error.

Configurable function-based guard

In Angular 14, we got function-based guards. This means that we can create a function that will return a guard. This is very useful because we can create a function that will return a guard for a specific role, and then we can apply this function to the routes that we want to protect.

// role.guard.ts
export const roleGuard = (role: 'MANAGER' | 'ADMIN'): CanActivateFn => {
  const guard: CanActivateFn = () => {
    const authService = inject(AuthService);
    const router = inject(Router);

    const hasAccess = authService.hasRole(role);
    return hasAccess ? true : router.createUrlTree(['/unauthorized']);
  };

  return guard;
};

And then we would apply the function to the routes that we want to protect:

// routes.ts
export const routes: Routes = [
  { 
    path: 'admin', 
    component: AdminComponent, 
    canActivate: [roleGuard(ROLES.ADMIN)],
  },
  { 
    path: 'manager', 
    component: ManagerComponent,
    canActivate: [roleGuard(ROLES.MANAGER)],
  },
];

When using function-based guards, we don't have to worry about typechecking, because we can infer the role from the function parameter and pass it to the AuthService.

How to test the guards

We can test the guards by creating a mock AuthService, but in our case we can use the real AuthService because it's already a fake service.

// role.guard.spec.ts
import { TestBed } from '@angular/core/testing';
import { RouterTestingModule } from '@angular/router/testing';
import { ActivatedRouteSnapshot, Router } from '@angular/router';
import { ROLES, AuthService } from './auth.service';
import { RoleGuard } from './role.guard';

describe('RoleGuard', () => {
  let router: Router;
  let guard: RoleGuard;
  let authService: AuthService;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [RouterTestingModule],
      providers: [RoleGuard, AuthService],
    });

    router = TestBed.inject(Router);
    guard = TestBed.inject(RoleGuard);
    authService = TestBed.inject(AuthService);
  });

  it('should be created', () => {
    expect(guard).toBeTruthy();
  });

  it('should return true if the user has the role', () => {
    authService.userRole = ROLES.ADMIN; // Set the user role
    const route = { data: { role: ROLES.ADMIN } } as unknown as ActivatedRouteSnapshot;
    expect(guard.canActivate(route)).toBeTrue();
  });

  it('should return /unauthorized if the user does not have the role', () => {
    authService.userRole = ROLES.ADMIN; // Set the user role
    const route = { data: { role: ROLES.MANAGER } } as unknown as ActivatedRouteSnapshot;
    const unauthorizedUrlTree = router.createUrlTree(['/unauthorized']);
    expect(guard.canActivate(route)).toEqual(unauthorizedUrlTree);
  });
});

And here's the test for the function-based guard:

// role.guard.spec.ts
describe('RoleGuard', () => {
  it('allows user to navigate to route if he has access', async () => {
    TestBed.configureTestingModule({
      providers: [
        AuthService,
        provideRouter([
          {path: 'admin', component: AdminComponent, canActivate: [roleGuard(ROLES.ADMIN)]},
        ]),
      ],
    });
    const authService = TestBed.inject(AuthService);
    const harness = await RouterTestingHarness.create();

    authService.userRole = ROLES.ADMIN;
    let instance = await harness.navigateByUrl('/admin');
    expect(instance).toBeInstanceOf(AdminComponent);
  });

  it('redirects to unauthorized if the user doesnt have access', async () => {
    TestBed.configureTestingModule({
      providers: [
        AuthService,
        provideRouter([
          {path: 'manager', component: ManagerComponent, canActivate: [roleGuard(ROLES.MANAGER)]},
          {path: 'unauthorized', component: NotAuthorizedComponent},
        ]),
      ],
    });

    const authService = TestBed.inject(AuthService);
    const harness = await RouterTestingHarness.create();

    authService.userRole = ROLES.ADMIN;
    let instance = await harness.navigateByUrl('/manager');
    expect(instance).toBeInstanceOf(NotAuthorizedComponent);
  });
});

I changed the testing way for the functional based guard to use the RouterTestingHarness because it's easier to think about the test this way (at least for me).

That's it!

Thanks for reading!

I tweet a lot about Angular (latest news, videos, podcasts, updates, RFCs, pull requests and so much more). If you’re interested about it, give me a follow at @Enea_Jahollari. Give me a follow on dev.to if you liked this article and want to see more like this!

Lazy loading services in Angular. What?! Yes, we can.

Enea Jahollari — Wed, 26 Apr 2023 07:25:51 +0000

We’re used to lazy loading modules or components in Angular. But what about lazy loading services? Wait, what? Yes, we can. In this article, we will learn how to lazy load a service in Angular and it’s gotchas.

What is Lazy Loading?

Lazy loading is a code optimization technique that is also called code splitting. It is used to load the code only when it is needed in order to reduce the initial bundle size but also the load time of the application. In order to lazy load code we use the dynamic import syntax.

For example, we can lazy load a module like this:

import("./my-component").then((file) => {
  // do something with the component
});

By doing this, we are telling the bundler to create a separate bundle for the module and load it only when the code is executed.

How to Lazy Load a Service in Angular?

Yes, we will use the dynamic import syntax. But, not only that! Because the services in Angular use the Injectable decorator, it means they are injectable and may also depend on other serivices. So, we cannot just lazy load the service and use it directly as a normal class.

What we have to do is to use the dynamic import syntax to lazy load the service and then use the injector to get the service instance. For example, we can lazy load a service like this:

import("./my-service").then((file) => {
  const service = this.injector.get(file.MyService);
  // do something with the service
});

This is great, but doesn’t give us a good DX (developer experience). We have to use the injector to get the service instance. So, we can create a helper function that will lazy load the service and return the service instance. Here’s a helper function that can help with that.

export function lazyLoadService<T>(loader: () => Promise<T>): Promise<T> {
  const injector = inject(Injector);

  return loader().then((serviceClass) => {
    const service = injector.get(serviceClass);
    return service;
  });
}

Let’s return an Observable instead of a Promise, as it’s more convenient to use in Angular, and easier to chain.

export function lazyService<T>(loader: () => Promise<Type<T>>): Observable<T> {
  const injector = inject(Injector);

  return defer(() => {
    return loader().then((service) => injector.get(service));
  });
}

The defer operator will create an Observable that will execute the loader function only when the Observable is subscribed to. So, we can use it like this:

lazyService(() => import("./my-service")).subscribe((service) => {
  // do something with the service
});

or better yet, we can pipe the service observable:

lazyService(() => import("./my-service")).pipe(
  concatMap((service) => {
    // do something with the service
  })
);

Let’s see an example of how to use it in a component:

const DataServiceImport = () => 
  import('./data.service').then((m) => m.DataService);

@Component({
  template: `
    <ul>
      <li *ngFor="let todo of todos$ | async">
        {{ todo.title }}
      </li>
    </ul>
  `,
  standalone: true,
  imports: [NgFor, AsyncPipe],
})
export class AppComponent {
  private dataService$ = lazyService(DataServiceImport);

  todos$ = this.dataService$.pipe(concatMap((s) => s.getTodos()));
}

And now, let’s take a look at the network tab!

Yeah, the service will be in it’s own bundle 🎉!

But what if we want to use the service in another component, we have to lazy load it again. Otherwise, it will be bundled in main bundle (if used in not lazy loaded component), or common bundle (if used in another lazy loaded component), and break the code splitting.

NOTE: The javascript bundle will be downloaded only once, no matter of how many times we lazy load it, because after the first download, webpack (the bundler) will just reuse the downloaded bundled.

Different ways to lazy load a service

Take a look at this tweet by Younes, where he explains different ways to lazy load a service in Angular:

Tweet 1: https://twitter.com/yjaaidi/status/1552281356608102404
Tweet 2: https://twitter.com/yjaaidi/status/1552570805715861504

What’s the usecase for lazy loading a service?

Let’s say we have a service that is used only in one component. And we want to lazy load the component. So, we can lazy load the service as well. And the service will be lazy loaded only when the component is loaded or the service is used.

Another use case is when we have very dynamic applications, meaning that we load components dynamically and maybe based on configs, and these components may use different services or the same services. But because we don’t know which services will be used, we can’t bundle them in the main bundle otherwise it will get big! So, we can lazy load the services and load them only when they are needed.

Conclusion

I want to give a shoutout to @Younes for his great research on lazy loading services in Angular. He is the one who inspired me to write this article. So, go ahead and follow him on Twitter.

After Ivy’s rollout, everything in Angular has become easier to work with. Lazy loading services is no exception!

Go ahead and try it out to reduce the main bundle size. And let me know what you think in the comments below.

Play with the feature here: https://stackblitz.com/edit/angular-jb85mb?file=src/main.ts 🎮

Thanks for reading!

New way of passing data to dynamically created components (New Feature 🎉)

Enea Jahollari — Wed, 19 Apr 2023 15:11:15 +0000

Topics covered in this article:

How it works today
How it can be done in Angular v16
How to migrate to the new API
How to test it
Caveats

How it works today

When working with Angular, we often need to render dynamic components. For example, we might want to render a component based on the user's input. In order to do that, we can use NgComponentOutlet directive.

So, we will take a look at how we can pass data to dynamically created components using NgComponentOutlet directive today.

Example:
Let's say we need to show a component based on the type we choose in a dropdown.

In order to pass data to dynamic components rendered by NgComponentOutlet directive, we have to:

Create an injection token
Create a new injector
Pass the data in the injector using the injection token.
Pass the injector to the NgComponentOutlet directive.
Use the injection token to get the data in the dynamic component.

So, first we need to create an injection token.

export interface DynamicData {
  url: string;
  updated: (changes: any) => void; // callback to update the data
}

export const DATA_TOKEN = new InjectionToken<DynamicData>("data");

Now, let's take a look at our dynamic components, ImageComponent and VideoComponent, and how we can use the injection token to get the data in the dynamic component.

@Component({
  template: `
    <img [src]="data.url" />
    <button (click)="data.updated({ url: 'https://angular.io' })">Update</button>
  `,
})
export class ImageComponent {
    data = inject(DATA_TOKEN); // will be of type DynamicData
}

@Component({
  template: `
    <video [src]="data.url" controls></video>
    <button (click)="data.updated({ url: 'https://angular.io' })">Update</button>
  `,
})
export class VideoComponent {
    data = inject(DATA_TOKEN); // will be of type DynamicData
}

Pretty "complex" usecase I know, but this is just for demonstration purposes.

Now, let's take a look at how we can use the NgComponentOutlet directive to render the dynamic components.

@Component({
  template: `
    <label for="type">Type</label>
    <select [ngModel]="selectedType" (ngModelChanges)="changeType($event)" name="type">
      <option value="image">Image</option>
      <option value="video">Video</option>
    </select>

    <ng-container *ngComponentOutlet="selectedItem.component; injector: selectedItem.injector" />
  `,
})
export class ParentComponent {
  private readonly injector = inject(Injector);

  items = {
    image: {
      component: ImageComponent,
      injector: Injector.create({
        parent: this.injector,
        providers: [{
            provide: DATA_TOKEN,
            useValue: {
              url: "https://angular.io/assets/images/logos/angular/angular.png",
              updated: (changes: any) => console.log("Image changes", changes),
            },
        }],
      }),
    },
    video: {
      component: VideoComponent,
      injector: Injector.create({
        parent: this.injector,
        providers: [{
            provide: DATA_TOKEN,
            useValue: {
              url: "https://www.youtube.com/watch?v=QH2-TGUlwu4",
              updated: (changes: any) => console.log("Video changes", changes),
            },
        }],
      }),
    },
  };

  selectedType: "image" | "video" = "image";
  selectedItem = this.items[this.selectedType];

  changeType(type: "image" | "video") {
    this.selectedType = type;
    this.selectedItem = this.items[this.selectedType];
  }

}

As you can see, we have to create a new injector for each dynamic component, register the data we want to pass to the injection token and then and pass it to the NgComponentOutlet directive using the selectedItem. We also pass an updated callback to the value. This callback is used to update the data in the parent component (in our case it just logs). So, it will work like an event emitter (output).

Yeah! This is a lot of boilerplate code 😬.

But, it's getting better in Angular v16 🥳.

How it can be done in Angular v16

In Angular v16, we can pass data to dynamically created components using the NgComponentOutlet directive using the inputs property 🤩.

First thing we will do is to covert our ImageComponent and VideoComponent to use the @Input() decorator.

@Component({
  template: `
    <img [src]="url" />
    <button (click)="updated({ url: 'https://angular.io' })">Update</button>
  `,
})
export class ImageComponent {
  @Input() url: string;
  @Input() updated: (changes: any) => void;
}

@Component({
  template: `
    <video [src]="url" controls></video>
    <button (click)="updated({ url: 'https://angular.io' })">Update</button>
  `,
})
export class VideoComponent {
  @Input() url: string;
  @Input() updated: (changes: any) => void;
}

It's pretty simple, right?

Now, let's take a look at how we can use the inputs property to pass data to dynamically created components.

@Component({
  template: `
    <label for="type">Type</label>
    <select [ngModel]="selectedType" (ngModelChanges)="changeType($event)" name="type">
      <option value="image">Image</option>
      <option value="video">Video</option>
    </select>

    <ng-container *ngComponentOutlet="selectedItem.component; inputs: selectedItem.inputs" />
  `,
})
export class ParentComponent {

  items = {
    image: {
      component: ImageComponent,
      inputs: {
        url: "https://angular.io/assets/images/logos/angular/angular.png",
        updated: (changes: any) => console.log("Image changes", changes),
      },
    },
    video: {
      component: VideoComponent,
      inputs: {
        url: "https://www.youtube.com/watch?v=QH2-TGUlwu4",
        updated: (changes: any) => console.log("Video changes", changes),
      },
    },
  };

  selectedType: "image" | "video" = "image";
  selectedItem = this.items[this.selectedType];

  changeType(type: "image" | "video") {
    this.selectedType = type;
    this.selectedItem = this.items[this.selectedType];
  }

}

As you can see, we can pass the data directly to the inputs property. No need to create a new injector and register the data in the injector. We can also do the same trick with the callback to update the data in the parent component.

How to migrate to the new approach

If you are using the old approach, you can migrate to the new approach by doing the following:

Convert your dynamic components to use the @Input() decorator instead of the inject() function.

Before:

@Component({})
export class ImageComponent {
    data = inject(DATA_TOKEN); 
}

After:

@Component({})
export class ImageComponent {
    @Input() data: DynamicData;
}

Pass the data directly to the inputs property of the NgComponentOutlet directive.

Before:

@Component({
    template: `
        <ng-container *ngComponentOutlet="item.component; injector: item.injector" />
    `,
})
export class ParentComponent {
  private readonly injector = inject(Injector);

  items = {
    image: {
      component: ImageComponent,
      injector: Injector.create({
        parent: this.injector,
        providers: [{
            provide: DATA_TOKEN,
            useValue: {
              url: "https://angular.io/assets/images/logos/angular/angular.png",
              updated: (changes: any) => console.log("Image changes", changes),
            },
        }],
      }),
    },
  };
}

After:

@Component({
    template: `
        <ng-container *ngComponentOutlet="item.component; inputs: item.inputs" />
    `,
})
export class ParentComponent {
  items = {
    image: {
      component: ImageComponent,
      inputs: {
        data: {
          url: "https://angular.io/assets/images/logos/angular/angular.png",
          updated: (changes: any) => console.log("Image changes", changes),
        },
      },
    },
  };
}

Remove the injected Injector from the parent component but also the InjectionToken created to pass the data to the dynamic component.

How to test it

To test the new approach, we will use the TestBed to create a test module and then create a test component that uses the NgComponentOutlet directive.

describe('ParentComponent', () => {
  let component: ParentComponent;
  let fixture: ComponentFixture<ParentComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [ParentComponent, ImageComponent, VideoComponent],
    }).compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(ParentComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  it('should create', () => {
    expect(component).toBeTruthy();
  });

  it('should display image by default', () => {
    const imageElement = fixture.debugElement.query(By.css('img'))
      .nativeElement as HTMLImageElement;
    expect(imageElement.src).toBe(
      'https://angular.io/assets/images/logos/angular/angular.png'
    );
  });

  it('should switch to video', () => {
    // select video option from the dropdown
    const selectElement = fixture.debugElement.query(By.css('select'))
      .nativeElement as HTMLSelectElement;
    selectElement.value = 'video';
    selectElement.dispatchEvent(new Event('change'));

    fixture.detectChanges();

    const videoElement = fixture.debugElement.query(By.css('video'))
      .nativeElement as HTMLVideoElement;
    expect(videoElement.src).toBe(
      'https://www.youtube.com/watch?v=QH2-TGUlwu4'
    );
  });

  it('should update image data', () => {
    spyOn(console, 'log');

    const imageUpdateButton = fixture.debugElement.query(By.css('button'));
    imageUpdateButton.triggerEventHandler('click', null);

    expect(console.log).toHaveBeenCalledWith('Image changes', {
      url: 'https://angular.io',
    });
  });

  it('should update video data', () => {
    spyOn(console, 'log');

    const selectElement = fixture.debugElement.query(By.css('select'))
      .nativeElement as HTMLSelectElement;
    selectElement.value = 'video';
    selectElement.dispatchEvent(new Event('change'));

    fixture.detectChanges();

    const videoUpdateButton = fixture.debugElement.query(By.css('button'));
    videoUpdateButton.triggerEventHandler('click', null);

    expect(console.log).toHaveBeenCalledWith('Video changes', {
      url: 'https://angular.io',
    });
  });
});

If our testing approach is just testing only what we see on the screen, then the tests should not change at all. We are still testing the same thing. We are just using a different approach to create the dynamic components.

Caveats

We are used to use the @Output() decorator to tell Angular that we want to listen to an event from the child component. But the NgComponentOutlet directive won't support the @Output() decorator or add an outputs field. So, we are left with the callback approach to notify the parent component about the changes in the child component.

Conclusion

I hope you enjoyed this article, and I hope that you will find this new feature useful.

If you have any questions or suggestions, feel free to leave a comment below.

This is the PR (community contribution) that implements the feature: https://github.com/angular/angular/pull/49735

Thanks to HyperLife1119 😎

Thanks for reading!

// Detect dark theme var iframe = document.getElementById('tweet-1648702729634586624-908'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1648702729634586624&theme=dark" }

Bind Route Info to Component Inputs (New Router feature)

Enea Jahollari — Wed, 05 Apr 2023 15:41:34 +0000

Pass router info to routed component inputs

Topics covered in this article:

How it works today
How it will work in Angular v16
How to use it
How to migrate to the new API
How to test it
Caveats

When building applications with Angular, most of the time we use the Router to render different pages for different urls.

And based on the url we also load the data based on its path parameters or query parameters.

In the latest version of Angular v16, we will get a new feature that will simplify the process of retrieving route information in the component and make it way easier.

How it works today

Let's say we have a routes array like this one:

const routes: Routes = [
  {
    path: "search",
    component: SearchComponent,
  },
];

And inside the component we need to read the query params in order to fill a search form.

With an URL like this: http://localhost:4200/search?q=Angular;

@Component({})
export class SearchComponent implements OnInit {
    // here we inject the ActivatedRoute class that contains info about our current route
    private route = inject(ActivatedRoute);

    query$ = this.route.queryParams.pipe(map(queryParams) => queryParams['q']);

    ngOnInit() {
        this.query$.subscribe(query => { // do something with the query });
    }
}

As you can see, we need to inject the ActivatedRoute service and then we can access the query params from it. But we can also access the path params and the data, or even the resolved data, as we can see in the following example:

const routes: Routes = [
  {
    path: "search/:id",
    component: SearchComponent,
    data: { title: "Search" },
    resolve: { searchData: SearchDataResolver }
  },
];

@Component({})
export class SearchComponent implements OnInit {
    private route = inject(ActivatedRoute);

    query$ = this.route.queryParams.pipe(map(queryParams) => queryParams['q']);
    id$ = this.route.params.pipe(map(params) => params['id']);
    title$ = this.route.data.pipe(map(data) => data['title']);
    searchData$ = this.route.data.pipe(map(data) => data['searchData']);

    ngOnInit() {
        this.query$.subscribe(query => { // do something with the query });
        this.id$.subscribe(id => { // do something with the id });
        this.title$.subscribe(title => { // do something with the title });
        this.searchData$.subscribe(searchData => { // do something with the searchData });
    }
}

How it will work in Angular v16

In Angular v16 we will get a new feature that will simplify the process of retrieving route information in the component and make it way easier.

We will be able to pass the route information to the component inputs, so we don't need to inject the ActivatedRoute service anymore.

const routes: Routes = [
  {
    path: "search",
    component: SearchComponent,
  },
];

@Component({})
export class SearchComponent implements OnInit {
    /* 
        We can use the same name as the query param, for example 'query'
        Example url: http://localhost:4200/search?query=Angular
    */
    @Input() query?: string; // we can use the same name as the query param

    /* 
        Or we can use a different name, for example 'q', and then we can use the @Input('q')
        Example url: http://localhost:4200/search?q=Angular
    */
    @Input('q') queryParam?: string; // we can also use a different name

    ngOnInit() {
        // do something with the query
    }
}

And we can also pass the path params, the data and resolved data to the component inputs:

const routes: Routes = [
  {
    path: "search/:id",
    component: SearchComponent,
    data: { title: "Search" },
    resolve: { searchData: SearchDataResolver }
  },
];

@Component({})
export class SearchComponent implements OnInit {
    @Input() query?: string; // this will come from the query params
    @Input() id?: string; // this will come from the path params
    @Input() title?: string; // this will come from the data
    @Input() searchData?: any; // this will come from the resolved data

    ngOnInit() {
        // do something with the query
        // do something with the id
        // do something with the title
        // do something with the searchData
    }
}

And of course we can rename the inputs to whatever we want:

const routes: Routes = [
  {
    path: "search/:id",
    component: SearchComponent,
    data: { title: "Search" },
    resolve: { searchData: SearchDataResolver }
  },
];

@Component({})
export class SearchComponent implements OnInit {
    @Input() query?: string; 
    @Input('id') pathId?: string; 
    @Input('title') dataTitle?: string;
    @Input('searchData') resolvedData?: any; 

    ngOnInit() {
        // do something with the query
        // do something with the pathId
        // do something with the dataTitle
        // do something with the resolvedData
    }
}

How to use it

In order to use this new feature, we need to enable it in the RouterModule:

@NgModule({
  imports: [
    RouterModule.forRoot([], {
      //... other features
      bindToComponentInputs: true // <-- enable this feature
    })
  ],
})
export class AppModule {}

Or if we are in a standalone application, we can enable it like this:

bootstrapApplication(App, {
  providers: [
    provideRouter(routes, 
        //... other features
        withComponentInputBinding() // <-- enable this feature
    )
  ],
});

How to migrate to the new api

If we have a component that is using the ActivatedRoute service, we can migrate it to the new api by doing the following:

Remove the ActivatedRoute service from the component constructor.
Add the @Input() decorator to the properties that we want to bind to the route information.
Enable the bindToComponentInputs feature in the RouterModule or provideRouter function.

Example with before and after for path params, with url: http://localhost:4200/search/123

// Before
@Component({})
export class SearchComponent implements OnInit {
    private route = inject(ActivatedRoute);

    id$ = this.route.params.pipe(map(params) => params['id']);

    ngOnInit() {
        this.id$.subscribe(id => { // do something with the id });
    }
}

// After
@Component({})
export class SearchComponent implements OnInit {
    @Input() id?: string; // this will come from the path params

    ngOnInit() {
        // do something with the id
    }
}

How to test it

In order to test the new feature, we can use the RouterTestingHarness and let it handle the navigation for us.

Here is an example of how to test the route info bound to component inputs with the RouterTestingHarness:

@Component({})
export class SearchComponent {
    @Input() id?: string; 
    @Input() query?: string; 
}

it('sets id and query inputs from matching query params and path params', async () => {
    TestBed.configureTestingModule({
        providers: [ provideRouter(
            [{ path: 'search/:id', component: SearchComponent }],
            withComponentInputBinding()
        ) ],
    });

    const harness = await RouterTestingHarness.create();

    const instance = await harness.navigateByUrl(
        '/search/123?query=Angular',
        TestComponent
    );

    expect(instance.id).toEqual('123');
    expect(instance.query).toEqual('Angular');

    await harness.navigateByUrl('/search/2?query=IsCool!');
    expect(instance.id).toEqual('2');
    expect(instance.query).toEqual('IsCool!');
});

It's as simple as that!

Caveats

Sometimes we want the id or queryParams to be observables, so we can combine them with other observable to get some data.

For example, let's say we have a component that is using the id and queryParams to get some data from the server:

@Component({})
export class SearchComponent implements OnInit {
    private dataService = inject(DataService);

    @Input() id?: string; 
    @Input() query?: string; 

    ngOnInit() {
        this.dataService.getData(this.id, this.query).subscribe(data => {
            // do something with the data
        });
    }
}

If we want to use the async pipe in order to subscribe to the data, we need to make sure that the id and query are observables instead of strings, otherwise this example below will not work:

@Component({})
export class SearchComponent implements OnInit {
    private dataService = inject(DataService);

    @Input() id?: string; 
    @Input() query?: string; 

    // this will not work because the id and the query don't have a value yet (they are undefined)
    // they will have a value only after the component is initialized and the inputs are set
    data$ = this.dataService.getData(this.id, this.query); 
}

In order to make the id and query observables, we can use the BehaviorSubject:

@Component({
    template: `
        <div *ngIf="data$ | async as data">
            {{ data }}
        </div>
    `
})
export class SearchComponent implements OnInit {
    private dataService = inject(DataService);

    id$ = new BehaviorSubject<string | null>(null);
    query$ = new BehaviorSubject<string | null>(null);

    @Input() set id(id: string) { this.id$.next(id); }
    @Input() set query(query: string) { this.query$.next(query); }

    data$ = combineLatest([
        this.id$.pipe(filter(id => id !== null)), 
        this.query$.pipe(filter(query => query !== null))
    ]).pipe(
        switchMap(([id, query]) => this.dataService.getData(id, query))
    );
}

As you can see, we are using the BehaviorSubject to make the id and query observables, and we are using the combineLatest operator to combine them with the switchMap operator to get the data from the server.

Personally, I think that this is a bit too much code for a simple example, so I would recommend to use the ActivatedRoute service instead of the new api in this case.

Priority of the route information when the route infos have the same name. For example, let's say we have a route with the following configuration:

const routes: Routes = [
  {
    path: 'test/:value',
    component: TestComponent,
    data: { value: 'Hello from data' },
  }
];

@Component({ template: `{{ value }}` })
export class TestComponent {
  @Input() value?: string;
}

The new api will bind the route information to the component inputs in the following order:

Data
Path params
Query params

If there's no data, it will use the path params, if there's no path params, it will use the query params
If there's no query params, the value input will be undefined!

We don't know where the input value will come from 😬

In my opinion, for this "issue" what we can do is to rename the Input in imports and use it like this:

import { Input as RouteInput, Component } from "@angular/core";

@Component({ template: `{{ value }}` })
export class TestComponent {
  @RouteInput() value?: string;
}

// OR 
import { Input as QueryParamInput, Component } from "@angular/core";

@Component({ template: `{{ value }}` })
export class TestComponent {
  @QueryParamInput() value?: string;
}

Not the best way possible, but we can see that it's not a normal input and that it is connected with the router info.

Conclusion

I hope you enjoyed this article, and I hope that you will find this new feature useful.

If you have any questions or suggestions, feel free to leave a comment below.

Play with the feature here: https://stackblitz.com/edit/angular-jb85mb?file=src/main.ts 🎮

Thanks for reading!

Async pipe is not pure 🤯

Enea Jahollari — Mon, 16 Jan 2023 15:48:11 +0000

Yes, that’s normal! Why? Because of how Angular does change detection under the hood!

To better understand how the async pipe works, let’s create our own from scratch!

Let’s call it SubscribePipe in order for to differ it from the original one.

Also, we want our pipe to check this points:

Work with Observables (we won’t handle Promises in this post)
No over-subscribing
Work with OnPush change detection
No memory leaks

And use it like this, ex:

@Component({
  selector: 'my-app',
  template: `
    <div *ngIf="show">
      Value: {{ obs$ | subscribe }}
    </div>
  `,
  standalone: true,
  imports: [CommonModule, SubscribePipe],
  // changeDetection: ChangeDetectionStrategy.OnPush // <-- after we handle it we should uncomment this
})
export class AppComponent {
  show = true;

  obs$ = interval(500).pipe(
    tap((x) => {
      if (x === 10) {
        this.show = false;
      }
    })
  );
}

Create a pipe (standalone)

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({
  name: 'subscribe',
  standalone: true
})
export class SubscribePipe implements PipeTransform {
  transform() {}
}

We want our pipe to accept an Observable type, that means we need to handle Observables, Subjects, BehaviorSubjects and ReplaySubjects.

Let’s create a Subscribable type that includes all of them (that will be a generic type).

type Subscribable<T> = Observable<T> | Subject<T> | BehaviorSubject<T> | ReplaySubject<T>;

Now that we know what our pipe accepts, let’s refactor the pipe to use it! Because we want to infer the type of the subscribable we will convert the pipe class to be generic.

Also, one other thing, we can also pass undefined or null to our pipe.

export class SubscribePipe<T> implements PipeTransform {
  transform(obs: Subscribable<T> | null | undefined) {}
}

Subscription handling

First we need to check if the observable is not null or undefined, and if it is we just return null;

transform(obs: Subscribable<T> | null): T | null {
  if (!obs) {
    return null;
  }
}

Now, let’s subscribe to the observable and store it’s last value and return it directly.

latestValue: T | null = null;

transform(obs: Subscribable<T> | null): T | null {
  if (!obs) {
    return null;
  }

  obs.subscribe(value => {
    this.latestValue = value;
  });

  return this.latestValue;
}

This won’t work! Why?

Because when change detection runs, the pipe will check the parameters in the transform method and if they haven’t changed, it will return the last value that it had cached before.

I’ve explained it more deeply in my previous post: It’s ok to use function calls in Angular templates! , where I explain how pipes memoization works and how we can do the same thing too when using normal functions.

This is the moment where we opt-out of pipe memoization by using the pure: false flag.

@Pipe({
  name: 'subscribe',
  standalone: true,
  pure: false // <-- It is true by default
})

The moment we set the pure option to be false, we tell Angular that we want to handle the transform method memoization by ourself.

If we run the code we will see something like this:

The reason why it does that is because every time change detection runs, the pipe will subscribe to our observable and let the other subscription in memory, and of course create a memory leak!

How can we fix that? By doing a simple equality check!

We will save the current observable reference, and every time the transform method is called, we will check if it’s equal with our current one, and if that’s true, we will just return that latest value.

private currentObs: Subscribable<T> | null = null;

transform(obs: Subscribable<T> | null): T | null {
  if (!obs) {
    return null;
  }

  if (obs === this.currentObs) { // <-- simple equality check
    return this.latestValue;
  } else {
    this.currentObs = obs; // <-- save current observable to a class field

    obs.subscribe((value) => {
      this.latestValue = value;
    });
  }

  return this.latestValue;
}

If we check the app now, we will see that it works fine! But it’s not finished!

Because we still cause a memory leak, because we never unsubscribe from the observable! Let’s do it!

Unsubscription handling

Just like we stored the latestValue and currentObs, we will also store the current subscription and assign the observable subscription to it!

private sub: Subscription | null = null;

transform(obs: Subscribable<T> | null): T | null {
  ...
  this.sub = obs.subscribe((value) => {
    this.latestValue = value;
  });
  ...
}

Good! Now we need to unsubscribe on ngOnDestroy, but not only there 💡. How so? Because we need to unsubscribe also on cases where we change the observable reference to be another observable or set it to null.

For example:

@Component({
  selector: 'my-app',
  template: `
    <div *ngIf="show">{{ obs$ | subscribe }}</div>
  `,
  standalone: true,
  imports: [CommonModule, SubscribePipe],
})
export class AppComponent {
  show = true;

  ngOnInit() {
    setTimeout(() => {
      this.obs$ = of(20000);
    }, 2000);

    setTimeout(() => {
      this.obs$ = null;
    }, 4000);
  }

  obs$ = interval(500).pipe(
    tap((x) => {
      if (x === 10) {
        this.show = false;
      }
    })
  );
}

So, we need to dispose the subscription also on these cases! Otherwise, we cause a memory leak!

Let’s create a dispose() method that has the unsubscription logic in order to re-use it!

private dispose() {
  if (this.sub) { // <-- first we check if we have a subscription
    this.sub.unsubscribe(); // <-- unsubscribe from the observable
    this.sub = null; // <-- remove the subscription reference
  }
}

Now, let’s use this method!

First, on ngOnDestroy() and then in the other cases mentioned above!

ngOnDestroy() {
  this.dispose();
}

transform(obs: Subscribable<T> | null): T | null {
  if (!obs) {
    this.dispose(); // <-- if we have a current sub and change the obs to be null we need to dispose it
    return null;
  }

  if (obs === this.currentObs) {
    return this.latestValue;
  } else {
    this.dispose(); // <-- before subscribing to a new observable, we need to dispose the existing one

    this.currentObs = obs;

    this.sub = obs.subscribe((value) => {
      this.latestValue = value;
    });
  }

  return this.latestValue;
}

If we see the app, it will still work without any issue! And now without memory leaks 🎉 yay!

Are we done? Not yet, because our pipe doesn’t work with OnPush ChangeDetection!

On, your editor, try to enable the changeDetection OnPush on your component and see the app! It won’t show anything!

But, how can we fix it? Just like any other time when we try to fix change detection issues 😈😄, put a cdr.markForCheck() after you update the value and we’re done!

private cdr = inject(ChangeDetectorRef); // <-- inject CDRef here

transform(obs: Subscribable<T> | null): T | null {
  ...
  this.sub = obs.subscribe((value) => {
    this.latestValue = value;
    this.cdr.markForCheck(); // <-- mark the component as dirty here, after we have updated the latestValue
  });
  ...
}

That’s it!

Code refactoring

Let’s move the subscription handling in a method (and also throw when we get an error), set cdr, currentObs to null in ngOnDestroy (to remove it’s reference and not cause any memory leak) and change the way code is handled in the transform method for better readability.

private subscribe(obs: Subscribable<T>) {
  this.currentObs = obs;

  this.sub = obs.subscribe({
    next: (res) => {
      this.latestValue = res;
      this.cdr.markForCheck();
    },
    error: (error) => {
      throw error;
    },
  });
}

transform(obs: Subscribable<T> | null): T | null {
  if (!obs) {
    this.dispose();
    return null;
  }

  // here we check if the obs are not the same instead of checking if they are the same
  if (obs !== this.currentObs) {
    this.dispose();
    this.subscribe(obs); // <-- use the method we extracted above
  }

  return this.latestValue;
}

ngOnDestroy() {
  this.dispose();
  this.cdr = null;
  this.currentObs = null;
}

Recap

Find the whole source code here.

We have handled almost all the cases that Angular’s async pipe handles except the promises (but also that can be done easily)! And understood why Angular async pipe is not pure, and why that is not an issue at all!

I hope you liked this post and learned something from it!

I tweet a lot about Angular (latest news, videos, podcasts, updates, RFCs, pull requests and so much more). If you’re interested about it, give me a follow at @Enea_Jahollari. Give me a follow on Dev.to if you liked this article and want to see more like this!

Thank you for reading!

It’s ok to use function calls in Angular templates!

Enea Jahollari — Wed, 28 Sep 2022 15:39:15 +0000

“You should never use function calls on Angular templates!” — That’s what you will see all over the internet! And I’m here to prove to you that that’s not always the case!

The issue

Every time Angular change detection runs (from events, setTimeout, manual or anything else), everything on the template will run again with it, that’s also the case for function calls. Why does Angular do this? Because it needs to check what’s changed on the template in order to update it.

If the function does something heavy, it will impact the performance of the application, because the way Angular updates the view is synchronous, and it will have to wait for the function to finish and then update the view.

The “Use a pipe” solution

The solution we’ll mostly see is “Use a pipe”. This is recommended because the pipes in Angular templates are more performant. How so? Because Angular will re-run the transform method of the pipe only if the parameters we pass to it have changed.

Let’s prove it!

Let’s dig in the source code

In the new Angular compiler (Ivy), templates are compiled into instructions. Let’s take an example and see what it generates.

Here’s a component with a simple pipe.

And here’s the cleaned up generated code:

As we can see, in line 29, that’s where we see what Angular generates for the template code.

So, there are instructions for creating a div, adding text, adding a pipe, closing the div, creating a button and adding a listener to it … (Ivy’s cool stuff 🌿). We can also see the if/else statement. What it does is, it separates the view creation from view updating, the first if does the view creation and the second one is for the updating part. You can read more on that here.

We are interested for the line 33 and 43, because that’s where the pipe does the magic 🪄. In line 33 it registers the pipe in the template and the binding of the data happens in *line 43 *(in the update phase). We see that it interpolates some text and that text comes from **ɵɵpipeBind1() **function. Let’s see what that function does underneath 🕵️‍♂️.

As we can see, the first three lines get the information for the pipe instance and then we have a return statement. In the return we have a check for isPure(), and it just checks if we have set pure field true or false in the pipe decorator.

If we have set the pure field to false it will directly return the pipeInstance.transform(v1) value, meaning Angular won’t do anything special with the pipe but just run the transform method again. It would be the same as using a method from the component class.

If the pipe is pure (as in our case), it will call the pureFunction1Internal helper function** and will pass some fields to it. Let’s see what pureFunction1Internal does underneath.

We can see that it checks if the binding is updated in the bindingUpdated function, and if that’s true it will update the binding otherwise it will return the value of the pure function (the current value). Let’s see what check it does underneath 🕵️‍♂️.

So, what it really checks is if the old value is the same as the new value (using Object.is()). You will ask: what value is this? Nothing else than the parameter that we have passed to the pipe transform method.

It means that if none of the parameters of that method has changed, we’re good to go, we can return false and we won’t have to run the function again, we can just use the old value of the binding.

And that’s what we wanted to prove in the first place 🥳.

What does this mean for us?

It means that we can create a helper function that does the magic Angular does for us, without needing to use a pipe at all 😎.

Here’s the helper function, we’ll explain how it works below.

So, memo is a function that accepts a function as parameter and returns a result.

In line 6 we check if the function parameters have changed, that’s what hasDifferentArgs function helps with. It first checks if the length of the args has changed, if yes returns true, and then does an equality check (just like Angular does with pipes) of the parameters.

If the parameters have changed we call the function again with the new parameters and save its result, and if not, we return the old value.

How to use it?

Here’s the example above converted to use the memo function.

Just like that! And yes, we are using a function in the template! And yes, it’s not a problem doing so! 😄

Is there any catch?

Yes, there is! The memo function will help you in cases when you call it in the template and pass the same value to it, and not use it with different parameters because that will break the “cache” of the memo function.

What do I mean by this? Here’s an example.

Because we are passing different values in different places in the template, the memo function will cache stuff per instance, and not per usage.

In this case, the “isOdd called” will show up 6 times every time we click on the button.

So, if we pass the same value in the all the places in the template, it will fire only once.

And here’s the console.

Pipes caches per function usage while memo util caches per function definition.

The idea and the inspiration for the blog post?

All thanks to a tweet from Pawel Kozlowski, an Angular team member. I just thought to dig more on the source code and explain it further.

// Detect dark theme var iframe = document.getElementById('tweet-1531327027327840256-715'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1531327027327840256&theme=dark" }

You’re interested in reactivity, signals, performance, change detection an other cool stuff like that? Go give Pawel a follow on Twitter, he is exploring the space and tweeting cool stuff about it!

While you’re on Twitter, give me a follow too at @Enea_Jahollari if want the** latest Angular news*, **videos, **podcasts, **updates, **RFCs, **pull requests* and so much more. Give me a follow on dev.to if you liked this article and want to see more like this!

Thank you for reading!

Introduction to Angular Language Service

Enea Jahollari — Fri, 16 Sep 2022 16:12:28 +0000

Working with Angular has its gotchas, but what makes it really a joy to start off, is its language service.

What’s a language service?

A language service is a program that you feed your code and it will report you completions, errors, hints and diagnostics on a file per file basis, all while making a distinction between syntactic and semantic errors of each file. And that’s what Angular language service does for Angular projects.

How does it help us?

Angular code files end with .ts or .html, so the code editor thinks that we’re writing Typescript and Html code, but that’s not totally true. Because, on top of that we are also writing Angular specific syntax like: components, directives, property/event bindings, etc. And the code editor doesn’t know anything about them.

That’s what the language service does for us, it understands that you’re inside an Angular project and tells the editor what that Angular specific syntax is.

VS Code uses Typescript Language Service and HTML Language Service to understand the Typescript and Html files too and because they are so widely used they are bundled with VS Code by default.

If we have just installed VS Code and open an Angular component with inline template here’s what we’ll see:

Because the editor thinks that this is a typescript file, it won’t provide code highlight for the template part, and it will be shown just like it was a string, even though the editor has support for HTML (and here we are inside a Typescript file).

So, we won’t get any support for Angular and HTML syntax from it. So, if we hover over the div or the click binding or the **ngIf* directive, we won’t get any information.

The Language Service tells the editor that we are inside an Angular component, and to treat the template field as an Angular template that in fact is HTML with enhanced capabilities (with some gluten over it).

If we install the Angular Language Service and open that file again. We will see something better.

Let’s hover over some of the elements in the template and see what kind of information it provides.

Event bindings

If we hover over the click event we will see that the information is just an addEventListener in the div element (because that’s what that click binding does).

And the type of the $event value is of MouseEvent because that’s what a addEventListener with click event type dispatches. So, no magic 🪄!

Let’s add a component that has an Output, and add it in the template.

When we hover over the onGameStart event we can see that the it’s just an EventEmitter that emits a boolean value, and that’s right!

Interpolation

If we hover over the interpolated version variable we can see that the right type will be shown, so version is just a property of the LazyComponent with type number. This also works for complex types.

The reason why everything shows the correct type is because the Angular templates are strictly typed and the language service just uses the Angular Compiler under the hood to get all this information.

Data binding

Let’s add an Input to the component we created before and pass some data to it from the LazyComponent.

The gameVersion input is of number type and here we pass a property of number type property. And everything goes fine.

Let’s change the property on LazyComponent to be of string type and see what we get:

Yes, we’ll get an error that tells us that the property we are passing has a wrong type from the one that the input requires.

Directives information

In the template we have an **ngIf* directive. If we hover over it we’ll see the class it comes from and the generic type of it, in this case it’s a boolean. So, we need to pass a boolean expression to the **ngIf* directive.

Let’s add an NgFor directive and see what information the editor gives us.

Yes, it will show us that the directive class is NgForOf and the generic types of it. Great so far!

These are some of the informations that the language service provides us!

But there’s more, yay 🥳!

Go to definition

We can right-click on every item in the template and click on Go to definition and it will send us there! Be it a component, directive, input, event, DOM element etc.

As we can see it will send us to the correct place, whether it is inside our components, directives, the ones provided by Angular, or the types of DOM elements, like lib.dom.ts etc.

Go to references

We can also use the Go to references option and it will show us every place where we have used the item that we searched for!

Rename symbol from template

Because everything is Typescript in Angular, we can use the Rename symbol in the template and all the references of that symbol will be renamed. Be it inputs, outputs, class properties or methods etc.

Rename symbol functionality will not work 100% correctly if we do it from the inside class and not from the template, because there’s an issue in VS Code itself that is not solved yet!

Code autocompletion

If we start writing stuff on the template the language service will provide VS Code autocompletion data that we can use, be it inputs, outputs, events, class properties etc.

Code fixes

In the latest version of the Language Service, we can make use of code fixes. We can create properties or methods directly from the template, or fix stuff that we may have written in a wrong way.

As we can see it will create the method and also pass the type of the event that we pass to that method, in this case it was MouseEvent.

Angular language service has come a long way! It was re-written from the ground-up because of the Ivy compiler and it was worth it! Because now we have all this good stuff that wasn't possible before.

There is a lot of cool stuff coming too, like importing components, directives, pipes for Standalone components but also for NgModules.

Till then, go install the language service (if you haven’t yet) and use it to the fullest, it has a lot to give and make your coding easier!

Incremental Static Regeneration for Angular

Enea Jahollari — Sat, 09 Apr 2022 17:26:21 +0000

If you are reading this, you've probably heard of SSR (Server-side rendering), SSG (Static site generation) and CSR (Client-side rendering).

A brief overview of them:

SSR: With server-side rendering, every time a page is requested it will be server-rendered (probably make api calls), and then it will be served to the client.
SSG: With static site generation, the rendering of the pages will be done at build time, and when the page is requested the client will be served the generated static file for that route.
CSR: With client-side rendering, the rendering of the page (and the api calls needed for that page) will happen on runtime (on clients device).

What’s ISR and what problem does it solve?

Let’s take an e-commerce site as an example. This e-commerce site has thousands of clients and thousands of products, and for each product there is a details page.

Because it’s an e-commerce site, it should be server-side rendered (probably using Angular Universal) in order for crawlers to read its content that is needed for SEO.

Now, every time a direct request to that product details page is made, the server will have to make an api call to get the data from the backend, then will render the HTML, and then will serve the page to the client.

This process happens every time a client opens that page.
Now imagine thousands of users opening that product page at the same time. Probably the server will get blown out, and we would need to increase the server resources (also the backend server resources too).

The server will need to do the same work for all the clients, in order to serve them the same page.

How has SSG helped so far?

With static site generation, we were generating each product details page at build time, doing the fetching data part only once, and serving static files to the users.

And let’s say that this helped a lot with the server resources on runtime because we would only serve static files and that’s all.

This was fine until we needed to change product’s details, and do all the work from the beginning. Build the site, generate all the pages, and deploy again. All this is just to change a product’s price. Imagine changing 100 product prices every 1 hour. How many times would we need to do the building, generating and deploying?

This is where ISR comes into play!

ISR combines the ideology of SSR and SSG into one.

With ISR, we render the page on the server the first time it is requested, save it in the cache and serve that cached page to all the other users that request that page.

For cache refreshing, we use time intervals or in-demand regeneration.

ISR is like SSG, but at runtime!

All good? Let’s do this in Angular!

To get started, first we need an application to have Angular Universal installed and configured.

Then, we install the ngx-isr package, a library created by me 😁.

ngx-isr helps you to manage all the ISR stuff with an easy-to-use and extendable API (inspired by Next.js).

npm install ngx-isr

After we install it, we need to do some small configurations.

Create an ISRHandler instance inside server.ts .

import { ISRHandler } from 'ngx-isr';

const isr = new ISRHandler({
  indexHtml, // <-- Is the path to the index.html
  invalidateSecretToken: 'MY_TOKEN', // replace with env secret key
  enableLogging: !environment.production
});

Replace Angular default server-side rendering with ISR rendering.

Replace this:

server.get('*',
  (req, res) => {
    res.render(indexHtml, { req, providers: [{ provide: APP_BASE_HREF, useValue: req.baseUrl }] });
  }
);

with this piece of code :

server.get('*',
  // Serve page if it exists in cache
  async (req, res, next) => await isr.serveFromCache(req, res, next),
  // Server side render the page and add to cache if needed
  async (req, res, next) => await isr.render(req, res, next),
);

Note: ISRHandler provides APP_BASE_HREF by default. And if you want to pass providers into the methods of ISRHandler, you will also have to provide the APP_BASE_HREF token.

Add the invalidation URL handler

server.get(
  "/api/invalidate", 
  async (req, res) => await isr.invalidate(req, res)
);

Add NgxIsrModule in AppServerModule imports

import { NgxIsrModule } from 'ngx-isr'; // <-- Import module

@NgModule({
  imports: [
    ...
    NgxIsrModule  // <-- Use it in module imports
  ]
})
export class AppServerModule {}

When importing the module, NgxIsrService will be initialized and will start to listen to route changes, only on the server-side, so the browser bundle won't contain any extra code.

That was it!

How to use it?

Add the revalidate key in route data and that’s it.

{
  path: "example",
  component: ExampleComponent,
  data: { revalidate: 5 }
}

NOTE: Routes that don’t have the revalidate key in data won’t be handled by ISR. They will fall back to Angular default server-side rendering pipeline.

To regenerate a page we need to make a get request to /revalidate. Like this:

GET /api/invalidate?secret=MY_TOKEN&urlToInvalidate=/example

How it works?

By using the revalidate key in route data we define the time interval
that the ISR Handler will use in order to know when to regenerate a specific route.

Options:

Don’t specify anything: The route won’t be cached and will always be server-rendered. (Like SSR)
0: First serve will be server-rendered and all the other ones will be served from cache. (Like SSG).
More than 0 (ex: 5): First serve will be server-rendered and the cache will be regenerated every 5 seconds (after the last request).

Advanced example

const routes: Routes = [
  {
    path: "one",
    component: PageOneComponent,
  },
  {
    path: "two",
    component: PageTwoComponent,
    data: { revalidate: 5 },
  },
  {
    path: "three",
    component: PageThreeComponent,
    data: { revalidate: 0 },
  }
];

Path one: It won’t be cached and will always be server-rendered before being served to the user.
Path two: The first request will be server-rendered and then will be cached. On the second request, it will be served from the cache that was saved on the first request. The URL will be added to a regeneration queue, in order to re-generate the cache after 5 seconds. On the third request, if the regeneration was finished successfully the user will be served the regenerated page, otherwise, they will be served with the old cached page.
Path three: The first request will be server-rendered and then will be cached. After the first request, all the other ones will be served from the cache. So, the cache will never be refreshed automatically. The only way to refresh the cache is to make a request to /invalidate API route.

Results

Serve the page: npm run dev:ssr.

Open Inspect Element.

And check the Last updated time and date change based on the revalidate key that you provided.

ISR issues?
Every time we change the source code, we have to do the build and deploy again. ISR helps only when data from the backend changes (and that’s okay).

That was it! Thanks for reading this long post!

If you liked it please leave a thumbs up and give a ⭐ to the Github repository.
If the library helps you or your business, you can buy me a coffee if you want 😊.

Configure Prettier and ESLint with Angular

Enea Jahollari — Sat, 19 Feb 2022 19:48:34 +0000

Everyone wants to write code in a fast bug-free way without thinking about its style most of the time. That’s why in this post I will talk about configuring ESLint and Prettier in an Angular project.

How does ESLint help?

By statically analyzing our code, ESLint can find problems and also suggest us fixes for them. And it can do better than that, it can fix our code automatically (who doesn’t want that?).

Install and configure ESLint

In this section, I will explain how to install ESLint in an Angular project and also configure it to better align with the Angular style guide and community standards.

Open the terminal and install ESLint schematics using this command:

ng add @angular-eslint/schematics

That was it. Now we have ESLint installed and also configured thanks to **ng add** command provided by the Angular-ESLint team.
Example error and how ESLint helps to fix it:

We can also run this command in terminal:
ng lint --fix
to fix all the fixable bugs in the project.

Install and configure Prettier

Even if we have ESLint watching our code for bugs, we also need a tool to better style and format it. That’s where Prettier comes into play.

Prettier is an opinionated code formatter that helps us beautify code in a standardized way every time we save the code.

Open terminal and type:
npm install prettier --save-dev
or if you’re using yarn :
yarn add prettier -D

Then we need to add .prettierrc.json and .prettierignore files in our root project directory.

Inside .prettierignore it’s better to add whatever we have inside .gitignore file.

Then we can run this command inside our project to format it:
npx prettier --write .

Inside .prettierrc.json we can change the default settings by overriding them.

The settings I use most of the time are this:

{
  "tabWidth": 2,
  "useTabs": false,
  "singleQuote": true,
  "semi": true,
  "bracketSpacing": true,
  "arrowParens": "avoid",
  "trailingComma": "es5",
  "bracketSameLine": true,
  "printWidth": 80
}

That’s it about Prettier. But we are not finished.

There are times where ESLint and Prettier have different opinions about code formatting and style. That’s why we need to tweak this part. More info here.

Configure Prettier to be used as an ESLint plugin

For ESLint and Prettier to play well together, we need to run Prettier as an ESLint plugin. This way we can just call ng lint --fix and ESLint will fix bugs but also format the code.

Open terminal and type:

npm install prettier-eslint eslint-config-prettier eslint-plugin-prettier — save-dev

or if you're using yarn:

yarn add prettier-eslint eslint-config-prettier eslint-plugin-prettier -D

Now we need to edit the .eslintrc.json file to include the prettier plugin.

{
  "root": true,
  "overrides": [
    {
      "files": ["*.ts"],
      "extends": [
        ...
        "plugin:prettier/recommended"
      ],
    },
    // NOTE: WE ARE NOT APPLYING PRETTIER IN THIS OVERRIDE, ONLY @ANGULAR-ESLINT/TEMPLATE
    {
      "files": ["*.html"],
      "extends": ["plugin:@angular-eslint/template/recommended"],
      "rules": {}
    },
    // NOTE: WE ARE NOT APPLYING @ANGULAR-ESLINT/TEMPLATE IN THIS OVERRIDE, ONLY PRETTIER
    {
      "files": ["*.html"],
      "excludedFiles": ["*inline-template-*.component.html"],
      "extends": ["plugin:prettier/recommended"],
      "rules": {
        // NOTE: WE ARE OVERRIDING THE DEFAULT CONFIG TO ALWAYS SET THE PARSER TO ANGULAR (SEE BELOW)
        "prettier/prettier": ["error", { "parser": "angular" }]
      }
    }
  ]
}

VSCode and Webstorm shortucts

That was it. We’re done with the configuration part.

After we edit a file, we want to format it and then save. That’s what we will configure now for both VS Code and Webstorm.

First make sure you have ESLint and Prettier plugin installed. WebStorm has support of of the box for both.

For VS Code we need to add this lines to settings.json:

{
  "[html]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.codeActionsOnSave": {
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint",
    "editor.codeActionsOnSave": {
      "source.fixAll.eslint": true
    },
    "editor.formatOnSave": false
  },
}

For Webstorm:
We need to check: Run eslint --fix on Actions On Save settings page:

Here you can find the steps summed up: Angular ESLint & Prettier Configuration

How to automate all these configurations?

As you saw, there are a lot of packages that you should install and configure. And I can tell you confidently that there is a way to manage all these automatically. NX is the answer.

What is NX?
NX is the next generation build system with first-class monorepo support and powerful integrations.
If we migrate our Angular app to an Nx monorepo (there is a straightforward migration path) we get all those configurations for free out-of-the-box.
But what makes NX special are some crazy features like computation caching, smart rebuilds, distributed task execution, remote build caching, powerful code generators, editor plugins, etc.

*That was it. Thank you for reading! See you on the next one.
*