DEV Community: ng-conf

Angular architecture matters: Monorepo

ng-conf — Wed, 15 Sep 2021 15:52:00 +0000

Sergio Ausin | ng-conf | Feb 2019

Whenever you start a new project, one of the first decisions we made is the structure of our code base. This is important because we do not want to have spaghetti code, features breaking when code changes... A few years ago, I worked in a project that comprises several apps with shared libraries. At first, everything was fine: apps were very small, few requirements; but every small app converts into a big one. The problem appeared when the first critical bug was reported. The typical steps to solve any bug were:

Identify the cause
Patch the affected code
Build a new version of the library. We used semantic versioning
Upload it to the private NPM repository
Update every app using the library
Verify that everything is working as intended (launch e2e tests, unit tests, etc.)
Finally, we released a new version of the apps

Obviously, if something went wrong we have to repeat some of these steps. This process may be a pain in the ass when you have to update several applications. On the other hand, you also have to be aware of the applications that are using the affected library. I wasted a lot of time upgrading libraries, so I decided to look for a better way to deal with this problem: the monorepository. The main advantages of this approach are:

Same library version for every app
Ease of maintenance: when you update a shared library, you update it for all apps.
No conflicts between versions

This approach is followed by Google and Facebook, among others. So, if you did not know it, you should give it a try! To help us with this task, the guys from Nrwl have created NX.

NX by Nrwl

NX is an extension for the @angular/cli that implements the monorepo-style development. It provides a set of code generators, libraries, linters…

For example, we can create an application with layered architecture: logic, user interface, etc. The picture below shows an example of layered architecture:

Monorepo folder structure

In the libs folder, there is a “three level” directory tree.

First level: the name of the apps. Inside this directory, there are the libs that our app will use
Second level: the use case/page directory
Third level: the “layer” directory. There are some typical libraries that I use: core for services, user-interface for components and a routing library which is lazy loaded by the app.

This architecture follows these rules:

A core library must not import a user interface library
A core library must not import a routes library
A user interface library must not import a routes library
A shared library must not import a non-shared library
A use case library must not import another use case library
A library must not import an app

To be consistent and make sure that we are following correctly the layered architecture, NX provides us a lint rule: “nx-enforce-module-boundaries”. To make it works, we have to set up some tags in every library. Those tags are set up in the nx.json file:



{

  "npmScope": "ngconf",

  "implicitDependencies": {

    "angular.json": "",

    "package.json": "",

    "tsconfig.json": "",

    "tslint.json": "",

    "nx.json": "*"

  },

  "projects": {

    "web-app": {

      "tags": []

    },

    "web-app-e2e": {

      "tags": []

    },

    "web-app-home-core": {

      "tags": [

        "scope:home",

        "type:core"

      ]

    },

    "web-app-home-user-interface": {

      "tags": [

        "scope:home",

        "type:user-interface"

      ]

    },

    "web-app-home-routes": {

      "tags": [

        "scope:home",

        "type:routes"

      ]

    },

    "web-app-workshops-core": {

      "tags": [

        "scope:workshops",

        "type:core"

      ]

    }

  }

}

nx.json hosted by GitHub

For this example, I have used the tags:

Scope: for the use case
Type: for the layer

Once we have set up correctly our nx.json file, we have to add the “nx-enforce-module-bundaries” rule to our tslint.json file.



{

  ...

  "rules": {

    ... // other tslint rules

    "nx-enforce-module-boundaries": [

      true,

      {

        "allow": [],

        "depConstraints": [

          {

            "sourceTag": "scope:shared",

            "onlyDependOnLibsWithTags": [

              "scope:shared"

            ]

          },

          {

            "sourceTag": "scope:home",

            "onlyDependOnLibsWithTags": [

              "scope:home",

              "scope:shared"

            ]

          },

          {

            "sourceTag": "type:core",

            "onlyDependOnLibsWithTags": [

              "type:core"

            ]

          },

          {

            "sourceTag": "type: user-interface",

            "onlyDependOnLibsWithTags": [

              "type:core"

            ]

          }

        ]

      }

    ]

  }

}

tslint.json hosted by GitHub

With this simple configuration we achieve the following goals:

Home libraries can import home and shared libs
Core libraries can only import core libraries
user-interface libraries can only import core libraries

If you try to import a user-interface library from a core lib you will see the following error message:

A project tagged with “type:core” can only depend on libs tagged with “type:core”

To sum up

NX enforces quality and consistency when we develop our apps. It gives us some good practices that we should follow when we are developing our apps!

EnterpriseNG is coming November 4th & 5th, 2021.

Come hear top community speakers, experts, leaders, and the Angular team present for 2 stacked days on everything you need to make the most of Angular in your enterprise applications.
Topics will be focused on the following four areas:
• Monorepos
• Micro frontends
• Performance & Scalability
• Maintainability & Quality
Learn more here >> https://enterprise.ng-conf.org/

Become an Angular contributor: Where to Start

ng-conf — Mon, 30 Aug 2021 22:11:23 +0000

Michael Prentice | ng-conf | Feb 2019

This is part 1 of a multi-post guide to contributing to Angular open source projects.

There are many personal and professional benefits to contributing to open source software projects. These may include an enhanced learning experience, the emotional feedback of helping a community, or establishing your public profile and building a reputation.

If you have attended ng-conf (or another Angular Community Conference) or have spoken to a past attendee, you may have seen or heard about the amazing, inclusive Angular community. You may have felt a desire to get more involved or to help give back to the community. This series of posts will help you do that while reducing some of the unknowns and concerns that many new contributors first encounter.

What and Where?

The first issue that many new contributors run into is that they have a desire to help, but they don’t know where to start.

When a new contributor looks at the Angular organization on GitHub, it can be a bit intimidating. There are 189 repositories that span AngularJS (version 1.x), Angular (version 2+), Testing, Builds, Tooling, Documentation, and Components.

Throughout this series of posts, we’re going to break this down and disambiguate these repositories… In this first post, we’ll provide focus on the core Angular Framework repository and its related packages. In future posts, we’ll cover the Angular CLI, Material Components, and provide details about some of the ancillary repositories and naming patterns.

Contributing to Angular (original background, foreground)

The angular/angular Repository

URL: github.com/angular/angular

Description

This repository hosts the Angular Framework, its core packages, and documentation.

The core packages are found in the [packages/ directory](https://github.com/angular/angular/tree/master/packages) and they include:

animations

Code related to animating HTML elements using CSS. Guide

bazel

Code related to building Angular using the open source Bazel build system

benchpress

Code related to End-to-End Performance testing of Angular using benchmarking. Guide

common

Code related to common pipes (JSON, date, async, etc.), directives (*ngIf, *ngFor, ngStyle, ngPlural, etc.), location and path strategies, and internationalization (localization, date/number/currency formatting, etc.)

compiler-cli

Code related to the ngcc and ngtsc compiler Command Line Interfaces (CLIs)

compiler

Code related to the Angular compiler including Ahead of Time (AOT), Just In Time (JIT), internationalization, parsers (templates, expressions, CSS), the view compiler, and compiler utilities

core

Code related to Change Detection, Dependency Injection, renderers, the linker, sanitization, metadata, and the View

elements

Code related to packaging Angular components as Custom Elements. Guide

forms

Code related to integrating Angular with Forms using a template-based or Reactive style. Guide

http

Code related to integrating Angular applications with backend APIs using the HTTP protocol. Guide

language-service

Code related to the Angular Language Service which provides enhanced support for editors that provide code completion, error highlighting, hints, and code navigation. Guide

platform-*

Code related to specific platforms that Angular supports including Server Side Rendering (server), web browsers (browser, browser-dynamic), and Web Workers (webworker, webworker-dynamic)

router

Code related to the Angular Router. Guide

service-worker

Code related to using Service Workers with Angular. Guide

upgrade

Code related to upgrading or downgrading modules to migrate from AngularJS to Angular. Guide

Documentation

Additionally, this repository hosts the code for the primary documentation site: angular.io (abbreviated aio in the repository). If you want to help with the documentation, you’ll need to follow the AIO Developer Guide.

Contribution Guide

The Angular Contribution Guide covers a lot of topics including where to submit questions, where to submit bugs, how to submit feature requests, how to create pull requests, and how to join the live community chat for real-time help. It also covers coding standards, Git commit message guidelines, and details about signing a Contributor License Agreement (CLA).

Additionally, you can join or participate in the Angular mailing list via Google Groups. The mailing list is a good place to ask questions that you might have before submitting a bug or feature request.

Help with new issues

Contribution is not only about making source code updates. One great way to start contributing is to comment on newly reported issues that you are knowledgeable about. This includes helping provide reproductions on StackBlitz or debugging someone’s problem locally to see if you can reproduce it. It may also include doing some research and reviewing the API docs to see if the issue reported is using the API properly and if it has the proper syntax. If you aren’t ready to start fixing bugs or updating docs, this is a great way to learn while contributing to the community.

Help with pull request reviews

If you are an experienced developer or if you want to move beyond helping others with issues, you can help by reviewing pull requests. In many cases, it is helpful just to politely ask someone to explain why they took a specific approach. Sometimes when a pull request author explains their approach to a reviewer, they realize that there is a better way that they had previously not considered. Other times they realize that they did not consider certain edge cases. The pull request author’s responses and discussion can help you learn more about the project and better equip you for making source code contributions.

If you have questions about any of these topics, please leave a comment and I will do my best to provide an answer for you.

Good First Issues

You can find issues that are good for new contributors here. These issues are generally limited in scope and have better guidance and instructions than a standard issue.

If you have questions or concerns about one of these issues, please post it as a comment on the issue. Please note that there are no stupid questions here. If you need help or guidance, please post a comment to ask for it. This is what these issues are designed for.

Note that some questions, that require a significant amount of effort to address, may receive a response that directs you to a specific educational resource. This may be a blog post, Markdown document, Podcast, etc.

Code of Conduct

Please note that the Angular Code of Conduct applies to all interactions within the Angular community. This includes public and private communications between Angular community members. The following are some examples of where you should follow the Code of Conduct: GitHub, Gitter, IRC, mailing lists, Twitter, Conferences, Podcasts, instant messaging, face to face communications, conference calls, interviews, press releases, website and blog content, etc. Any questions or violations should be sent to conduct@angular.io.

Developer Guide

The Angular Developer Guide includes details about prerequisites, getting the source code, installing dependencies, building the Angular framework, and running tests locally.

Next steps

I plan to similarly document contributing to the Angular Command Line Interface (CLI), Angular Component Dev Kit (CDK), and the Angular Material Components.

I also plan to dig into some of the details based upon feedback and what questions are raised by the community. This is especially true for the Developer Guide, but I’m waiting for a few of my PRs, that help smooth some rough edges, to land.

Subscribe to the ng-conf publication to be notified of those updates.

Simplified Angular Change Detection

ng-conf — Fri, 16 Jul 2021 19:10:48 +0000

Pankaj Parker | ng-conf | Mar 2019

A detailed guide to the core part of Angular Framework

Angular is one of the most extraordinary javascript frameworks available, because it all the features required for the web development out of the box. The change detection system is at heart of framework, it essentially helps to update bindings on a page. In this article, we will learn about change detection in detail, in a simple and easy to understand way.

Before we begin, let me highlight what principles frameworks or libraries to build applications these days.

General Application Architecture

Basically what we have is the state of our application, that we are trying to replicate on the UI, this is why we need data bindings on the template. Afterward we wire up “state + template” and replicate data on view. Also in the future, any changes that happen in the state get reflected on view.

This process of syncing HTML with the state can be termed as “Change detection”, each framework has its own way of doing it. React uses virtual DOM with reconciliation algorithm, Angular uses change detection, etc. This article will cover how change detection works in Angular.

What is Change Detection?

In simple word:- a process to synchronize the model/state changes to the view.

Let’s take a simple example. Suppose we have a simple component with its own HTML like shown below.

a simple binding example

<span>
  {{title}}
</span>
<button (click)="title='Changed'">
  Change Title
</button>

app.component.html hosted by GitHub

import { Component } from '@angular/core';
@Component({
  selector: 'my-app',
  templateUrl: './app.component.html',
  styleUrls: [ './app.component.css' ]
})
export class AppComponent  {
  title  = 'Angular'
}

app.component.ts hosted by GitHub

app.component.html has a simple span which is displaying the title property of a component and there is a button on click which will modify the title property value of changed.

demo

When the page gets happens, it shows "Angular“ on the page. Later when we click on Change Title button it changes the binding value to ”Changed“. This is super awesome, the Angular framework manages this functionality for us. What it essentially does is, track the value changes which are automagically reflected on the UI. Awesome! Check this stackblitz of the above example.

magic

Wondering 🤔 How angular updates the binding? That’s okay! Nothing really happens with magic, a framework must be running some code behind the scenes to do it. This process of updating binding is called as change detection. But the question is when angular running a change detection and how? To find out answers to these question, let’s dig a bit further.

When should change detection happen?

The simple answer to this question would be “as soon as an application’s state changes”. But when does the application’s state can change? 🤔

Event Callback
Network Call (XHR)
Timers (setTimeout, setInterval)

Do you see any similarity in the examples above? Yes! they are all asynchronous. That means we can simply say any asynchronous call can cause a change in application state and that’s the instance where we should update our state on UI. So far so good!

Suppose we’re building our own change detection system, we would be firing change detection after the above 3 situations.

Let’s try to implement our own change detection system.

We’re just making sure to call detectChanges method from each method which includes XHR call, Timer, and Event. Just assume that the detectChanges method is responsible for the actual change detection. The vague implementation of change detection would look like the example below

//network Call
getDataFromServer().then(()=> {
   //state has changed
   detectChanges();
})

//timeout function
setTimeout(()=> {
   //Call change detection
   detectChanges();
}, 5000)

element.addEventListner('click', (event) =>{
   //state could have change
   detectChanges();
});

change-detection.js hosted by GitHub

And the implementation of detectionChanges method would look like the example below

let detectChanges => () => {
  if(currentState != prevState) {
    updateView(currentState);
  }
}

detectChanges.jshosted by GitHub

Ah! but doing this thing inside our real-world application will mess up everything. Generally in a real-world application you could have this in hundreds of thousands of places. So what can be a better implementation of this? Basically, we can also say that we are supposed to fire change detection when VM turn is over.

ZoneJS to the rescue

ZoneJS is an API which has been mostly ported out from the dart language. Behind the scenes, ZoneJS monkey patches the function. Basically, it helps to keep an eye on all async tasks, and provide an ability to call code before or after a task has been completed. The Zone API has different hooks to place your code onBeforeTask, onAfterTask, onZoneCreated, onError.

ZoneJS simple example

var myZoneSpec = {
  beforeTask: function () {
    console.log('Before task');
  },
  afterTask: function () {
    console.log('After task');
  }
};

var myZone = zone.fork(myZoneSpec);
myZone.run(function() {
   console.log('My task successfully got executed.')
});

// Output:
// Before task
// My task successfully got executed.
// After task

zonejs.js

So Angular uses the power of Zones to fire change detection. What happens is, if any asynchronous call happens, ZoneJS API emits data to the onMicrotaskEmpty observable, and angular calls the detectChanges method based on the same.

What happens when Application Bootstrap?

When an angular application bootstraps, it creates a platform for a bootstrapped angular module. It creates an ApplicationRef for a whole module. Basically, ApplicationRef has a reference to allcomponents, componentTypes and isStable (zone flag), also it has methods like detatchView, attachView, tick etc. You can look at this line from the source code.

Let’s have a quick look at application_ref.ts from the angular source code. You will see that after creating an ApplicationRef, it places a subscription on the onMicrotaskEmpty observable, so as soon as the VM tick over it emits a value into onMicrotaskEmpty observable, that will be listened to by a subscription, eventually that will call the tick method inside the current Zone of application.

this._zone.onMicrotaskEmpty.subscribe({
  next: () => { 
    this._zone.run(() => { 
      this.tick();
    }); 
  }}
);

zone_tick.js hosted by GitHub

Let’s look into how the tick method works.

tick(): void {
    try {
      this._views.forEach((view) => view.detectChanges());
      if (this._enforceNoNewChanges) {
        this._views.forEach((view) => view.checkNoChanges());
      }
    } catch (e) {
      ...
    } finally {
      ...
    }
  }

tick_implementation.js hosted by GitHub

Implementation of the tick method looks pretty simple. It basically loops over each view (components are internally referred to as view) and calls their detectChanges method which is responsible for updating UI bindings. The interesting thing is on the 4th line, it runs only in dev mode because in the application_ref.ts constructor it sets to_enforceNoNewChanges property.

this._enforceNoNewChanges = isDevMode()

Above is a gist about how change detection works, let's dig deeper how we can use this while crafting Angular application.

Change Detection Strategy

In total angular has two flavours of change detection.

Default
OnPush

Let's look at each change detection strategy.

Default

When you don’t specify the change detection strategy on the Component decorator, by default angular applies the Default strategy.

Any Angular application consists of components, the component where we bootstraped a root component. and we can draw out a diagram of an application with regards to a component. So if change detection fires in any component it will cause the tick method to be fired in the ApplicationRef. Ultimately firing detectChanges method from root component to its descendants as shown in the diagram below.

change detection strategy — Default

The problem with the default strategy is, changes that have been detected in on any component lead to firing change detection on all the components (if all component are set to Default strategy. But most of the time we don’t need such behavior, it would eventually affect the performance of an application by running multiple unnecessary change detection cycle.

Can we solve this problem efficiently? Luckily there is a solution, you can easily switch the change detection strategy to OnPush.

OnPush

onPush strategy makes component change detection bit smarter. It runs a change detection for a component only when Input bindings value of a component is changed. Actually, it compares the reference between oldValue and newValue of a Input binding. That means if a parent components properties of an object do not change it would not trigger change detection for that component.

change detection strategy — OnPush

As you can see in the above diagram, we’ve set a level 1 component to OnPush strategy. Both the component have the input of name. The root component is passing the input name to both the component with name1 and name2 respectively. On initial page load change detection fires on all the components. And later the right-hand side component emits an event, which tends to change the root component state.

So, again change detection started firing from the root component. Then change detection runs for the 1st level (OnPush) component. Before firing change detection on those components, it checks for the input binding name newValue and oldValue and if there are changes then only fire change detection for that component and it’s descendants. Changes have been detected for the right-hand side component. So change detection gets triggered only for right-hand side branch of components. By setting OnPush change detection strategy we can significantly improve application performance.

Make sure you enforce immutability on the Input binding value while using component OnPush strategy.

Before proceeding we can have a look at a real application that is built using both change detection strategies. This application is deployed on https://pankajparkar.github.io/demystifying-change-detection.

This is a pretty simple application, it has posts displayed on the page and each post can have comments. The way that the application architected, it’s component hierarchy shown below.

root => post-list (all posts)=> post (single post)=> comment-list

The black border around the component indicates the boundary of that particular component.

Since we want to keep eye on when change detection fires, we highlight the components to yellow as soon change detection fires. We have used ngAfterViewChecked which tells us that the change detector has visited the current component.

highlight component on change detection fired

ngAfterViewChecked(): void {
  this.zone.runOutsideAngular(() => {
    this.el.nativeElement.classList.add('highlight')
    setTimeout(() => {
      this.el.nativeElement.classList.remove('highlight')
    }, 1500)
  })
}

highlight.ts hosted by GitHub

all component on default strategy

So you can see in the above diagram, on initial page load gets highlighted and they applied with highlight class. Thereafter while adding a comment in a comment field, you can see that on each keyup event it fires change detection and all component get highlighted.

Now, look at the uses of the OnPush change detection strategy, how it makes a difference in the change detection run cycle.

Right now all the components are set to OnPush strategy. So on page load change detection runs for all components, that’s perfectly fine. Thereafter when I tried to add a text in the comment section, it fires change detection for the comments section of the current component, not others. That’s great! But you can see that the other components post components are getting highlighted.

Ah! What is going on? PostComponent is already set to OnPush, there is no Input binding on that component but it seems to be changed. Is this a bug, is the ngAfterViewChecked lifecycle hook being called without reason? Perhaps.

Let’s not get confused. We can look into further.

Taken from Max Koretskyi article from @angularInDepth

Refer to the above diagram — When change detection is running for a parent component, it follows a certain process. Initially, it updates the binding of child components, then calls the ngOnInit, ngDoCheck, ngOnChanges lifecycle hook of the child component. We can also state that this process happens before rendering the parent component. Then it updates the DOM on the current component. Later it runs change detection for a child component(depending on the strategy), followed by calling hooks ngAfterViewChecked, ngAfterViewInit.

That means while running change detection of a parent component, it runs ngDoCheck, ngContentChecked, ngAfterViewChecked lifecycle hooks of child component irrespective of a component change detection strategy.

Check this Github issue link logged by Pascal Precht ʕ•̫͡•ʔ

You might have missed, There is a catch. If you look at the change detection strategy of PostListComponent, it has been set to OnPush strategy, but there is no Input binding passed to it. So when PostListComponent component retrieves a data form the ngOnInit hook, it doesn’t run change detection from the root component (AppComponent). But it prevents to running change detection on PostListComponent since no Input have been changed. So we had to call either the detectChanges method or the markForCheck method of ChangeDetectorRef dependency. This will force change detection to run throughout. Such cases can easily happen in a real-world application. You can tackle such situations by calling markForCheck or detectChanges.

TL;DR

The difference between calling `markForCheck`, `detectionChanges` and tick would be

markForCheck — Once you call markForCheck method on component change detector, it will traverse a component tree till root, and mark those components to run change detection only for the next iteration. It will run change detection on marked component even though they are using the OnPush strategy.

detectChanges — When you call this method on changeDetectorRef provider, it will run change detection from the current component and all it’s descendants. While running change detection it keeps the change detection strategy in mind.

tick — The tick method applicable on ApplicationRef API. It will run change detection from the root component to all its descendants. It respects the change detection strategy of a component.

There are two more methods that exist in the ChangeDetectorRef provider

detach — By calling this method you can pluck out a component from the tree of the current component to its descendants. Whenever there is a need for running change detection on the component you could call detectChanges or markForCheck method depends on your need.

reattach — A Plucked a component from the tree can be easily brought back to its original place by calling reattach method. This can be used for fine tune application performance.

I hope this article has helped you to understand the mystery of what’s under the hood of change detection. Eventually, this will also make you comfortable with predicting when change detection runs in your application. By applying various flavors you can easily gain performance benefits in your application.

I gave a talk about this topic recently in #ngIndia

If you like this article press 👏 clap button 50 times or as many times you want. Feel free to ask a question if you have any. Thanks a lot for reading!

Thanks Tayamba Mwanza for grammatical review 😊

ng-conf: Join us for the Reliable Web Summit

Ready to build the most reliable web applications possible? Join us for the Reliable Web Summit this August 26th-27th, 2021 to learn how! A summit conference on building reliable web applications, including the following three pillars:

Scalable infrastructure and architecture
Maintainable Code
Automated Testing

https://reliablewebsummit.com/

MockStore in NgRx v7.0

ng-conf — Mon, 12 Jul 2021 18:30:49 +0000

John Crowson | ng-conf | Apr 2019

NgRx v7.0 included the released of a new @ngrx/store/testing module that features a mock Store to be used in testing NgRx applications. The module was introduced in #1027 with some documentation following in #1591.

Note: You can use this API and functionality in NgRx v5 and v6 using the standalone pngrx-mockstore package.

Currently, the documentation is light and doesn’t include a complete working code sample. I’ll provide two examples that should help clear things up.

Existing: StoreModule

It has been possible to condition the NgRx store in a unit test by providing the StoreModule in the testing module configuration. The StoreModule creates a store with the initial state defined in the store’s reducer. To condition the desired state for a given test case, you could have to dispatch several actions.

New: MockStore

The MockStore class provides a simpler way to condition NgRx state in unit tests. You provide an initial default state, then update the state using setState(<nextState>).

Let’s see how MockStore can simplify an existing test suite:

Testing Auth Guard Example

The NgRx example-app contains an AuthGuard that provides us a simple example of using the MockStore:

// NgRx v7.3.0
@Injectable({
  providedIn: 'root',
})
export class AuthGuard implements CanActivate {
  constructor(private store: Store<fromAuth.State>) {}

  canActivate(): Observable<boolean> {
    return this.store.pipe(
      select(fromAuth.getLoggedIn),
      map(authed => {
        if (!authed) {
          this.store.dispatch(new AuthApiActions.LoginRedirect());
          return false;
        }

        return true;
      }),
      take(1)
    );
  }
}

auth-guard.service.ts hosted by GitHub

The AuthGuard selects getLoggedIn from the store. If the latest getLoggedIn is true, a LoginRedirect action is dispatched and the function returns false. If the latest getLoggedIn is false, it returns true.

The existing AuthGuard test uses the StoreModule, which requires the test to dispatch a LoginSuccess action to condition the getLoggedIn selector to return true:

// NgRx v7.3.0
describe('Auth Guard', () => {
  let guard: AuthGuard;
  let store: Store<any>;

  beforeEach(() => {
    TestBed.configureTestingModule({
      imports: [
        StoreModule.forRoot({
          ...fromRoot.reducers,
          auth: combineReducers(fromAuth.reducers),
        }),
      ],
    });

    store = TestBed.get(Store);
    spyOn(store, 'dispatch').and.callThrough();
    guard = TestBed.get(AuthGuard);
  });

  it('should return false if the user state is not logged in', () => {
    const expected = cold('(a|)', { a: false });

    expect(guard.canActivate()).toBeObservable(expected);
  });

  it('should return true if the user state is logged in', () => {
    const user: any = {};
    const action = new AuthApiActions.LoginSuccess({ user });
    store.dispatch(action);

    const expected = cold('(a|)', { a: true });

    expect(guard.canActivate()).toBeObservable(expected);
  });
});

auth-guard.service.spec.ts hosted by GitHub

Let’s refactor the same tests to condition the store’s state without actions using MockStore:

// Future version of example-app using MockStore
import { provideMockStore, MockStore } from '@ngrx/store/testing';

describe('Auth Guard', () => {
  let guard: AuthGuard;
  let store: MockStore<fromAuth.State>;
  const initialState = {
    auth: {
      loginPage: {} as fromLoginPage.State,
      status: {
        user: null,
      },
    },
  } as fromAuth.State;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [AuthGuard, provideMockStore({ initialState })],
    });

    store = TestBed.get(Store);
    guard = TestBed.get(AuthGuard);
  });

  it('should return false if the user state is not logged in', () => {
    const expected = cold('(a|)', { a: false });

    expect(guard.canActivate()).toBeObservable(expected);
  });

  it('should return true if the user state is logged in', () => {
    store.setState({
      ...initialState,
      auth: {
        loginPage: {} as fromLoginPage.State,
        status: {
          user: {
            name: 'John',
          },
        },
      },
    });

    const expected = cold('(a|)', { a: true });

    expect(guard.canActivate()).toBeObservable(expected);
  });
});

auth-guard.service.spec.ts hosted by GitHub

Here are the steps:

Line 6: Declare a MockStore using the same type assertion that is used when declaring the Store in the AuthGuard (fromAuth.State).
Line 7: Create an initial state conforming to the same state interface that was asserted on line 6. This will be the default state for all tests. Since fromAuth.State extends fromRoot.State and our tests only depend on the the user attribute, we can cast everything else.
Line 19: Provide the MockStore using provideMockStore, passing in the initialState created in the previous step.
Line 22: Inject the Store inside the test.
Line 31: To condition a different state, use setState.

Testing Effect + withLatestFrom Example

I came across NgRx issue #414 which describes difficulty testing effects that incorporate state using the withLatestFrom operator and the StoreModule.

@Effect()
example$ = this.actions$.pipe(
  ofType(ActionTypes.ExampleAction),
  withLatestFrom(this.store.pipe(
    select(fromExample.getShouldDispatchActionOne)
  )),
  map(([action, shouldDispatchActionOne]) => {
    if (shouldDispatchActionOne) {
      return new ActionOne();
    } else {
      return new ActionTwo();
    }
  })
);

The effect’s injected state couldn’t be changed after TestBed.get(<effect>) had been called, making it difficult to test different values selected by getShouldDispatchActionOne in the above snippet. The three common workarounds were:

Use Jasmine’s SpyOn to mock the return value of state.select(…): spyOn(store, 'select').and.returnValue(of(initialState)). However, select is now an RxJs operator. ❌
Move TestBed.get(<effect>) from beforeEach into each individual test after the state is conditioned appropriately. 😐
Provide a mockStore (hey, don’t we have one of those now?). 😀

Let’s see how we can test effects that use withLatestFrom using the MockStore:

Let’s add a new effect, addBookSuccess$, to the NgRx example-app’s BookEffects. When a new book is successfully added, we’ll select the books the user now has in their collection the store, then display an alert with a different message depending on the quantity:

@Injectable()
export class BookEffects {
  @Effect({ dispatch: false })
  addBookSuccess$ = this.actions$.pipe(
    ofType(CollectionApiActionTypes.AddBookSuccess),
    withLatestFrom(this.store.select(fromBooks.getCollectionBookIds)),
    tap(([action, bookCollection]) => {
      if (bookCollection.length === 1) {
        window.alert('Congrats on adding your first book!')
      } else {
        window.alert('You have added book number ' + bookCollection.length);
      }
    })
  );

  // search$ effect deleted for simplicity

  constructor(
    private actions$: Actions<FindBookPageActions.FindBookPageActionsUnion>,
    // ...
    private store: Store<fromBooks.State>
  ) {}
}

book.effects.ts hosted by GitHub

We can use the MockStore to condition the state, allowing us to test each of the two cases:

import * as fromBooks from '@example-app/books/reducers';
import * as fromSearch from '@example-app/books/reducers/search.reducer';
import * as fromChildBooks from '@example-app/books/reducers/books.reducer';
// Omitting autoimports
describe('BookEffects', () => {
  let effects: BookEffects;
  let actions$: Observable<any>;
  let store: MockStore<fromBooks.State>;
  const initialState = {
    books: {
      search: {} as fromSearch.State,
      books: {} as fromChildBooks.State,
      collection: {
        loaded: true,
        loading: false,
        ids: ['1']
      }
    }
  } as fromBooks.State;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        BookEffects,
        {
          provide: GoogleBooksService,
          useValue: { searchBooks: jest.fn() },
        },
        provideMockActions(() => actions$),
        provideMockStore({ initialState }),
      ],
    });

    effects = TestBed.get(BookEffects);
    actions$ = TestBed.get(Actions);
    store = TestBed.get(Store);
    spyOn(window, 'alert');
  });

  describe('addBookSuccess$', () => {
    it('should print congratulatory message when adding '
       + 'the first book', (done: any) => {
      const action = new AddBookSuccess(generateMockBook());
      actions$ = of(action);

      effects.addBookSuccess$.subscribe(() => {
        expect(window.alert)
          .toHaveBeenCalledWith(
            'Congrats on adding your first book!'
          );
        done();
      });
    });

    it('should print number of books after adding '
       + 'the first book', (done: any) => {
      store.setState({
        ...initialState,
        books: {
          search: {} as fromSearch.State,
          books: {} as fromChildBooks.State,
          collection: {
            loaded: true,
            loading: false,
            ids: ['1', '2']
          }
        }
      });

      const action = new AddBookSuccess(generateMockBook());
      actions$ = of(action);

      effects.addBookSuccess$.subscribe(() => {
        expect(window.alert)
          .toHaveBeenCalledWith(
            'You have added book number 2'
          );
        done();
      });
    });
  });
});

book.effects.spec.ts hosted by GitHub

Here are the steps, similar to those in the AuthGuard Example:

Line 9: Declare a MockStore using the same type assertion that is used when declaring the Store in the BookEffects (fromBooks.State).
Line 10: Create an initial state conforming to the same state interface that was asserted on line 9. This will be the default state for all tests. Since fromBooks.State extends fromRoot.State and our tests only depend on the the ids attribute, we can cast everything else.
Line 32: Provide the MockStore using provideMockStore, passing in the initialState created in the previous step.
Line 38: Inject the Store inside the test.
Line 59: To condition a different state, use setState.

Thanks for reading! You can follow me on Twitter @john_crowson :)

For more Angular goodness, be sure to check out the latest episode of The Angular Show podcast.

ng-conf: Join us for the Reliable Web Summit

Come learn from community members and leaders the best ways to build reliable web applications, write quality code, choose scalable architectures, and create effective automated tests. Powered by ng-conf, join us for the Reliable Web Summit this August 26th & 27th, 2021.
https://reliablewebsummit.com/

Consistent Console Logs in Angular

ng-conf — Fri, 09 Jul 2021 15:22:08 +0000

Jared Youtsey | ng-conf | Apr 2019

When you have to log, do it consistently.

Logging is necessary. It allows us to debug in both development and production. But console is disallowed by tslint by default. And for good reason. Console logging is a mess most of the time. If you can just willy-nilly console.log(whatever) then your logs are pretty much useless.

We can end up with too much logging in production, which can slow our application down, and not enough in development where we need more details.

I’ve had to deal with this issue on multiple projects and have written a static logger class in Angular that allows us to control what we log and where.

Here is the gist https://gist.github.com/jkyoutsey/e99336d58c2c83bc0ba03cde78fcc64e

In a nutshell you have the following options:

debug|info|warn|error will log in all environments unless you also set the optional devOnly: boolean argument to true. Then the module and method will still log, but not the message argument. This allows for tracing without leaking sensitive data in a production environment.

devOnly|techDebt do not have the optional devOnly argument and will only ever log to the console in a non-production environment.

By environment I mean your src/environments/environment.ts’s production property value. If it’s false you’ll get all log statements. If it’s true you’ll only get debug|info|warn|error.

Your output will now be consistently formatted, making it easier to read, parse, or even analyze.

Sample Logger Usage

The above commands result in the following output in Chrome DevTools:

Readable Console Output

I’ve even created a VisualStudio Code snippet to make it easier:

"Log All The Things": {
    "prefix": "ll",
    "body": [
        "Logger.${LEVEL}('${CLASS}', '${METHOD}', `${message}`);"
    ]
}

logger.ts.vscode.snippet.txt hosted by GitHub

And I’ve got unit tests for it so it won’t impact your coverage (but you shouldn’t worry too much about coverage): https://gist.github.com/jkyoutsey/01e3e2db4ba9a570245bd63d543960e1

If you find this useful or interesting, please clap!

ng-conf: Join us for the Reliable Web Summit

Editing Tabular Data in Angular

ng-conf — Tue, 06 Jul 2021 18:06:13 +0000

Jim Armstrong | ng-conf | May 2019

A fun dive into everything from custom Directives to advanced ViewChildren

Introduction

This article targets beginning to intermediate-level Angular developers and covers a wide variety of topics that arise in production applications. While centered around the concept of editing tabular data, these techniques may be used in a variety of other Angular applications.

For anyone who has read at least one of my articles, you should understand that my background is applied mathematics and scientific computing. So, this article continues the trend of exploring the use of Angular in scientific and business (analytics) applications.

Working with time-series data is a fundamental concept in numerous business and engineering sectors. In this context, front-end development is largely concerned with minor transformations and display of data. Concepts such as data grids, tabular display, and visualization with charts are quite familiar to front-end devs. What is likely to be less familiar is the need to edit one or more values in a time series.

Data often comes from physical instruments that have some degree of fallibility and/or manual entry that is subject to typical human error. So, at some point during your FE career, it may be necessary to develop components that facilitate both the display and editing of tabular data. Only the latter is discussed in this article.

The Project

Before continuing, point your friendly, neighborhood browser to this Github, so that you can follow along with the project deconstruction.

theAlgorithmist/Angular-Table-Editing on github.com

Techniques covered in the remainder of the article include

Using Angular Material from a feature module
Custom Directives (including @HostListener and @HostBinding)
@ViewChild vs @ViewChildren and subscribing to changes on the latter
Validate while typing
Custom Events

The project is organized into a few simple folders,

— src/app

— — features

— — — table-edit (table edit component, custom directive, and feature module

— — libs (because we always need some custom libraries — otherwise, I would be out of business :)

— — models (all data models)

— — services (because data has to come from somewhere)

The data used in this sample project comes from an actual, historical dataset on used-car sales from the book, “Machine Learning in R” by Lantz. For tutorial purposes, suppose that all data in the table comes from reliable sources except mileage, which is hand-entered in another application. The code provided with this article simulates a use-case where someone with edit and/or approval authority visually examines a series of data to search for outliers. That data is displayed in a table which contains an Input field in one column to support editing that particular item. To make the demo more realistic, the original data was hand-edited to insert a number of outliers.

And, it would not be a project if we did not have some requirements! Every one of the following requirements was taken from an actual client application I’ve worked on in the past.

1 — Display the data in a table with headers and data returned from a service.

2 — One and only one column is editable, the car mileage. This is hardcoded into the application and will not change.

3 — The table should be paged. The number of initial rows and allowable rows for padding will be provided. Allow sorting by date of manufacture as older cars should generally have more mileage.

4 — A user may tab between rows, but indication of an edited value is via pressing ‘Return’. I’ve also been required to add a small button to the side of the input in actual projects, but that’s not required for this demo.

5 — User inputs are validated while typing. Only numerical, integer inputs (with no minus sign) are allowed. If the user enters an incorrect character, reset the input field value to its value when the user first focused on the field (or the most recently edited and valid value).

6 — Inputs fields have a small, grey border by default (color to be provided and not changeable). When the user successfully edits a mileage value, replace the border with a green color (to be provided and not changeable).

7 — Whenever the user navigates to a new page, the input borders should be reset to the default value.

8 — Whenever a user clicks on a row, whether they edit a value or not, record that click and store the number of clicks on each car id to be returned to the server. I actually had a client who wanted to do this to capture ‘interest’ in a particular row of data, i.e. they believed the click was indicative of interest in the data whether the user actually edited the data or not. Okay, well, as long as the money’s there … I don’t care :)

9 — Capture whenever the user moves from one page to another so that we can potentially take action in the future. Yes, folks, that’s a common one … people want to do something, but they won’t know what it is until well into the future.

10 — Add a ‘Save’ button. Clicking on this button will send a record of all edited data to the server. For tutorial purposes, the button will be implemented, but the handler only logs the edited data to the console.

In an actual application, a person with edit authority would perform the data editing and then after saving the data, a person with approval authority would be responsible for viewing all data and approving the modifications. This article is only concerned with the edit portion of the process.

Material Table

Enough has been written on the use of Material and Material Table in particular, that there is little benefit from adding a lot of explanation in this article. Suffice to say that I personally prefer using ngContainer to create templates for each column. The most important column in the layout provided below is mileage, and there is a Material Input field that allows editing of the mileage values.

<div class="mat-elevation-z8">

  <table mat-table matSort [dataSource]="dataSource">

    <tr mat-header-row *matHeaderRowDef="displayOrder"></tr>

    <tr mat-row *matRowDef="let row; columns: displayOrder" (click)="onTouched(row)"></tr>

    <ng-container matColumnDef="year">
      <th mat-header-cell *matHeaderCellDef mat-sort-header="year"> Year </th>
      <td mat-cell *matCellDef="let element"> {{element.year}} </td>
    </ng-container>

    <ng-container matColumnDef="model">
      <th mat-header-cell *matHeaderCellDef> Model </th>
      <td mat-cell *matCellDef="let element"> {{element.model}} </td>
    </ng-container>

    <ng-container matColumnDef="price">
      <th mat-header-cell *matHeaderCellDef> Price </th>
      <td mat-cell *matCellDef="let element"> {{element.price}} </td>
    </ng-container>

    <ng-container matColumnDef="mileage">
      <th mat-header-cell *matHeaderCellDef> Mileage </th>
      <td mat-cell *matCellDef="let element">
        <mat-form-field>
          <input matInput class="bordered editable" type="text" min="0" max="1000000" value="{{element.mileage}}" id="{{element.carid}}"
                 (keyup)="__checkNumber($event)" (inputChanged)="onEdited($event)" >
          <mat-hint><strong>Mileage</strong></mat-hint>
        </mat-form-field>
      </td>
    </ng-container>

    <ng-container matColumnDef="color">
      <th mat-header-cell *matHeaderCellDef> Color </th>
      <td mat-cell *matCellDef="let element"> {{element.color}} </td>
    </ng-container>

    <ng-container matColumnDef="transmission">
      <th mat-header-cell *matHeaderCellDef> Transmission </th>
      <td mat-cell *matCellDef="let element"> {{element.transmission}} </td>
    </ng-container>

  </table>

  <!-- options should always be Fibonacci :) -->
  <mat-paginator [length]="150" [pageSize]="5" [pageSizeOptions]="[5, 8, 13]" showFirstLastButtons (page)="onPage($event)"></mat-paginator>

  <div align="right">
    <button mat-button color="primary" (click)="onSave()">Save</button>
  </div>
</div>

table-edit.component.html hosted on GitHub

Note the inclusion of the Material paginator near the end of the layout.

The necessary Material modules are separated into a feature module as shown in the file

/src/app/features/material.module.ts

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

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

import {
  MatTableModule,
  MatPaginatorModule,
  MatInputModule,
  MatSortModule,
  MatButtonModule
} from '@angular/material';

const PLATFORM_IMPORTS: Array<any> = [BrowserAnimationsModule];

const MATERIAL_IMPORTS: Array<any> = [MatTableModule, MatPaginatorModule, MatInputModule, MatSortModule, MatButtonModule];

@NgModule({
  imports: [PLATFORM_IMPORTS, MATERIAL_IMPORTS],

  exports: MATERIAL_IMPORTS,

  declarations: []
})
export class MaterialModule { }

which is imported into the table edit module

/src/app/features/table-edit/table-edit.module.ts

import { NgModule     } from '@angular/core';
import { CommonModule } from '@angular/common';

import { MaterialModule } from '../material.module';

import { TableEditComponent     } from '../table-edit/table-edit/table-edit.component';
import { InputSelectorDirective } from './directives/input-selector.directive';

export const TABLE_COMPONENTS: Array<any> = [TableEditComponent, InputSelectorDirective];

@NgModule({
  imports: [MaterialModule, CommonModule],

  exports: TABLE_COMPONENTS,

  declarations: TABLE_COMPONENTS
})
export class TableEditModule { }

This allows the table-edit functionality to be easily imported into any project, including ours in /src/app/app.module.ts

import { BrowserModule    } from '@angular/platform-browser';
import { NgModule         } from '@angular/core';
import { HttpClientModule } from '@angular/common/http';

// feature module
import { TableEditModule  } from './features/table-edit/table-edit.module';

// app-level components
import { AppComponent } from './app.component';

const APP_DECLARATIONS: Array<any> = [AppComponent];

@NgModule({
  declarations: APP_DECLARATIONS,
  imports: [
    BrowserModule, HttpClientModule, TableEditModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Data Models

All data models (interfaces) for the application are in the /src/app/models/models.ts file. A single record of car data is modeled as

export interface ICarData
{
  carid: number;
  year: number,
  model: string,
  price: number
  mileage: number;
  color: string;
  transmission: TransmissionEnum;
}

and the entire model (including headers) is

export interface ICarDataModel
{
  header: Array<string>;

  data: Array<ICarData>;
}

When the user edits car mileage, it is necessary to record the id of the edited vehicle and the new mileage value, which are stored in an IEditedData instance.

export interface IEditedData
{
  id: number;

  value: number;
}

Main App Component

The main app component, /src/app/app.component.ts simply loads a car data model from a JSON file and then separates the header and car data into two bound variables in the __onModelLoaded method,

protected __onModelLoaded(result: ICarDataModel): void
{
  // this handler could be used to check the integrity of returned data
  this.header = result.header.slice();

  // assign a copy of the returned model to the bound data
  this.data = result.data.map( (car: ICarData): ICarData => {return JSON.parse(JSON.stringify(car))} );
}

From this point, the remainder of the application is handled by the table edit component.

Table Edit Component

The table edit component (/src/app/features/table-edit/table-edit/table-edit.component.ts) employs an InputSelectorDirective to select individual Input fields. This is accomplished by using a class selector in the Directive,

@Directive({
  selector: '.editable'
})
export class InputSelectorDirective implements OnInit

and then applying that class in the Input field in the template,

/src/app/features/table-edit/table-edit/table-edit.component.html

<input matInput class="bordered editable" type="text" min="0" max="1000000" value="{{element.mileage}}" id="{{element.carid}}"
       (keyup)="__checkNumber($event)" (inputChanged)="onEdited($event)" >

A ViewChild of this Directive provides a direct reference to a single instance of that Directive, applied to an Input field with the class ‘editable.’ This application, however, requires references to all such input fields in the current table page. This is where ViewChildren and QueryList are used.

/src/app/features/table-edit/table-edit/table-edit.component.ts

@ViewChildren(InputSelectorDirective)
protected _inputs: QueryList<InputSelectorDirective>;   // reference to QueryList returned by Angular
protected _inputsArr: Array<InputSelectorDirective>;    // Array of Directive references

The QueryList provides a reference to the InputSelectorDirective for all Input fields in the current page.

Two Typescript Records are used to store edited data and record ‘row touches’,

protected _edited: Record<string, number>;
protected _touches: Record<string, number>;

Some programmatic support is required to interface with the Material table, specifically a data source, reference to the MatPaginator (paginator), and MatSort (sorting). This is accomplished with two ViewChild instances and a public variable (for binding)

@ViewChild(MatPaginator)
protected _paginator: MatPaginator;

@ViewChild(MatSort)
protected _sort: MatSort;

// (Material) Datasource for the table display
public dataSource: MatTableDataSource<ICarData>;

That concludes the basic setup for this component. In terms of logic, a summary of relevant class methods follows to aid in your deconstruction of the application.

Method: onEdited(evt: IEditedData): void

This method is called whenever the mileage data is edited. It first checks the argument and event id and then stores the edited data in the class edited-data Record.

Method: onTouched(row: ICarData): void

This method is called whenever a user clicks on a table row, which is taken as an indication of interest in that data, whether it is edited or not. Yes, I’ve actually had to implement this for a client in a real application. As long as the check clears the bank, it works for me :)

Method: onSave(): void

This is a placeholder for you to implement a service call to store the edited data should you wish to modify the code for use in a production environment. The edited data is logged to the console to help visualize formatting of the edited-data Record.

Method: onPage(evt: PageEvent): void

This is another placeholder method in case you want to modify the application to perform some function whenever the user pages to another set of table data.

Method: __checkNumber(evt: any): boolean

This method is called to validate a number while typing. It defers the validation to the library method, Validation.checkNumber(), which is useful for numeric entry of physical properties that must be greater than or equal to zero.

Method: __onInputsChanged(): void

This method is executed whenever the QueryList of Input fields changes (i.e. on page change). The method’s primary action is to reset the border color on all new fields. Modify for additional functionality as you see fit.

Since the QueryList of InputSelectorDirective instances changes every time the user navigates to a new page of the table, it is necessary to subscribe to changes in that list. The subscription is made in the ngAfterViewInit lifecycle method,

public ngAfterViewInit(): void
{
  // subscribe to changes in the query list
  this._inputs.changes.subscribe( () => this.__onInputsChanged() );
}

and here is the handler,

protected __onInputsChanged(): void
{
  // input query list changed (which happens on profile selection)
  this._inputsArr = this._inputs.toArray();

  // set default border color on everything
  if (this._inputsArr && this._inputsArr.length > 0) {
    this._inputsArr.forEach( (input: InputSelectorDirective): void => {input.borderColor = '#cccccc'});
  }
}

The use of this method and onPage() provides a natural separation of the primary focus on Input field changes with any other activities that may be requested on page change. The result is better focus on single responsibility between methods.

Input Selector Directive

This Directive provides a collection of Output and event handlers to facilitate editing the mileage data in the table.

The single Output is ‘inputChanged’ and is emitted whenever a mileage value is changed,

/src/app/features/table-edit/directives/input-selector.directive.ts

@Output('inputChanged')
protected _changed: EventEmitter<IEditedData>;

A single HostBinding to the border-color style facilitates changing the border color of each Input field based on whether that element is initially displayed or in an edited state.

@HostBinding('style.border-color')
public borderColor: string = '#cccccc';

There are two host listeners, one for the ‘focus’ event and the other for ‘keyup.’ When an Input field receives focus, it is necessary to capture the current value and the id associated with that mileage value. The former is used to re-populate the field with the initial value in the event a typing error is detected. The id must be emitted along with the edited value in order to associate the edited value with a specific record of car data.

The ‘keyup’ listener performs basic validation on the current numerical input for the mileage value. A valid value on clicking ‘Return’ causes the Input field to be colored green. Input errors while typing cause the field to be repopulated with the last-known-good value.

@HostListener('keyup', ['$event']) onKeyUp(evt: KeyboardEvent): boolean
{
  // test for singleton leading negative sign as first character
  const v: string = this._input.value;
  const n: number = v.length;

  // for now, allow a blank field as it is possible that the entire number could be deleted by backspace before
  // entering a new number
  if (n == 0) {
    return true;
  }

  // physical quantities may not be negative and a decimal is currently not allowed
  if ( (n == 1 && v == "-") || (evt.key == ".") )
  {
    this.hasError     = true;
    this._input.value = this._currentValue.toString();

    return true;
  }

  // check for most recent keystroke being an enter, which is currently the only way to indicate an edit
  const code: string = evt.code.toLowerCase();
  if (code == 'enter' || code == 'return')
  {
    if (!isNaN(+v) && isFinite(+v))
    {
      this.hasError      = false;
      this._currentValue = +v;

      // set 'edited' border color and emit the changed event
      this.borderColor = '#66CD00';

      this._changed.emit({id: this._currentID, value: +v});
    }
    else
    {
      this.hasError     = true;
      this._input.value = this._currentValue.toString();
    }

    return true;
  }

  this.hasError = !Validation.checkNumber(evt);

  if (this.hasError)
  {
    console.log( "error: ", this._currentValue );
    // indicate an error by replacing the bad input with the 'current' or last-known good value
    // this may be altered in a future release
    this._input.value = this._currentValue.toString();
  }

  return true;
}

input-selector.directive.ts hosted by GitHub

Summary

This has been a long and somewhat involved deconstruction. Scientific, engineering, and business-analytic applications often expose a much higher degree of interactivity to FE devs. I hope this article and the supporting code has helped beginning- and intermediate-level Angular developers with their understanding of the platform.

ng-conf: Join us for the Reliable Web Summit

How To Analyze An Angular Project with Fortify

ng-conf — Fri, 02 Jul 2021 18:15:25 +0000

Rogelio Flores Zubillaga | ng-conf | May 2019

Learn to run static code analysis on your Angular Typescript project.

Angular + Fortify for the win

Recently, I started a small Angular application that acts as an installer for a distributed API Gateway application. As part of our testing and quality engineering, we always inspect our web applications. However, we hadn’t done much with static code analysis. It was mostly security dynamic analysis over our client and server communication. Fortify is a product that we have used for this since the company that I work for owns it, and recently they added support for Typescript in their static code analysis. So this was a great opportunity to use it on our Angular project.

About Fortify

Fortify is a product of Micro Focus that allows security scans of applications. Many people are familiar with “WebInspect”, which some people use as a synonym for Fortify.

Think of Fortify as big happy family where there are several siblings. Each sibling is a product or program you can run. “Fortify WebInspect” provides dynamic analysis of web applications and services. This is like the first-born son that makes their parents proud. You always want to show others that you run his security scans. Some of your customers might even require that you do this. It helps you prove that your software is secure.

Fortify Static Code Analyzer (SCA) identifies security vulnerabilities in the source code. Think of it as the sibling everyone dislikes. Like the know-it-all boy in the Polar Express. Nobody likes him because it will usually tell you things you don’t like to hear. Such as “your code sucks”, or “your code is insecure”. So you try to avoid him.

Fear no more.

There is one in every family

In this article, I will focus only on Fortify SCA. Yes, the annoying kid. Fortify SCA is best used during the software development phase. Thus, the target audience of this article are software engineers. Whether involved in the development, or the testing and quality of web applications.

Most Angular applications use Typescript. And Angular is one of the most used web frameworks nowadays, so let’s explore how to use Fortify with Angular. Our method will apply to any project that uses Typescript and Javascript though.

Obtaining and Installing Fortify

We’re going to talk about the on-premise client of Fortify SCA. There is Fortify On Demand, which is the SaaS offering (more on that later). If you don’t have Fortify yet, you can get it here. There is the option to get a free trial, which comes with some limitations. I suggest you download Fortify SCA and “Applications”, which means you will get the Source Analyzer (the scanner), the Scan Wizard, the Report Generator, Audit Wizard, and others. We will talk at least about these four. Once you have downloaded the software, you go through these steps to install them:

Run installbuilder, found in the compressed file you downloaded. Hit Next (after each of the following steps as well).
Accept the license agreement
Accept default installation directory or provide your own
Specify where your license file fortify.license is
(Optionally) provide server settings for security content updates. I left the default Update server URL and didn’t need to provide a proxy host/port.
Answer if you want to migrate from a previous SCA installation (I didn’t have one, so I said no)
Select if you want to install sample source code projects

At the end of the installation, you will see a screen like this:

Last screen of the Fortify SCA installer

When the installation completes, you will see a checkbox that reads “update security content after installation”. If you leave it selected (default), a quick update will run. When it’s done, a few seconds later, a new dialog appears with the updates, which you can dismiss with an OK button. You are now ready to start using it to scan your project.

Creating A Script To Scan (Analyze) Your Code

I know of at least three ways you can run a static code analysis with Fortify. One is to simply run sourceanalyzer from the command line. A second way is using the Scan Wizard to help you create a script that runs the scan. And the third way is to use the Audit Workbench to run your scan, which is probably the easiest one. The last two methods eventually run sourceanalyzer. Unfortunately, if we’re talking about an Angular project — but this applies to any project that contains Typescript files, the only way I found to scan Typescript files was to use the command line.

However, since the command line needs a Build ID, I will teach you how to create a script with the Scan Wizard, which creates one. This will also teach you more about some of the options sourceanalyzer by looking at how the generated script calls it.

Fortify provides you with the Scan Wizard (ScanWizard executable), which generates a script for your platform, based on some inputs and options. Run it, and you will see a wizard with this screen (I have already selected a Project Root):

Screen 1 of the Scan Wizard — Specify Project Root

Select the Add Project Root button and specify the path to your application. Then hit Next. The wizard will then scan your project root and find all the source code files that it can potentially scan. It might take a few seconds. You will now see this screen:

Screen 2 of the Scan Wizard — Review Source Files

By default, it will have all directories selected. You can deselect directories such as node_modules unless you want to scan all your dependencies. By deselecting directories, the wizard will update the file count and automatically detect the languages used in those directories. You can deselect languages as well if you don’t want to scan a particular set of files. Note that Typescript doesn’t appear in the list of languages. Don’t worry, I’ll tell you later how to add Typescript files to the scan.

Once you have made your selections, hitting Next will take you to the Translation and Scan screen of the wizard. In this screen you select for which platform you want to generate a script. You can also select whether you want a quick scan. Note that if you select this option, your scan will be faster, but you will be sacrificing accuracy. I recommend that you use this option the first time you run a scan. That way you don’t have to wait as long to make adjustments, if needed. Once you’re satisfied with your settings, you can turn off the “quick scan”.

The other options are to automatically upload the results to Fortify’s SSC (cloud-based product), or include custom rules. I will not discuss these options in this article.

Screen 3 of the Scan Wizard — Translation and Scan options

After clicking on the Next button, you end up with the actual script:

Screen 4 of the Scan Wizard — output script

Finish the wizard and you will find the output script on your project’s root directory. By default the script didn’t have executable rights after it gets created. To fix that, simply add executable rights like this on a UNIX-like system:

chmod +x FortifySCA.sh

Before you can execute your script, you might need to add Fortify’s bin directory to your PATH environment. On Unix-like systems, you do something like this:

export PATH=$PATH:/Applications/Fortify/Fortify_SCA_and_Apps_18.20/bin

According to Fortify’s documentation, to be able scan Typescript, we need to change the default configuration. We need to enable “higher order ” analysis and languages, and specify javascript/typescript. These are the properties I added to my properties file:

com.fortify.sca.hoa.Enable=true
com.fortify.sca.Phase0HigherOrder.Languages=javascript,typescript
com.fortify.sca.EnableDOMModeling=true

The third property above is recommended for DOM-related vulnerabilities in the documentation. You can specify these properties in three ways, in order of the priority they will be used:

Using the -D option on the command-line
Specifying them in the {Fortify Installed Dir}/Core/config/fortify-sca-quickscan.properties file, but only if you specify the-quick option to run a “quick” scan.
Specifying them in the Core/config/fortify-sca.properties file.
There is also a Core/config/fortify.properties which has more higher-level properties that users seldom need to change. You could also put your properties here.

Note that if you add your properties to any of these files, they will affect every scan on that system.

So, the full command on the CLI to run your scan could look like this:

./FortifySCA.sh -Dcom.fortify.sca.EnableDOMModeling=true -
Dcom.fortify.hoa.Enable=true -
Dcom.fortify.sca.Phase0HigherOrder.Languages=javascript,typescript

However, running this command didn’t include Typescript files in the scan. To include them, I had to explicitly tell the analyzer to scan those files. I also couldn’t use the script just generated to include Typescript files in the scan. I had to use sourceanalyzer. But you could simply reference the same Build ID that your script generated (look for BUILDID= in your script).

Finally, this is how you can run an analysis on your Angular project which will include your Typescript files:

sourceanalyzer -b <build_id> clean 
sourceanalyzer -b <build_id> <path_to_code_root>/**/*.ts
sourceanalyzer -Xmx14745M -Xms400M -Xss24M -b <build_id> -quick -scan -f results.fpr

The first command simply cleans any previous artifacts of the scan. If this is your first time running it, you don’t need it. But you don’t want to forget to do that especially if you automate this process on a build system. You might also be able to modify the output script from the Scan Wizard to add these options.

Note that on the third command above I’m specifying a limit on the memory used (the -X** flags, and also providing the -quick flag). This is because I ran this on my laptop, which doesn’t have enough memory to run a full scan. Remove these options once you have your final setup on a machine that has more than 16GB of memory. See the documentation links at the end of this article for system requirements.

You can put these commands in a single script that can be part of your build process. You can include it in a tool like Jenkins. For instance, your scan can run when triggered by a SCM commit and/or be part of your CI pipeline.

Reading the Results

To read the output of the scan, open your “Audit Project” with Audit Workbench. The Audit Project is what the documentation calls the output file (which ends in .fpr) of your scan. Audit Workbench is one of the applications that you can download with Fortify. In it, you see all the vulnerabilities categorized by levels; Critical, High, Medium, and Low.

Here is a sample screenshot. It’s from a scan of an Angular project. Note that it detected a privacy violation on a Typescript file. This issue is actually triggered from an HTML template. It categorized it as Critical, but since it’s related to a debug-only print out, we’re not too worried.

Audit Workbench showing detected issues on Typescript/Angular code.

You see summaries of each vulnerability along with details and recommendations for remediation.

Scanning your application often during the development cycle will help improve quality. It also gives you trends that you can track. And you track them so that you identify and eliminate the bad ones. Changes during the development phase are cheaper than when the code is complete.

Don’t wait until you’re ready to ship to scan your application.

You can also create reports and automate the process. Instead of opening the Audit Project with Audit Workbench, you can generate a report. There are two generators, ReportGenerator and BIRTReportGenerator. I had used the open source reporting engine BIRT before (and liked it), and it was recommended by the documentation anyway, so that’s the one we’re using.

This is the command I ran to create a PDF document with a report based on OWASP Top 10 2017, following by a screenshot:

BIRTReportGenerator -template "OWASP Top 10" -source results.fpr -output myreport.pdf -format PDF -showSuppressed -Version "OWASP Top 10 2017"

Part of the Developer Workbook report. It shows an issue found in a Typescript file. The file is part of an Angular Component

There are several templates to use, depending on what type of report you want. This is the full list included in the installation:

Developer Workbook
DISA STIG
CWE/SANS Top 25
FISMA Compliance
OWASP Mobile Top 10
OWASP Top 10
PCI DSS Compliance
DISA CCI 2

I have ran successfully the first two reports from the list, plus the OWASP Top 10 as shown above. To learn the meaning of the options I used, and other ones available when generating BIRT reports, run

BIRTReportGenerator -help

You will see that there is a --Version option for some of the report templates. These target specific versions of specifications that you might be interested in being compliant.

Resources

Fortify also has a SaaS option. It’s called Fortify on Demand (FoD). If you’re using it, upload your source code, and wait for the results.

Note that the free trial version of Fortify on Demand does not support Typescript

There is also a plugin for the most popular IDEs. Along with an account with FoD, you can run scans during development without leaving your IDE. I know Eclipse and IntelliJ have plugins available.

There is another product called Fortify Software Security Center. It will allow you to keep scan results in a central place on the cloud. It is basically a repository of your scan results (the .fpr files). It makes it easier to see trends, and make comparisons between scans.

Here is the product announcement for the latest version as of this writing (18.20). In it you’ll find information about the new features, and links to documentation and samples.

Finally, I want to point out that there are free resources available to scan your Angular project, including them with tslint for example. However, if your company is already licensing Fortify for WebInspect (dynamic analysis), then most likely you also have access to the static code analyzer.

ng-conf: Join us for the Reliable Web Summit

Upgrading an Existing Angular Application to CLI 7.3 for Conditional Polyfills

ng-conf — Mon, 28 Jun 2021 19:55:36 +0000

Jared Youtsey |ng-conf | May 2019

Angular has allowed us to polyfill features back to browsers like IE 9, 10, and 11 for a while using the polyfills.ts file. With the introduction of Angular CLI 7.3 we get conditional polyfills, where we only ship the older polyfills to pre-ES2105 browsers. This results in a savings of about 56Kb. This won’t take you from average to superhero load times, but this is an easy optimization.

If you’re starting a new project, just make sure you have at least @angular/cli@7.3.0 installed globally via npm and ng new away!

If you have an older project there are a few more steps. Here is the outline:

Upgrade global CLI to 7.3
Upgrade project to CLI 7.3
Delete IE polyfills from polyfills.ts
Add flag to angular.json
Validate it’s working

First, upgrade your global installation of the CLI. I recommend uninstalling the old one first for good measure.

npm uninstall -g @angular/cli

npm install -g @angular/cli

Next, upgrade your project to the latest Angular version with:

ng update @angular/cli @angular/core

This will have made a few changes to your package.json, but you may need to make a few more.

typescript version should be > 3.2.0 and < 3.3.0.
@angular-devkit/build-angular version should be at least 0.13.6

Next, delete the polyfills for IE 9, 10, and 11 from the polyfills.ts file:

Now add one flag to angular.json under your project in architect/build/options:

"es5BrowserSupport": true

Now, let’s verify that it works.

ng build

In your project’s dist folder under your project name you should find a new es2015-polyfills.XXX.js file. This is the file that will be conditionally loaded if the browser requires those polyfills.

How do the browsers know whether or not to load the es2015-polyfills? Open the index.html from your project’s dist folder and look down at the bottom. The following script tags were added by the builder to your index.html during compilation (I’ve formatted these for the purpose of this article):

Notice the nomodule attribute on the es2105-polyfills line. The HTML spec for nomodule says:

The nomodule attribute is a boolean attribute that prevents a script from being executed in user agents that support module scripts.

Basically, if you put nomodule on a script tag, any evergreen browser which supports modules is going to ignore that script. So, your older browsers will download this, but the newer ones will not. This will save you about 56Kb on startup!

If you found this useful, please leave a few claps for me and follow me on Medium!

If you want to learn more about Angular, be sure and attend ng-conf, the biggest, best Angular conference around!

ng-conf: Join us for the Reliable Web Summit

Animating Angular’s ngIf and ngFor

ng-conf — Fri, 25 Jun 2021 16:46:55 +0000

Jared Youtsey | ng-conf | May 2019

*ngIf and *ngFor will remove elements from the DOM. There isn’t a CSS solution for animating a non-existing element in the DOM. But Angular provides us with a simple solution.

For purposes of brevity, wherever I refer to *ngIf it is equally applicable to *ngFor. The complete, working code can be downloaded here.

Let’s start with the default application generated by the CLI and just modify the nice Angular logo in and out of the view based on a button we add.

ng new ngifAnimation

You won’t need routing and can select SCSS for the styling.

Let’s add the button we want to use to toggle our *ngIf on the image. Open app.component.html and add a simple button: (this is the default HTML)

<!--The content below is only a placeholder and can be replaced.--
<div style="text-align:center">
<h1>Welcome to {{ title }}!</h1>
<button (click)="onClick()">Toggle Image</button>
...

Now let’s add the onClick() method to the class that toggles a public variable showImage:

export class AppComponent {
  title = 'ngifAnimation';  
  showImage = false;
  onClick() {
    this.showImage = !this.showImage;
  }
}

Now, let’s add the *ngIf in the template on the <img> tag:

<img
  *ngIf="showImage"
  width="300"
  alt="Angular Logo"
  src="..."
/>

Let’s add a little bit of CSS to force the button to stay put when the image pops in and out: (app.component.scss)

button {
  display: block;
  margin: 0 auto;
  clear: both;
}

If you run the app now you’ll be able to click the button and the image will jarringly pop in and out of the view. If you check your developer tools, you’ll find that the <img> tag is popping in and out of the DOM. When showImage is false the <img> tag isn’t even present. This is where our inability to use CSS comes into play. It’s a terrible user experience to have elements, especially large ones, pop in and out without some transition. Let’s make it grow and fade in and out in a pleasing manner!

To handle animations (for way more reasons than just the one covered in this article) Angular provides the BrowserAnimationsModule. As of the latest Visual Studio Code, though, it doesn’t want to auto-import this module for you if you add it to your AppModule imports. It’s hidden in @angular/platform-browser/animations. Let’s add the import manually and add it to the module’s imports.

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
import { BrowserAnimationsModule } from '@angular/platform-browser/animations';
@NgModule({
  declarations: [AppComponent],
  imports: [BrowserModule, BrowserAnimationsModule],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

Now we’re ready to add our Angular animations! But where? We’ll approach this in the simplest manner. But be aware that we’re just scratching the surface of the power of Angular animation. It’s worth learning much more about. The simple approach is directly in the affected component. In our case, that’s app.component.ts's @Component directive. Here is the whole thing, but don’t worry, we’ll break it down and explain it.

import { trigger, state, style, animate, transition } from '@angular/animations';
@Component({
  ...,
  animations: [
    trigger(
      'inOutAnimation', 
      [
        transition(
          ':enter', 
          [
            style({ height: 0, opacity: 0 }),
            animate('1s ease-out', 
                    style({ height: 300, opacity: 1 }))
          ]
        ),
        transition(
          ':leave', 
          [
            style({ height: 300, opacity: 1 }),
            animate('1s ease-in', 
                    style({ height: 0, opacity: 0 }))
          ]
        )
      ]
    )
  ]
})

Whew! That’s a lot and it’s not terribly obvious without reading through it carefully. Let’s break it down, bit by bit.

First, animations: [] is an array of things we want to happen or state definitions. In this case we just want to trigger an animation called inOutAnimation. You can name this what you like. It should be descriptive for what it accomplishes or what it should consistently apply to. In our case we are animating an image in and out of the view.

Then, we give the trigger a set of states and/or transitions. We only need two specific transitions to occur that are related to *ngIf: :enter and :leave. These are the states that CSS just doesn’t give us. :enter is when a DOM element is being added, and :leave is when a DOM element is being removed.

When we want the image to :enter we are starting with the style of height: 0, opacity: 0. It’s basically invisible to start with. When it’s done we would like it to be 300 pixels tall and be completely opaque.

This is where the animate instruction comes in. We are going to animate over 1) a period of time 2) with a particular easing mechanism 3) to a new style. 1 and 2 are combined in the first string-based instruction, 0.3s ease-out. This means that we are animating to the new style over 0.3 seconds, and we are easing out, or coming to a gentle stop rather than a sudden one. 3 specifies what the end styling should be. In our case that’s 300 pixels high and completely opaque.

If you run this now you’ll find that nothing has changed. We now need to apply the animation to the element that is being added/removed from the DOM. In this case, it’s our <img> tag that has the *ngIf directive on it.

<img
  *ngIf="showImage"
  [@inOutAnimation]
  width="300"
  alt="Angular Logo"
  src="..."
/>

Here we use the name of the trigger to bind the animation to the template element.

If you run it now, you can click the button and the image zoom/fades in. Click it again and it’ll shrink/fade out! Voila!

Personally, I find the syntax of Angular animations somewhat difficult. It’s non-obvious and, if you’re not doing it every day, you’re probably going to have to re-learn this a few times. And the template syntax works with or without the []'s, which makes me scratch my head a bit.

Maybe the Angular team will give us a ReactiveAnimationsModule someday that makes animation a bit easier to work with, like ReactiveFormsModule did for forms? One can hope.

This is just scratching the surface of what Angular animations are capable of. Very complex transforms/transitions are possible and can be carefully coordinated in ways that CSS just can’t guarantee.

As a side note, if you’re worried about performance vs pure CSS animations, this is a quote from the Angular docs:

Angular’s animation system lets you build animations that run with the same kind of native performance found in pure CSS animations. You can also tightly integrate your animation logic with the rest of your application code, for ease of control.

If you’ve found this useful, I’d appreciate a few claps for this article.

If you’d like to learn more about Angular in a fun environment while hanging out with the movers and shakers of the Angular world, snag a ticket to ng-conf and join us for the best Angular conference in the US.

Image by PIRO4D from Pixabay.

For more Angular goodness, be sure to check out the latest episode of The Angular Show podcast.

ng-conf: Join us for the Reliable Web Summit

Supercharge your Angular application using Web Workers

ng-conf — Tue, 22 Jun 2021 18:33:00 +0000

Zama Khan Mohammed | ng-conf | May 2019

UI blocking is a thing of the past!

Original 📷 by @ja5on

https://angularprojects.com

If you are building an application where you do a lot of calculations on UI, such as creating CAD documents, doing heavy geometrical calculations, or heavy data table manipulations, then you might have observed that the UI sometimes becomes laggy or janky.

This happens because JavaScript is not the only thing that runs on the main thread, but other things like the painting of pixels, style calculations, and many others also run on it. When we run heavy long-running JavaScript on the browser, occasionally we see that frames are missed, which does not provide a great User Experience.

We have heard that Web Workers is one of the promising solutions to such a problem, but we never knew that it was so easy to introduce it to our Angular Application using Angular CLI.

Angular CLI v8.0.0-beta.11 added improved bundling support for Web Workers without you needing to add any new configuration. In this article, we will create an application in which we will run heavy calculations of checking if a list of more than 600 numbers are prime numbers or not.

Let’s create a new Angular CLI application using v8.0.0-beta.11 with npx command.

> npx -p @angular/cli@next ng new prime-numbers

Adding Web Workers is as easy as generating components, services, etc. using ng generate command.

> ng generate worker prime-calculations
CREATE src/tsconfig.worker.json (209 bytes)
CREATE src/tsconfig.json (131 bytes)
CREATE src/app/prime-calculations.worker.ts (121 bytes)
UPDATE tsconfig.app.json (232 bytes)
UPDATE angular.json (3558 bytes)

This will add a file called prime-calculations.worker.ts in the app folder along with the other changes that are required for web workers setup (only done once).

Now that we have our worker file, let’s first install a package prime-number that can check if a number is a prime number, and also has a list of 600+ prime numbers.

> npm install prime-number

The operation that we want to execute in both JavaScript thread and Web Worker is the following, where we loop over the primeNumberList and check if they're a prime number or not by using the method isPrimeNumber

import isPrimeNumber from 'prime-number';
import primeNumberList from 'prime-number/list';
const arePrimeList = primeNumberList.map((prime) => {
    return isPrimeNumber(prime);
});

Let’s add two buttons, one to run the logic in the worker, and another one in the main thread.

<button (click)=”runWorker()”>Web Worker</button>
<button (click)=”runThread()”>JavaScript Thread</button>

Now let’s add both methods to our AppComponent class.

import isPrimeNumber from 'prime-number';
import primeNumberList from 'prime-number/list';
...
export class AppComponent {
    title = 'web-worker';
    runWorker() {
       const worker = new Worker('./prime-calculations.worker', { 
           type: 'module' 
       });
       worker.onmessage = ({ data }) => {
           console.log('From Web Worker:', data);
       };
       worker.postMessage({});
    }
    runThread() {
        const arePrimeList = primeNumberList.map((prime) => {
            return isPrimeNumber(prime);
        });
        console.log('From Javascript Thread', arePrimeList);
    }
}

The runThread method is just doing calculations right in the method, but in runWorker, we are creating a new worker, and listening to onmessage, and then posting a message using worker.postMessage()

Now let’s update our worker prime-calculations.worker.ts with the same logic,

import isPrimeNumber from 'prime-number';
import primeNumberList from 'prime-number/list';
addEventListener('message', ({ data }) => {
    const arePrimeList = primeNumberList.map((prime) => {
        return isPrimeNumber(prime);
    });
    postMessage(arePrimeList);
});

Here we listen to the message and then run the same prime calculations that we did in the JavaScript thread.

Now that both methods are doing the same calculations, let’s see how our app reacts when a user clicks on each button.

Here we clearly see the lag when the JavaScript Thread button was clicked. When we clicked on the Web Worker button we did not see any delay. That happened because the Web Worker runs in a separate thread and does not block the main thread.

Conclusion:

Angular is not just a framework but it’s a platform. Angular’s tooling, especially Angular CLI is exceptional and it is what makes developing Angular Apps much easier.

👋 Hi! I’m Zama Khan Mohammed. I work at Tekzenit as a Software Architect — Web Technologies. I’m actively involved in working on Projects using Angular, React and Serverless Technologies along with writing a book “Angular Projects”.

For more Angular goodness, be sure to check out the latest episode of The Angular Show podcast.

ng-conf: Join us for the Reliable Web Summit

Angular on Azure — Part I

ng-conf — Thu, 17 Jun 2021 17:23:50 +0000

Pankaj Parker | ng-conf | May 2019

Using Azure Pipeline

Developers test software in a local environment using servers such as LAMP, WAMP, node, IIS, and Apache. Local deployment is good in terms of fast development and debugging, but we can’t ship our physical machines to the client in order to access to the application 😂. We have to deploy an application to a web server/cloud in order to make it accessible to the end user on their preferred platform (mobile, desktop, etc).

A variety of cloud providers exist in the current market, the most popular being Microsoft Azure, Google Cloud Platform, AWS. These providers offer an unbeatable combination of ease, speed, and automation, so if you have not deployed using such a platform, then this is the article for you! This article focuses on deploying an Angular app to Azure.

What is Deployment?

The action of bringing resources into effective action

In web development, deployment is concerned with making our static/dynamic resources available over the wire so the end user can access them in a desired device, using a browser.

What is hosting?

Web hosting is a service that allows organizations and individuals to post a website or web page onto the Internet.

The deployment process is incomplete without hosting.

Deployment Philosophy

Deployment exposes your web application using a philosophy that has been followed for year. The diagram below outlines typical deployment steps that could be applied to any type of software.

Deployment Philosophy

What is Azure?

Azure is a cloud platform service which provides cloud services, including those for compute, analytics, storage, serverless, AI and ML, IoT, containers, DevOps, mobile, and networking. It is widely considered as both a PaaS and IaaS product. This article covers the development, deployment, and DevOps aspects of the platform.

If you are new to Azure, a free subscription is available for those wishing to try the platform without any commitment.

Azure App Service

The Azure App Service is part of the PaaS section of the platform. It easily builds and deploys a highly available web app to the cloud. Multiple features are available right out of the box, as illustrated below.

Azure app service

The important steps are numbered in the above screenshot. If a resource group is not created, then do so in step 3. Also, if you do not have a service plan, create one at this time. Make sure you select ‘ASP .NET 4.7’ in the ‘Runtime Stack’ option in step 5. For more information, follow the guide for the detailed creation of Azure Service Plan and Azure App Service.

Once you’re done with the fill in details, click on “Review and create” button and then on the next screen press “Create” button. To see the newly created resource you can click on “All Resources” option in the sidebar.

Newly created resource group added

The following url can be loaded to check if the recently deployed application is available in the cloud, https://.azurewebsites.net/

In my case I used app name as “angular-deployment” so URL would become https://angular-deployment.azurewebsites.net/

The deployed application running in the cloud

But, before moving forward, we should minimize the final bundle size of the application. No worries; that process is discussed in a later section.

Make angular application production ready

Angular CLI tooling is incredible; simply executing ng serve compiles angular code to Javascript and generates bundle files. For a simple hello-world app, however, the total file size is far short of desirable.

Angular currently offers two compilation modes

Just in Time (JIT) Mode
Ahead of Time (AOT) Mode

In short, JIT ships the Angular compiler over the wire and component templates are compiled inside the browser. AOT mode precompiles all templates and makes the resulting JS available for further optimization before shipping the bundled application over the wire. Smaller application sizes and quicker response makes for better UX!

For those new to the Angular CLI, AOT mode is enabled with the command

ng build --prod

This command compiles all templates, then applies tree-shaking, optimization, minification, and bundling to create a final, highly-optimized package. All distribution files are automatically placed in the dist folder of your project, which can be directly hosted to a cloud provider.

Setup Deployment

In this article, Azure DevOps (formerly known as VSTS) is used to deploy an application to the cloud.

DevOps create project

If you have not created an organization, then do so before clicking the ‘Create Project’ button, as shown in the above diagram. This displays the ‘Create New Project’ dialog.

Create a project inside the Organization

In “Create new project” screen, fill project name, description and select visibility (I selected private). Also, version control was set to ‘Git’, and ‘Work item process’ defaulted to ‘Agile.’ Then, click the ‘Create’ button.

The dashboard page is displayed after a project is created. Several actions may be performed from the dashboard sidebar.

Azure DevOps Gist

Boards — To track down tasks and progress of a project
Repos — Code repositories involved in the development.
Pipelines — CI / CD pipeline
Test Plans — Provides all tools to successfully test your applications
Artifacts — Provides a secure, highly performant store and easy feed

The most important feature in the above list for purposes of this article is the Azure Pipelines setup.

Create A Brand New Pipeline

Pipeline page

Select the ‘Pipelines’ option from the left sidebar, which displays the ‘New Pipeline’ button in the middle of the screen. The following dialog is displayed after clicking the ‘New Pipeline’ button.

Pipeline creation page

Pipelines are created with yaml files. A new yaml file may be created with a visual tool or by using the ‘Use the classic editor’ link at the bottom of the dialog.

Repository selection

The next step is selecting a repository resource, which can be a new repository (above) or using an existing repo as shown below. I’m using my existing Github repo, so I selected ‘Github’ at this stage. To select a Github repo, click on the ‘…’ Button to browse repositories.

Select a repository

Select the desired repository for deployment. In this example, I selected the ‘weather-cast’ repo. Then, click the ‘Select’ button.

Select a source

At this point, you are very close to creating a brand new pipeline! By default, the ‘master’ branch is selected. Click on the ‘Continue’ button.

Select job template page

Now, you’ve made it to the final page of pipeline creation! Next, we create a ‘Job’, or the steps involved in the actual deployment. For now, just select ‘Empty Job’ to create a blank Job with no content. Don’t worry, we will add steps for it in the next section.

Empty Job page

After the pipeline is created, you will see a screen where an Agent pool is assigned to run a job when any tasks are to be deployed. For this tutorial, we are going to setup deployment tasks under the ‘Agent Job 1.’ Simply click on the ‘+’button in the dialog.

Setting Up Pipeline Step

Cool! We’ve finally made it to the stage where we can add tasks for the deployment job! Refer to the following screen shot.

1. Install node

Install node on vm

After clicking the ‘+’ icon beside ‘Agent Job 1,’ you can search by ‘node’ in the list (item 1 in the screen shot) then select ‘Node Tool Installer.’ When that dialog displays (item 2), click the ‘Add’ button (item 3 in the above screenshot).

Making node available on machine

This displays the first task in the ‘Agent job 1’ list. Next, fill in the details for this task. Enter display and version spec, as shown above. This configures NodeJS on our VM.

2. Install Angular CLI

Install Angular CLI to machine

As before, search for ‘npm’ in the task list and then click the ‘Add’ button. Fill in the details as shown above to install the Angular CLI as the next step in the task list.

3. npm install

npm install on package folder

Continue the same process as above to create a task that installs all npm dependencies.

4. Create Prod Build

Create prod build

Again add npm ask and fill in the details shown above. This time select command as in “custom”, and “command and arguments” would be run build. Basically, it calls ng build --prod command written as scripts in . This task helps to create a production ready angular package.

This is the task that creates the production-ready Angular package. Continue as before using the details shown in the above screenshot. ‘Command’ is ‘custom’ and the ‘Command and arguments’ input is ‘ng build — prod’. This causes the ng build --prod command to be written in the ‘scripts’ section of the [package.json](https://github.com/pankajparkar/weather-cast/blob/master/package.json#L8) file.

5. Host dist folder

Next, search for ‘Azure App Service Deploy’ and add it to the task list. Fill in the details as shown below. This task hosts and deploys code to the server.

Azure app service deploy

After you have finished entering details, click on the ‘Save and queue’ button. This saves and subsequently runs the pipeline. You will see a message with a hyperlink containing a build number. Or, you may navigate to ‘Pipelines > Builds’ to see the following screen.

After the build is finished

After the job is finished, we can check it as shown below.

Final Azure Pipeline

Final pipeline tasks

Conclusion

This article outlined the steps to deploy an Angular application to Azure directly from Github or another repository. An Azure pipeline is a powerful feature to setup and visualize a deployment job with minimal effort.

If you like this article press 👏 clap button 50 times or as many times you want. Feel free to ask a question if you have any. Thanks a lot for reading!

ng-conf: Join us for the Reliable Web Summit

Soon, I will release part II of this article which covers CI and CD with Azure
Pipeline. Stay tuned!

For more Angular goodness, be sure to check out the latest episode of [The Angular Show podcast]

Dynamic Component Generation in Lazy-Loaded Routes

ng-conf — Tue, 15 Jun 2021 18:30:13 +0000

Jim Armstrong | ng-conf | Jun 2019

— Exploit Data Driven Component Layout, Loaded On-Demand in Angular

One of the fun things about being an applied mathematician in front-end development is the never-ending stream of complex, interactive problems that users wish to solve. These range from gamification of business applications to data-driven user experiences. Two interesting applications of the latter topic include dynamic routing through an application and dynamic component layout. Both are examples of user experiences that vary based on factors such as user role and prior uses of the application. In other words, two different users may be presented with an entirely different experience based on both a priori knowledge of the user and how the user interacts with the application in real time.

The general solution I’ve applied to dynamic routing is a data-driven, adaptive decision tree. This is, unfortunately, a client-proprietary solution and can not be shared in public. However, I built the solution on top of two projects that I have released to the public in my Github, a general tree data structure and a lightweight expression engine. Both are written in Typescript. I believe any enterprising developer with some fundamental knowledge of decision trees could duplicate my work. So, here is the best I can do for you at present:

theAlgorithmist/TSTree - Typescript Math Toolkit General Tree Data Structure on github.com

theAlgorithmist/TSExpressionEngine - Typescript Math Toolkit Expression Engine on github.com

Dynamic, Data-Driven Component Layout

This article discusses how to layout Angular components programmatically, based on a simple JSON data structure. A simple example I’ve worked on in the past is where components are vertically stacked in an order that is server-generated. Consider a case where three components, A, B, and C could be presented to a user. They might be displayed in the order A, B, C, or A, C, B, or perhaps C, B, A. In general, there are n! display permutations of n components (displayed n at a time). One might be willing to struggle with a layout that could accommodate all possible scenarios for three components, but what about when the client later indicates there could be anywhere from three to eight components? And, we know how clients think, so that 3–8 range will not stay constant for very long. In short, this is a situation that is much better managed with an imperative instead of declarative approach.

Thankfully, the Angular team has provided everything we need to dynamically generate components at runtime. But, before we move on, here is the repo for this article so that you can follow along with the deconstruction, and have the code for experimentation and future usage in projects.

theAlgorithmist/Angular8LazyLoadDynamic - Angular 8 Dynamic Component Generation in a Lazy-Loaded Route on github.com

The Scenario

This demo simulates a scenario where a user logs into an application and then selects a navigational element that routes to another area of the application. The user experience, however, is tailored to each specific user based on information that is known about the user after login. A service call is to be made before activating the route. The service returns some JSON data that describes the order in which child components are to be displayed in the Angular Component associated with the selected route. The JSON data also provides some simple textual and numerical data that is used for binding within each of the child components.

Since the order of the components is not known in advance and the number of components can also vary, the child components are dynamically created and then rendered into the parent component’s template. For demonstration purposes, the number of components in the code distribution is limited to three. The technique, however, is easily scaled to any number of components in any arbitrary order.

The Process

I’ll treat the explanation in a cookbook fashion since additional information on each step in the process is readily available online for subsequent study.

1 — Each child component that could be rendered into a parent component must be provided as an EntryComponent into the Module associated with the route. This is why the route should be lazy-loaded as there is no guarantee that every user will navigate to this route.

2 — A route Resolver is used to ensure that the JSON data is loaded before the route activates. This is the mechanism a server would use to dynamically alter the experience for each individual user.

3 — In order for an Angular component to be dynamically displayed in a template, it must be added to a ViewContainerRef associated with a DOM container after creating the component. An Attribute Directive is used for this purpose.

4 — Each child component is to be generated by two Factories. One factory (that we write) generates component type and raw data instances based on a symbolic code and a known number of components. So, if the component range is changed from 3–8 to 2–12 at a later point, the four new items must be added to the factory. Another factory (provided by Angular and discussed below) is used to create the actual Angular component at runtime.

5 — The template for the lazy-loaded component consists of a ng-container as the primary container with a ngFor that loops over the number of dynamic components specified in the JSON data.

6 — Each dynamic component is associated with a ng-template by using an attribute directive.

7 — A QueryList of dynamic item attribute directives is processed by the parent component. Each child component is created by an Angular Component Factory (provided by a factory resolver) and then added to the ViewContainerRef of the ng-template. Data for each component is then added to the newly created component for binding. This requires some handshaking between the parent component code and the attribute directive. The actual separation of concerns can be experimented with and adjusted to suit your specific desires.

Application Layout

The application structure for this demo is rather simple. There is a single application module and component. The main app component displays a button whose markup contains a routerLink. That is used to route the user to the single feature module, appropriately named ‘feature’ :)

The main app module provides a single route resolver that is used to ensure the JSON data for dynamic layout is loaded before the route is activated.

All libraries, directives, and components for the single feature are provided in the feature folder.

The model for dynamically generated components is provided in src/app/models.

There is no relevant code in the main app component and the only item worth deconstructing is the main app routing module. Relevant code from the routing module is provided below.

/src/app/app-route-module.ts

const routes: Routes = [
  {
    path: `feature`,
    resolve: { model: AppRouteResolver },
    loadChildren: () => import(`./feature/feature.module`).then(m => m.FeatureModule)
  }
];

@NgModule({
  imports: [RouterModule.forRoot(routes)],
  providers: [AppRouteResolver],
  exports: [RouterModule]
})
export class AppRoutingModule { }

Note the new Angular 8 dynamic import syntax for lazy-loaded routes. This module also provides the route resolver, AppRouteResolver. The model property is used when loading data from the activated route.

Now, we can deconstruct each of the above-listed steps.

(1) Feature Module

Look at /src/app/feature/feature.module.ts. The important code is shown below.

export const DYNAMIC_COMPONENTS: Array<any> = [
  BaseComponent, Component1Component, Component2Component, Component3Component
];

@NgModule({
  declarations: [
    DynamicItemDirective, FeatureComponent, ...DYNAMIC_COMPONENTS
  ],
  imports: [
    CommonModule,
    RouterModule,
    RouterModule.forChild(localRoutes),
  ],
  providers: [],
  entryComponents: DYNAMIC_COMPONENTS
  exports: [
    DynamicItemDirective, ...DYNAMIC_COMPONENTS
  ]
})

The three dynamic components in this example are Component1Component, Component2Component, and Component3Component. Yes, those are stupid names, but slightly better than my original choice of Moe, Larry, and Curly :) Each of these components extends BaseComponent.

In particular, note the declaration of all of dynamic components in the entryComponents property of NgModule. Since there is no direct reference to any of these components in a template, Angular needs this information directly for compilation purposes. Without entryComponents Angular will tree-shake out those components because they are never referenced in a template.

The attribute directive, DynamicItemDirective, is used to associate a ViewContainerRef with a specific DOM element (ng-template in this example).

(2) Route Resolver

The resolver is used by the main app component and is provided in /src/app/app-route.resolver.ts. This code implements the Resolve interface by providing a concrete implementation of the resolve() method.

@Injectable({providedIn: 'root'})
export class AppRouteResolver implements Resolve<LayoutModel>
{
  constructor(@Inject(DataService) protected _service: DataService)
  {
    // empty
  }

  resolve(): Observable<LayoutModel>
  {
    // load layout model
    return < Observable<LayoutModel> > this._service.getData('/assets/layout-model.json');
  }
}

DEV Community: ng-conf

Angular architecture matters: Monorepo

NX by Nrwl

Monorepo folder structure

nx.json hosted by GitHub

tslint.json hosted by GitHub

To sum up

EnterpriseNG is coming November 4th & 5th, 2021.

Become an Angular contributor: Where to Start

What and Where?

Contributing to Angular (original background, foreground)

The angular/angular Repository

Description

animations

bazel

benchpress

common

compiler-cli

compiler

core

elements

forms

http

language-service

platform-*

router

service-worker

upgrade

Documentation

Contribution Guide

Help with new issues

Help with pull request reviews

Good First Issues

Code of Conduct

Developer Guide

Next steps

Simplified Angular Change Detection

General Application Architecture

What is Change Detection?

a simple binding example

app.component.html hosted by GitHub

app.component.ts hosted by GitHub

demo

magic

When should change detection happen?

change-detection.js hosted by GitHub

detectChanges.jshosted by GitHub

ZoneJS to the rescue

ZoneJS simple example

zonejs.js

What happens when Application Bootstrap?

zone_tick.js hosted by GitHub

tick_implementation.js hosted by GitHub

Change Detection Strategy

Default

change detection strategy — Default

OnPush

change detection strategy — OnPush

highlight component on change detection fired

highlight.ts hosted by GitHub

all component on default strategy

Taken from Max Koretskyi article from @angularInDepth

TL;DR

The difference between calling markForCheck, detectionChanges and tick would be

ng-conf: Join us for the Reliable Web Summit

MockStore in NgRx v7.0

Existing: StoreModule

New: MockStore

Testing Auth Guard Example

auth-guard.service.ts hosted by GitHub

auth-guard.service.spec.ts hosted by GitHub

auth-guard.service.spec.ts hosted by GitHub

Testing Effect + withLatestFrom Example

book.effects.ts hosted by GitHub

book.effects.spec.ts hosted by GitHub

ng-conf: Join us for the Reliable Web Summit

Consistent Console Logs in Angular

Sample Logger Usage

Readable Console Output

logger.ts.vscode.snippet.txt hosted by GitHub

The difference between calling `markForCheck`, `detectionChanges` and tick would be

Animating Angular’s ngIf and ngFor