Ensuring that users of your Angular application have the latest features, bug fixes, and security patches is critical for a smooth user experience. This post will explain a version-checking solution for Angular applications within an Nx workspace, focusing on keeping the app synchronized with the latest version hosted on the server. We’ll cover each layer of the C4 Model, from Context down to Sequence, to illustrate the technical design. At the end, we’ll discuss how Service Workers and Server-Side Rendering (SSR) could further strengthen this solution.

There are (2) aspects to consider. The build process will need to retrieve and use a specific version for the comparison. The runtime Angular application will need to be able to retrieve the local version information and compare it to what is currently deployed (i.e., production).

Build System

Build Context View

In the Context View, we look at the big picture — who interacts with the system and the primary entities involved. This diagram shows the key actors and their relationships in the version-checking process.In this view, we identify the external systems and users that interact with the version-checking process, providing a high-level overview of the system’s environment and its boundaries.

Key Actors:

• User: The person accessing the Angular application via a browser. They expect the application to be up-to-date and functional.
• Angular Application: The client-side application running in the user’s browser. It needs to check for updates to ensure it has the latest version.
• Cloud Endpoint: The server environment where the application and version information (version.json) are hosted.
• Application Host: Represents the current application instance in production, exposed via the Cloud Endpoint.

Summary of Interactions:

• The User interacts with the Angular Application through their browser.
• The Angular Application interacts with the Cloud Endpoint to retrieve the latest version information, ensuring it has the most recent version of version.json.

Build Container View

The Container View breaks down the main pieces of the system and how they interact to ensure version consistency. It includes the Angular application, its services, and the versioning files hosted on the cloud.

Main Containers:

• Angular Application: The front-end application that the user accesses.
• Build Script/Workflow: Handles the build process and includes the version-checking logic.
• Distribution Output: The final build output containing application assets, including the version.json file.
• Cloud Endpoint: Hosts the application and the version.json file, providing an endpoint for the Angular application to check the current version.

Process Overview

• During each build, the Build Script/Workflow generates and packages a version.json file based on the version in package.json.
• The version.json file is added to the Distribution Output and deployed to the Cloud Endpoint.
• The Angular Application can request version.json from the Cloud Endpoint to validate its version against the server’s latest version.

Build Component View

The Component View drills down into the specific services and logic within the Angular application that handle version checking. It describes how each piece contributes to determining if the app in the user’s browser is the latest version.

Core Components:

• Configuration Service: Retrieves and stores configuration settings, including the current application version.
• Version Check Service: Manages the version-checking process by periodically or on-demand fetching version.json from the Cloud Endpoint. It compares the server version to the locally running version.
• Notification System: Notifies the user if the application is outdated and suggests reloading to update to the latest version.

Component Interactions:

• The Angular Application initializes the Configuration Service and the Version Check Service on startup.
• The Version Check Service can be configured to perform scheduled checks or triggered on-demand by the user. It retrieves version.json from the Cloud Endpoint and compares it to the current version stored by the Configuration Service.
• If a version mismatch is detected, the Notification System alerts the user to reload the application.

Build Sequence Diagram

The Sequence Diagram illustrates the step-by-step interactions among the components to manage version checking. It shows how the Angular application, through its services, checks for updates and notifies the user as needed.

1. Build-Time Version Determination:

• The Build Script triggers the versioning process using an Nx Executor.
• The Nx Version Executor retrieves the version from package.json and updates version.json in the application assets.
• The application is built, and version.json is included in the Distribution Output, which is then deployed to the Cloud Endpoint.

2. Run-Time Version Check:

• The Version Check Service in the Angular application fetches the version.json file from the Cloud Endpoint.
• It compares the local and server versions. If a mismatch is detected, the user is notified and prompted to reload the app.

Nx Executor for Version Management

To update the executor to create a JSON file in the target project’s assets folder and provide a sample configuration in a project.json file, follow these steps:

Update the Executor to Create a JSON File

1. Modify the executor: Update your executor code to write the version information to a JSON file in the target project’s assets directory.

import { ExecutorContext } from '@nrwl/devkit';
import * as fs from 'fs';
import * as path from 'path';

interface VersionCheckOptions {
  project: string;
}

export default async function runExecutor(
  options: VersionCheckOptions,
  context: ExecutorContext
) {
  try {
    const workspaceRoot = context.root;
    const projectRoot = context.workspace.projects[options.project].root;
    const packageJsonPath = path.join(workspaceRoot, 'package.json');
    const assetsFolder = path.join(workspaceRoot, projectRoot, 'assets');
    
    if (!fs.existsSync(assetsFolder)) {
      fs.mkdirSync(assetsFolder, { recursive: true });
    }
    
    const packageJson = JSON.parse(fs.readFileSync(packageJsonPath, 'utf8'));
    const versionInfo = { version: packageJson.version };

    const outputFilePath = path.join(assetsFolder, 'version-info.json');
    fs.writeFileSync(outputFilePath, JSON.stringify(versionInfo, null, 2));

    console.log(`Version info written to ${outputFilePath}`);
    
    return { success: true };
  } catch (error) {
    console.error('Failed to write version info:', error);
    return { success: false };
  }
}

Configure the Executor in executors.json

Ensure your executors.json is correctly set up:

{
  "executors": {
    "version-check": {
      "implementation": "./src/executors/version-check/executor",
      "schema": "./src/executors/version-check/schema.json",
      "description": "Create a JSON file with version information in the project's assets folder"
    }
  }
}

Create the Executor Schema

Create a schema.json file (at libs/your-plugin-name/src/executors/version-check/) to define the options your executor will receive:

{
  "type": "object",
  "properties": {
    "project": {
      "type": "string",
      "description": "The name of the project where the JSON file will be created."
    }
  },
  "required": ["project"]
}

Sample Configuration in project.json

Here’s how you can configure a target to use this executor in a project.json file:

{
  "name": "your-project-name",
  "root": "apps/your-project-name",
  "sourceRoot": "apps/your-project-name/src",
  "projectType": "application",
  "targets": {
    "check-version": {
      "executor": "your-plugin-name:version-check",
      "options": {
        "project": "your-project-name"
      }
    }
  }
}

Run the Executor

You can now execute this target in your Nx workspace or in an automation script (e.g., CI/CD pipeline) to update the version information.

npx nx run your-project-name:check-version

This setup will create a version-info.json inside the assets folder of the specified project, containing the version information from the root package.json.

System Architecture Overview

Managing application versioning is essential to provide users with the most up-to-date content. This information will guide you through a version-checking system for Angular applications in an Nx workspace, designed to keep the application in sync with the latest version on the server. We’ll explore each layer of the C4 Model: Context, Container, Component, and Sequence, and discuss future improvements with Service Workers and Server-Side Rendering (SSR).

System Context View

The Context View provides an overview of the system and its key interactions with users and external systems. Here’s the big picture of how version management works in our setup.

Key Actors:

• User: The end-user accessing the Angular application via their browser.
• Angular Application: A single-page web application that runs in the user’s browser.
• Version Check System: Responsible for determining if the application version in the browser matches the version hosted on the server.
• Application Host: The server hosting the current version of the application, including version information in version.json.

Summary of Interactions:

• The User interacts with the Angular Application, which checks with the Application Host to verify that the application version is up to date.
• The Version Check System retrieves the version from a locally stored version.json file and compares it with the hosted version to ensure consistency.

System Container View

In the Container View, we break down the main parts of the version-checking system and how they communicate with each other. This level outlines the key services involved in version management.

Main Containers:

• Angular Application: The application itself, which runs in the browser and initiates the version check.
• Configuration Service: A service within the Angular app responsible for managing configuration settings, including version details.
• Version Check Service: Checks the application’s version status against the hosted version on a scheduled or on-demand basis.
• Version Information: Stores the current version information of the application as a JSON asset (version.json).
• Cloud Endpoint: The server where the Angular application and the version information are hosted, making them accessible to the Version Check System.

Process Overview:

• The Angular Application interacts with the Configuration Service to retrieve initial version details and periodically calls the Version Check Service to fetch the latest version information from the Cloud Endpoint.
• The Version Information file, located on the Cloud Endpoint, provides the reference version. If a mismatch is detected, the system can prompt the user to reload.

System Component View

The Component View provides a deeper look at the specific services and components that drive version checking within the Angular application. This view focuses on the internal structure and logic of the version-checking process.

Core Components:

• Angular Application: Initializes the Configuration Service and Version Check Service, which are essential to managing and verifying the version.
• Configuration Service: Sets and retrieves configuration settings, storing the current version of the application.
• Version Check Service: A dedicated service for checking the application version. It includes:
• Timer/Schedule: Manages when version checks occur, either at fixed intervals or upon user request.
• Notification System: Notifies the user if a version update is available and prompts a reload.
• Logging: Tracks version check activity for diagnostics and troubleshooting.

Component Interactions:

• The Angular Application initializes the Configuration Service and the Version Check Service when it starts up.
• The Version Check Service can be triggered on a schedule or on-demand to fetch the version.json from the Cloud Endpoint. If the version in the version.json file on the server differs from the local version, the Notification System alerts the user to reload.

System Sequence Diagram

The Sequence Diagram shows the step-by-step interactions of the version-checking system components, from initialization to version verification.

1. Application Initialization:

• The Angular Application loads configuration settings through the Configuration Service, which includes the current version information stored locally.

2. Scheduled or On-Demand Version Check:

• The Version Check Service is initialized and retrieves current version settings.
• The service checks the hosted version information file (version.json) at the Cloud Endpoint to see if a newer version is available.

3. Version Comparison and Notification:

• If a version mismatch is detected, the Version Check Service triggers the Notification System to prompt the user for a reload.
• Depending on the check (scheduled or on-demand), the system will continue to monitor for updates and notify users as needed.

Merits of the Solution

This version-checking solution offers several key benefits:

• Automation: Custom Nx executors automate the retrieval and updating of version information, reducing human error and ensuring consistency.
• User Notification: By regularly checking for updates, the application can notify users if a new version is available, enhancing the user experience.
• Configurable Checks: The solution supports both scheduled and on-demand checks, allowing flexibility in how frequently the application verifies its version.
• Simple Deployment: The use of version.json is a lightweight approach that integrates well with standard web hosting, requiring minimal server-side configuration.

Proposed Future Path: Service Workers and SSR

While the current setup is effective, it has limitations. Service Workers and Server-Side Rendering (SSR) could enhance this solution’s reliability and user experience.

Service Workers

Service Workers run in the background and can intercept network requests, making them ideal for handling caching and background updates.

Advantages:

• Automatic Background Updates: Service Workers can detect updates without user interaction, fetching the latest assets in the background.
• Enhanced Caching: Service Workers enable more efficient caching and offline capabilities, improving load times and availability.
• Smooth User Experience: Service Workers can reload the app seamlessly after an update, creating a frictionless experience for users.

Implementation:

• Angular has built-in support for Service Workers through @angular/service-worker. Configuring a Service Worker to cache assets and periodically check version.json can automate update handling.

Server-Side Rendering (SSR)

SSR renders the initial page on the server, reducing time-to-interactive and ensuring users receive the latest version upon first load.

Advantages:

• Improved Performance: SSR decreases load time by delivering pre-rendered HTML, especially beneficial for new users or slow network connections.
• SEO Boost: Pre-rendered pages improve visibility and indexing by search engines.
• Fresh Content on First Load: SSR ensures that users always get the latest version on the first load, preventing cached content issues.

Implementation

• Angular Universal can be used to set up SSR for an Angular application.
• Combining SSR with Service Workers offers both fast initial loads and background updates.

Conclusion

This version-checking system offers a robust foundation to ensure users always have the latest version of your Angular application. By leveraging a clear separation of concerns with the Configuration Service, Version Check Service, and Notification System, it provides an effective and maintainable solution. The current setup supports both build-time and run-time checks, maximizing flexibility. Looking ahead, integrating Service Workers and Server-Side Rendering (SSR) can further enhance the system, offering smoother, automated updates, greater reliability, and improved performance.

These advancements pave the way for an industrial-strength version management approach, minimizing outdated application issues and optimizing user experience.

Angular Application Version Check with Nx Executor was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

As of Nx version 17, the approach to calling Angular CLI schematics from an Nx Generator has changed. The wrapAngularDevkitSchematic function was part of Nx's utilities to bridge the gap between the Angular DevKit and Nx's devkit. However, with newer versions of Nx, this function has been removed as Nx has moved towards a more unified approach.

Calling Angular CLI Schematics in Nx v17+

To call an Angular CLI schematic from an Nx Generator in Nx v17 and later, you can use the externalSchematic function provided by Angular's DevKit. Here’s how you can do it:

1. Import externalSchematic:
2. First, you need to import externalSchematic from @angular-devkit/schematics.

import { externalSchematic } from '@angular-devkit/schematics';

3. Call the Schematic in Your Generator:

Within your Nx generator, you can use externalSchematic to execute an Angular schematic. Here’s an example:

import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';

export function myNxGenerator(options: any): Rule {
  return chain([
    // ... other rules or functions
    externalSchematic('@angular/material', 'navigation', {
      // options for the Angular schematic
    }),
    // ... other rules or functions
  ]);
}

In this example, the externalSchematic function is used to call the Angular Material navigation schematic with specific options.

Important Points

• Dependencies: Make sure you have the necessary Angular packages installed in your workspace to use their schematics.
• Compatibility: Ensure that the Angular CLI version in your workspace is compatible with Nx v17.
• Chain with Other Rules: You can chain this call with other rules or functions in your generator to create complex workflows.

Summary

In Nx v17 and later, you use the externalSchematic function from Angular's DevKit to call Angular CLI schematics within Nx generators. This approach provides a seamless way to integrate Angular CLI capabilities into your Nx workspace, enabling the use of a wide range of existing schematics alongside Nx's powerful tooling.

Complex applications require more simplicity.

In the world of Angular development, components are often considered the bedrock upon which apps are built. Couple this with a layered architecture where you separate the concerns of an application, understanding the responsibilities of an Angular component becomes even more crucial.

This article aims to address the concern of Angular Components within Enterprise web applications, how to manage and simplify these concerns and, in particular, why the use of UI Services can help mediate these responsibilities, ensuring robust, scalable, and maintainable enterprise-level applications.

What Is The Concern Of An Angular Component?

Before delving into the specifics of managing an Angular component’s concerns, we must first define what we mean by a ‘concern’. In the context of system design, a ‘concern’ is a particular aspect of the system’s functionality. For an Angular Component, the main concern lies in collecting or displaying information.

Components are one of the fundamental building blocks of any Angular application, and they serve as a conduit between the template (HTML) and the underlying data (services). In other words, components are responsible for rendering data and handling user interaction. They form the user interface logic which serve distinct purposes within the user interface, and consequently, they should only be concerned with their specific role in this domain.

@Component({
    selector: 'app-user-detail',
    templateUrl: 'user-detail.component.html'
  })
  export class UserDetailComponent {
    user$: Observable<User>;

    constructor(private userService: UserService) {}

    ngOnInit() {
      this.user$ = this.userService.getUser();
    }
  }

In the snippet above, the UserDetailComponent collects user data from the UserService and communicates this information to its template. This use of components simplifies and encapsulates the data collection and display process, so the component doesn't concern itself with where the data came from or where it's going.

Establishing The Component State

In addition to collecting and displaying data, components have another potential concern: managing their state. The ‘state’ in this context encompasses the various conditions a component can exist within throughout the lifetime of an app. Understanding and handling the different states of a component is pivotal for efficiently maintaining the component’s behavior and data flow.

The state of a component could be:

1. It’s retrieving data (isLoading state).
2. It’s submitting data (isSubmitting state).
3. The component has data (hasData state).
4. The component is in an error state due to an unsuccessful API call (isError state).

A design strategy where each state of a component is clear-cut and well-defined makes it easier to handle the rendering of each state, keeping robust and dynamic user interfaces even with unpredictable data outcomes.

UI Services: Mediating Data Operations

Cutting through the complexity that arises with handling data operations and state management of an Angular component, UI Services can make for an eloquent solution.

UI Services, as the name suggests, act as a mediator or broker for data operations between components and domain services, which implement business logic. They leverage the Dependency Injection (DI) system in Angular to share data across components which gives more control over the components’ state and reduces their concerns.

UI Services are beneficial as they ensure that:

1. Components remain ‘thin’, focusing only on their primary concern — collecting or displaying data.
2. Data is persisted across routes, ensuring a more smooth user experience.
3. Duplication of data fetching logic is minimized.

@Injectable()
export class UserUIStateService {
  private isLoading$ = new BehaviorSubject<boolean>(false);
  private isError$ = new BehaviorSubject<boolean>(false);

  constructor(private userService: UserService) {}

  loadUser() {
    this.isLoading$.next(true);
    this.userService.getUser()
      .pipe(finalize(() => this.isLoading$.next(false)))
      .subscribe(() => {}, () => this.isError$.next(true));
  }
  
  getUserDataState(): Observable<DataState> {
    return combineLatest([this.isLoading$, this.isError$])
      .pipe(map(([isLoading, isError]) => ({ isLoading, isError })));
  }
}

In the code sample above, the UserUIStateService is a UI Service. It's mediating between the userService (a domain service) and an Angular component to manage the user data. It uses BehaviorSubjects to manage and expose the state of the component (whether it's loading or error), and the loadUser method controls fetching data from the UserService while updating the loading and error state.

Conclusion

By taking the time to properly determine the concerns and responsibilities of the components in your Angular applications, you’ll be better equipped to design and build applications that are scalable, robust, and easy to maintain.

The use of UI Services significantly reduces complexity, enhances code readability, and simplifies data and state management within components. By successfully delegating responsibilities between the layers of an application, developers can navigate through large codebases more efficiently and troubleshoot more effectively.

As with all architectural decisions, the use of layered architecture and components requires careful planning and consideration, but the benefits are compelling — a more organized, maintainable, and scalable enterprise web application. Dedicate some time to understand and implement such practices, and you’ll undoubtedly see the merits and benefits reflected in your Angular applications.

Angular Components in Enterprise Web Applications: Managing and Simplifying their concerns with UI… was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Software developers and architects know that enterprise applications need a blend of the perfect blend of functionality, efficiency, and security. The ideal code would improve the user’s experience while ensuring the application’s stability. Within Angular, a TypeScript-based framework, we have a secret weapon to achieve this: Directives!

This blog post focuses on creating two directives — a sanitizer for preventing SQL Injection and Cross-Site Scripting (XSS) attacks and a trimmer to maintain the cleanliness of your input data.

Angular provides built-in functionality for creating directives to extend the functionality of HTML attributes and tags. A critical tool within Angular for working with Directives is the NG_VALUE_ACCESSOR, which provides a bridge between Angular's forms API and its DOM elements.

We will start with the code to develop the directives, and then I will provide detailed explanations.

Sanitizer Directive

// sanitize.directive.ts
import {Directive, forwardRef, HostListener} from '@angular/core';
import {NG_VALUE_ACCESSOR, ControlValueAccessor} from '@angular/forms';

@Directive({
  selector: '[appSanitizeValues]',
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => SanitizeDirective),
      multi: true
    }
  ]
})
export class SanitizeDirective implements ControlValueAccessor {
  // To hold the sanitized value
  sanitizedValue: any = '';
  onTouched: any;
  onChange: any;

  // Listen to input changes
  @HostListener('input', ['$event.target.value'])
  inputChanged(value: string) {
    const el = document.createElement('div');
    el.innerHTML = value; // converts the value to HTML to be sanitized
    this.sanitizedValue = el.textContent || el.innerText; // gets the sanitized value
    this.onChange(this.sanitizedValue); // emits the sanitized value to the Form API
  }

  registerOnChange(fn: any): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: any): void {
    this.onTouched = fn;
  }

  writeValue(value: any): void {
    this.sanitizedValue = value || '';
  }
}

Trimmer Directive

// trim.directive.ts
import {Directive, forwardRef, HostListener} from '@angular/core';
import {NG_VALUE_ACCESSOR, ControlValueAccessor} from '@angular/forms';

@Directive({
  selector: '[appTrimValues]',
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => TrimDirective),
      multi: true
    }
  ]
})
export class TrimDirective implements ControlValueAccessor {
  // To hold the trimmed value
  trimmedValue: any = '';
  onTouched: any;
  onChange: any;

  // Listen to input changes
  @HostListener('input', ['$event.target.value'])
  input(value: string): void {
    this.trimmedValue = value.trim(); // Trims the value
    this.onChange(this.trimmedValue); // Emits the trimmed value to the Form API
  }

  registerOnChange(fn: any): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: any): void {
    this.onTouched = fn;
  }

  writeValue(value: any): void {
    this.trimmedValue = value || '';
  }
}

Now that we have created both directives let’s dive into the details of how they work.

Understanding NG_VALUE_ACCESSOR and ControlValueAccessor

The NG_VALUE_ACCESSOR is a token used by Angular's Form API to access the native elements. It is combined with ControlValueAccessor, an interface that acts as a bridge between Angular's Form API and native DOM elements. By using the ControlValueAccessor interface, we can customize the way values are passed from the DOM to the Form API and vice versa.

Each directive contains a registerOnChange function that Angular calls to update the form model when the model changes. It also has a registerOnTouched function, which gets called when the form control is touched.

writeValue is used to write a new value from the form model into the view or (if needed) DOM property.

Understanding the Directive Code

The @Directive decorator creates a new directive definition process, and inside it, we are passing in some metadata.

• selector : '[appSanitizeValues]' or '[appTrimValues]' - These selectors tell Angular how to find the directive usage in the HTML template.
• providers - This tells Angular how to provide the NG_VALUE_ACCESSOR.
• provide: NG_VALUE_ACCESSOR - This is what the provider supplies.
• useExisting - tells Angular that the provider is going to use an existing token
• forwardRef - We need forwardRef here because SanitizeDirective and TrimDirective aren't defined until later, yet we are referencing it inside of itself.
• multi: true - This allows for multiple directives to be applied to the same host element.

One thing you will notice is that both directives are strikingly similar. That’s because, in Angular, the ControlValueAccessor will always have this structure.

Finally, in your main Angular module or a shared module, add your directives to the declarations array to be recognized by Angular's compiler and available for use throughout the application.

import {SanitizeDirective} from './sanitize.directive';
import {TrimDirective} from './trim.directive';

@NgModule({
  declarations: [
    SanitizeDirective,
    TrimDirective
  ],
})

Conclusion

Directives offer a powerful way to encapsulate and share behaviour changes in our Angular applications. For an enterprise-level application, using directives can help standardize functionality across vast codebases, keeping everything clean and consistent! By using NG_VALUE_ACCESSOR and ControlValueAccessor, we can leverage Angular's powerful Forms API to extend our application's functionality and enhance our control of user-generated input.

By creating a sanitizer directive, we provide an elegant solution to prevent harmful injections, increasing the overall security of our application. The trimmer directive maintains clean data in our forms for a seamless user experience. Making these part of the application initialization allows us to avoid repetitive code and unnecessary overhead.

With these new tools in your arsenal, your Angular enterprise application is poised to operate securely and effectively. Remember that the best code is not only efficient but also clean and easy to understand. Happy Coding!

Increasing Security and Improving Efficiency in Enterprise Applications with Angular Directives was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Complex applications require more simplicity.

In the world of Angular development, components are often considered the bedrock upon which apps are built. Couple this with a layered architecture where you separate the concerns of an application, understanding the responsibilities of an Angular component becomes even more crucial.

This article aims to address the concern of Angular Components within Enterprise web applications, how to manage and simplify these concerns and, in particular, why the use of UI Services can help mediate these responsibilities, ensuring robust, scalable, and maintainable enterprise-level applications.

What Is The Concern Of An Angular Component?

Before delving into the specifics of managing an Angular component’s concerns, we must first define what we mean by a ‘concern’. In the context of system design, a ‘concern’ is a particular aspect of the system’s functionality. For an Angular Component, the main concern lies in collecting or displaying information.

Components are one of the fundamental building blocks of any Angular application, and they serve as a conduit between the template (HTML) and the underlying data (services). In other words, components are responsible for rendering data and handling user interaction. They form the user interface logic which serve distinct purposes within the user interface, and consequently, they should only be concerned with their specific role in this domain.

@Component({
    selector: 'app-user-detail',
    templateUrl: 'user-detail.component.html'
  })
  export class UserDetailComponent {
    user$: Observable<User>;

    constructor(private userService: UserService) {}

    ngOnInit() {
      this.user$ = this.userService.getUser();
    }
  }

In the snippet above, the UserDetailComponent collects user data from the UserService and communicates this information to its template. This use of components simplifies and encapsulates the data collection and display process, so the component doesn't concern itself with where the data came from or where it's going.

Establishing The Component State

In addition to collecting and displaying data, components have another potential concern: managing their state. The ‘state’ in this context encompasses the various conditions a component can exist within throughout the lifetime of an app. Understanding and handling the different states of a component is pivotal for efficiently maintaining the component’s behavior and data flow.

The state of a component could be:

1. It’s retrieving data (isLoading state).
2. It’s submitting data (isSubmitting state).
3. The component has data (hasData state).
4. The component is in an error state due to an unsuccessful API call (isError state).

A design strategy where each state of a component is clear-cut and well-defined makes it easier to handle the rendering of each state, keeping robust and dynamic user interfaces even with unpredictable data outcomes.

UI Services: Mediating Data Operations

Cutting through the complexity that arises with handling data operations and state management of an Angular component, UI Services can make for an eloquent solution.

UI Services, as the name suggests, act as a mediator or broker for data operations between components and domain services, which implement business logic. They leverage the Dependency Injection (DI) system in Angular to share data across components which gives more control over the components’ state and reduces their concerns.

UI Services are beneficial as they ensure that:

1. Components remain ‘thin’, focusing only on their primary concern — collecting or displaying data.
2. Data is persisted across routes, ensuring a more smooth user experience.
3. Duplication of data fetching logic is minimized.

@Injectable()
export class UserUIStateService {
  private isLoading$ = new BehaviorSubject<boolean>(false);
  private isError$ = new BehaviorSubject<boolean>(false);

  constructor(private userService: UserService) {}

  loadUser() {
    this.isLoading$.next(true);
    this.userService.getUser()
      .pipe(finalize(() => this.isLoading$.next(false)))
      .subscribe(() => {}, () => this.isError$.next(true));
  }
  
  getUserDataState(): Observable<DataState> {
    return combineLatest([this.isLoading$, this.isError$])
      .pipe(map(([isLoading, isError]) => ({ isLoading, isError })));
  }
}

In the code sample above, the UserUIStateService is a UI Service. It's mediating between the userService (a domain service) and an Angular component to manage the user data. It uses BehaviorSubjects to manage and expose the state of the component (whether it's loading or error), and the loadUser method controls fetching data from the UserService while updating the loading and error state.

Conclusion

By taking the time to properly determine the concerns and responsibilities of the components in your Angular applications, you’ll be better equipped to design and build applications that are scalable, robust, and easy to maintain.

The use of UI Services significantly reduces complexity, enhances code readability, and simplifies data and state management within components. By successfully delegating responsibilities between the layers of an application, developers can navigate through large codebases more efficiently and troubleshoot more effectively.

As with all architectural decisions, the use of layered architecture and components requires careful planning and consideration, but the benefits are compelling — a more organized, maintainable, and scalable enterprise web application. Dedicate some time to understand and implement such practices, and you’ll undoubtedly see the merits and benefits reflected in your Angular applications.

Angular Components in Enterprise Web Applications: Managing and Simplifying their concerns with UI… was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Software developers and architects know that enterprise applications need a blend of the perfect blend of functionality, efficiency, and security. The ideal code would improve the user’s experience while ensuring the application’s stability. Within Angular, a TypeScript-based framework, we have a secret weapon to achieve this: Directives!

This blog post focuses on creating two directives — a sanitizer for preventing SQL Injection and Cross-Site Scripting (XSS) attacks and a trimmer to maintain the cleanliness of your input data.

Angular provides built-in functionality for creating directives to extend the functionality of HTML attributes and tags. A critical tool within Angular for working with Directives is the NG_VALUE_ACCESSOR, which provides a bridge between Angular's forms API and its DOM elements.

We will start with the code to develop the directives, and then I will provide detailed explanations.

Sanitizer Directive

// sanitize.directive.ts
import {Directive, forwardRef, HostListener} from '@angular/core';
import {NG_VALUE_ACCESSOR, ControlValueAccessor} from '@angular/forms';

@Directive({
  selector: '[appSanitizeValues]',
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => SanitizeDirective),
      multi: true
    }
  ]
})
export class SanitizeDirective implements ControlValueAccessor {
  // To hold the sanitized value
  sanitizedValue: any = '';
  onTouched: any;
  onChange: any;

  // Listen to input changes
  @HostListener('input', ['$event.target.value'])
  inputChanged(value: string) {
    const el = document.createElement('div');
    el.innerHTML = value; // converts the value to HTML to be sanitized
    this.sanitizedValue = el.textContent || el.innerText; // gets the sanitized value
    this.onChange(this.sanitizedValue); // emits the sanitized value to the Form API
  }

  registerOnChange(fn: any): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: any): void {
    this.onTouched = fn;
  }

  writeValue(value: any): void {
    this.sanitizedValue = value || '';
  }
}

Trimmer Directive

// trim.directive.ts
import {Directive, forwardRef, HostListener} from '@angular/core';
import {NG_VALUE_ACCESSOR, ControlValueAccessor} from '@angular/forms';

@Directive({
  selector: '[appTrimValues]',
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => TrimDirective),
      multi: true
    }
  ]
})
export class TrimDirective implements ControlValueAccessor {
  // To hold the trimmed value
  trimmedValue: any = '';
  onTouched: any;
  onChange: any;

  // Listen to input changes
  @HostListener('input', ['$event.target.value'])
  input(value: string): void {
    this.trimmedValue = value.trim(); // Trims the value
    this.onChange(this.trimmedValue); // Emits the trimmed value to the Form API
  }

  registerOnChange(fn: any): void {
    this.onChange = fn;
  }

  registerOnTouched(fn: any): void {
    this.onTouched = fn;
  }

  writeValue(value: any): void {
    this.trimmedValue = value || '';
  }
}

Now that we have created both directives let’s dive into the details of how they work.

Understanding NG_VALUE_ACCESSOR and ControlValueAccessor

The NG_VALUE_ACCESSOR is a token used by Angular's Form API to access the native elements. It is combined with ControlValueAccessor, an interface that acts as a bridge between Angular's Form API and native DOM elements. By using the ControlValueAccessor interface, we can customize the way values are passed from the DOM to the Form API and vice versa.

Each directive contains a registerOnChange function that Angular calls to update the form model when the model changes. It also has a registerOnTouched function, which gets called when the form control is touched.

writeValue is used to write a new value from the form model into the view or (if needed) DOM property.

Understanding the Directive Code

The @Directive decorator creates a new directive definition process, and inside it, we are passing in some metadata.

• selector : '[appSanitizeValues]' or '[appTrimValues]' - These selectors tell Angular how to find the directive usage in the HTML template.
• providers - This tells Angular how to provide the NG_VALUE_ACCESSOR.
• provide: NG_VALUE_ACCESSOR - This is what the provider supplies.
• useExisting - tells Angular that the provider is going to use an existing token
• forwardRef - We need forwardRef here because SanitizeDirective and TrimDirective aren't defined until later, yet we are referencing it inside of itself.
• multi: true - This allows for multiple directives to be applied to the same host element.

One thing you will notice is that both directives are strikingly similar. That’s because, in Angular, the ControlValueAccessor will always have this structure.

Finally, in your main Angular module or a shared module, add your directives to the declarations array to be recognized by Angular's compiler and available for use throughout the application.

import {SanitizeDirective} from './sanitize.directive';
import {TrimDirective} from './trim.directive';

@NgModule({
  declarations: [
    SanitizeDirective,
    TrimDirective
  ],
})

Conclusion

Directives offer a powerful way to encapsulate and share behaviour changes in our Angular applications. For an enterprise-level application, using directives can help standardize functionality across vast codebases, keeping everything clean and consistent! By using NG_VALUE_ACCESSOR and ControlValueAccessor, we can leverage Angular's powerful Forms API to extend our application's functionality and enhance our control of user-generated input.

By creating a sanitizer directive, we provide an elegant solution to prevent harmful injections, increasing the overall security of our application. The trimmer directive maintains clean data in our forms for a seamless user experience. Making these part of the application initialization allows us to avoid repetitive code and unnecessary overhead.

With these new tools in your arsenal, your Angular enterprise application is poised to operate securely and effectively. Remember that the best code is not only efficient but also clean and easy to understand. Happy Coding!

Increasing Security and Improving Efficiency in Enterprise Applications with Angular Directives was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building Dynamic UIs: Angular’s Component-Based Approach Meets Enterprise Patterns

Developing dynamic and responsive user interfaces present a unique challenge in the realm of enterprise applications. They must be scalable, maintainable, and able to handle large volumes of data while providing an intuitive and responsive user experience.

Angular, a robust front-end web application framework by Google, provides a solid solution to this challenge. Offering a component-based architecture, Angular encourages developers to break their application into smaller, reusable pieces called components. This approach greatly simplifies the process of creating complex user interfaces and promotes modularity, reusability, and testability.

This blog post will demystify the complexities of building dynamic user interfaces in enterprise applications. We will delve into the nuances of Angular’s component-based architecture and see how it aligns with CLEAN architecture and SOLID principles. Additionally, it will demonstrate this with practical, enterprise-level code examples and best practices to help the learner grasp these concepts effectively.

Challenges in Building Complex and Dynamic UIs

Developing user interfaces for enterprise applications is fraught with challenges that stem from their inherent complexity and the dynamic nature of business processes. These UIs need to be adaptable, scalable, and able to cater to a variety of user roles and workflows.

Further, enterprise applications generally integrate with several other systems and services. Therefore, the UI has to provide a seamless interface that abstracts this complexity from the user. Implementing such UIs that stay resilient against these challenges requires a well-defined architecture and appropriate design patterns.

Angular’s Component-Based Architecture

Angular addresses these challenges with its hierarchical component-based architecture. As per this architecture, an Angular application is basically a tree of components. Each component is an independent, self-contained piece of UI that encapsulates its own state (data), view (template), and logic (class).

Component-based architecture has a number of benefits. It:

• Promotes modularity and reusability, as components are independent and can be reused across different parts of the application.
• Simplifies unit testing, as components can be tested independently.
• Enhances maintainability and readability, as each component focuses on a single responsibility.
• Facilitates parallel development, wherein different teams can work on different components simultaneously, without stepping on each others’ toes.

Let’s illustrate this with a code example. Suppose you are building an e-commerce application. You could have individual components for Header, Footer, Product List, Shopping Cart, and so on. The ‘Product List’ component might look something like this:

import { Component, OnInit } from '@angular/core';
import { Product } from '../models/product';
import { ProductService } from '../services/product.service';

@Component({
  selector: 'app-product-list',
  templateUrl: './product-list.component.html',
  styleUrls: ['./product-list.component.css']
})
export class ProductListComponent implements OnInit {
  products: Product[];
  
  constructor(private productService: ProductService) { }
  
  ngOnInit(): void {
    this.products = this.productService.getProducts();
  }
}

The ProductListComponent is a self-contained unit of the application that is responsible for fetching and displaying the list of products. It uses ProductService to fetch the products, which could be coming from a back-end API. The component doesn't need to know where the data is coming from. It simply focuses on rendering the data it gets in the best way possible.

Integration with Enterprise Patterns

The component-based architecture of Angular aligns well with key software engineering principles, such as SOLID principles and CLEAN architecture. These principles guide developers to build scalable, maintainable, and testable software.

For instance, the ‘Single Responsibility Principle’ of SOLID encourages developers to have each class (component, in Angular’s case) responsible for a single piece of functionality. The above example of ProductListComponent is a great demonstration of the SRP principle. The component has one and only one responsibility: to manage and display a list of products.

The Dependency Inversion Principle is another example, which states that high-level modules shouldn’t depend directly on low-level modules. Rather, they should depend on abstractions. The ProductListComponent in our example depends on ProductService, an abstraction of the data fetching logic, rather than depend directly on a database or an API.

A quick note on Nx Workspace: a powerful monorepo tool by Nrwl. It goes hand in hand with Angular (and other similar technologies) by providing efficient tools for code management and scalability. The use of Nx Workspace is beyond the scope of this blog post, but it’s highly recommended for managing code in large, enterprise-level Angular applications.

Best Practices for Clean Architecture

Imbuing your Angular project with the principles of clean architecture goes a long way in ensuring its scalability, maintainability, and testability. Here are some best practices to follow:

1. Adhere to the Single Responsibility Principle (SRP). Each component, service, or class should do one thing and do it well.
2. Leverage Angular’s Dependency Injection. Use services to handle cross-component communication and external service interaction. Services in Angular are singleton objects that get instantiated only once during the lifetime of an application.
3. Enforce strict separation of concerns. Segregate the application functionality using modules. For example, Authentication, User Management, and Products could be different modules in an e-commerce application.
4. Use Angular Routing for navigational concerns. Angular offers a powerful router module that helps in managing navigation and maintaining the state of the application.
5. Test your components and services. Angular offers robust testing tools out of the box. Leveraging these to create unit and integration tests is a great way to enforce the correctness of your codebase.

Conclusion

Creating dynamic, scalable, and maintainable user interfaces for enterprise applications can be a daunting task. However, Angular’s component-based architecture, along with adherence to SOLID principles and Clean Architecture patterns, can help simplify the process.

With a mélange of modern design principles, best practices, and a concise codebase, this blog post has strived to demonstrate how complexity in UI development can be mitigated significantly. Further, it highlighted how embracing principled design patterns and Angular’s superb tooling can lead to a more streamlined, efficient, and satisfying developer experience.

Creative, component-based design fosters a clean, intelligent strategy towards web application development. It empowers teams to build streamlined applications that are easy to navigate, maintain, and expand. So, embrace these powerful techniques and unleash the full potential of your Angular applications! Armed with these strategies, you are well on your way to mastering complex UI development in enterprise environments.

Building Dynamic UIs: Angular’s Component-Based Approach Meets Enterprise Patterns was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, most web applications are not simple — especially when they include forms, APIs, and a database. Modern web applications now contain complex business rules and data validation requirements. Most business applications collect a fair amount of data. This means that the application or software must verify or validate that the information is correct before making expensive API calls. In addition to this, there may be other business rules that must be evaluated to ensure that the business logic is correct.

Therefore, what is your strategy to implement business rules and data validation? Most likely if you have five developers on your development team you will have five different ways to manage business rules and data validation. Over a period of time, the variance in the implementation of this type of code will create technical debt that will be difficult to overcome. If the application supports revenue generation then it is essential that the code is conventional, consistent, repeatable, and for sure testable.

Game Plan and Strategy

Hope is not a good strategy. If you hope the code will just work and the business rules will be fine without any thought or planning, good luck!

There are different sources in your application that may require validation. The validation and business rule strategy may include the Angular form validators. However, this is just the first layer of validation and business rule processing of the application. As the code progresses towards making an API call there are other opportunities for validation and business rule processing. Most likely there will be different types of validation using different mechanisms.

I like to imagine a set of safety nets that are layered depending on the layer of the application (UI/UX, UI Services, domain service layers, business logic, and data access/HTTP calls). This is where it gets interesting. In the lower layers of your application, you cannot use the reactive form Validators that implements the ValidatorFn interface. Therefore you might want to consider using a rule engine to create a more conventional way to manage validation and business rules.

Type of Validation and Rules

1. form input (synchronous)
2. asynchronous validation of form input that may include an API operation
3. business logic with business rules
4. data validation before an API call

Occasionally you might need to create a custom validator for form input. This custom validator might be synchronous or async. Either way, you will need to write some custom code. The validator must also be testable to verify the results. It should be a pure function — see an example here.

Motivation

Two core principles of great software design are Separation of Concerns (SoC) and Single Responsibility. Business rules and validation are an integral part of most business applications. There are rules and validations that must occur during the processing of business logic. Most applications will combine the business logic with rules and data validation — when this happens, testing and maintaining applications becomes more difficult.

A rule engine allows the application to have a good Separation of Concerns (SOR). A good rule engine allows you to:

• Quickly start using out-of-the-box rules that are already implemented.
• Create custom rules that are either simple or composite.
• Create rules that can be reused throughout the application. Code reuse eliminates copy/paste of common rules.
• Use a single ValidationContext to add rules, execute rules, and evaluate the rule results.
• Use a consistent pattern and mechanism to implement your business rules and data validation.
• Integrate rules with Reactive Form custom validators (async or sync).

The following diagram shows a strongly-typed Typescript rule engine that allows applications to implement simple or sophisticated business rules as well as data validation. It contains a set of common rules ready for use; as well as a framework and set of classes to create custom rules for Angular applications, components, services, and library projects.

Do not worry about the complexity of the diagram below. The diagram shows the internal design of the rule engine. The ValidationContext provides a simple API to add rules, execute rules, and to retrieve rule results.

The rule engine is using a simple design pattern called Composite. This was the first library I created using TypeScript in 2016. This was a turning point for me. I was currently using AngularJS. However, the new version of Angular 2 was just released and I was interested in its capabilities. One of my concerns was that the new version of angular was using TypeScript. Imagine that was a real concern that I had. I was a little apprehensive about adding a new programming language to my current list.

My thought was that if I could create a reusable library using TypeScript then I would learn Angular 2 along with TypeScript but with a focus on creating reusable libraries for my enterprise web applications.

International JavaScript Conference (New York 2021)

Well, five years later I am still focused on reusable libraries and Angular 2 or rather just Angular. Next month I will present at the International JavaScript Conference in New York (September 27–30, 2021) on the topic of Custom Angular Libraries.

Why use a rule engine?

Here are some reasons for using a rule engine. The biggest reason is below.

• Provides a consistent way to implement business and validation rules and provides a consistent mechanism to retrieve the results.

Most rule engines will come with predefined rules out of the box. Good rule engines will also have an API/Framework to allow you to create or compose custom rules using existing and other rules. This kind of capability is a game-changer.

The rule engine I use has a set of predefined rules ready to go.

• AreEqual
• AreNotEqual
• GuidIsValid
• IsFalse
• IsTrue
• IsNullOrUndefined
• IsNotNullOrUndefined
• Max
• Min
• Range
• StringIsRegExMatch
• StringIsNotNullEmptyRange
• StringIsNullEmptyRange

More motivation and reasons to use a rule engine:

• You can create a reusable library of custom rules and use them in one or more applications.
• Combine default with one or more custom rules to create a CompositeRule - a rule that contains other rules (ruleset).
• Each rule has a Priority property to execute rule sets in a specified sequence.
• Take advantage of Typescript classes to quickly create simple or composite (nested) rules using the API that is part of the framework.
• Use the ValidationContext to simply add, execute, and retrieve rule results.
• Code faster using Fluent API style syntax — be more productive.
• Using the CompositeRule base class, you can create a rule that contains other rules of either simple or composite types. The rule execution algorithm manages the complexity - now you can create rules and reuse rules to match your business logic.

ValidationContext

The ValidationContext is the container object for rules. It allows the developer to add, execute and retrieve the results of the evaluated rules.

• Add rules by calling the addRule() function.
• Execute rules by calling the renderRules() function.
• Retrieve the results (a list of RuleResult items) using the results public property.

The following code snippet shows import statements and initialization of the ValidationContext as a member in the class.

The following shows the entire ValidationContext class with its implementation details. It is straightforward, you make the calls in the following sequence:

1. addRule(..): Add rules that you want to evaluate.
2. renderRules(): Renders all rules added to the ValidationContext.
3. Determine the state of the validation by using either: hasRuleViolations() or isValid(). Each returns a boolean value indicating the status of the validation context.
4. Retrieve the ValidationContext.results which is a array of RuleResult items.

ValidationContext

The ValidationContext is the entry point into using the rule engine. It is small but powerful.

Adding Rules to the ValidationContext

Using an initialized [ValidationContext] object, you can add rules using a Fluent API syntax. The following example uses existing rules.

A rule requires:

• Name: the name of the rule.
• Message: the text to display if the rule fails.

Here is an example of a business action (unit of work) for adding a contact. It uses the ValidationContext to add a set of specific rules to validate the action. If all of the rules evaluate without any errors, the API is called with the contact DTO object.

Focus on the preValidateAction() method. This is where the rules are implemented for adding a new contact to the application.

Custom Rules

Notice that the rules for adding a new Contact contains an EmailAddressFormatIsValidRule rule.

Custom rules inherit from either a CompositeRule or a SimpleRule. All rules inherit from the RulePolicy class and are executed and evaluated the same way. A RuleResult is returned when a simple or composite rule is evaluated.

Rules with Rules (Composite)

A composite rule is a collection of simple and composite rules.

Notice that this composite rule contains another composite rule: StringIsRegExMatch. Rules can be an Object-Graph of rules - a rule chain. Where each rule or group of rules (Composite) must evaluate without any errors for the rule or context to be valid. If any rule fails within the ValidationContext the ValidationContextState.State is Failure.

Executing Rules

When you have added one or more rules to an instance of a ValidationContext, you are ready to execute the rules. The renderRules() method will return the ValidationContext - each of the rules is evaluated against their specified targets. You are now ready to evaluate the rule results.

this.validationContext.renderRules()

Evaluation Rule Results

After the rules are executed, you can examine the rule results. Each rendered rule will have a result — either valid or not valid, based on the rule, criteria, and target value(s).

Many times it is useful to filter or extract the failed rules from the ValidationContext. The following code snippet shows how you would extract failed rules that are marked as displayable (i.e., e.rulePolicy.isDisplayable) into a list of ServiceMessage items.

RulePolicy

The RulePolicy is the base class for all rule types. The angular-rules-engine contains (2) types of rule implementations:

1. Simple
2. Composite.

These rule types form the basis of all rules in the rule engine. The rule engine uses the Composite Design Pattern — click here for more information about this pattern. All rules have the following properties of information.

• isValid: Use to indicate the status of the rule after evaluation.
• message: Use to provide a message for failed rules.
• name: Use to create a name that identifies the specified rule.
• priority: Use to assign a numeric value to the rule. Rules are sorted by priority and executed in the same sort sequence.
• result: The output of an executed rule. It contains the result and RulePolicy information.
• isDisplayable: Use to indicate if the rule result is displayable to the caller. Default value is false. You must explicitly provide a [true] value for this when initializing a new rule.
• renderType: Currently the only option is RenderType.EvaluateAllRules.
• severity: Use to indicate the severity (Exception, Warning, or Information) if the rule evaluation is not valid.
• source: Use to indicate the source or location of the rule.

The following RulePolicy class is the base class for all rules. Each of the default rules also extends either the SimpleRule or the CompositeRule. And each of these classes extends from the RulePolicy class. The allows all rules to have common behavior and execution strategies.

IRuleComponent

This interface is just infrastructure for the rule engine. It provides the contract that all rules will contain an execute() method - this provides a consistent mechanism to begin the process of all rules that implement this interface.

export interface IRuleComponent {
    execute(): RuleResult;
}

RuleResult

The output of an executed rule is a RuleResult object that contains the rule (rulePolicy), an indicator for the rule's state (isValid), and a message to be used if the rule has failed.

Simple Rules

The main difference between SimpleRule and a CompositeRule is how they are rendered during their execution. A simple rule has a single evaluation with a single result.

The following code is the IsTrue rule. This rule evaluates the target and creates a new RuleResult in the render() method. Basically, the result is based on the evaluation of the target value. This render() method returns a single result. This is much different from a composite rule discussed later that has to return a RuleResult for each rule in a list of rules.

Composite Rules

A composite rule is a rule that contains a list of rules to be evaluated. A rule in this list can be a rule that extends from either SimpleRule or CompositeRule. This allows for a more complex implementation of rules - it is a very powerful pattern. You can have a rule that contains a list of rules, where one of those rules may be a CompositeRule, where one of those rules in the composite rule is a composite side-by-side with other simple and complex rules.

You are creating a rule tree where all rules will have to evaluate to be valid for the container rule to be valid. This pattern allows a developer to create new custom rules and then use those rules with the default rules to orchestrate a rule implementation against a target object or value.

The CompositeRule extends from RulePolicy which has the responsibility of calling render() on each rule. In the case of a composite rule, this method will iterate through the list of rules and call the execute() method of each rule. Then the results are processed to determine if any of the rules failed.

The following shows an implementation of a composite rule. Basically, this rule is using (2) default rules, both of which are also composite rules. All rules within each composite must evaluate to true for this rule to be valid.

The Range rule used in the composite rule above uses (2) simple rules to form the composite. Each rule has to evaluate to true for the entire rule to be valid.

Conclusion

There are lots of details in the implementation of a rule engine. However, remember that you only need to initialize a ValidationContext, add rules, and then call the renderRules() to evaluate the ruleset and provide a list of RuleResult items. It is that simple. Happy rule rendering.

For more information on how this cross-cutting concern library is used within a CLEAN Architecture approach with SOLID principles — please visit www.AngularArchitecture.com

Resources

• The Composite Pattern — Design Patterns Meet the Frontend
• Composite Pattern (Wikipedia)
• Composite Pattern using C#

A new software project starts pristine — no code, no projects, no files. However, in just a few days or weeks of development there might be some variations of code syntax and formatting. This may be due to different developer styles, IDEs, text editors, tools, or even scaffolding generators.

It is much easier to gain control and manage the code syntax and formatting rules with a shared monorepo and Nx Workspace. A new Nx Workspace provides ESLint rules and configuration for all projects within a workspace.

What Does It Do

The name is the combination of ES and Lint. ESLint provides the ability to analyze (e.g., lint) your EcmaScript or TypeScript code to verify it meets the criteria of specified rules and required syntax. Typically, these tools are automated for the developer and also within a continuous integration (CI) environment.

• ES: EcmaScript
• Lint: the name of a tool that analyzed C code in 1978

Some advantages to using ESLint:

• Less errors in production
• Readable, maintainable and more consistent code
• Fewer discussions about code style and aesthetic choices during code reviews
• Objective measurement of code quality

ESLint Configuration Cascades

I like that our new Nx Workspace environment provides a workspace-level ESLint configuration using the .eslintrc.json file. You get this by default when you add/generate a project in the workspace.

• Create a new Nx Workspace: npx create-nx-workspace workspace --scope-name=angular-architecture
• Add package to create an Angular application: yarn add @nrwl/angular@12.3.3 -D
• Generate a fuzzy project that needs linting: nx g @nrwl/angular:application fuzzy

When you add a new project to the Nx Workspace the CLI will add a new .eslintrc.json to the project. This means that the files in the project will use the closest .eslintrc.json configuration - if this configuration extends other configuration from upstream folders these rules will also be included in the lint evaluation process.

Adding a "root": true to a lower-level configuration will stop the cascade effect of extended rules. This limits the rules to the specific level or project - nice, if you have a custom configuration for a specific use case.

Project Level ESLint

Each project also contains a configuration for ESLint rules that apply to the project-level only using the overrides for the lint rules.

What is interesting about the project-level configuration is that it uses JSON extends to inherit lint settings from the workspace-level configuration using the extends list of .eslintrc.json files.

There is a relationship between the project and the workspace level ESLint configuration files.

Lint Your Angular Application

Here is a simple example of a linting issue in our fuzzy application. Some developers or teams may not want the following issues in the code base.

• a console.log statement exists.
• there is an empty ngOnInit method.

Run the CLI lint command to evaluate the code syntax using the rules in the current .eslintrc.json configuration for the project and workspace.

run: nx lint

The output:

Notice that the @angular-eslint/no-empty-lifecycle-method ESLint rule is an error for the empty method in the component file.

ESLint on Save

Add the following to your Visual Studio Code settings.json file.

Automated Formatting

Linting and code formatting can work together. Note, linting is focused on syntax rules based ont the target language (e.g., TypeScript, HTML, etc.). While formatting is concerned with other things like using single or double quotes. Formatting is important because it is part of the consistency and readability factors of your code base.

Configure Visual Studio Code to automatically format the entire file or modified code. Open your user settings and configure the Format section to save.

There is more to integrate Prettier with ESLint Integrate ESLint with Prettier.

Where Are My Linting Rules

Using Nx provides some really nice out-of-the-box configuration and setup for ESLint. There is a set of packages installed for the workspace that provide rules, plugins, and configuration for ESLint to just work. Here are the devDependencies that enable ESLint to work in the Nx Workspace.

Below is an example of a lint error. It contains information that tells where the rule is coming from. The no-empty-lifecycle-method rule that was used to evaluate the component file is located in the @angular-eslint package.

error Lifecycle methods should not be empty @angular-eslint/no-empty-lifecycle-method

I really like that we can install a package that contains a set of ready to use rules. You can take the default settings and you can override any rules where you want to fine tune the configuration (i.e., off, warn, error).

Conclusion

The formatting and linting rules that you or your team use can be contextual to different factors. You can establish the rules, modify them over time — evaluate the impact on the team and the code quality. It is another tool that we have to create consistent code. The Nx Workspace makes it very easy to get started.

Resources

• Github.com: nx-eslint repository
• Configuring ESLint
• Angular ESLint
• Angular ESLint with Nx Workspace
• TypeScript ESLint
• What Is a Linter? Here’s a Definition and Quick-Start Guide

Keep Your Nx Workspace Clean with ESLint was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.

I attended the Enterprise NG Conference by ng-conf last week. Eric Simons (@EricSimons40) the founder of StackBlitz got me re-engaged with StackBlitz. I learned about StackBlitz 3 years ago when I attended an Angular Meetup hosted by StackBlitz in San Francisco (2017). I was on a pleasure trip with my wife — however, when I found out that the Angular Core Team was going to be there that evening I just had to go. It was a fun night!

One of the main use-cases of StackBlitz is for online documentation — to show some code, or rather a working application within a browser. This is an amazing feat. You can load an entire development environment within a few seconds and start writing code. Seeing this live 3 years ago was amazing.

It is easy to get a StackBlitz project embedded into a web page. I used the URL for my specific StackBlitz project and embedding it on my Medium blog. My URL:

https://stackblitz.com/edit/icon-button

The result is a running Angular application with:

• Code Editor (Angular Project) with the latest version
• Visual Studio Code experience in a browser
• custom name for the StackBlitz project

You can click on the [Edit on StackBlitz] link and it will open the code and application in a separate window. You can also fork the project and modify the code.

More Uses for StackBlitz

There is a new version for the Enterprise that will allow private StackBlitz projects for a company — on-premise hosting of projects. This will allow for development teams to create and share proof-of-concept (POC) applications.

Some teams require a StackBlitz proof to accompany a bugfix item. This kind of project could demonstrate the issue with a code sample.

You could also use a StackBlitz project to target an Angular package — a custom package or a 3rd-party package you want to investigate and learn more about. You can create a POC project with working examples.

Material Button with Icon + Stackblitz was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.