This is thanks to the default Angular’s change detection mechanism, which constantly checks for changes in data and updates the view accordingly. While this is great for most use cases, it is possible to manually detect changes for performance optimisation.

Let’s explore change detection strategies in Angular.

What is a change detection strategy?

A change detection strategy is a mechanism that decides when Angular should update the view of a component.

Angular offers the following change detection strategies:

• ChangeDetectionStrategy.Default
• ChangeDetectionStrategy.OnPush

Any newly generated component uses the default strategy.

ChangeDetectionStrategy.Default

Default strategy triggers change detection for DOM events, timers, promises, XHR, observables etc. Therefore, every time something changes in our application, a change detection will run on all components to update the view.

Angular achieves this by creating a change detector, which is responsible for listening to changes and updating the view of the component.

ChangeDetectionStrategy.OnPush

The OnPush strategy can be used to optimise the performance of an Angular application.

With OnPush strategy, Angular only performs a change detection cycle on a component and its children, if there is a change in the component’s input properties or if an event is triggered.

OnPush triggers change detection when:

• DOM events listened by the component emit
• async pipe receives a new event
• @Input() property updates by change detection
• Explicitly registration using ChangeDetectorRef::markForCheck

If the component’s data model is updated outside of Angular’s change detection mechanism, Angular will not update the view.

This may sound like a drawback, but it’s actually a useful feature when used correctly.

The OnPush strategy is designed to reduce the number of unnecessary change detection cycles. This is especially important in complex applications, where change detection can become a bottleneck and degrading overall performance of the application.

How to use onPush strategy

To use the OnPush strategy, you simply need to set the changeDetection property of the component’s @Component decorator to ChangeDetectionStrategy.OnPush.

Here’s an example:

import { ChangeDetectionStrategy, Component } from '@angular/core';

@Component({
  selector: 'app-hello-world',
  template: `
    <p>{{ message }}</p>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class HelloWorldComponent {
  message = 'Hello, World!';
}

It’s important to note that when using the OnPush strategy, you need to make sure that Angular is aware of any changes in the component’s data model.

This can be done by using the markForCheck method from the ChangeDetectorRef class.

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

constructor(private cd: ChangeDetectorRef) { }

ngOnInit() {
  // Do some work that changes data
  this.cd.markForCheck();
}

The ChangeDetectorRef class provides a way to interact with the change detection mechanism and manually trigger change detection.

You can mark a component or its ancestors for checking using the markForCheck method. Next time change detection runs, the view will reflect the new state of data.

markForCheck() vs detectChanges()

Another method available on the change detector is detectChanges. You might be wondering, what is the difference between markForCheck and detectChanges.

The key difference between these is that detectChanges() triggers change detection, while markForCheck() doesn’t trigger change detection.

With detectChanges(), the change detection will run for the current component and all its children. This is a common fix to the infamous error Expression has changed after it was checked.

On the other hand, markForCheck() simply goes upwards from the current component to the root component and updates their view state to ChecksEnabled. The change detection for the component will happen in the future either as part of the current or next change detection cycle. The parent component views will also be checked even if they had detached change detectors. 

Should I use onPush strategy?

If change detection is a bottle-neck in your component, go ahead and try onPush change detection strategy. This is a great way to fine-tune the performance of your application.

However, premature optimisation can have an adverse effect on your application.

If you use onPush strategy without a valid reason, the component code will be more complex, harder to test and more difficult to maintain.

Based on my experience, the default strategy will work just fine for most small to medium sized applications.

Conclusion

In this post, we’ve looked at the different change detection strategies available in Angular. Default strategy automatically updates view when there is a change in the data model. OnPush strategy allows us to optimise performance by giving us the freedom to choose when to check for changes.

The post Change Detection in Angular: Default vs OnPush appeared first on onthecode.

Angular provides a built-in Title service that we can use to set the title of the web page dynamically from code. We will use the title service in combination with router events to change page title for all routes.

Setting page title in Angular

Firstly, import the Title service in the component you want to set the title:

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

Inject the Title service in the constructor of the component:

constructor(private titleService: Title) {}

Then you can use the setTitle method of the Title service to set the title of the web page.

For example, you can set the title based on the data received from a service or from the component’s properties:

this.title.setTitle(`My Awesome App - ${data.title}`);

As you can see, it is pretty straightforward to use set the title in Angular.

Setting the title for all routes

Instead of setting the title in every component that’s associated with a route, we’ll take it a step further and dynamically set the title from the routes table.

DRY (don’t repeat yourself) is a principle in software development that recommends to do something once, and only once.

The first step is to update routes table in every feature module to hold page titles.

const routes: Routes = [
  {
    path: "",
    component: HomePageComponent,
    data: {
      title: "Home"
    }
  },
  {
    path: "blog",
    component: BlogPageComponent,
    data: {
      title: "Blog"
    }
  },
  {
    path: "**",
    component: NotFoundPageComponent,
    data: {
      title: "Not Found"
    }
  }
];

You should now go through all routes of your app and make sure there is a title associated with every route!

Next, generate a service to get data from the current route:

ng generate service route-data

Implement the service with below code:

import { Injectable } from "@angular/core";
import { ActivatedRoute, ActivatedRouteSnapshot, Data } from "@angular/router";

@Injectable({
  providedIn: "root"
})
export class RouteDataService {

  constructor(private route: ActivatedRoute) { }

  get(): Data {
    return this.getRouteSnapshot().data;
  }

  private getRouteSnapshot(): ActivatedRouteSnapshot {
    let route = this.route;

    while (route.firstChild) {
      route = route.firstChild;
    }

    return route.snapshot;
  }
}

This service allows us to pull out the data object we defined in our routes earlier.

Like any other singleton service, we can inject it into any component to set the title.

Since we want to set the title for every page, we need to subscribe to router events in the root component app.component.ts.

Let’s to update app.component.ts to read the title every time navigation occurs:

import { filter } from 'rxjs';

import { Component, OnInit } from '@angular/core';
import { Title } from '@angular/platform-browser';
import { NavigationEnd, Router } from '@angular/router';
import { RouteDataService } from './route-data.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {
  constructor(private router: Router,
    private routeDataService: RouteDataService,
    private title: Title) {
  }

  ngOnInit(): void {
    this.router.events
      .pipe(filter(event => event instanceof NavigationEnd))
      .subscribe(_ =>
        this.title.setTitle(`${this.routeDataService.get()["title"]} - Umut Esen`)
      );
  }
}

By using this method, you can set the title of the web page dynamically based on the data from the router events, which will update the title of the window in real-time.

Conclusion

In summary, we learned how to set the page title in Angular. Through DRY principle, we implemented a feature that sets the page title based on Angular router events.

Let me know what you think by dropping a comment below!

The post How to Set Page Title Based on Route in Angular appeared first on onthecode.

We will create a basic routes file and append routes dynamically from an XML sitemap ahead of running npm run prerender command when building the application.

Pre-requisites

This post assumes you already have an Angular Universal application. If this is not the case, add server-side rendering (SSR) capability to your Angular application by following this guide.

Once you add SSR, you can use npm run prerender command to prerender your application.

Benefits of prerendering

Prerendering with Angular Universal refers to the process of rendering an application’s content on the server side before sending it to the client.

This can help improve the performance of an Angular application, especially for users with slow internet connections or on devices with limited resources.

By pre-rendering the application’s initial state on the server and then serving the fully rendered HTML to the client, the client’s web browser can start rendering the page immediately, rather than having to wait for all of the necessary JavaScript to download and execute before the content is displayed.

This can lead to a faster time to first paint and a better user experience overall.

Prerender options

There are a few build options available to use with prerender command as outlined by official documentation.

These options are:

• Provide extra routes in the command line
• Provide routes using a file
• Prerender specific routes

A sitemap is likely to have a large number of URLs so we’ll provide routes using a file.

Modify prerender command

Open up package.json and update prerender command to use a routes file:

"prerender": "ng run myapp:prerender --routes-file routes.txt"

There is no need to manually create a routes.txt file because the script we’re about to write will automatically create it.

Generate routes file

We will retrieve urls from an XML sitemap using xml-sitemap-url-scraper package.

Install this package as a dev dependency so it does not ship with production bundle:

npm install xml-sitemap-url-scraper --save-dev

Using this package to retrieve URLs is pretty simple, just provide a direct link to your sitemap as shown below.

What you’ll get in return is a promise containing all of the URLs found in the sitemap.

const fs = require('fs');
const { sitemapUrlScraper } = require("xml-sitemap-url-scraper");

const url = "https://mysite.com/sitemap_index.xml";

sitemapUrlScraper([url])
    .then(urls => {
        const routes = urls
            .map(url => url.replace(new URL(url).origin, ""))
            .join('\r\n');

        fs.writeFile('routes.txt', '\r\n' + routes, err => {
            if (err) {
                console.error(err);
            }
        });
    })
    .catch(err => { console.log(err); })

Since prerender command expects relative URL separated by a line break in the routes file, we’re post-processing the results before creating the file routes.txt.

You’ll want to save this script to the root of your project and run using node in the command line:

node route-fetcher.js

Processing XML Sitemap:  https://mysite.com/sitemap_index.xml
Processing XML Sitemap:  https://mysite.com/post-sitemap.xml
Processing XML Sitemap:  https://mysite.com/page-sitemap.xml
Processing XML Sitemap:  https://mysite.com/category-sitemap.xml

You would ideally run this script as part of your continuous delivery pipeline, before prerendering the application.

Your routes.txt will be populated with all the links specified in your sitemap.

Conclusion

Hopefully this post helped you with prerendering the pages of your Angular application using a routes file.

What do you think? Let me know in the comments below!

The post Generating Routes File for Angular Universal Prerender appeared first on onthecode.

In this post, I’ll explain the steps I took to identify the root cause of issue and propose potential solutions.

Identifying the root cause

The exception stack trace hints at the root cause of this issue:

(Windows 8.1.0.0): Executed 9 of 846‌ SUCCESS‌ (0 secs / 1.912 secs)‌
15 12 2022 15:14:23.895:ERROR [karma-server]: ‌TypeError: Cannot read properties of undefined (reading 'range')‌
    at handleRangeHeaders (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:134:21)
    at processRequest (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\middleware.js:98:19)
    at ready (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:54:12)
    at handleRequest (D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\util.js:185:5)
    at D:\Agents\1\_work\424\s\MyApp.Web\node_modules\webpack-dev-middleware\lib\middleware.js:64:7
    at new Promise (<anonymous>)

Let’s dig deeper and find out what’s going on the line of code throwing this exception:

// node_modules\webpack-dev-middleware\lib\util.js:134 
handleRangeHeaders(content, req, res) {
    // assumes express API. For other servers, need to add logic to access
    // alternative header APIs
    res.setHeader('Accept-Ranges', 'bytes');

    if (req.headers.range) {
      const ranges = parseRange(content.length, req.headers.range);

It looks like webpack-dev-middleware is handling requests as part of the test run. When it comes to handling headers on the request, it is falling over with:

Cannot read properties of undefined (reading 'range')‌

Clearly, Accept-Ranges headers are not present in some requests performed during our test run.

In order to pinpoint which request is causing this error, let’s output the name of each file during the test run:

// node_modules\webpack-dev-middleware\lib\util.js:134 
  handleRangeHeaders(content, req, res) {
    console.log(req.url);

Run tests again with ng test and see the file name causing this issue:

/_karma_webpack_/assets/icons/icon-library.svg
15 12 2022 15:14:23.895:ERROR [karma-server]: ‌TypeError: Cannot read properties of undefined (reading 'range')‌

At this point, we can see the file name and this should hopefully be familiar to you. The chances are your project is somehow trying to load this file from the assets folder using a relative path.

Let’s look at what we can do to fix this issue.

Fix #1 – Configure karma to use proxy

The very first thing I tried to fix this issue was to follow the advice of Ievgen, who had the same problem within an Angular project inside a docker container.

Simply add the following code in karma.conf.js after config.set({

proxies: {
    '/assets/': '/base/src/assets/'
},

Ievgen suggests this new rule in karma configuration will point all requests matching /assets/ to the base folder of the project. Unfortunately, this did not work for me even after adjusting the path to match the setup of my project.

Although Ievgen’s solution did not work for me, it put me in the right direction and helped identify the following fixes.

Fix #2 – Stop using relative paths

The first thing I did was to find all the usages of assets folder in the entire source code.

It turned out some css files were using relative paths to load some images from the assets folder:

  content: url(../../../assets/icons/back-icon.png);

The fix is to define the path from the src folder:

  content: url("/src/assets/icons/back-icon.png");

Repeat this for all references of assets folder to ensure all paths correctly identify a file.

Fix #3 – Exclude 3rd party stylesheets during test run

There may be external packages included in the test configuration within angular.json that are using relative path to assets folder.

// angular.json 
"test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "codeCoverage": true,
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "karma.conf.js",
            "styles": [
              "src/styles.css"
              "node_modules/@my-company/web-styles/sass/main.scss"
            ],
            "scripts": [],
            "assets": [
              "src/assets",
              "src/Web.config",
              "src/auth.config"
            ]
          } 

As you can see in the above snippet, the test configuration is loading styles from an external package.

Since this package is internally using relative paths to assets, folder the exception is thrown. The solution is to remove this line of code to exclude 3rd party stylesheets during the test run.

I hope you found this post useful, drop a comment below to let me know what you think!

The post Fixing Angular Unit Tests: Cannot read property ‘range’ of undefined appeared first on onthecode.

In this post, I will show you how to set the HTTP status code from an Angular application with SSR.

Background

Let’s address why you might even want to set HTTP status code from an Angular component in the first place.

As an example, my application renders the following component when it does not recognise a URL:

import { Component } from '@angular/core';
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent {}

When the component is rendered in the browser, the status code is actually 200 OK.

Search engines would consider this response as valid and continue indexing the contents of this page.

In this case, we should be returning the correct status code: 404 Not Found.

Another possible scenario is returning status code 401 Unauhorised when securing pages from anonymous access.

Inject response from Express.js

Like any other server-side application, we need to modify the HTTP response to set the status code.

To do this in Angular Universal, we can inject the Response object from Express.js server into the constructor of the component:

import { Component, Inject, Optional } from '@angular/core';
import { RESPONSE } from '@nguniversal/express-engine/tokens'
import { Response } from 'express'
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent {
  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }
}

Notice the dependency is optional since Angular Universal applications run on both the server and the browser.

An optional parameter becomes null when the application is running in the browser. This means any usage of the response should be protected with a null guard.

Setting the status code

With the response available in the component, we can implement our logic inside the OnInit event.

We can pass in the status code to the status method as shown below as per Response API docs.

export class NotFoundPageComponent implements OnInit {
  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }

  ngOnInit() {
    // Return 404 when running server side
    if (this.response) {
      this.response.status(404);
    }
  }
}

Since the response can be null in the browser context, we guard against null value to avoid our component from failing.

Let’s now serve an SSR build locally to test the status code.

npm run build:ssr
npm run serve:ssr

Running the same scenario now yields 404 Not Found response in the browser.

Full source code

Putting it all together this is how the component looks like now:

import { Component, Inject, OnInit, Optional } from '@angular/core';
import { RESPONSE } from '@nguniversal/express-engine/tokens'
import { Response } from 'express'
@Component({
  selector: 'app-not-found-page',
  template: `
      <h1>Not Found</h1>
      <p>This page does not exist.</p>
  `
})
export class NotFoundPageComponent implements OnInit {

  constructor(
    @Optional() @Inject(RESPONSE) private response: Response
  ) { }

  ngOnInit() {
    // Return 404 when running server side
    if (this.response) {
      this.response.status(404);
    }
  }
}

Unit tests

It helps to put in unit test coverage around the features of the component to act as a safety net. Tests also help document our code.

This is the full spec file containing the implementation details for all of the tests:

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { NotFoundPageComponent } from './not-found-page.component';
import { RESPONSE } from '@nguniversal/express-engine/tokens';
import { By } from '@angular/platform-browser';

describe('NotFoundPageComponent', () => {
  let component: NotFoundPageComponent;
  let fixture: ComponentFixture<NotFoundPageComponent>;
  let response: any;

  describe('client-side', () => {
    beforeEach(async () => {
      await TestBed.configureTestingModule({
        declarations: [NotFoundPageComponent],
        providers: [
          {
            provide: RESPONSE,
            useValue: null
          }
        ]
      })
        .compileComponents();

      fixture = TestBed.createComponent(NotFoundPageComponent);
      component = fixture.componentInstance;
      response = TestBed.inject(RESPONSE);
      fixture.detectChanges();
    });

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

    it('should render elements', () => {
      expect(fixture.debugElement.query(By.css("h1")).nativeElement.textContent).toEqual("Not Found");
      expect(fixture.debugElement.query(By.css("p")).nativeElement.textContent).toEqual("This page does not exist.");
    });
  });

  describe('server-side', () => {
    beforeEach(async () => {
      await TestBed.configureTestingModule({
        declarations: [NotFoundPageComponent],
        providers: [
          {
            provide: RESPONSE,
            useValue: jasmine.createSpyObj("Response", ["status"])
          }
        ]
      })
        .compileComponents();

      fixture = TestBed.createComponent(NotFoundPageComponent);
      component = fixture.componentInstance;
      response = TestBed.inject(RESPONSE);
      fixture.detectChanges();
    });

    it('should set 404 status code on response', () => {
      expect(response.status).toHaveBeenCalledOnceWith(404);
    });
  });

});

The post Angular Universal: Setting HTTP Status Code appeared first on onthecode.

./src/polyfills.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Cannot resolve type entity i3.DialogModule to symbol

Error: node_modules/@angular/material/dialog/index.d.ts:3:36 - error TS2307: Cannot find module '@angular/cdk/dialog' or its corresponding type declarations.

3 import { CdkDialogContainer } from '@angular/cdk/dialog';

After hours of research online with no luck, it turns out I never had @angular/cdk as a dependency in the project.

I found this out by checking the getting started section of Angular Material docs.

How to fix Error: Cannot resolve type entity i3.DialogModule to symbol:

1. Open up package.json file
2. Add @angular/cdk to dependencies section:
3. Run npm install to update download the new package

It doesn’t matter where you put the new dependency, as long as it is within the dependencies block.

One thing to watch out for is using the correct version – it must match the rest of the Angular packages.

In the code snippet below, you can see I am using version ^14.2.1 because all other angular packages are on this version.

  ....
  "dependencies": {
    "@angular/animations": "^14.2.1",
    "@angular/common": "^14.2.1",
    "@angular/compiler": "^14.2.1",
    "@angular/core": "^14.2.1",
    "@angular/cdk": "^14.2.1",
    ...
  }
  ...

I hope this post helped you solve this problem!

It is really not clear to my why I didn’t have this error in Angular 13. After all, a missing dependency should break builds, right? Let me know in the comments, if you know why.

The post Error: Cannot resolve type entity i3.DialogModule to symbol appeared first on onthecode.

What does ng-deep do?

One of the great features of Angular is that components support view encapsulation.

With view encapsulation, Angular creates a scope for every component at runtime so that the styles of a component don’t affect the rest of the application.

While this protects logic from leaking to other components, it also makes it more difficult to style elements in child components.

To overcome this issue, Angular introduced a special selector ng-deep.

ng-deep selector completely disables the view encapsulation policy of a child component, leaking styles into components you don’t want to change.

ng-deep example

In the example below, the parent component is styling a button within the child component using ng-deep selector.

import { Component } from "@angular/core";

@Component({
  selector: "app-parent",
  template: `<app-child></app-child>`,
  styles: [
    `
      ::ng-deep .hello {
        color:red;
      }
    `
  ]
})
export class ParentComponent { }

@Component({
  selector: "app-child",
  template: ` <button class="hello" (click)="sayHello()"> Hello </button> `,
  styles: [``]
})
export class ChildComponent {}

So that’s what ng-deep looks like – it makes it easy to workaround the view encapsulation.

Why you need to avoid ng-deep

The main reason for avoiding ng-deep is because the selector has been deprecated for years.

Angular also plans to drop support for ng-deep in a future release so your next Angular upgrade may be more difficult.

Also, ng-deep can lead to unexpected outcomes.

Since ng-deep pierces the view encapsulation policy, you might find your deep styles affect a component unintentionally.

The only case you cannot avoid ng-deep

Based purely on my experience, there is only one situation where you cannot avoid ng-deep.

And that’s when you’re dealing with components from third party libraries like Bootstrap, Material etc.

This is because you simply cannot change the third party component code, so you have to use ng-deep.

Let me clarify an important point before we start, there is no true replacement to ng-deep.

Alternative #1 – :host selector

In situations where you want to apply styles directly to a child component (not its elements), :host selector can be used instead of ng-deep.

:host selector targets the child component as a whole, instead of elements inside its template.

Any style marked with :host in a child component can be overridden by a parent component without using ng-deep.

@Component({
  selector: "app-parent",
  template: `<app-child></app-child>`,
  styles: [
    `
      app-child {
        background-color:green;
      }
    `
  ]
})
export class ParentComponent { }

@Component({
  selector: "app-child",
  template: `
  <button class="hello"> Hello </button>
  `,
  styles: [
    `
    :host {
      background-color:red;
      width:200px;
      height:200px;
      display: block;
    }
    `
  ]
})
export class ChildComponent {}

This approach works well for simple scenarios where you want to modify the styles of the child component and not its elements.

Alternative #2- CSS variables

In more complex cases, where you need to apply styles to elements of Another alternative to ng-deep is to use CSS variables to share values between parent and child component.

Angular view-encapsulation does not cover CSS variables so it is possible for the parent to define a variable like --text-colour and the child component can make use of it in its stylesheet file.

This is especially useful for complex scenarios where you want the child component to be reusable.

import { Component } from "@angular/core";

@Component({
  selector: "app-parent",
  template: `<app-child></app-child>`,
  styles: [
    `
    app-child { /* declare variable for child */
      --text-colour: green;
    }
    `
  ]
})
export class ParentComponent { }

@Component({
  selector: "app-child",
  template: `
  <button class="hello"> Hello </button>
  `,
  styles: [
    `
    button { /* use variable from parent, or default value of 'red'*/
      color: var(--text-colour, red); 
    }
    `
  ]
})
export class ChildComponent {}

It is worth noting that major browsers have full support for CSS variables. This, of course, does not include IE.

It is also possible to bind CSS variables in the HTML template of the parent component:

import { Component } from "@angular/core";

@Component({
  selector: "app-parent",
  template: `<app-child [style.--text-colour]="'green'"></app-child>`,
  styles: [` `]
})
export class ParentComponent { }

The only limitation of this approach is that you need to modify the child component. This may be a problem if you’re trying to style a third party component.

The post Using ng-deep in Angular appeared first on onthecode.

By default, styles defined in an Angular component only work in that specific component. This is due to the Emulated view encapsulation policy set by Angular.

This logical scope is great because styles of component A cannot affect component B. This is also the case where component B is a child of component A.

Example

In the following template, we want to apply styling the img tag in the html content.

const content = '<img src=".." alt="..">'

<!-- Post page component html -->
<div [innerHtml]="content"></div>

Unfortunately, the following CSS rule does not work because of the default view encapsulation policy.

img {
    border: 1px solid red !important;
}

Emulated view encapsulation is preventing styles from intercepting inside and outside of the component.

In this case, value bound to innerHtml attribute is considered outside of the component. This is because the value of content variable was not originally defined in your component HTML.

There are a couple of ways you can work around this issue. Let’s check out each solution.

Remove view encapsulation

#1 workaround is to change the view encapsulation of the component to ViewEncapsulation.None

@Component({
  selector: 'app-post-page',
  templateUrl: './post-page.component.html',
  styleUrls: ['./post-page.component.scss'],
  encapsulation: ViewEncapsulation.None
})
export class PostPageComponent implements OnInit {}

Please note that changing ViewEncapsulation to None can have pretty far-reaching consequences.

This applies your styles globally – so if you set something like a div tag to have a background color, this will change all divs in your app to have that background color.

I would steer clear of changing the ViewEncapsulation unless you absolutely have to.

Use ::ng-deep

A better solution is to use ::ng-deep selector in each of your CSS rules.

:host ::ng-deep img {
    border: 1px solid red !important;
}

This styling above will now apply to images deep in this component.

It is important to limit the use of ::ng-deep to only children of an encapsulated parent component. Otherwise, it would apply to all images in child components.

Using the :host keyword before ::ng-deep takes care of this.

The post Making Styles Work with [innerHtml] in Angular appeared first on onthecode.

Problem demonstration

There are many things to consider when it comes to building accessible web applications. One important consideration is visually impaired users – allowing them to interact by hearing where they cannot see. This includes announcing screen reader messages in a timely manner.

The following example demonstrates how to use LiveAnnouncer service in Angular:

@Component({...})
export class MyComponent {

 constructor(liveAnnouncer: LiveAnnouncer) {
   liveAnnouncer.announce("Hey Google");
 }
}

While the above works fine, the problem surfaces when multiple components use announce method:

// Search component
liveAnnouncer.announce("Search in progress");

// Notification component
liveAnnouncer.announce("You have a new message");

// Search component
liveAnnouncer.announce("Search complete");

LiveAnnouncer works by updating the text content of a single aria-live region within the HTML document object model. It always overwrites the text content when your code invokes announce.

If notification service calls announce while a search is in progress and completes quickly, a visually impaired user would not hear You have a new message. This is not a great experience as the user would not know about the new message they have just received.

Extending LiveAnnouncer

Let’s create a singleton ScreenReaderService, which will internally use LiveAnnouncer.

We need to delay each call to LiveAnnouncer using the setTimeout function.

We also need to keep track of how many times our application wants to announce screen reader messages – with a counter. Extending each delay based on the counter creates a simple queue of announcements.

Putting it all together:

import { LiveAnnouncer } from "@angular/cdk/a11y";
import { Injectable } from "@angular/core";
 
@Injectable({
  providedIn: "root"
})
export class ScreenReaderService {
  private counter = 0;
 
  constructor(private announcer: LiveAnnouncer) { }
 
  announce(message: string): void {
    setTimeout(() => {
      this.announcer.announce(message, "polite", 200);
      this.counter--;
    }, 300 * this.counter);
 
    this.counter++;
  }
}

Waiting a varying period of time between each announcement allows screen reader software to read messages correctly.

The following are some of the test cases that helped me come up with the solution above. I am using the fakeAsync zone to simulate the passage of time using the tick method.

import { LiveAnnouncer } from "@angular/cdk/a11y";
import { discardPeriodicTasks, fakeAsync, flush, TestBed, tick } from "@angular/core/testing";
 
import { ScreenReaderService } from "./screen-reader.service";
 
describe("ScreenReaderService", () => {
  let service: ScreenReaderService;
  let announcer: any;
 
  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        {
          provide: LiveAnnouncer,
          useValue: jasmine.createSpyObj("LiveAnnouncer", ["announce"])
        }
      ]
    });
    service = TestBed.inject(ScreenReaderService);
    announcer = TestBed.inject(LiveAnnouncer);
  });
 
  it("should be created", () => {
    expect(service).toBeTruthy();
  });
 
  it("should announce message", fakeAsync(() => {
    service.announce("Page loaded");
    tick(0);
    expect(announcer.announce).toHaveBeenCalledWith("Page loaded", "polite", 200);
  }));
 
  it("should announce two simultaneous messages correctly", fakeAsync(() => {
    service.announce("Page loaded");
    service.announce("Content loaded");
    tick(300);
    expect(announcer.announce).toHaveBeenCalledWith("Page loaded", "polite", 200);
    tick(300);
    expect(announcer.announce).toHaveBeenCalledWith("Content loaded", "polite", 200);
  }));
 
  it("should announce three simultaneous messages correctly", fakeAsync(() => {
    service.announce("Page loaded");
    service.announce("Content loaded");
    service.announce("Footer loaded");
    tick(300);
    expect(announcer.announce).toHaveBeenCalledWith("Page loaded", "polite", 200);
    tick(300);
    expect(announcer.announce).toHaveBeenCalledWith("Content loaded", "polite", 200);
    tick(300);
    expect(announcer.announce).toHaveBeenCalledWith("Footer loaded", "polite", 200);
  }));
});

Now that we have a service for screen reader announcements, all we need to do is use it in our components.

This is how I solved the problem of LiveAnnouncer not queueing messages!

Are you considering accessibility when building your Angular applications? Share your thoughts in the comments below!

The post How to Queue Messages Sent to LiveAnnouncer appeared first on onthecode.

Having developed several Angular applications myself, I have come to realise the 5 tips below.

Shorten commands

The official getting started guide tells you to use the full names of commands, such as:

ng generate component MyComponent

While this is great for beginners, it is also possible to achieve the same output by using the initials of commands.

ng g c MyComponent

You can shorten various commands as shown in examples below:

ng generate module MyModule ====> ng g m MyModule
ng generate pipe MyPipe ====> ng g p MyPipe
ng generate service MyService ====> ng g s MyService

Dry run flag

It is often useful to know what effect executing a certain command will have on your workspace. You can use the CLI flag --dryRun to see the effects of a command without making any changes:

hello-world % ng generate component Home --dryRun
CREATE src/app/home/home.component.css (0 bytes)
CREATE src/app/home/home.component.html (19 bytes)
CREATE src/app/home/home.component.spec.ts (614 bytes)
CREATE src/app/home/home.component.ts (261 bytes)
UPDATE src/app/app.module.ts (931 bytes)
NOTE: The "dryRun" flag means no changes were made.

Enable routing and Sass for new projects

The CLI can easily scaffold a new application using the new command. Unless you plan on keeping your newly created project for demonstration purposes, you should enable routing and Sass support.

ng new HelloWorld --routing --style=scss

As you’d expect, this will scaffold a new application called HelloWorld.

Since we used the routing flag, a new file called app-routing.module.ts will appear under src\app. This is for your convenience to start adding routes to your application. It even registers the routing module with AppModule so you can get going right away. It is worth noting this flag also works when generating modules.

The command also creates a styles.scss in your project, instead of the usual style.css. Since we enabled Sass support, all newly generated components will also have a corresponding *.scss file.

Combine commands

You can combine multiple Angular CLI commands, for example:

ng g m feature --route feature --module app.module

This command generates a new feature module with routing support. It also registers the feature module as a lazy-loaded module in app.module.

It is amazing how all of the above can be achieved just by using a single command.

Strict mode (v10)

Angular promotes best practices and consistency since the early days of development. With the adoption of Typescript, we have had compile-time checks that allowed us to prevent issues as early as possible.

With the recent release of Angular v10, we now have optional strict mode in CLI. The strict mode lets us perform more build-time optimisations and deliver faster apps with fewer issues. In order to opt into the strict mode, you need to use the strict flag:

ng new HelloWorld --strict

This command generates a new project with the following settings:

• Strict mode in TypeScript, as well as other strictness flags recommended by the TypeScript team. Specifically, strict, forceConsistentCasingInFileNames, noImplicitReturns, noFallthroughCasesInSwitch
• Turns on strict Angular compiler flags strictTemplates and strictInjectionParameters
• Reduced bundle size budgets by ~75%
• Turns on no-any TSLint rule to prevent declarations of type any
• Marks your application as side-effect free to enable more advanced tree-shaking

So there you have it, these are my favourite Angular CLI tips! What is your favourite CLI feature? Let me know by dropping a comment below.

The post 5 Angular CLI Tips You Should Know appeared first on onthecode.