17.5.2 • Published 3 months ago

@buildmotion/configuration v17.5.2

Weekly downloads
-
License
MIT
Repository
github
Last release
3 months ago

Configuration :: Custom Angular Configuration Service

Library Overview

The libs/configuration directory contains the following files and folders:

  1. Configuration Files:

    • .browserslistrc: Configuration for target browsers.
    • .eslintrc.json: ESLint configuration for linting the codebase.
    • ng-package.json: Configuration for building and packaging Angular libraries.
    • package.json: Contains metadata about the project, dependencies, and scripts.
    • project.json: Nx configuration for the library.
    • tsconfig.json, tsconfig.lib.json, tsconfig.lib.prod.json, tsconfig.spec.json: TypeScript configuration files for various build scenarios.
    • jest.config.ts: Configuration for Jest, a JavaScript testing framework.
  2. Documentation:

    • README.md: Contains documentation and information about the configuration library.
  3. Source Code:

    • src: Directory containing the source code of the library.

Overview

The configuration library provides a custom Angular service to manage and provide application configuration settings. It also provides a context for the configuration settings.

  1. Service & Module:

    • configuration.service.ts: Likely the main service file that handles configuration-related functionalities.
    • configuration.module.ts: The module file for the configuration library.
  2. Configuration Context:

    • configuration-context.ts: Possibly provides a context or environment for the configuration settings.
  3. Tests:

    • configuration.service.spec.ts: Contains unit tests for the configuration service.
    • configuration.module.spec.ts: Contains unit tests for the configuration module.
    • configuration-context.spec.ts: Contains unit tests for the configuration context.
  4. Configuration Details:

    • config: A directory that might contain detailed configuration settings, classes, or interfaces.
  5. Mocks:
    • mocks: A directory possibly containing mock data or services for testing purposes.

To understand the design, architecture, and purpose of each component, I'll briefly review each of these files. Given the scope of this analysis, I'll provide an overview and highlight essential parts of these files.

Let's start with the main service file, configuration.service.ts, to understand its capabilities and functionalities.

ConfigurationService Overview

The configuration.service.ts file defines an Angular service named ConfigurationService, which seems to manage and provide application configuration settings.

Imports and Dependencies

import { Injectable, Optional } from '@angular/core';
import { Observable, ReplaySubject, Subject } from 'rxjs';
import { ConfigurationContext } from './configuration-context';

These imports bring in Angular's core functionalities, RxJS observables, and the custom ConfigurationContext.

Service Declaration and Initialization

@Injectable({
  providedIn: 'root',
})
export class ConfigurationService<T> implements IConfigurationService<T> {
    private settingsSubject: Subject<T> = new ReplaySubject<T>(1);
    public readonly settings$: Observable<T> = this.settingsSubject.asObservable();
    config!: T;

The ConfigurationService is a generic service (indicated by <T>) that provides configuration settings. It uses a ReplaySubject to manage and emit configuration data.

Constructor

constructor(@Optional() context: ConfigurationContext<T>) {
    if (context) {
        this.settingsSubject.next(context.config);
    }
}

The service constructor accepts an optional ConfigurationContext which, if provided, emits its configuration through the settingsSubject.

Public Accessors

The service exposes settings as a public property, with getter and setter methods. The setter updates the internal configuration and emits the new configuration through the settingsSubject.

```typescript
public get settings(): T {
    return this.config;
}

public set settings(value) {
    this.config = value;
    this.settingsSubject.next(this.config);
}

Interface Declaration

export interface IConfigurationService<T> {
  readonly settings$: Observable<T>;
}

The IConfigurationService interface defines the shape of the service, ensuring it has a settings$ observable property.

Initialize Service

You can use the ConfigurationService in your Angular application by importing the ConfigurationModule and providing a ConfigurationContext object. The ConfigurationContext<T> allows you to specify a type using the <T>. This is convenient because it allows you to specify the type of the configuration settings you want to use for each Angular application - and the service will provide the configuration settings as an observable of that type.

Use the forRoot() static method to initialize the ConfigurationModule with a ConfigurationContext<T> object.

import { NgModule, ModuleWithProviders } from '@angular/core';
import { CommonModule } from '@angular/common';
import { ConfigurationContext } from './configuration-context';

@NgModule({
  imports: [CommonModule],
})
export class ConfigurationModule {
  static forRoot<T>(
    configContext: ConfigurationContext<T>
  ): ModuleWithProviders<ConfigurationModule> {
    return {
      ngModule: ConfigurationModule,
      providers: [
        {
          provide: ConfigurationContext,
          useValue: configContext,
        },
      ],
    };
  }
}

Observations & Feedback

  1. Quality & Design:

    • The service is modular and maintains a clear separation of concerns.
    • Use of TypeScript generics (<T>) ensures flexibility and type safety for various configuration structures.
  2. Architecture:

    • The service leverages the reactive programming paradigm using RxJS ReplaySubject to provide the latest configuration settings.
  3. Reactivity:

    • The use of ReplaySubject ensures that any subscriber will immediately receive the latest emitted value, making it ideal for configuration settings that might be needed immediately upon subscription.
  4. Improvement Suggestions:

    • It might be beneficial to have error handling or validation mechanisms when setting configuration values.
    • More inline comments and documentation would enhance clarity, especially for public methods and properties.
17.5.2

3 months ago

17.5.0

5 months ago

17.4.7

5 months ago

17.4.8

5 months ago

17.5.1

5 months ago

17.4.6

5 months ago

17.4.5

5 months ago

15.9.12

5 months ago

15.9.11

5 months ago

17.4.1

5 months ago

17.4.0

5 months ago

17.4.3

5 months ago

17.4.2

5 months ago

17.4.4

5 months ago

16.0.2

5 months ago

16.0.1

5 months ago

14.9.42

1 year ago

14.3.1

2 years ago

14.2.10

2 years ago

14.0.1

2 years ago

14.2.0

2 years ago

14.0.2

2 years ago

14.2.1

2 years ago

14.2.2

2 years ago

14.1.3

2 years ago

14.2.3

2 years ago

14.1.4

2 years ago

14.2.4

2 years ago

14.1.5

2 years ago

14.1.7

2 years ago

12.2.0

2 years ago