DEV Community: Dmitry A. Efimenko

[Boost]

Dmitry A. Efimenko — Wed, 28 Jan 2026 04:26:05 +0000

Angular Skills: Agent Skills for AI-Assisted Development

Brandon Roberts ・ Jan 26

#angular

Angular Animation Magic: Unlock the Power of the View Transition API

Dmitry A. Efimenko — Wed, 30 Apr 2025 13:47:33 +0000

This is a cross-post of my article from www.angularspace.com. If you want to read the original, head there!

🪄 Introduction: A Glimpse of Magic

When I first saw a presentation about the View Transition API, it blew my mind. It is truly magical!

The core idea is that the browser captures a visual snapshot of DOM elements marked with the view-transition-name CSS property before a DOM change. After the DOM change, the differences are animated using CSS Animations.

To truly appreciate its capabilities, take a look at these examples:

Here's a classic code example illustrating how to trigger a view transition:

function handleClick(e) {
  // Fallback for browsers that don't support this API:
  if (!document.startViewTransition) {
    updateTheDOMSomehow();
    return;
  }

  // With a View Transition:
  document.startViewTransition(() => updateTheDOMSomehow());
}

updateTheDOMSomehow? Somehow?? And it will just work? Yep, it will. This highlights the remarkable flexibility of the API.

I won't delve into the fundamentals of the View Transition API in this article. The official documentation provides excellent information if you're not already familiar with it. A basic understanding of Angular components, signals, and CSS is recommended.

🚧 The Angular Challenge: Beyond Route Transitions

Working with the View Transition API in Angular is already possible for navigating between routes. However, animating individual elements on a page is not supported out of the box. How can this gap be bridged?

⚙️ Setting the Stage

Begin by creating a basic Angular component to experiment with:

@Component({
  selector: 'basic-demo',
  styleUrl: './basic-demo.component.scss',
  template: `
    <button (click)="toggle()">Toggle position</button>

    <div class="relative">
      <div class="box" [class]="position()">
        <span>{{ position() }}</span>
      </div>
    </div>
  `,
})
export class ViewTransitionBasicDemoComponent {
  position = signal<'left' | 'right'>('left');

  toggle() {
    this.position.set(this.position() === 'left' ? 'right' : 'left');
  }
}

This component displays a box initially positioned on the left. Clicking the button toggles its visual position between the left and the right, while also displaying the current position within the box. The CSS has been omitted for brevity. Find the complete example on StackBlitz.

Now, attempt to animate the element using the View Transition API.

First, add the following to the application's global styles:

:root {
  view-transition-name: none;
}

This ensures that only elements explicitly marked with view-transition-name will be animated.

According to the View Transition API, two key elements are needed for the animation to work:

The element intended for animation must have the view-transition-name CSS property set with a unique value.
The document.startViewTransition() function needs to be called. The provided callback function should update the DOM.

Applying the CSS property is straightforward:

<div class="box" [class]="position()" style="view-transition-name: box">
  <span>{{ position() }}</span>
</div>

However, the second part presents a challenge in Angular.

A naive attempt might look like this:

toggle() {
  document.startViewTransition(() => {
    this.position.set(this.position() === 'left' ? 'right' : 'left');
  });
}

... and surprisingly, it works! The animation occurs. See it in action on StackBlitz.

You will see why this is rather surprising as we introduce a little bit more complexity to our example and talk more about SPA paradigm on rendering.

Let's add a computed property and another DOM element that would be shown depending on the new computed property:

@Component({
  selector: 'app-root',
  styles: `// omitted for brevity`,
  template: `
    <button (click)="toggle()">Toggle position</button>

    <div class="box-container">
      <div class="box" [class]="position()" style="view-transition-name: box">
        <span>{{ position() }}</span>
      </div>
    </div>

    @if (isCircleVisible()) {
      <div class="circle" style="view-transition-name: circle"></div>
    }
  `,
})
export class App {
  position = signal<'left' | 'right'>('left');

  isCircleVisible = computed(() => this.position() === 'right');

  toggle() {
    document.startViewTransition(() => {
      this.position.set(this.position() === 'left' ? 'right' : 'left');
    });
  }
}

Now, while toggling between "left" and "right", the box still animates, but the circle is not animated despite having view-transition-name CSS property as seen in this StackBlitz example.

🔄 The SPA Paradigm: Data Updates vs. DOM Manipulation

Recall that the startViewTransition function's callback expects a function that updates the DOM:

document.startViewTransition(() => {
  updateTheDOMSomehow();
});

However, in Single Page Applications (SPAs) like Angular, developers typically work with data (state) and rely on the framework to render the DOM in response to data changes. Direct DOM manipulation is generally avoided.

So, the updateTheDOMSomehow() part isn't directly available to a developer working with Angular. Instead, the developer would write the updateTheDataSomehow() function, which doesn't directly align with the View Transition API's requirement.

The animation works for the box in the simpler case likely because Angular is fast enough to synchronize the state change and the DOM update within the execution of the callback function:

document.startViewTransition(() => {
  this.position.set(this.position() === 'left' ? 'right' : 'left');

  // Angular is quick enough to update DOM dependent on `position` here
});

However, the computed property likely schedules a separate render tick that occurs outside the startViewTransition callback. This explains why the circle isn't animated.

Furthermore, the box animation might also become inconsistent. The animation might work when switching from left to right but fail from right to left. Removing the circle-related code might resolve this inconsistency.

The key takeaway is that Angular renders DOM changes at its own pace, influenced by various factors. The data can't simply be updated within the startViewTransition callback with the expectation that the DOM would be ready immediately.

There needs to be a way to ensure the DOM has been updated within that callback:

document.startViewTransition(async () => {
  this.position.set(this.position() === 'left' ? 'right' : 'left');

  await angularUpdatedTheDOM(); // <-- Need to do this
});

🌉 Bridging the Gap between the View Transition API and Angular

To adhere to the Single Responsibility Principle, encapsulate the view-transition-related logic within a dedicated service:

@Injectable({ providedIn: 'root' })
export class ViewTransitionService {
  run(stateChangeFn: () => void) {
    if (!document.startViewTransition) {
      stateChangeFn();
      return;
    }

    document.startViewTransition(async () => {
      stateChangeFn();

      await createRenderPromise(); // <-- TODO
    });
  }
}

Angular provides the afterNextRender function, which is precisely what is needed to create the createRenderPromise function:

function createRenderPromise(injector: Injector) {
  return new Promise<void>((resolve) => {
    afterNextRender({
      read: () => {
        resolve();
      }
    }, { injector });
  });
}

Now, update the component to utilize this new service:

export class App {
  private viewTransitionService = inject(ViewTransitionService);

  position = signal<'left' | 'right'>('left');

  isCircleVisible = computed(() => this.position() === 'right');

  toggle() {
    this.viewTransitionService.run(() => {
      this.position.set(this.position() === 'left' ? 'right' : 'left');
    });
  }
}

With this service in place, all animations should now work as expected. See it running on StackBlitz.

🚦 Handling Concurrent Transitions: A Potential Pitfall

Let's refine our demo slightly. First, slow down all view transition animations to 3 seconds to observe the behavior more clearly:

::view-transition-group(*) {
  animation-duration: 3s;
}

Now, add another element - a triangle - that will be animated somewhat independently:

@if (isTriangleVisible()) {
  <div class="triangle" style="view-transition-name: triangle"></div>
}

For simplicity, update the component to show the triangle after a short delay:

isTriangleVisible = signal<boolean>(false);

toggle() {
  this.viewTransitionService.run(() => {
    this.position.set(this.position() === 'left' ? 'right' : 'left');
  });

  setTimeout(() => {
    this.viewTransitionService.run(() => {
      this.isTriangleVisible.set(!this.isTriangleVisible());
    });
  }, 700);
}

See this implementation on StackBlitz.

Also add some logging to the run method of the ViewTransitionService:

run(stateChangeFn: () => void) {
  // ...

  console.log('start transition');
  document.startViewTransition(async () => {
    console.log('state change');
    stateChangeFn();

    await createRenderPromise(this.injector);
    console.log('rendered');
  });
}

Upon pressing the "toggle" button, an unexpected behavior is observed. The first two elements begin animating, but after 700ms, the animation abruptly stops. The animated elements jump to their final state and then the triangle element starts its animation.

The console output shows:

start transition
state change
rendered
start transition
state change
rendered

This behavior is actually by design. Currently, only one view-transition animation can run at any given time. If a new view-transition is initiated while another is in progress, the ongoing transition is canceled. While there's a proposal for Scoped View Transitions, it's not yet available.

From the service's perspective, adding configuration options to handle this could be considered. For instance, the run method could accept an options argument to define how an incoming animation should behave: (1) cancel the previous animation, (2) be skipped, or (3) wait for the previous animation to complete.

While exploring these implementations could be valuable, there's another crucial scenario that needs to be discussed.

⏱️ A Case For Optimizing the Overlapping Transitions

Let's reduce the timeout for starting the triangle animation from 700ms to 2ms. Now, clicking the "Toggle" button will likely still result in the second animation canceling the first. However, a different console output might be seen:

start transition
start transition
state change
rendered
state change
rendered

The createRenderPromise() method takes a small amount of time to complete, potentially slightly more than 2ms on some systems. This means that both view transitions are being started before Angular has a chance to render the changes from the first state update. This presents an opportunity for optimization. Below is a visualization of the timing of view transitions within the Angular rendering cycle:

Initial Snapshot (Yellow): This occurs when document.startViewTransition is called. It likely involves capturing the initial snapshot of the relevant DOM elements.
State Change and Render (Blue): The view transition callback is executed. Here, the Angular state is updated, which triggers DOM changes. Then the render promise waits for Angular to reflect these changes in the DOM.
Final Snapshot (Yellow): Once the callback completes, the browser takes the final snapshot of the DOM.
Animation (Red): Finally, the browser performs the view transition animation.

In the initial scenario with a 700ms delay, the timeline of the two view transitions looked like this:

However, with the 2ms delay, the timeline looks like this:

As seen above, there is an overlap in the blue blocks where state changes are applied. In this case, a second view transition doesn't need to be initiated. Instead, the second state change should ideally be applied as part of the first view transition since Angular hasn't finished rendering yet:

This might seem like a minor edge case, but it's a critical aspect of effectively handling view transitions in Angular.

To address this, modify the run method in the ViewTransitionService to:

Buffer each incoming stateChangeFn without immediately executing it.
If no view transition is currently active, start one. Within the view transition callback, execute all the buffered stateChangeFn in order.
If a view transition is already in progress:
- if Angular did not complete rendering cycle yet, execute the buffered stateChangeFn functions
- if Angular completed the rendering cycle and View Transition API started the animation, schedule another view transition .run call once the current view transition completes

Use a buffer to ensure that the state change functions aren't lost in case they come after Angular has completed the rendering cycle for the current view transition. This also ensures that state change functions are executed in the order they were received (FIFO).

Find a simplified version of the ViewTransitionService with these changes applied on StackBlitz.

The code for this is becoming quite extensive, so for the remaining examples, I'll primarily provide references to StackBlitz for longer code snippets.

With this updated service, pressing the "Toggle" button should now execute all animations smoothly:

🛠️ Refining the API: Moving Closer to the DOM

While the ViewTransitionService is functional, the developer experience can be further improved. Currently, every time something needs to be animated, the corresponding state change needs to be wrapped within viewTransitionService.run(() => { /* ... */ }). This can lead to scattering rendering logic throughout the application's business logic, making it less maintainable. Ideally, there should be a way to mark elements for view transitions directly within the DOM structure. Something like this:

<ng-container *vt="stateProp">
  <div style="view-transition-name: box;">
    Element to animate - {{stateProp}}
  </div>
</ng-container>

There needs to be a directive that observes changes to the provided stateProp. Right before the state changes, call viewTransitionService.run(() => { /* ... */ }) to allow the View Transition API to capture the "start" snapshot. The callback of the run method would then contain the actual state update.

🤔 The Challenge of Timing: Capturing the "Before" State

This raises the question of how to intercept the moment precisely before the state change is reflected in the DOM. Angular's ngOnChanges lifecycle hook is executed after the property has already changed, making it too late to reliably capture the initial state for the view transition.

Younes Jaaidi has conducted remarkable experiments exploring ways to intervene between the state change and the DOM update in Angular. However, his solution involves monkey-patching private Angular APIs. While his approach would provide a cleaner directive API - our API will opt for a less experimental approach.

The directive will rely on an extra piece of state that will be responsible for modifying the DOM after viewTransitionService.run is invoked.

✨ Introducing the *vt Directive: A Custom Rendering Strategy

Here's a basic implementation of such a directive:

@Directive({
  selector: '[vt]',
  standalone: true,
})
export class ViewTransitionRenderer<T> {
  private viewTransitionService = inject(ViewTransitionService);
  private document = inject<DocumentWithViewTransition>(DOCUMENT);
  private templateRef = inject(TemplateRef);
  private viewContainerRef = inject(ViewContainerRef);
  private cdr = inject(ChangeDetectorRef);

  trackingData = input.required<T>({ alias: 'vt' });

  private context: Context<T> = createContext(null as any);

  ngOnChanges(changes: Changes) {
    const shouldAnimate = !changes.trackingData.firstChange;

    // assign these variables outside of the callback to avoid closure issues
    const firstChange = changes.trackingData.firstChange;
    const currentValue = changes.trackingData.currentValue;

    if (!this.document.startViewTransition || !shouldAnimate) {
      this.render(firstChange, currentValue);

      return;
    }

    this.viewTransitionService.run(() => {
      this.render(firstChange, currentValue);
    });
  }

  private render(isFirstChange: boolean, trackingData: T) {
    this.context.$implicit = trackingData;

    if (isFirstChange) {
      this.viewContainerRef.createEmbeddedView(this.templateRef, this.context);
    }

    this.cdr.detectChanges();
  }
}

interface Context<T> {
  $implicit: T;
}

function createContext<T>(data: T): Context<T> {
  return { $implicit: data };
}

In this directive, the trackingData input holds the value that will be rendered when the view transition is ready to proceed – specifically, within the callback of the viewTransitionService.run method.

Inside the .run callback, the input's value is assigned to the $implicit context of the directive.

The expectation is that the template within the *vt directive will now use the directive's implicit context variable instead of the original state property passed to the directive.

<ng-container *vt="stateProp; let state">
  <div style="view-transition-name: box;">
    Element to animate - {{state}}
  </div>
</ng-container>

Notice the usage of {{state}} instead of {{stateProp}} in the template.

A slightly more convenient syntax can be used by re-assigning the same name as the original property to the $implicit context variable:

<ng-container *vt="stateProp; let stateProp">
  <div style="view-transition-name: box;">
    Element to animate - {{stateProp}}
  </div>
</ng-container>

This approach works, although its suitability as a best practice might be debatable. Thoughts?

With this directive in place, the demo component can be updated to leverage the directive:

@Component({
  selector: 'app-root',
  imports: [ViewTransitionRenderer],
  template: `...`,
})
export class App {
  position = signal<'left' | 'right'>('left');

  isCircleVisible = computed(() => this.position() === 'right');

  isTriangleVisible = signal<boolean>(false);

  toggle() {
    this.position.set(this.position() === 'left' ? 'right' : 'left');

    setTimeout(() => {
      this.isTriangleVisible.set(!this.isTriangleVisible());
    }, 2);
  }
}

Template:

<button (click)="toggle()">Toggle position</button>

<div class="box-container">
  <ng-container *vt="position(); let position">
    <div class="box" [class]="position" style="view-transition-name: box">
      <span>{{ position }}</span>
    </div>
  </ng-container>
</div>

<ng-container *vt="isCircleVisible(); let isCircleVisible">
  @if (isCircleVisible) {
    <div class="circle" style="view-transition-name: circle"></div>
  }
</ng-container>

<ng-container *vt="isTriangleVisible(); let isTriangleVisible">
  @if (isTriangleVisible) {
    <div class="triangle" style="view-transition-name: triangle"></div>
  }
</ng-container>

See this fully implemented on StackBlitz.

Below is a diagram showing the data flow between the consuming component, the *vt directive, the ViewTransitionService and the View Transition API:

🎯 Fine-Grained Control: Enabling View Transitions on Demand

Let's modify the demo to trigger the animation for the triangle element separately:

<button (click)="toggleBox()">Toggle Box</button>

<button (click)="toggleTriangle()">Toggle Triangle</button>

toggleBox() {
  this.position.set(this.position() === 'left' ? 'right' : 'left');
}

toggleTriangle() {
  this.isTriangleVisible.set(!this.isTriangleVisible());
}

Now, open Chrome Dev Tools > Animations, click the "Pause" button, and then click "Toggle Triangle." Navigate to the "Elements" tab and inspect the active view transitions. See something like this:

::view-transition
  ::view-transition-group(box)
  ::view-transition-group(circle)
  ::view-transition-group(triangle)

This indicates that even though only the triangle is intended to be animated, the box and circle are also part of the view transition. While their state might remain unchanged, this can have several drawbacks:

The timing of other animations could influence the view transition timing of the intended element.
Having numerous active animation simultaneously might lead to interference between them.
Debugging animations becomes more complex when all of them are active by default.

A mechanism is needed to selectively enable or disable view transitions based on the intent. This mechanism should be automated as much as possible.

In the current demo, all three elements are always included in the view transition because they always have a view-transition-name CSS property set. To disable a view transition on an element, this property needs to be set to none.

Create another directive that works in conjunction with the *vt directive. This directive will allow the desired view-transition-name value to be specified only when an animation is active:

<ng-container *vt="isTriangleVisible(); let isTriangleVisible">
  @if (isTriangleVisible) {
    <div class="triangle" vtName="triangle"></div>
  }
</ng-container>

By default, this directive will apply the value none to the view-transition-name style. However, when the parent *vt directive initiates a view transition, the vtName directive will apply the specified value. Once the view transition completes, it will revert back to none.

I won't include the full implementation code for this directive here to keep the article concise. If interested in the implementation details - find them on Github.

🧩 Advanced Use Cases: Animating an Item in the Lists and Customizing Transitions

Before concluding, consider another common scenario.

Imagine a list of cards displayed in a column, driven by a for loop. Each card has "up" and "down" buttons to move it within the list:

@Component({
  // ...
})
export class Cards {
  cards = signal<number[]>([0, 1, 2, 3]);

  up(id: number)) {
    this.cards.update(move(id, 'up'));
  }

  down(id: number)) {
    this.elements.update(move(id, 'down'));
  }
}

@for (card of cards(); track card) {
  <div class="card">
    <button (click)="up(card)">Up</button>
    <button (click)="down(card)">Down</button>
  </div>
}

To achieve a basic animation of card movement, wrap the container in the *vt directive and apply the [vtName] directive to each card:

<ng-container *vt="cards(); let cards">
  @for (cardId of cards; track cardId) {
    <div class="card" [vtName]="'card-' + cardId">
      <button (click)="up(cardId)">Up</button>
      <button (click)="down(cardId)">Down</button>
    </div>
  }
</ng-container>

Running this code will produce the expected animation:

However, what if there is a requirement to customize the animation of the specific card that was clicked? That element's view transition can not be easily targeted because all cards have dynamically generated view-transition-name values:

::view-transition-image-pair(???) {
  animation: size-up-and-down ease-in 0.5s;
}

There needs to be a way to dynamically set a custom view-transition-name on the clicked element.

A new property and a method could be introduced in the ViewTransitionService:

activeViewTransitionNames = signal<string[] | null>(null);

setActiveViewTransitionNames(...ids: string[]) {
  this.activeViewTransitionNames.set(ids);
}

This method would be expected to be called right before the view transition starts. Once the transition finishes, the activeViewTransitionNames would be reset:

this.currentViewTransition.finished.finally(() => {
  this.activeViewTransitionNames.set(null);
});

With this in place, a new directive: [vtNameForActive] can be introduced. This directive would check if the activeViewTransitionNames signal contains the name provided to the [vtName] directive on the same element. If it does, it would apply a specific view-transition-name (e.g., 'target-card'):

<div
  class="card"
  [vtName]="'card-' + cardId"
  [vtNameForActive]="'target-card'"
>
</div>

The Cards component would then be updated as follows:

export class Cards {
  private viewTransitionService = inject(ViewTransitionService);

  cards = signal<number[]>([0, 1, 2, 3]);

  up(id: number)) {
    this.viewTransitionService.setActiveViewTransitionNames(`card-${card.id}`);
    this.cards.update(move(id, 'up'));
  }

  down(id: number)) {
    this.viewTransitionService.setActiveViewTransitionNames(`card-${card.id}`);
    this.elements.update(move(id, 'down'));
  }
}

Now, target the clicked element with a specific CSS rule:

::view-transition-image-pair(target-card) {
  animation: size-up-and-down ease-in 0.5s;
}

Again, the implementation details of the [vtNameForActive] directive are omitted for brevity. Find its implementation within the @ngspot/view-transition package on Github.

The full code for making this cards animation can be found here.

📦 Further Abstraction: The @ngspot/view-transition Package

In this article there was a deep dive into challenges of integrating View Transition API with Angular. All the services and directives mentioned here can be found in the @ngspot/view-transition Package.

This package provides several more convenient directives to simplify handling various edge cases. Two notable directives are [vtNameForRouting] and [vtNameForRouterLink], which streamline the use of view transitions during route navigation.

Explore the various demos showcasing the animations made possible in Angular through the View Transition API and the @ngspot/view-transition package.

As a final thought, I encourage the amazing Angular community to try out this package and provide feedback. I'm confident that there are still many undiscovered challenges and edge cases when integrating the View Transition API with Angular. By collaborating on the API and the tools within the @ngspot/view-transition package, we can collectively simplify this powerful integration! 🙌

New in ngx-errors 4.0

Dmitry A. Efimenko — Thu, 16 May 2024 23:21:07 +0000

The @ngspot/ngx-errors library makes it easy to provide validation error messages in apps. The 4.0 release includes 3 large breaking changes:

The library has undergone a large internal implementation rewrite making use of Angular signals and is now expected to be used together with Angular >17.1.
The library moved away from using NgModules. All directives in the library are now standalone. The directives are available in the consuming applications through exported the NGX_ERRORS_DECLARATIONS variable.
The ngxError directive is now expected to be used as a structural directive. This causes a potential breaking change in behavior. In the previous version, the HTML element that the ngxError directive was applied to was always in the DOM. When the error was supposed to be invisible, the hidden attribute was applied to that HTML element. With the new behavior, the DOM associated with the ngxError directive gets completely removed when the error is supposed to be invisible.

Here is an example of using the new version of ngx-errors:

import { NGX_ERRORS_DECLARATIONS } from '@ngspot/ngx-errors';

@Component({
  selector: 'my-component',
  standalone: true,
  imports: [FormsModule, NGX_ERRORS_DECLARATIONS],
  template: `
    <input [(ngModel)]="email" #emailModel="ngModel" required type="email" />

    <div [ngxErrors]="emailModel.control">
      <div *ngxError="'required'">Email is required</div>
    </div>
  `,
})
export class MyComponent implements OnInit {
  email: string;
}

Since the new version of the library does not rely on NgModules, a utility function was introduced to provide library configuration object. The utility function can be used either at the application level or at the component level:

import { provideNgxErrorsConfig } from '@ngspot/ngx-errors';

bootstrapApplication(AppComponent, {
  providers: [
    provideNgxErrorsConfig({
      showErrorsWhenInput: 'dirty',
      showMaxErrors: 1,
    })
  ]
});

For more info and usage examples, see the README file. See the demo here.

The @ngspot/ngx-errors-material 4.0 package has undergone a similar set of changes. The directives are now standalone and are available through the NGX_ERRORS_MATERIAL_DECLARATIONS variable. These declarations include declarations from NGX_ERRORS_DECLARATIONS so no need to import these separately.

The new release also includes one major feature. When using the ngxError directive inside of the <mat-form-field> component, there is no need to include a parent ngxErrors directive. The <mat-form-field> component serves the purpose of ngxErrors directive.

See the example below:

import { NGX_ERRORS_MATERIAL_DECLARATIONS } from '@ngspot/ngx-errors-material';

@Component({
  selector: 'my-component',
  standalone: true,
  imports: [
    ReactiveFormsModule,
    MatInputModule,
    NGX_ERRORS_MATERIAL_DECLARATIONS,
  ],
  template: `
    <form [formGroup]="form">
      <mat-form-field>
        <mat-label>Name</mat-label>

        <input matInput formControlName="name" />

        <mat-error *ngxError="'required'">Name is required</mat-error>
      </mat-form-field>
    </form>
  `
})
export class MyComponent {
  private fb = inject(FormBuilder);

  form = this.fb.group({
    name: this.fb.control('', { validators: [Validators.required] }),
  });
}

See the demo here.

Happy programming!

👏 Special thanks to @anaboca for reviewing this article.

Accessing directives located in child components in Angular

Dmitry A. Efimenko — Mon, 16 Oct 2023 16:14:42 +0000

📜 Scenario

In my application I had a directive that would track unsaved changes in a template-driven form. I won't bother you with the implementation of this directive, but its interface was as follows:

@Directive({
  selector: 'form[appUnsavedChangesTracker]',
  standalone: true,
  exportAs: 'unsavedChangesTracker',
})
export class UnsavedChangesTrackerDirective<T = any> {
  isDirty$: Observable<Boolean>;

  setInitialValue(value: T): void;
}

There were two components. First, the smart component, which would provide data:

@Component({
  selector: `app-smart-component`,
  standalone: true,
  imports: [FormComponent],
  template: `
    <app-form-component
      [formModel]="formModel$ | async"
      (save)="saveData($event)"
    >
    </app-form-component>
  `
})
export class SmartComponent {
  apiService = inject(ApiService);

  formModel$ = this.apiService.getData();

  saveData(data: FormModel) {
    this.apiService.save(data).pipe(
      // when data saved successfully we need to access the
      // UnsavedChangesTrackerDirective and call setInitialValue method
    ).subscribe();
  }
}

Second, a dumb component containing the form:

@Component({
  selector: `app-form-component`,
  standalone: true,
  imports: [FormsModule, UnsavedChangesTrackerDirective],
  template: `
    <form appUnsavedChangesTracker (ngSubmit)="saveForm()">
      <input [ngModel]="formModel.name" name="name" />

      // other input controls removed for brievety

      <button type="submit">Save</button>
    </form>
  `
})
export class FormComponent {
  @Input() formModel: FormModel;

  @Output() save = new EventEmitter<FormModel>();

  @ViewChild(NgForm) ngForm: NgForm;

  saveForm() {
    if (this.ngForm.valid) {
      this.save.emit(this.ngForm.value);
    }
  }
}

If you'd like to learn more about the Smart/Dumb component approach, watch this video by Joshua Morony.

Here we encounter a problem: the UnsavedChangesTrackerDirective is attached to the <form>, which is located in a child component. However, the parent smart component needs to access the UnsavedChangesTrackerDirective to update the initial form value when data is saved to the server.

We can't simply query for the UnsavedChangesTrackerDirective directive via @ViewChild() since it's not located in the view of the parent component. We need another way.

💡 Initial solution

There is a saying coined in a story by Francis Bacon:

If the mountain will not come to Muhammad, then Muhammad must go to the mountain

A reference to the directive located in the child component cannot be injected from the parent. However, a directive located in the child component can inject anything up the injection tree. So, we could:

Create a dedicated service provided somewhere higher in the injection tree, for example, at the level of the parent component.
Inject that new service into the directive located in the child component.
Then the directive could "register" itself within the injected service.

So, here's the service where the directive will "register" itself:

@Injectable()
export class UnsavedChangesTrackerService {
  private tracker$$ = new BehaviorSubject<UnsavedChangesTrackerDirective | undefined>(undefined);
  tracker$ = this.tracker$$.asObservable();

  setTracker(tracker: UnsavedChangesTrackerDirective) {
    this.tracker$$.next(tracker);
  }
}

Now the directive can inject the service and "register" itself:

export class UnsavedChangesTrackerDirective<T = any> {
  service = inject(UnsavedChangesTrackerService, { optional: true })

  constructor() {
    if (this.service) {
      this.service.setTracker(this);
    }
  }

  // rest of the functionality is removed for brievety
}

Notice how we used a BehaviorSubject inside the service and "nexted" the instance of the directive into it. The reason for this is that the parent component, along with the provided service, will instantiate first, and the child component will instantiate later. Consequently, there will be a brief moment when the reference to the directive will be undefined. Whether or not this is a problem for you depends on when the tracker directive is being accessed. Using a BehaviorSubject eliminates this issue.

Now, we can update the parent smart component to provide the UnsavedChangesTrackerService and use the referenced directive from it:

@Component({
  selector: `app-smart-component`,
  standalone: true,
  imports: [CommonModule, FormComponent],
  providers: [UnsavedChangesTrackerService],
  template: `
    <app-form-component
      [formModel]="formModel$ | async"
      (save)="saveData($event)"
    >
    </app-form-component>
  `
})
export class SmartComponent {
  apiService = inject(ApiService);
  unsavedChangesTrackerService = inject(UnsavedChangesTrackerService);

  formModel$ = this.apiService.getData();

  saveData(data: FormModel) {
    this.apiService.save(data).pipe(
      // when data saved successfully we need to access the
      // UnsavedChangesTrackerDirective and call setInitialValue method
      withLatestFrom(this.unsavedChangesTrackerService.tracker$),
      tap(([_, tracker]) => {
        tracker.setInitialValue(data);
      })
    ).subscribe();
  }
}

⚡ Reusable solution

In the previous example, we figured out how to access a directive used in a child component from a parent component. We achieved this by using a service to register a reference to the directive. This was possible because we had access to the directive's code and could customize it according to our needs. But what if we don't own the directive that we need access?

In such cases, we can still employ a similar approach, but we must make the service more generic so that it can register any type of directive.

@Injectable()
export class RefTrackerService<T> {
  private ref$$ = new BehaviorSubject<T | undefined>(undefined);
  ref$ = this.ref$$.asObservable();

  private definedRef$ = this.ref$.pipe(
    filter((x): x is T => x != null)
  );

  setRef(ref: T) {
    this.ref$$.next(ref);
  }

  withDefinedRef<Source>(): OperatorFunction<Source, [Source, T]> {
    return (source$) =>
      source$.pipe(
        switchMap((val) => {
          return this.definedRef$.pipe(map((ref) => [val, ref] as [Source, T]));
        })
      );
  }
}

There are a few additional features in this version compared to the one we saw earlier, especially the withDefinedRef function. This function is quite similar to the built-in RxJS withLatestFrom function, but don't worry about it for now. There will be an example of how it's used later.

Now that we have a service, we need a method to set the reference to any directive in that service. Angular provides a standard way to access references to directives or components from the template. In our case, we'll want to write something like this:

<form
  unsavedChangesTracker
  #ref="unsavedChangesTracker"
  [trackRef]="ref"
  (ngSubmit)="saveForm()"
>
  <input [ngModel]="formModel.name" name="name" />

  <!-- other input controls removed for brievety -->

  <button type="submit">Save</button>
</form>

Notice the #ref variable. We're defining a variable called "ref" which will contain an instance of UnsavedChangesTrackerDirective.

Also, observe the [trackRef]="ref". We'll create a custom directive that allows us to save that "ref" variable in the RefTrackerService. Here's the "trackRef" directive:

@Directive({
  selector: '[trackRef]',
  standalone: true,
})
export class TrackRefDirective<T = unknown> {
  private refTrackerService = inject(RefTrackerService);

  @Input({ required: true }) trackRef!: T;

  ngOnInit() {
    this.refTrackerService.setRef(this.trackRef);
  }
}

Now the parent component can be updated like so:

@Component({
  selector: 'app-smart-component',
  standalone: true,
  imports: [CommonModule, FormComponent],
  providers: [RefTrackerService],
  template: `
  <ng-container *ngIf="formModel$ | async as formModel">
    <app-form-component
      [formModel]="formModel"
      (save)="saveData($event)"
    >
    </app-form-component>
  </ng-container>
  `,
})
export class SmartComponent {
  apiService = inject(ApiService);
  refTrackerService = inject(RefTrackerService<UnsavedChangesTrackerDirective>)

  formModel$ = this.apiService.getData();

  saveData(data: FormModel) {
    this.apiService.saveData(data).pipe(
      this.refTrackerService.withDefinedRef(),
      tap(([_, unsavedChangesTrackerDirective]) => {
        unsavedChangesTrackerDirective.setInitialValue(data);
      })
    ).subscribe();
  }
}

The final working code can be found on StackBlitz.

️⚙️ A note on the architecture

There's something I don't quite like about the code example above - the saveData() method and everything within it.

The component contains logic for saving data, which makes the component much "smarter" than it needs to be, and this will make it harder to unit-test.
Additionally, there is some imperative code in the subscribe() call.

To understand why I believe these are problematic areas, please read my next article: "Dumb Components Are Overrated" (coming soon).

Going from Jest to Karma/Jasmine in an NX monorepo

Dmitry A. Efimenko — Mon, 20 Mar 2023 12:01:36 +0000

🤔 I honestly don’t understand the hype around Jest.

People often cite the following for switching from Karma/Jasmine to Jest:

#1 Jest has better performance

#2 Jest is easier to configure

#3 Jest has easier CI/CD integration

#4 Jest has a nicer reporting format

Here’s what I think about each of these bullet points:

#1 Jest has better performance

There is some merit to this statement. Jest does NOT run unit tests in a browser. Therefore Jest does not have to spend time starting a browser, which takes a few seconds. Unit tests might be faster because they run in this “mocked” browser environment.

There are also random claims without any proof around the internet that Jest is 2 to 3 times faster than Jasmine. Maybe. Although there’s this open issue on Jest with a ton of upvotes (at the moment of writing this blog): “Jest performance is at best 2x slower than Jasmine, in our case 7x slower”. So…

#2 Jest is easier to configure

Again, maybe. I haven’t personally run into any issues configuring a project to use Karma. Usually, the tooling (NX or Angular/CLI) does the whole job! Then modifying the configuration is a piece of cake — as I’ll show toward the end of the article.

#3 Jest has easier CI/CD integration

This is a matter of configuration. All that is needed is to provide a configuration to run the unit tests in CI/CD via a headless browser. It’s really not difficult, especially with the countless resources online showing how to.

#4 Jest has a nicer reporting format

This is, again, a matter of configuration. Don’t like the default reporter that comes out of the box for an Angular project? No problem, use a different one! I’ll show what I do for each of my projects in the section “ Configuring Karma Reporter ” below.

👍 Why I like Karma/Jasmine

I really don’t want to make this article into a “Jest vs Karma/Jasmine” thing. Like Jest? Fine! Use it! And no need to continue reading this!

Personally, I like Karma/Jasmine. Here are a couple of reasons why:

Confidence

In my opinion, even if Jest was faster than Jasmine, I do not think that is reason enough to switch to Jest.

In contrast to Jest, Karma runs unit tests in the real browser — the same environment where the project that was built will run. This ensures that the unit tests run the code in the real environment. Thus, a developer gains better confidence in the quality of the code. This is worth a lot!

Stability

I have recently run into an issue related to Jest, which causes the unit tests to error out. This completely blocked me and was the tipping point for me to convert my project to Karma/Jasmine and write this article.

Without further ado, here are the steps I took to do the conversion.

➡️ Converting Jest to Karma/Jasmine

I created two separate NX workspaces.
I added an Angular library to both of them. However, one was configured to have Jest as a test runner and another one had a Karma/Jasmine test runner.
Then I looked at the differences and applied them to my project!

Here are all the files that got changed for one project:

Uninstall Jest-related dependencies from the project

npm uninstall @nrwl/jest @types/jest jest jest-environment-jsdom jest-preset-angular ts-jest

Install Karma/Jasmine dependencies

npm install -D @types/jasmine@4.0.0 jasmine-core@4.2.0 jasmine-spec-reporter@7.0.0 karma@6.4.0 karma-chrome-launcher@3.1.0 karma-coverage@2.2.0 karma-jasmine@5.1.0 karma-jasmine-html-reporter@2.0.0

Notice, that I’m installing specific versions of the packages. I need to make sure that all of these packages are compatible with each other. I know that these packages are the right versions because these were the versions installed by Nx. Let the other folks figure out the right version combination 😉.

Adjust files in the root directory

nx.json — update unitTestRunner to “karma” and point things to “karma.conf.js” instead of jest.config.js

karma.conf.js — a new file copied from the fresh NX workspace

Adjust files in each individual project

/projects/myProject/jest.config.ts — removed

/projects/myProject/src/test-setup.ts — removed

/projects/myProject/karma.conf.js — copied from the fresh NX workspace

/projects/myProject/project.json — update targets.test.executor to be @angular-devkit/build-angular:karma and update related options (copy from fresh NX workspace and update paths)

tsconfig.lib.json — update the exclude property (copy from fresh NX workspace)

tsconfig.lib.prod.json — modify this file if your project is publishable. Remove exclude property.

tsconfig.spec.json — remove files and compilerOptions.module properties. Adjust compilerOptions.types property.

All-in-all — not that many changes. Somebody should write a schematic to do this automatically though😁.

At this point, the configuration is exactly the same as in a fresh Nx workspace. Now, time to improve!

⚙️ Configuring the Karma Reporter

In this section, it will be apparent to see how easy it is to work with the Karma configuration and how to improve the reporter.

By default, Karma is configured to use two reporters: ['progress', 'kjhtml'] .

The kjhtml reporter is the reporter used in the browser. I usually remove it. I also switch the chrome browser option to ChromeHeadless option so that the browser window does not open altogether.

The process reporter is the default reporter used in the terminal. I don’t quite like how it prints out things. I usually switch it out to the karma-mocha-reporter .

Install the mocha reporter

npm i -D karma-mocha-reporter

Update the karma.config.js

That’s it!

📖 Summary

I mostly wrote this article for my own sake — in case I’ll need to do this again in the future. But I hope it’ll help fellow programmers who face similar dilemmas too.

👏 Special thanks to Ana Boca for reviewing this article!

Have a Day at the Spa working on Your SPA with Remote Data

Dmitry A. Efimenko — Wed, 20 Jul 2022 07:51:15 +0000

📑 TLDR:

Use the RemoteData data structure from the @ngspot/remote-data library to describe data being requested from an API.
Use RxJS and a custom operator trackRemoteData from the @ngspot/remote-data-rx library for best results.

Have you ever written a component or a service where an HTTP call is made to request some data from an API and display it to the user? That’s mostly a rhetorical question — most applications do that. There are common scenarios that need to be addressed when dealing with remote data.

🤔 Naive Approach Example

Many times, I’ve written components and services where HTTP calls are made to request some data. Previously, my approach used an imperative style of coding (before I learned the magical power of data streams).

Although there are many issues with the code above (like manually subscribing, not using OnPush change detection, not using trackBy for the ngFor loop, a bug due to a potential racing condition, etc.), the code above works. Please ignore the imperfections for the time being. Most of them will be taken care of by the end of the article and the rest are omitted for simplicity.

Next, I realized that the call to the API takes time and I need to display some loading template while the data is loading. So I added theisLoading property to keep track of that!

Simple enough! But wait, what if the API returns an error? I want to display something to the user in this circumstance. I know how to handle this! So I introduced another property: error!

Ufff, three properties to keep track of all the possible state options and a whole bunch of code to maintain these three properties?! And that’s just for one API call. What if there are multiple API calls?? What I have does not have all possible states either. There’s one more — a case when data has not been requested yet.

In the example above, data gets loaded automatically when the component initializes, but that could be different. What if you want to display a prompt to the user with some instructions for the case when data has not yet been requested? That is a lot of spaghetti code!

💡 RemoteData to the Rescue!

The spaghetti code of handling all the possible states can be solved with a data structure that encapsulates all these possible cases:

You can get better type safety if you create a dedicated type for each of the states and then use a TypeScript union feature.

Now, I will create a few builder functions that return the RemoteData for each possible state of the request (1) not asked, (2) loading, (3) success, and (4) error.

With all of this in place, here is the rewritten component:

This is much cleaner! Only one property to maintain and this property handles all use-cases. The @ngspot/remote-data library has essentially been rebuilt. Feel free to use it!

But I can do better! Read on.

💪 Using the power of RxJS

Remember the numerous issues mentioned at the beginning of the article?

Among them is a bug related to a racing condition. If a user presses the button “Load products” many times quickly, then many requests will be fired up. The chances are, that due to the timing of the network, the responses for these requests will be returned out of order. The response for the request associated with the very first click could end up coming back last. This means that the UI might not display the freshest data.

RxJS is perfect for handling asynchronous data streams. It has mechanisms for dealing with this sort of situation. In addition, it makes it easy to use OnPush change detection, which improves the performance of your application and can improve the general quality of your components.

Without further ado, here is the rewritten component using reactive streams and the RemoteData data structure.

This solution is much more robust. There are no manual subscriptions. Data is propagated to the template via reactive streams with theasync pipe, which allows the use of OnPush change detection. Finally, race conditions are handled via the switchMap operator, which automatically cancels any previous requests in flight and starts a new one.

RxJS allows building a custom operator using multiple existing operators. That’s what I had done with the example above — I took the operators used to handle the RemoteData loading, success, and error cases and extracted these operators into a custom operator called trackRemoteData. Find the trackRemoteDataoperator under @ngspot/remote-data-rx library. There are a couple more bells and whistles built-in.

With that, the code becomes even simpler.

🧡 Credit Where Credit is Due

There are similar solutions for handling remote data out there. I have tried most of them, but none provided me with the exact feature-set I wanted. Here are a few of them:

Where it all began: “How Elm Slays a UI Antipattern”
https://www.npmjs.com/package/ngx-remotedata
https://github.com/daiscog/ngx-http-request-state

Nonetheless, these solutions inspired me to create the two libraries that I now use in most of my projects. I hope you find them helpful too.

I wish you happy programming!

👏 Special thanks to Ana Boca for reviewing this article.

What’s new in ngspot/ngx-errors 3.1.3?

Dmitry A. Efimenko — Fri, 14 Jan 2022 09:31:19 +0000

🚀 Feature 1: integration with @angular/material

@ngspot/ngx-errors is a library that makes it easy to provide validation error messages in apps. The 3.1.3 release takes this functionality a step further for applications that use @angular/material.

Let's say that there is an application where the errors are configured to only show to the users when the form is submitted:

… and there is a component that uses a FormGroup inside of a template that has an Angular Material input within the form field with corresponding validation error:

Everything is straightforward, however, if the user types something in the input and clicks away, the input gets highlighted red, but the error message isn’t shown!

It makes sense that the error message isn’t shown — the application was configured to show errors only when the form is submitted. So why is input getting highlighted prematurely? Turns out, Material Inputs has its own logic that determines when inputs are in an error state. By default, the input enters an error state when it’s “touched”. This is lucky because ngx-errors has the same default, but the moment the developer wants to customize behavior, things get out of sync.

Version 3.1.3 synchronizes the input error state with the errors actually shown to the user. The input will only get highlighted if there are errors shown to the user.

🚀Feature 2: Custom error state matchers

The @angular/material team has done a great job designing the API for errorStateMatcher. This API has the ability to provide a global errorStateMatcher or override it via an @Input at the level giving the developer a good amount of flexibility.

@ngspot/ngxerrors also provides flexibility to the developer since it is possible to provide a global configuration for when to show the errors as well as override it at lower levels — in the component templates where ngxErrors and ngxError directives are used. Here’s an example of this functionality from the docs:

The showWhen input would allow the developer to override the default configuration. However, in the previous versions, the developer could only use set values for the showWhen input: 'touched' 'dirty' 'touchedAndDirty' and 'formIsSubmitted' .

With the release of version 3.1.3, the developer can now provide their configurations. See the docs for more info.

🚀Feature 3: new config option — showMaxErrors

Finally, the icing on the cake — a new configuration option that enables developers to configure how many total errors are allowed to be displayed per the ngxErrors block at the same time.

Imagine that the form control has multiple validation rules associated with it — a pretty common scenario. Here’s how the template would look:

It is possible that these validation rules would be invalid at the same time, in which case, all error messages would be displayed to the user:

This by itself does not sound like the end of the world. However, it gets ugly real fast if another input is added below the first one:

The problem has to do with the implementation of the current styles. There’s been an open issue about it since 2017! And that’s why open source is great— people have been coming up with great workarounds for this issue. A developer could choose any of these or use the showMaxErrors configuration option of @ngspot/ngx-errors to only display one error at a time. This might be a good option if you’d like to ease the cognitive load on your users.

I wish you happy programming!

👏 Special thanks to Ana Boca for reviewing, testing, and providing some of the code for this article.

Declarative Route Path Management in Angular Apps — Even Better Than Best Route Forward

Dmitry A. Efimenko — Wed, 07 Jul 2021 06:49:25 +0000

Declarative Route Path Management in Angular Apps — Even Better Than Best Route Forward

When I read Netanel Basal's article — “Best Route Forward — Declarative Route Path Management in Angular Apps”— I wanted to try out the solution to route path management described in the article right away in the apps I work on. The solution in Netanel’s article is intended to help with managing routes in large Angular apps. The idea is great! However, I quickly discovered that the solution does not quite work for the apps that have many feature modules with their own routes — i.e large apps. If these feature modules have their own lazy feature modules with their own routes, a single service class really does not cut it. Let me demonstrate what I mean using a simplified example.

Here is an AppModule with the following routes:

There are two lazy modules for routes “products” and “customers”. The Products module contains a feature module as well. Here are the associated feature route declarations:

Products routes:

EditModule routes:

A class with methods, like in Netanel’s article, works great for a flat route structure:

But what can be done with the routes for the lazy feature module? Below are three naive options that come to mind.

🤔 Naive Option #1

Create methods only at the top-level disregarding the nested nature of routes:

Here’s how it would be used:

This approach has some clear downsides:

The methods for a feature module are managed within the same class.
The method names are long and repetitive.
Each child route explicitly specifies the parent /products path.
This will get really ugly for child routes of the edit feature module.

🤔 Naive Option #2

Have the products method return an object to attempt to represent the nested nature of routes:

Now, something like this can be typed:

This feels a bit better, but there are still a few downsides:

The methods for a feature module are managed within the same class.
The root products route is lost.
Each child route explicitly specifies the parent /products path.

🤔 Naive Option #3

Create a separate class for products routes:

This approach also lets the route be used like so:

Now, the ability to manage child routes in separate files is gained, but the ability to use Angular’s dependency injection has been lost! The following downsides still exist:

The root products route is lost (could add a method root()?).
The explicit use of this.parentPath does not feel DRY.
the parentPath needs knowledge of where it is in the hierarchy of lazy feature routes. Otherwise resulting URL will be wrong.

💪 RoutePathBuilder

Long story short, I decided to create a solution that will keep all the benefits of Netanal’s solution and add the features I was looking for:

Original features

A single source of truth for each path in the application
Strong typings
Access to Angular’s dependency injection
Use of absolute links (meaning, the generated link is absolute)

New features:

Managing routes of feature modules via separate classes
Use of property chaining to reflect the nested nature of the routes
No explicit use of parentPath in method implementations. Use of relative URL parts for the assembly of the URLs.
Flexible return type: to access either a url, a urlTree (useful for RouteGuards), or seamlessly navigate() to the desired route
A utility function to simplify the use of the this.route.createUrlTree(commands) method

Say hello to @ngspot/route-path-builder.

The @ngspot/route-path-builder library consists of a single abstract class — RoutePathBuilder. Here is how the new library will describe the routes using the hypothetical example from above.

With this setup, inject the AppRoutes anywhere in the app and use it!

The url and urlFromCommands methods return an instance of the AppUrl class. This class has the url and urlTree properties and a navigate() method. With this in mind, here’s how the AppRoutes service can be used:

Here’s how AppRoutes can be used in a route resolver:

The RoutePathBuilder provides a root() method that returns the AppUrl for the root path of a given feature module. For example:

The RoutePathBuilder also exposes two protected properties — router and injector. The router is there as a convenient way to access the router in case it is needed without having to inject an extra service in the component or service. The injector is also there to avoid providing dependencies in the constructor. For example:

Of course, dependencies can also be provided in the constructor, but in that case, Injector needs to be added to the dependencies and super(injector) added the to the body of the constructor.

Notice the use of { providedIn: 'any' } for the services that extend RoutePathBuilder. This means that a separate instance of that service will be created for each lazy feature module of the app. This is important because the injector should be the reference to the injector of that lazy module, not the injector of the root module. This way, accessing a service declared in the lazy feature module will not fail.

I hope you find the @ngspot/route-path-builder library helpful. I wish you happy navigating!

👏 Special thanks to Ana Boca for reviewing, testing, and providing some of the code for this article.

🚀 In Case You Missed It

@ngspot has more goodies! For example, ngx-errors — an Angular-endorsed library for displaying validation messages in forms. More will be coming soon!

Follow me on Mediumor Twitterto read more about Angular and JS!

Lost in Translation… Strings

Dmitry A. Efimenko — Wed, 21 Aug 2019 08:42:48 +0000

i18n for Server-Side Rendered Angular applications

AngularInDepth is moving away from Medium. More recent articles are hosted on the new platform inDepth.dev . Thanks for being part of indepth movement!

🤔 The Background

What does i18n stand for and why is there an “18” in the middle? Even as an engineer with more than ten years of experience in the field I had no idea until I looked it up. It’s the number of letters between “i” and “n” in the word “internationalization.” So, i18n is internationalization. Pretty neat. One of the definitions of i18n is:

The design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.

By following the i18n definition link above, we can see that there are multiple areas of development that i18n touches on. However, the area we’ll concentrate on in this article is:

Separating localizable elements from source code or content, such that localized alternatives can be loaded or selected based on the user’s international preferences as needed.

In essence, whatever should be displayed in different languages needs to be separated out from the meat of the code to enable its maintainability.

In the article, we will explore how to implement our translation strings in a maintainable manner, enable the application to load only necessary resources, and allow browser memorization of the selected language. Then we will enable Server-Side Rendering (SSR) and solve issues encountered during enabling SSR in the Angular application.

The article is split up in the following parts:

Part 1. Setting the Scene

Part 2. Adding SSR to the App

Part 3. Solution 1 — Fix via Providing a Separate I18nModule for the Server

Part 4. Solution 2 — Provide Everything in a Single Module

Part 5. Improve Performance with TransferState

Part 6. Are We There Yet?

In the first part of this article, we will follow simple instructions for setting up an Angular application and adding i18n capabilities to it. Beginner-level developers may want to take a deep dive into Part 1. More advanced developers may glance at the code in the following sections and proceed to “Part 2. Adding SSR to the App” to find out what obstacles adding SSR will create and how to solve them.

📝 Part 1 of 6: Setting the Scene

For the purposes of this article, we’ll work with a bare-bones Angular application generated with AngularCLI. To follow along with the article, we will generate an app using the command (assuming the Angular CLI installed globally):

ng new ssr-with-i18n

For the sake of the example let’s add a couple of components:

ng g c comp-a
ng g c comp-b

Now, we will replace the contents of app.component.html with these two components:

*** The code up to this point is available here.

🗺️ Let’s Add i18n

As with most things in coding, there are many ways to skin a cat. Originally, I wanted to use the framework-independent library i18next with an Angular wrapper: angular-i18next. However, there is currently an unfortunate limitation with angular-i18next: it’s not capable of switching language on the fly, which is a show-stopper for me.

In this article, we’ll use a popular library: ngx-translate.

Note : The concepts of organizing modules and code described in this article do not apply just to ngx-translate. An application can use the new and shiny transloco library, which was released the date of writing this article (8/15/2019). The reader might even be trying to solve an issue that has nothing to do with translations. Therefore, this article is helpful for anybody who’s trying to solve a SSR related issue.

Using ngx-translate will allow us to store our strings in separate JSON files (a file per language) where each string will be represented by a key-value pair. The key is a string identifier and the value is the translation of the string.

Install dependencies

In addition to the core library, we’ll install the http-loader library which will enable loading translations on-demand.

npm install @ngx-translate/core @ngx-translate/http-loader --save

2. Add the code

The directions for the ngx-translate package suggest adding relevant code directly to the AppModule. However, I think we can do better. Let’s create a separate module that will encapsulate i18n related logic.

ng g m i18n --module app

This will add a new file: /i18n/i18n.module.ts and reference it in the app.module.ts.

Modify the i18n.module.ts file according to the documentation. The full code file is below:

Nothing fancy is going on. We just added the TranslateModule and configured it to use the HttpClient to load translations. We exported TranslateModule as well to make the pipe transform available in the AppModule and in HTML templates. In the constructor, we specified available languages and used a function provided by ngx-translate to get and use the browser’s default language.

By default, the TranslateHttpLoader will load translations from the /assets/i18n/ folder, so let’s add a couple of files there.

/assets/i18n/en.json

{
  "compA": "Component A works",
  "compB": "Component B works"
}

/assets/i18n/ru.json

{
  "compA": "Компонент А работает",
  "compB": "Компонент Б работает"
}

Note: we are using a single file per language. In more complex applications there’s nothing limiting us from creating files based on locale, e.g. en-US.json, en-Gb.json. These will be treated essentially as separate translations.

With this configuration, we should be able to update our component templates to use the translation strings instead of hard-coded text.

// comp-a.component.html
<p>{{'compA' | translate}}</p>

// comp-b.component.html
<p>{{'compB' | translate}}</p>

Run the application and notice that it’s using the translations from the en.json file. Let’s add a component that will let us switch between the two languages.

ng g c select-language --inlineStyle --inlineTemplate

Update the contents of the select-language.component.ts file.

The ngx-translate library allows us to switch languages via a simple translate.use() API call. It also allows us to determine the currently selected language by querying the translate.currentLang property.

Insert the new component in the app.component.html file after the h1 tag.

Run the application and see that the language can now be switched on the fly. Selecting a different language will request the appropriate .json file.

Now, if we select the language ru and refresh the browser, we’ll see that the page still loads with the language en selected. The browser does not have a mechanism for remembering the selected language. Let’s fix that.

🙄 Memorizing the Selected Language

The Angular community has made many plugins enhancing the functionality of the ngx-translate package. One of them is exactly what we need — ngx-translate-cache. By following instructions, we’ll (1) install the package

npm install ngx-translate-cache --save

and (2) use it inside of the I18nModule.

Now, if we select the language ru and refresh the browser we’ll see that it remembered our choice. Notice, that we selected 'Cookie' as a place to store the selected language. The default selection for this option is 'LocalStorage' . However, LocalStorage is not accessible on the server. A big part of this article has to do with enabling SSR, so we’re being a little bit proactive here and storing the language selection in the place where a server can read it.

Up until now there really was nothing special about this article. We simply followed instructions posted in relevant packages and encapsulated the i18n related logic in a separate module. Adding SSR has some tricky parts, so let’s take a closer look.

*** The code up to this point is available here.

💪 Part 2 of 6: Adding SSR to the App

Angular CLI is amazing! In particular, its schematics feature allows us to add new capabilities to the app using a simple command. In this case, we’ll run the following command to add SSR capabilities.

ng add [@nguniversal/express-engine](http://twitter.com/nguniversal/express-engine) --clientProject ssr-with-i18n

Running this command updated and added a few files.

files added/changed after ng add command

If we look at the package.json file, we’ll see that now we have a few new scripts that we can execute. The two most important are: (1) build:ssr and (2) serve:ssr . Let’s run these commands and see what happens.

Both commands run successfully. However, when we load the website in the browser, we get an error.

TypeError: Cannot read property 'match' of undefined
    at new I18nModule (C:\Source\Random\ssr-with-i18n\dist\server\main.js:113153:35)

A little bit of investigation reveals that the failing code is:

browserLang.match(/en|ru/)

The browserLang variable is undefined, which means that the following line of code didn’t work:

const browserLang = translateCacheService.getCachedLanguage() || translate.getBrowserLang();

This happens because we’re trying to access browser-specific APIs during the server-side rendering. Even the name of the function — getBrowserLang suggests that this function won’t work on the server. We’ll come back to this issue, but for the time being, let’s patch it by hard-coding the value of the browserLang variable:

const browserLang = 'en';

Build and serve the application again. This time there is no error. In fact, if we look at the network tab of the Developer Tools we’ll see that SSR worked! However, the translations didn’t come through.

Let’s see why this is happening. Notice the factory function used in the TranslateModule to load translations: translateLoaderFactory . This function makes use of the HttpClient and knows how to load the JSON files containing translations from the browser. However, the factory function is not smart enough to know how to load these files while in the server environment.

This brings us to the two issues we need to solve:

PROBLEM 1. Being able to determine the correct language to load in both the client and the server environments (instead of hard-coding the value to en ).

PROBLEM 2. Based on the environment, use the appropriate mechanism to load the JSON file containing translations.

Now that the issues are identified, let’s examine different ways to solve these issues.

🤔 Evaluating Existing Options

There are a few ways that we can make everything work. There is a closed issue in the ngx-translate repository related to enabling SSR — issue #754. A few solutions to PROBLEMS 1 and 2 can be found there.

Existing Solution 1. Fix via HttpInterceptor

One of the latest comments on issue #754 suggests using a solution found in the article “Angular Universal: How to add multi language support?" to address the PROBLEM 2. Unfortunately, PROBLEM 1 is not addressed in the article. The author suggests a fix using the HttpInterceptor, which patches the requests to retrieve the JSON files while on the server.

Even though the solution works, it feels a bit awkward to me to create an interceptor that will patch the path of the request. In addition, why should we be making an extra request (even though it’s local) when the server has access to the files through the file system? Let’s see what other options are available.

Existing Solution 2. Fix via Importing JSON Files Directly

A few recent comments on the same issue #754 suggest importing the contents of JSON files straight into the file which defines our module. Then we can check which environment we’re running in and either use the default TranslateHttpLoader or a custom one, which uses the imported JSON. This approach suggests a way to handle PROBLEM 2 by checking the environment where the code is running: if (isPlatformBrowser(platform)). We’ll use a similar platform check later in the article.

Please don’t do this! By importing JSON files like shown above, they will end up in the browser bundle. The whole purpose of using HttpLoader is that it will load the required language file on demand making the browser bundle smaller.

With this method, the translations for all the languages will be bundled together with the run-time JavaScript compromising performance.

Although both existing solutions provide a fix for PROBLEM 2, they have their shortcomings. One results in unnecessary requests being made and another one compromises performance. Neither of them provides a solution for PROBLEM 1.

🔋 A Better Way — Prerequisites

In the upcoming sections I’ll provide two separate solutions to the identified PROBLEMS. Both of the solutions will require the following prerequisites.

Prerequisite 1. We need to install and use a dependency called cookie-parser.

Prerequisite 2. Understand the Angular REQUEST injection token

Prerequisite 1. Why Do We Need cookie-parser?

The ngx-translate-cache library is in charge of creating a cookie in the client when a user selects the language. By default (although it can be configured) the cookie is named lang. In the upcoming solutions, we’ll need a way to access this cookie on the server. By default, we can access the information we need from the req.headers.cookie object in any of the Express request handlers. The value would look something like this:

lang=en; other-cookie=other-value

This property has all the information we need, but we need to parse the lang out. Although it’s simple enough, there is no need to reinvent the wheel since cookie-parser is an Express middleware that does exactly what we need.

Install the required dependencies.

npm install cookie-parser
npm install @types/cookie-parser -D

Update the server.ts file to use the installed cookie-parser.

import * as cookieParser from 'cookie-parser';
app.use(cookieParser());

Under the hood, the cookie-parser will parse the Cookies and store them as a dictionary object under req.cookies.

{
  "lang": "en",
  "other-cookie": "other-value"
}

Prerequisite 2. The Angular REQUEST Injection Token

Now that we have a convenient way of accessing Cookies from the request object, we need to have access to the req object in the context of the Angular application. This can easily be done using the REQUEST injection token.

Here’s the obvious fact: The REQUEST injection token is available under @nguniversal/express-engine/tokens. Here is a not so obvious fact: the type for the req object is the Request provided by type definitions of the express library.

This is important and might trip us over. If this import is forgotten, the typescript will assume a different Request type from the Fetch API that’s available under lib.dom.d.ts. As a result, TypeScript will not have knowledge of req.cookies object and will underline it with red.

Now We Are Ready for the Solutions

Please make a mental snapshot of the PART 2 Checkpoint below. We will use this code as a starting point for the next two parts of this series where we’ll explore how to fix the two PROBLEMS outlined previously.

PART 2 Checkpoint

*** The code up to this point is available here.

👌 Part 3 of 6: Solution 1 — Fix via Providing a Separate I18nModule for the Server

Currently, our application looks like this:

The diagram above shows the path of code execution when the code runs in the browser (green) and when it runs in the server (grey). Notice that in the client-side path, the file that bootstraps the whole application (main.ts) imports the AppModule directly. On the server-side path, the main file imports a separate module, the AppServerModule, which in turn imports the AppModule. Also, notice that the I18nModule is a dependency of AppModule , which means that the code of I18nModule will be executed in both the client and in the server.

In the solution below we’ll make the browser side look more like the server side. We’ll introduce a new module — the AppBrowserModule . That will be the module to be bootstrapped. We’ll also rename the I18nModule to I18nBrowserModule and move it into the imports of the AppBrowserModule . Finally, we’ll introduce a new module, the I18nServerModule, that will use file system access to load JSON files. This module will be imported inside of the AppServerModule. See the resulting structure below:

Below is the code of the new I18nServerModule.

https://medium.com/media/1cbcd2e42cadd338186eca59d8015bfc/href

There are two main things happening in the code above.

First, we make use of the REQUEST injection token provided by Angular to get a hold of the full request object. We use the token to access the cookies object to find out what language the user selected in the browser. Knowing the language, we call the use method of the TranslateService class so that our website gets rendered in that language.

Second, the action above will trigger our custom loading mechanism defined in the TranslateFsLoader class. In the class, we simply use standard node API to read files from the file system (fs).

Solution 1 Summary

This solution completely separates the compilation path for the server from the compilation path for the browser. PROBLEM 1 is solved due to the translate.getBrowserLang() existing only in the I18nBrowserModule, which will never run in the server environment.

PROBLEM 2 is similarly solved by each I18n Module — the Server and the Client modules — using their own Translation Loader mechanism — the TranslateFsLoader and TranslateHttpLoader respectively.

I like this option because it comes with a clear separation between the code that runs on the server and the code that runs in the browser. Introducing the AppBrowserModule establishes the architecture for handling cases when the server- and client-side logic significantly differs.

However, there is one more approach to tackle this task. Keep reading!

*** The code up to this point is available here.

👌 Part 4 of 6: Solution 2 — Provide Everything in a Single Module

Now that we looked at Solution 1, let’s examine another way. In contrast to Solution 1, this solution does not require the creation of new modules. Instead, all code will be placed inside of the I18nModule. This can be achieved using the isPlatformBrowser function provided by the Angular framework.

Let’s come back to the PART 2 Checkpoint.

git checkout step-2

Now we’ll make the I18nModule aware of the platform it’s running in and use the appropriate Loader depending on the environment — either the TranslateFsLoader created in the previous Part or the TranslateHttpLoader provided by the ngx-translate library.

Add the PLATFORM_ID to the deps of the translateLoaderFactory. This will allow us to select the loader in the factory depending on the current platform.

https://medium.com/media/57480582b6b38f9e3445e92012cc833a/href

Now, the factory function will use the appropriate Loader depending on the platform. Similar adjustments need to be done to the constructor of the I18nModule.

https://medium.com/media/f57dde99e7a0d9bd82007e641095259f/href

If we try to build the application now we’ll get an error.

Module not found: Error: Can't resolve 'fs' in 'C:\ssr-with-i18n\src\app\i18n'
Module not found: Error: Can't resolve 'path' in 'C:\ssr-with-i18n\src\app\i18n'

That’s because the fs and the path dependencies, which are strictly Node dependencies, are now referenced in the file that’s compiled for the client-side environment.

We, as developers, know that these server-side dependencies won’t be used because they are behind appropriate if statements, but the compiler does not know that.

There is an easy fix for this issue as well. We can let our compiler know not to include these dependencies in the client-side bundle using a new browser field of the package.json file.

Add the following to the package.json file.

"browser": {
  "fs": false,
  "path": false
}

Now, everything will compile and run exactly the same as with the previous solution.

Solution 2 Summary

Both PROBLEM 1 and PROBLEM 2 are solved by separating the browser-specific code from the server-specific code via an if statement that evaluates the current platform:

isPlatformBrowser(this.platform)

Now that there is only a single path of compilation for both platforms, fs and path dependencies that are strictly node dependencies cause a compilation-time error when the build process compiles a browser bundle. This is solved by specifying these dependencies in the browser field of the package.json file and setting their values to false.

I like this option because it’s simpler from the perspective of the consumer application. There’s no need to create additional modules.

Update: I just learned that platform checks considered an anti-pattern because “platform” in general is an ephemeral concept. Although this solution might seem simpler and works, the Solution 1 is preferred.

*** The code up to this point is available here.

⚡ Part 5 of 6: Improve Performance with TransferState

If we run our app in its current state and take a look at the network tab of the Browser Developer Tools, we’ll see that after initial load the app will make a request to load the JSON file for the currently selected language.

This does not make much sense since we’ve already loaded the appropriate language in the server.

Making an extra request to load language translations that are already loaded might seem like it’s not a big issue worth solving. There probably are areas of an application that will result in a bigger bang for the buck in terms of performance tuning. See this article for more on this topic. However, for bigger applications, translation files might also get bigger. Therefore, the time to download and process them will also increase, at which point this would be an issue to solve.

Thankfully, Angular Universal provides a tool to solve this issue with relatively little effort: TransferState. When this solution is in use, the server will embed the data with the initial HTML sent to the client. The client will then be able to read this data without the need to ask the server.

Overview of the Workflow

To make use of the TransferState feature, we need to:

Add the module provided by Angular for the server and for the client: ServerTransferStateModule and BrowserTransferStateModule
On the server: set the data that we want to transfer under a specific key using API: transferState.set(key, value)
On the client: retrieve the data using API: transferState.get(key, defaultValue)

Our implementation

First, let’s add the TransferState Modules to the imports:

https://medium.com/media/7b7148b58383b9719eaec180bd9e152a/href https://medium.com/media/31e53ac3e9a83071ec76e204cb710d4e/href

Now let’s make appropriate changes to the I18nModule. The snippet below shows the new code.

https://medium.com/media/d5a367b6a1fca9fcb2745805b4eeb0cb/href

Second, the translateLoaderFactory will now look like this:

https://medium.com/media/9ad6dccd3a56f382432251b962196f6f/href

TranslateFsLoader will now make use of TransferState:

https://medium.com/media/dda5fd43cc24aac4a7d661c394464a85/href

How does it exactly transfer the state? During the server-side rendering, the framework will include the data in the HTML tag. See this in the image below.</p> <p><img src="https://cdn-images-1.medium.com/max/800/1*gM-kQXfp9HZ8uKQVAFFOeQ.gif" alt=""></p> <p>Once the client-side bundle bootstraps, it will be able to access this data.</p> <p>Now we need to allow the client-side Loader to make use of the transferred data. Currently, our loader factory function simply returns the TranslateHttpLoader. We’ll have to create a custom loader that will also be capable of handling the transfer state.</p> <p>Let’s create a new file to hold the custom loader class. The new loader will look like the one below.</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/7bd1ed9f614d712f15a711f0fbb50b1d/href">https://medium.com/media/7bd1ed9f614d712f15a711f0fbb50b1d/href</a></iframe> <p>Update the translateLoaderFactory to use the new Loader:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/41c6140cb6605119da07a80e4923a843/href">https://medium.com/media/41c6140cb6605119da07a80e4923a843/href</a></iframe> <h4> <a name="transferstate-summary" href="#transferstate-summary" class="anchor"> </a> TransferState Summary </h4> <p>Using TransferState allowed us to avoid loading data from the browser that was already loaded on the server.</p> <p>Now, if we run the application we’ll see that there is no unneeded request to the JSON file for the currently selected language in the network tab.</p> <p>*** The code up to this point is available <a href="https://github.com/DmitryEfimenko/ssr-with-i18n/tree/step-5">here</a>.</p> <h3> <a name="‍-‍-part-6-of-6-are-we-there-yet" href="#‍-‍-part-6-of-6-are-we-there-yet" class="anchor"> </a> ‍ <strong>🤷‍</strong> Part 6 of 6: Are We There Yet? </h3> <p>Whether you’ve chosen to go with the Solution 1 or 2, it seems like it’s all working now! Let’s close the Browser Developer Tools and enjoy the feeling of accomplishment after a lot of work.</p> <p>Just to make sure everything is working correctly, let’s update our JSON files and add “!!!” at the end of all translation strings to celebrate. Build and start the application. Refresh the page and then… scratch your head. The “!!!” aren’t there. What happened?</p> <p>While the Browser Developer Tools panel was open, the browser would clear cache on each page reload. It means the browser would download fresh JSON files each time. The moment we closed the Developer Tools panel, the browser started caching our assets. Even though we’ve changed the contents of the JSON files, the browser does not know about it.</p> <p>But how does the browser know to load fresh JavaScript and CSS files every time? That’s because Angular’s build scripts append a unique set of characters (hash) to the file name.</p> <p><img src="https://cdn-images-1.medium.com/max/245/1*XB942Ub-LqWpWxmxB6QTgA.png" alt=""></p> <p>This hash changes every time when the contents of the file change. We need to implement a similar feature for our JSON files.</p> <p>Luckily, the implementation is straightforward. Let’s create /scripts folder and a new file there: hash-translations.js.</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/32fd5b74173dff06fc4e537b704a7181/href">https://medium.com/media/32fd5b74173dff06fc4e537b704a7181/href</a></iframe> <p>For this script to work, we need to install a new dependency.<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>npm install md5 -D </code></pre></div> <p></p> <p>The script file above defines two important variables: the source directory and the destination directory.</p> <p>First, the script will clean up the destination directory if it was not empty. Then the script will look at the source path specified, read the JSON files, and generate hashes using md5 based on the files’ contents.</p> <p>Once the hashes are generated, the script will write a copy of each file in the destination directory, but this time with the hash in the file name.</p> <p>Finally, the script will generate the map.json file and put it in the destination directory as well. This file will let us pick the correct hashed file based on the locale. The contents of this file will look like the following:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>{ "en": "[hash-for-file-1]", "ru": "[hash-for-file-2]" } </code></pre></div> <p></p> <p>Add an entry to the package.json file under the scripts field that will let us execute the file we created.</p> <p>Also, update the start and build:ssr scripts to run this new script:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/2df8bcbf65d2dbba2109d4bf140b4de7/href">https://medium.com/media/2df8bcbf65d2dbba2109d4bf140b4de7/href</a></iframe> <p>Go ahead and run the new script to see the results. Note, that there is no need to check-in auto-generated files into the repository since they will be changing often. Add an entry to the .gitignore file.<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>src/assets/i18n/autogen/* </code></pre></div> <p></p> <p>Finally, update the Translation Loaders to serve auto-generated files.</p> <p>The path to the file that we need to load looks like this: ./assets/i18n/autogen/${lang}.${hash}.json. The ./assets/i18n/autogen/ part is the prefix. The .${hash}.json is the suffix. Both of these variables need to be customized in order to make use of the auto-generated files.</p> <p>Here’s how we can handle the prefix change for both loaders.</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/6cfe640a5436c57d5cb120ab36a9fc53/href">https://medium.com/media/6cfe640a5436c57d5cb120ab36a9fc53/href</a></iframe> <p>The suffix would have to be handled in the getTranslation method of each loader since we need access to the lang variable.</p> <p>First, we need to get a hold of the auto-generated map.json file.<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>const i18nMap = require('../../assets/i18n/autogen/map.json'); </code></pre></div> <p></p> <p>We use a require syntax because this file might only be available during compilation.</p> <p>The TranslateBrowserLoader will have the following changes:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/02c508c6edaab4549ef58ce28bf4ce4e/href">https://medium.com/media/02c508c6edaab4549ef58ce28bf4ce4e/href</a></iframe> <p>For the TranslateFsLoader , it is a one-line code change.</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/fa8925109b6c4b65794ce68d957ba02c/href">https://medium.com/media/fa8925109b6c4b65794ce68d957ba02c/href</a></iframe> <p>Compile and run the app. Everything will work as expected and the browser will load updated translation files when it needs to.</p> <p>*** The final code is available <a href="https://github.com/DmitryEfimenko/ssr-with-i18n">here</a>.</p> <h3> <a name="article-summary" href="#article-summary" class="anchor"> </a> 👏 Article Summary </h3> <p>In this article, we built a maintainable solution for managing application translation strings via separate JSON files. We utilized a popular library — <em>ngx-translate</em>. We’ve also looked at the current solutions for integrating this functionality with Server-Side Rendered applications provided by the community. We talked about the weaknesses of these solutions and provided better options. Finally, we implemented a few of the advanced features, such as: (1) memorization of the selected language via Cookies, (2) utilizing State Transfer to avoid unnecessary HTTP requests to the server, and (3) breaking cache for the translation files.</p> <p><strong>Special thanks to</strong> <a href="http://www.linkedin.com/in/anaboca"><strong>Ana Boca</strong></a> <strong>and</strong> <a href="https://github.com/abashmak"><strong>Alex Bashmakov</strong></a> <strong>for reviewing, testing, and providing some of the code for this article.</strong></p> <h4> <a name="call-to-action" href="#call-to-action" class="anchor"> </a> Call to Action </h4> <p>I always enjoy feedback, so please 👏, 📝, and subscribe to AngularInDepth publication.</p> <hr>