Angular Best Practices

Adhere to these core software engineering principles:

• Law of Demeter: Use only one dot notation when accessing objects or services (e.g., someObject.someProperty). Avoid deep chaining like a.b.c.d.
• DRY (Don't Repeat Yourself): Do not duplicate text, expressions, or logic. Move repeated code into constants, Enums, Classes, or functions.
• Mutation Rules:
  • Components: Avoid mutations inside components to prevent issues with OnPush change detection.
  • Nested Functions: Do not change references to object properties from within nested functions. Instead, initialize the object where it belongs and use return values to update it.
• Control Flow: Prefer if (condition) return; (early return) over if (condition) { ... } else { ... }.

Do not name interfaces or entities starting with verbs. Use nouns to describe what the entity is rather than what it does.

• Bad: CreatePoTipInfoModel (starts with a verb)
• Good: ProductOwnerTipInfoCreateModel (ends with the action/context, but the entity is a Model/Noun)

To react to @Input changes, prefer using a setter or a getter over ngOnChanges:

• Use a Setter: When you need to run logic immediately when an input value changes. This provides better type safety than ngOnChanges.
• Use a Getter: When you need to derive a value based on an input change. This is cleaner than manually updating a property in ngOnChanges.

Note: If you must use ngOnChanges (e.g., to avoid 'glitch' effects), ensure you wrap SimpleChanges in a Generic.

// Using a setter
@Input()
set userName(name: string) {
  console.log('name inside input was changed', name);
  this.firstName = name;
}
public firstName: string = '';

// Using a getter
public get isProductEditable(): boolean {
  return this.product.status === this.recordStatus.Approved && (!!this.isAdmin || !!this.isOwner);
}

Never call .subscribe() inside another .subscribe() block. This creates complex, hard-to-manage code. Instead, use RxJS higher-order operators like switchMap to flatten the streams into a single subscription.

Example Transformation: Instead of subscribing to StreamA and then subscribing to StreamB inside the callback, use StreamA.pipe(switchMap(val => StreamB(val))).subscribe(...).

// Instead of nested subscribe:
this.isModuleEditor$.pipe(
  switchMap(access => this.draftsService.getDrafts(DraftStatuses.Created, this.user.userId)),
  takeUntil(this.destroy$)
).subscribe((result) => {
  if (result) {
    this.containersService.pendingDraftState.next(result ? result : []);
  }
});

Avoid using Promise in favor of RxJS for the following reasons:

1. Cancellation: RxJS provides built-in support for unsubscription/cancellation, whereas async/await requires manual management of cancellation tokens.
2. Complexity Management: RxJS makes it easy to organize timeout and retry logic.
3. Declarative Data Fetching: You can start requests declaratively using the | async pipe in templates without manual lifecycle management.
4. State Dependency: RxJS simplifies making requests dependent on state changes like filtering, pagination, or searching.

To maintain clean boundaries and follow the Dependency Inversion principle, categorize data into three distinct types:

1. DTO (Data Transfer Object): The raw data format that comes from or goes to the backend.
2. Model: Represents business logic. These are used as value objects and should not contain methods. Map DTOs to Models inside your HTTP services.
3. VM (View Model): The specific data shape required by a component for rendering.

Follow specific prefix patterns based on the function's behavior to improve clarity:

• Side effects (modifying state/arguments): Prefix with set. Example: setSomething(data: SomeType): void.
• State changes (no arguments): Prefix with change. Example: changeSomething(): void.
• Value retrieval: Prefix with get, regardless of whether arguments are present. Examples:
  • getSomething(): string
  • getSomething(data: SomeType): string

getSometing() : string
getSometing(data: SomeType) : string

When creating an associative array where property names are known or specific, use an interface with an index signature rather than the Record<K, V> utility type. This allows you to explicitly name the property keys, which improves readability.

// Instead of Record<number, SectionCounters>
sectionsCounters: { [classifierValueId: number]: SectionCounters }

To prevent unintended data mutations between parent and child components and to support OnPush change detection strategies, follow these immutability patterns:

• Class/Interface Properties: Add the readonly modifier to all properties.
• Object References: When you cannot set individual properties to readonly, use the Readonly<T> utility type to wrap the object.
• Change Detection: When updating data, copy the object and change its reference rather than mutating existing properties.

// Good: Using readonly on properties
interface IRequirementDTO {
  readonly id: number;
  readonly name: string;
}

// Good: Using Readonly utility for objects
requiremensDTO: Readonly<IRequirementDTO>[] = [];
const user = Readonly<User>;