DEV Community: Raúl Julián López Caña

Angular Tips | Environmental Providers using CLI Builders

Raúl Julián López Caña — Mon, 27 Feb 2023 20:38:25 +0000

Have you ever thought about configuring different Angular development environments to consume resources or services depending on the configuration? Generate builds of the same application that consume resources from different sources? Then read on!

In some Web application development scenarios that work with APIs, we may not have access to them at will. In these cases, solutions such as proxies, fake/mock servers… are often used.

All of them are good solutions, but… Can we take advantage of Angular Dependency Injection and the CLI Builders to create and provide services depending on the environment? Let’s see it :)

First of all, if you are not familiar with Angular configurations, I advise you to take a look at the official documentation section.

Our goal is to achieve the following behavior:

# Should init dev-server with HTTP Providers*
ng serve

# Should init dev-server with Faker Providers*
ng serve --configuration faker

Setup Environment

# Create a new Angular Project
ng new env-providers

# Install needed dependences
npm install --save-dev @angular-builders/custom-webpack
npm install --save faker

Modeling Providers

We need to get the following structure:

FooInterface: defines the interface to be implemented by the different services (Http & Faker)

foo-service/foo-service.interface.ts

import { Observable } from 'rxjs';

export interface IFooService {
  retrieve(id: number): Observable<Foo>;
}

FooService (HTTP impl.): concrete implementation of the service with access to data by HTTP protocol.

foo-service/foo.servicice.ts

import { Injectable } from '@angular/core';
import { Observable } from 'rxjs';
import { IFooService } from './foo-service.interface';

import { HttpClient } from '@angular/common/http';

@Injectable({
  providedIn: 'root'
})
export class FooService implements IFooService {

  constructor(
    private http: HttpClient
  ) {}

  retrieve(id: number): Observable<Foo> {
    return this.http.get(`${environment.API_URL}/foo`);
  }
}

FooService (Faker impl.): concrete implementation of the service of objects generated by Faker.

foo-service/foo*.servicice.faker.ts

import { Injectable } from '@angular/core';
import { Observable, of } from 'rxjs';
import { IFooService } from './foo-service.interface';

import * as faker from 'faker';

@Injectable({
  providedIn: 'root'
})
export class FooService implements IFooService {

  retrieve(id: number): Observable<Foo> {
    return of(new Foo({
      id: id,
      name: faker.name
    }));
  }
}

Now we have our providers ready to use, so … Let’s do it!

app.component.ts

import { Component, OnInit } from '@angular/core';
import { FooService } from './foo-service/foo.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {

  public foo$: Observable<Foo>;

  constructor(
    private *fooService*: FooService
  ) {}

  ngOnInit() {
    this.foo$ = this.fooService.retrieve(1);
  }
}

Note that the service is being imported from /foo.service, that is, the service that will be used by default when running ng serve without additional parameters.

Configuring & Hacking CLI Builders

Now that we have our services created and are being consumed from a component of our application, we will configure the project so that the Angular CLI works as described at the beginning of the article.

Artifact & builder configuration

We must modify the angular.json file with a configuration similar to the one I show below:

angular.json

"projects": {
  . . .
  "architect": {
    /* <build> artifact config */
    "build": {
      /* Custom artifact builder */
      "builder": "@angular-builders/custom-webpack:browser",
        "options": {
          /* Our custom builder adjustment */
          "customWebpackConfig": {
            "path": "./providers.config.ts"
          },
            . . .
          },
          "configurations": {
            "production": {
              . . .
            },
            /* Our build configuration */
            "faker": {
              "tsConfig": "tsconfig.app.faker.json"
            }
         }
      }    
    }
  }
}

In this file, we perform 3 important changes:

We changed the default Angular builder to the one we installed from @angular-builders/custom-webpack.
With the customWebpackConfig property we indicate the file that will perform the necessary modifications to inject some or other providers. We will build later.
We create a new configuration called faker. This will perform the TypeScript transpilation with the configuration defined in tsconfig.app.faker.json .

The new tsconfig file:

tsconfig.app.faker.json

{
  "extends": "./tsconfig.app.json",
  "include": [
    "src//*.d.ts",
    "src/**/*.service.faker.ts"
  ]
}

What we are doing with this configuration is explicitly telling Typescript to transpile the files ending with .service.faker.ts. This is because **if imports of the files are not found, the TypeScript compiler will not compile them unless explicitly specified* (includeoption).

Extending Builder behavior

Finally, we will extend the functionality of the CLI Builder with the following configuration.

providers.config.ts

import * as webpack from 'webpack';

const PROVIDER_FILE_CASING = '.service';

// Retrieve '--configuration' parameter*
const configurationIndex =
  process.argv.indexOf('--configuration') > -1
    ? process.argv.indexOf('--configuration') + 1
    : 0;
const configuration = configurationIndex
    ? `${process.argv[configurationIndex]}`
    : '';

export default (*config*: webpack.Configuration) => {
  config.plugins.push(
  /*
   * Using webpack plugin to replacement:
   *   We are searching all '.service' occurrences
   *   & replace it to `.service.<configuration>`
   */
     new webpack.NormalModuleReplacementPlugin(
       new RegExp(`(.*)${PROVIDER_FILE_CASING}(\.*)`),
         resource => {
           resource.request = resource.request.replace(
             new RegExp(`${PROVIDER_FILE_CASING}`),
             `${PROVIDER_FILE_CASING}.${configuration}`
           );
         }
      )
   );
   // New config is returned to Builder
  return config;
};

We are creating a replacement rule that replaces:

.service => *.service.faker

That is, replace HTTP providers with Faker providers.

And that’s it! Now, when we execute the ng serve command, the application will be built on the development server with the HTTP providers, while if we run ng serve --configuration faker, it will do so with the Faker providers.

Applicability

We can use this approach if…

We need to configure different development environments that access to data from different sources or comunication protocols.
We need to generate different builds of our application based on the Data Access Layer.
We want to reduce test execution time due to server latency in test environments or we cannot access it.

Angular Tips | Combine Abstract Factory Pattern & Injector to inject a service depends on parameter 👷 📐

Raúl Julián López Caña — Mon, 28 Jan 2019 11:55:36 +0000

The good practices guide of Angular proposes that the transfer and storage of information is done through services.

In many occasions, we will want to create generic components (to manage different resources of a family) that will have to handle different services depending on how they were created.

The challenge to be solved in this context (and the topic of the article) is to manage this dynamic injection of services in a c lean, scalable and efficient way.

In this article we will use the Abstract Factory pattern in combination with the Angular Injectors to solve the mentioned problem.

A poor and ugly solution

One way to solve this problem is to inject each service and use whatever is necessary:


@Component({
  . . .
})
export class GenericComponent implements OnInit {

  public resource: any;

  constructor(
    private service1: Service1,  
    private service2: Service2, // Rest of services  
    . . .
  ) {}

  ngOnInit() {
    // Get parameter to resolve Service to use
    const serviceType = this.route.snapshot.data['type'];

    // Resolve service to use

    if (serviceType === 'SERV1') {
      this.foods = this.service1.get();
    }
    if (serviceType === 'SERV2') {
      this.foods = this.service1.get();
    }
    // Everything else
    // . . .
  }
}

However, it is not a good solution , since the logic and the constructor of our component will grow as we need to add more services. What about if you have to solve the injection of 50 services?

Applying method

If you are not acquainted with the Abstract Factory pattern, I recommend this reading before applying the method: Abstract Factory Pattern.

To implement this creational pattern, we should consider coding the following classes and interfaces:

AbstractFactoryInterface: interface that will implement each class.
AbstractFactoryProvider: will solve a ConcreteFactory upon request.
ConcreteFactory(s): create an instance of a class that implements the Abstract Factory Interface.

Keep in mind that implementation doesn’t strictly follow the principles of the Abstract Factory pattern, this is an adaptation combined with the Angular Injectors.

AbstractFactoryInterface & AbstractFactoryProvider

The first step is to create the common interface (methods that will implement the concrete classes) and the provider responsible for resolving which class to instantiate.

// food.ts

import { PastaService } from './pasta.service';
import { PizzaService } from './pizza.service';

// AbstractFactoryInterface
export interface Food {  
 get(): Observable<any>;  
}

// AbstractFactoryProvider as a HashMap
export const foodMap = new Map([
  ['PASTA', PastaService],
  ['PIZZA', PizzaService]
]);

ConcreteFactory

Once our interfaces and the provider are created, we will create our concrete classes.

// pasta.service.ts

import { Injectable } from '@angular/core';
import { Food } from './food.interface';
. . .

// ConcreteFactory
@Injectable()
export class PastaService implements Food {

  constructor() {}

  public get(): Observable<any> {
    return Observable.of([
      {
        name: 'Carbonara'
      },
      {
        name: 'Pesto'
      }
    ])
  }
}

Note that the PizzaService class implements the methods of the Food interface.

Angular Injector

Once our ConcreteFactories are implemented, we will proceed to solve the one that proceeds and inject it using the Angular Injector.

// generic.component.ts

import { Component, OnInit, Injector, Input } from '@angular/core';
import { foodMap } from './food.interface';

@Component({
  selector: 'generic-food',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class GenericFoodComponent implements OnInit {

  @Input() type: string; // 'PASTA' or 'PIZZA'
  public foods: Array<any>;
  public service: any;

  constructor(private injector: Injector) {}

  ngOnInit() {
    // Resolve AbstractFactory
    const injectable = foodMap.get(this.type);
    // Inject service  
    this.service = this.injector.get(injectable);
    // Calling method implemented by Food interface
    this.service.get().subscribe((foods) => {
      this.foods = foods;
    })
  }
}

Considerations

Please consider not applying this method when it is not strictly necessary and only when you need to instantiate services in a generic and dynamic way.

Conclusions

We have seen how to apply the AbstractFactory pattern in combination with the Angular Injectors, which can resolve the coding of bad smells when you need to inject a service depending on a parameter instance of inject all of them.

Example

rjlopezdev-injector - StackBlitz

Angular Tips | Use Projection technique for improve your components reusability

Raúl Julián López Caña — Sat, 12 Jan 2019 12:28:15 +0000

Reusability is one of the pillars of software engineering and an important indicator that informs us of, among others, the quality of the architecture of a module, component, system …

Angular proposes an architecture based on Web Components with the aim of improving the quality of the project, the reuse of code blocks, modularization …

Some of the best known techniques for writing our components are C omposition and Parameterization. With these techniques, we can encapsulate blocks of code within each other (giving rise to new components) and configure their appearance and behavior according to some parameters.

The objective of this article is to introduce a lesser known technique that improves the reusability of the components: the Projection.

Composition example

list.component.html


<h1> List of items </h1>
<item *ngFor="let item of items"> </item>

item.component.html

<div>
  <h2> {{ item.title }} </h2>
  <p> {{ item.text }} </p>
</div>

Applying this technique, we can create components by composing others.

Example of Parameterization

parameterized.component.ts

@Component({
  ...
})
export class ParametrizedComponent {
  @Input() param1: string;  
  @Input() param2: boolean;

  constructor() {}
}

parameterized.component.html

<h1> {{ param1 }} </h1>
<span *ngIf="param2" class="badge badge-secondary"> New </span>

foo.component.html

<h1> This is an example of ParameterizedComponent usage </h1>
<parametrized
  [param1]="This is a title"  
 [param2]="true">
</parameterized>

Applying this technique, we can create components with a ppearance and dynamic behavior dependent on parameters.

Improving reusability: Component Projection

By using the previous techniques, we have managed to encapsulate small blocks of code into components, composing them to give rise to others (composition) and giving them a different behavior and appearance depending on a series of predefined parameters.

However, we can go a step further.

Imagine that you wanted to create a layout with a hierarchy that could vary beyond configurations through parameters:

We could use the technique of composition and parameterization, although we would limit the parameters and force us to write components and templates with the sole purpose of being used in … perhaps a single component?

Let’s see how our template could be using the projection to create a “card” component (with its header, body and footer):

tree.component.html

<card>
  <card-header> Some header </card-header>
  <card-body>
    <div class="content">
      <h2> Title </h2>
      <p> Lorem impsum... </p>
      <img src="awesome-foo.png">
    </div>
  </card-body>
  <card-footer> With love by @rjlopez </card-footer>
</card>

To make possible the construction of this hierarchy, we will use the angular tag . This tag, allows us to load in the component the template that is found inside the tag of our component.

card.component.html

<div class="card text-center">
  <ng-content select="app-card-header"> </ng-content>
  <ng-content select="app-card-body"></ng-content>
  <ng-content select="app-card-footer"></ng-content>
</div>

card-header.component.html

<div class="card-header">
  <ng-content></ng-content>
</div>

With the previous sentence, using , we indicate that the component accepts an embedded html tag. And what tag do you accept? Through the “select” attribute, we inform you that you must accept tags of type . In case of not passing any value to “select”, it will accept all the content.

Conclussions

By using this technique, we can create hierarchical components and less dependent on others, which greatly improves the reusability of these. As a result, we will achieve a more flexible architecture and increase the degree of code reusability.

rjlopezdev-angular-projection - StackBlitz

Angular Tips (Pipe It! 🔥) | Prevent hardcoding & unnecessary variables and methods declaration using pipes

Raúl Julián López Caña — Thu, 20 Dec 2018 16:42:27 +0000

On many occasions, we need to write text strings in our Angular templates.

The two most common solutions (or at least those that I have found in the projects I have worked on) are the following:

Write the value of the variable directly in the template:

foo-component.component.html

<img [src]="'path/to/my/resource.png'">
<div> THIS IS A FOO TITLE </div>

This form presents the problem that the constants are not unified and, in the future, if we want to change the values of these, we must search for the content of the literals and replace them with each occurrence.

Write the constants in a separate file, import it and declare it as a variable in the component in order to use it:

my-collection-of-constants.ts

export const Foo = {  
 foo: 'foo',  
 resource: 'my/foo/file.png'  
}

my-component.component.ts

@Component(
...
)
export class MyComponent {

  public foo = Foo;

  ...

  public getFooValueByKey(key: string) {  
    return this.foo[value];  
  }

}

my-component.component.html

<div> {{ getFooValueByKey('foo') }} </div>
<img [src]="foo.resource">

Through this solution, we unify the value of the constants , all right!.

However, we will dirty the component with the declaration of multiple variables and methods whose only purpose is to display text.

Proposed solution: use Pipes

In order to prevent hardcoding in templates and the declaration of unnecessary variables in components, the following solution based on Angular Pipes is proposed:

Generate a file that contains an object with the values to be used or displayed:

hardcoded-values.ts

export const hardcodedValues = {
  pasta: 'An awesome pasta dish',
  pizza: 'The most tasty pizza ever',
  dessert: 'Icecream, cupcakes... and more!'
}

Create our Pipe in the following way.

prevent-hardcoding.pipe.ts

import { Pipe, PipeTransform } from '@angular/core';
import { hardcodedValues } from './hardcoded-values.ts';

@Pipe({  
 name: 'preventHardcoding'  
})
export class PreventHardcodingPipe implements PipeTransform {

  transform(value: any, args?: any): any {
    if (value in hardcodedValues) {  
      return hardcodedValues[value];  
    } else {
      console.error(
        `
        No properly value set for key '${value}'.
        Please, check available keys.
        Feel free to add new one if you need.
        `
      );
      return undefined;
    }
  }

}

If you look closely at the transform method, what it will do is check if the value of the key value and, if so, return the associated value.

All right! Now we can use our Pipe to use values housed in the hardcodedValues object.

app.component.html

<!-- Display value in template -->
<div> {{ 'pasta' | preventHardcoding }} </div>

<!-- As @Input for component -->
<app-foo
  [someInput]="'pizza' | preventHardcoding">
</app-foo>

With the use of this pattern, we were able to decouple the value of the text strings, numbers … of each component. Thus, any change in the displayValues object will propagate to each component that makes use of the preventHardcoding Pipe.

prevent-hardcoding-pipe - StackBlitz

Angular permissions based on roles | Part 2. Permissions for multiple resources

Raúl Julián López Caña — Tue, 04 Sep 2018 18:25:52 +0000

In the previous article, a roles and permits handler, a global service to consume the handler and a directive for easy use have been implemented.

In this article, we will focus on solving the problem of managing different permissions for each resource of the application.

For example, a USER can READ, and ORDER pizza, but can only READ orders.

Glossary:

Define the model Permission
Refactor(PermissionBase and its extended classes)
Refactor(Service): isGranted now controls permissions and resources
Refactor(Directive): now receives resource and permission as parameter
Stackblitz demo

1. Define the model Permission

We need to define a new data structure that relates resources with permissions. For this, we will first define the permissions that the application will handle.

export enum Resource {
  PASTA = 'PASTA',
  PIZZA = 'PIZZA',
  BILL = 'BILL'
}

Once the resources are established, we can define the permission’s structure:

import { Resource } from './resource';
import { PermissionType } from './permission-type';

export class Permission {
  public resource: Resource;
  public permissions: PermissionType[];

  constructor(resource: Resource, permissions: PermissionType[]) {
    this.resource = resource;
    this.permissions = permissions;
  }
}

Each permission will handle a list of permissions for each resource and user.

2. Refactor(PermissionBase and its extended classes)

We will adapt the new PermissionBase class to handle the new permissions.

import { Permission } from '../permission';

export abstract class PermissionBase {
  public permissions: Permission[];

  constructor() {}
}

Now, extended class permissions are defined for each resource:

import { PermissionType } from '../permission-type';
import { Resource } from '../resource';
import { PermissionBase } from './base.permissions';
import {Permission } from '../permission';

export class UserPermission extends PermissionBase {
  constructor() {
    super();
    this.permissions = [
      new Permission(Resource.BILL, [
        PermissionType.READ,
        PermissionType.ORDER
      ]),
      new Permission(Resource.PASTA, [
        PermissionType.READ,
        PermissionType.ORDER
      ]),
      new Permission(Resource.PIZZA, [
        PermissionType.READ,
        PermissionType.ORDER
      ])
    ];
  }
}

3. Refactor(Service): isGranted now controls permissions and resources

Let’s refactor!

isGranted(resource: Resource, permission: PermissionType) {
  for (const res of this.permissions.permissions) {
    if (resource == res.resource) {
      for (const perm of res.permissions) {
        if (perm == permission) {
          return true;
        }
      }
    }
  }
  return false;
}

4. Refactor(Directive): now receives resource and permission as parameter

We adapt the directive so that it receives an Input parameter, composed of a resource and a type of permission.

@Input() set appIsGranted(permission: Array<string>) {  
  this.isGranted(  
    permission[0] as Resource,  
    permission[1] as PermissionType  
  );  
}

private isGranted(resource: Resource, permissionType: PermissionType) {
  if (this.permissionManagerS.isGranted(resource, permissionType)) {
    this.viewContainer.createEmbeddedView(this.templateRef);
  } else {
    this.viewContainer.clear();
  }
}

Now, we can easily use like:

<div *appIsGranted="['PIZZA', 'CREATE']">
  // This block will only be shown to granted users
</div>

<my-component *appIsGranted="['PASTA', 'DELETE']">
  // This component will only be shown to granted users
</my-component>

5. Stackblitz demo implementation

rjlopez-angular-permissions-part2 - StackBlitz

Angular permissions based on roles | Part 1. Roles, permissions and Permission Manager

Raúl Julián López Caña — Mon, 20 Aug 2018 14:48:45 +0000

One of the biggest challenges we face when building Angular applications is the control and management of user permissions.

Many times, we must show components or allow actions depending on the type of user.

In this article, a proposed solution to this problem will be explained:

Glossary:

Define roles and permissions
Build classes for the management of permissions of each user
Service for the management of permissions
Directive for the easy use of permissions management
Stackblitz demo implementation_

1. Define roles and permissions

The first thing we have to define are the types of roles that our application will handle:

export enum Role {
  SUPERUSER = 'su',
  ADMIN = 'admin',
  USER = 'user',
  UNKNOWN = 'unknown'
}

The next step is to define the different permissions that we want to grant to users:

export enum PermissionType {
  CREATE = 'CREATE',
  READ = 'READ',
  UPDATE = 'UPDATE',
  DELETE = 'DELETE',
  OTHER = 'OTHER'
}

2. Build classes for the management of permissions of each user

Once the structure of our roles and permissions has been defined, we will implement the base class for the permissions of each type of user.

import { PermissionType } from '../permission-type';

export abstract class PermissionBase {
  public permissions: PermissionType[];
  constructor() {}
}

The next step will be to extend the base class for each type of user.

For example, for the superuser role who is granted for CREAD, READ, UPDATE, DELETE and OTHER actions:

import { PermissionType } from '../permission-type';
import { PermissionBase } from './base.permissions';

export class SuperuserPermission extends PermissionBase {

  constructor() {
    super();
    this.permissions = [  
      PermissionType.CREATE, PermissionType.READ,   
      PermissionType.UPDATE, PermissionType.DELETE,  
      PermissionType.OTHER  
    ];  
  }
}

After defining the permissions for each type of user, we will build a factory to build the instance of the class of permissions.By using the singleton pattern, we will limit to a single instance to prevent multiple instances of the permission handler.

import { PermissionBase } from './base.permissions';
import { Role } from '../role';
import { SuperuserPermission } from './superuser.permissions';
import { AdminPermission } from './admin.permissions';
import { UserPermission } from './user.permissions';
import { UnknownPermission } from './unknown.permissions';

export class PermissionsFactory {

  public static instance: PermissionBase;
  private constructor() {}

  public static getInstance() {
    if (this.instance) {
      return this.instance;
    } else {
      const role = localStorage.getItem('role');
      switch(role) {
        case Role.SUPERUSER:
          this.instance = new SuperuserPermission();
          break;
        case Role.UNKNOWN:
          this.instance = new UnknownPermission();
          break;
        . . .
        default:  
          this.instance = new UnknownPermission();
          break;
      }
    }
  }
}

3. Service for the management of permissions

For now, we have built our permissions for each user and a permission factory to obtain the instance. However, we need an accessible way to determine whether or not a user can perform a specific action.

To solve this problem, we will implement a global service that makes use of our permission instance. In this way, it will be accessible from any component or directive of our application.

import { Injectable } from '@angular/core';
import { PermissionType } from './permission-type';
import { Role } from './role';
import { EnumValues } from 'enum-values';
import { PermissionBase } from './permissions/base.permissions';
import { PermissionsFactory } from './permissions/factory.permissions';

@Injectable(  
 provideIn: 'root'
)  
export class PermissionManagerService {

  private permissions: PermissionBase;
  constructor() { }

  isGranted (permission: PermissionType) {
    const permissions = PermissionsFactory.getInstance().permissions;
    for (let perm of permissions) {  
      if (perm === permission){  
        return true;  
      }  
    }  
    return false;
  }

  authAs (role: Role) {
    localStorage.setItem('role',
      (role === null)
        ? Role.UNKNOWN
        : role
    );
    this.permissions = PermissionsFactory.getInstance();
  }
}

isGranted method receives a permission type as parameter, iterates the user’s permissions and returns true if found.
authAs method demand a permission manager instance.

4. Directive for the easy use of permissions management

Now, PermissionManagerService can be consumed easily. However, we can make it even easier to use the service in the templates by creating a directive that consumes it:

import { Directive, Input, TemplateRef, ViewContainerRef } from '@angular/core';
import { PermissionType } from './permission-type';
import { PermissionManagerService } from './permission-manager.service';

@Directive({  
 selector: '[appIsGranted]'  
})  
export class IsGrantedDirective {
  constructor(
    private templateRef: TemplateRef<any>,
    private viewContainer: ViewContainerRef,
    private permissionManagerS: PermissionManagerService
  ) { }

  @Input() set appIsGranted(permission: PermissionType) {
    this.isGranted(permission);
  }

  private isGranted(permission: PermissionType) {
    if (this.permissionManagerS.isGranted(permission)) {  
      this.viewContainer.createEmbeddedView(this.templateRef);  
    } else {  
      this.viewContainer.clear();  
    }
  }
}

Note that appIsGranted Directive is it is an overwrite of the ngIf directive implementation.

Directive usage:

<div appIsGranted="'CREATE'">
  // This block will only be shown to granted users
</div>

<my-component appIsGranted="'DELETE'">
  // This component will only be shown to granted users
</my-component>

5. Stackblitz demo implementation

rjlopez-angular-permissions-part1 - StackBlitz

Note that it is not an implementation for a real environment and contains mocked code and data.

See Angular permissions based on roles | Part 2. Permissions for multiple resources