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.

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.

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.

A working solution is available on Github at:

angularlicious/configuration-for-libraries

The Angular Workspace provides the ability to have multiple library and application projects in a single environment. Although this capability has been available since version 6, I find that many developers and teams are not taking full advantage of shared libraries. Having the ability to share and reuse code in the form of libraries adds to the effectiveness of your development team.

Think of the many shared libraries that would benefit your Angular applications. Here is a list of different library types that are common to applications.

• features
• cross-cutting concerns
• utilities
• frameworks
• foundational

There are many opportunities to create libraries for our Angular applications. However, one of the difficulties is getting the configuration to these libraries. This post will demonstrate how an Angular application can provide configuration to Libraries in an Angular Workspace environment. The focus will be on providing configuration to libraries. The Logging and ErrorHandling libraries volunteered to participate in this demonstration. However, the process and patterns could be used for any type of library in the Workspace.

What We Get from Angular

Angular applications have an environment context that provides configuration items targeting specific environments for the application. Angular libraries in the Workspace cannot access the environment context. Applications reference and use libraries — and Angular Libraries may reference and use other libraries. If libraries had access to the environment context it would cause a circular dependency.

One of the main tenets of developing reusable libraries is to keep them generic enough to be reused by many applications and libraries. Therefore, the next evolution of the target library is to create a configuration for elements that can vary. Therefore, libraries need configuration.

Note: Not all library projects need configuration, but when they do, they prefer it pushed.

Libraries Need Configuration Too

The target Angular application is the source of the configuration and has the responsibility to provide that configuration to the specified library items. Since the environment context is part of the Application’s domain, the library cannot reference and use this for its configuration.

Note: The environment context is an object with data elements. It is not strongly typed in terms of its schema. However, the members of the environment context are typed - however, there is not defined object type.

No need to worry, we can use some simple patterns and create a strongly-typed mechanism for library configuration.

Provide Strongly-Typed Configuration to Angular Libraries

Here is what needs to happen to enable configuration for libraries.

1. each library will define its own configuration schema or object type
2. each library will define an interface for the structure of the specific configuration
3. each library will subscribe to publish events of configuration
4. library configuration will be pushed to libraries
5. each library has the responsibility to validate the configuration provided
6. each library has the responsibility to define default values for any required items.
7. each application will retrieve the configuration
8. a service will provide the mechanism to publish configuration to library subscribers.

The linchpin in this scenario will be a new Configuration service that will act as a mediator between applications with configuration and the libraries that need that configuration. It is following an inversion of control pattern where libraries cannot retrieve or instantiate their own configuration — it will be provided to them. Applications will use the new ConfigurationService to publish configuration.

The main goal is to use a push strategy. The libraries should not pull or request their own configuration. It is not their responsibility to have such knowledge. Therefore, we will let the libraries react to published events of configuration when applications provide it.

Configuration Library

Create a new library in your Angular Workspace. It will be used to mediate the transfer of configuration information from applications to libraries with configuration requirements.

ng generate library configuration --publishable --unit-test-runner=jest

Add a new ConfigurationService to the library. This is a very straight-forward service. It does one thing and it does it very well. It provides the configuration from the application to any subscribers. The target subscribers in our context are libraries. However, the service could also be used by other modules, components, and services within the application.

• the settings$ is a ReplaySubject that buffers a set of values and emits the values immediately to subscribers
• the ReplaySubject will buffer or keep the one configuration available to emit to all subscribers no matter when or where they subscribe.
• a ConfigurationContext is injected into the constructor of the service.

The ConfigurationContext is just a container class for anything that can be provided to the ConfigurationModule and made available to members of that module, like the ConfigurationService. We could pass the actual configuration directly, but I like to keep my options open for future opportunities.

Interface-Driven Configuration

Notice that the settings$ ReplaySubject is of type IConfiguration. We are using an interface-driven approach to allow the interfaces to define the types for each library configuration. The IConfiguration provides the container type for all configuration members.

Providing the Configuration to Libraries

If you are wondering how the ConfigurationContext is provided to the ConfigurationModule, the library’s module has a static forRoot() method to allow applications to provide the library with the specified configuration.

The ConfigurationContext is just a class to define the members of the context. Currently, it only has a config property. The members of this class are available to the ConfigurationModule when they are set as one of the providers of the module. Basically, the forRoot() allows the module to have the input setup as a provider - the ConfigurationContext is now available for dependency injection. The service now has direct access to this input because it is injected into the constructor of the ConfigurationService.

The ConfigurationService in the ConfigurationModule contains a public ReplaySubject. The ConfigurationService is injected into the constructor of the service. This allows the LoggingService to subscribe to configuration events from the ConfigurationService. When the configuration is emitted, this service will use the provided value (i.e., IConfiguration ).

The log() method allows the LoggingService to emit a new LogEntry item. The LogWriters configured by the application will respond by sending the specified log entry to the target repository and/or the console. To recap, the LoggingService only does (2) things:

1. uses the LoggingConfig provided by the ConfigurationService to set up some of the logging information
2. creates LogEntry items and publishes them to subscribed log writers.

Library Configuration Recipe

This is a functional logging service that can be used by any number of applications and also by other Angular libraries. This is an important part of the library configuration recipe.

1. a ConfigurationService is injected into the service constructor.
2. the service subscribes to the ReplaySubject for configuration events.
3. the service handles a configuration value emitted by the ReplaySubject.
4. the service can validate and provide any required default values based on the configuration

Note: You can learn more about the log writers by reviewing the code in the GitHub repository. https://github.com/angularlicious/configuration-for-libraries

Application Configuration

The actual configuration for the application should be consistent and typed. It should also be environment specific. Therefore, the application should have a configuration defined for each application environment. Use the same convention of the environment constant.

• app.config.development.ts
• app.config.stage.ts
• app.config.production.ts

The AppConfig shown below shows the implementation of an application configuration. This configuration is typed and is based on interfaces. Since it is a Typescript object, there is no need to load the configuration using HTTP or importing a JSON file.

Note: Originally, the solution used JSON files for the configuration. The application imported the JSON file or supplied the path to the file to an HTTP GET call. This could work well in a scenario where you would like to replace the JSON file during the CI/Build process for specific environments. Keep important or private information secure!

Now, each environment (i.e., development, stage, or production) can target the specified configuration and make it available using the appConfig property of the environment object.

The application’s configuration is now ready. The ConfigurationModule is imported and the application’s configuration is provided to the module using the static forRoot() method. This module has the responsibility to load the library services and to provide the configuration.

Conclusion: (Bonus: Plug-in Services)

Notice that the module is using the APP_INITIALIZER to initialize the log writers. What are log writers? Well, the LoggingService has the responsibility to provide an endpoint for the application to send a log message and other details. The writers have the responsibility to write/send the message to a target. The ConsoleWriter simply logs events to the browser's console. You can view the log messages in the developer tools console. This works great for development. However, in non-production environments, the log items should be stored in a centralized repository.

The LogglyWriter writes the log messages to Loggly — a cloud-based provider. This implementation uses Loggly for a centralized repository of application logs. There are several cloud-based solutions to choose for centralized logging. A centralized repository allows you to monitor, filter, and analyze log events for your Angular applications.

All of this made possible using Angular Libraries and typed Configuration from the application. More information about Angular Workspace and the Angularlicious Podcast at https://angularlicio.us — or on Twitter @angularlicious.

• angularlicious/configuration-for-libraries
• Angularlicious (@angularlicious) | Twitter

Use RxJS to Push Configuration to Angular Libraries was originally published in angularlicious on Medium, where people are continuing the conversation by highlighting and responding to this story.