DEV Community: Damian Sire (Dev)

Evolution in Form Validators: Goodbye customError, Hello Plain Objects

Damian Sire (Dev) — Thu, 30 Oct 2025 21:42:24 +0000

Form management in Angular, especially with the arrival of Signal-based forms, is constantly evolving to improve ergonomics and the overall developer experience (DX).

A subtle but incredibly welcome change is the simplification in how we define custom validation errors.

What previously required a utility function like customError to wrap our error object, now allows us to return a plain JavaScript object (POJO) directly.

This change reduces boilerplate, simplifies the API, and makes creating validators much more intuitive.

💡 Note: The form() and validate() APIs discussed here are part of the new Signal-based forms system.

You can explore the implementation details in the Angular PR:

👉 PR #64339 — Simplify Custom Errors

🔑 The Key Change: Before and After

Let's look at a direct comparison — the core of this improvement.

Before 👎

Previously, to indicate a custom validation error, we often needed to import and use a utility function to wrap our error and ensure it was correctly typed and recognized by the forms system.

import { customError } from 'some-forms-library';

const cat = signal('meow');

const f = form(
  cat,
  (p) => {
    validate(p, () => {
      // We needed the customError wrapper
      if (p() === 'meow') {
        return customError({ kind: 'i am a custom error' });
      }
      return null;
    });
  });

🧩 Simplified Validator API in Angular Signal Forms

With the new simplified API, the validation engine is smart enough to understand a simple object as an error response.

If the validator function returns an object, it's an error.

If it returns null or undefined, it's valid.

const cat = signal('meow');

const f = form(
  cat,
  (p) => {
    validate(p, () => {
      // We simply return the error object
      if (p() === 'meow') {
        return { kind: 'iAmACustomError' }; // Much cleaner!
      }
      return null; // Valid
    });
  });

💡 Why Does This Change Matter?

🚫 Less Boilerplate

You no longer need to import customError in every validator file.

🧠 More Intuitive API

The flow feels natural — "Is there an error? If so, return the error object."

🧪 Easier Testing

Mocking or stubbing a validator is trivial when it just returns an object.

⚙️ Consistency

It aligns with how synchronous validators work in traditional reactive forms (Validators.required returns { required: true }).

🎯 Final Thoughts

While this might seem like a small change, it’s a perfect example of Angular’s ongoing effort to make APIs simpler, more consistent, and more developer-friendly.

Cleaner validators mean fewer imports, less friction, and a smoother DX overall — especially as Signal-based forms continue to mature.

File Naming Conventions: Keep Your Project Clean and Readable ✨

Damian Sire (Dev) — Sat, 27 Sep 2025 19:17:16 +0000

Ever jumped into an Angular project and felt lost in a sea of confusing file names? 🌊 Consistent naming isn't just about being tidy; it's a cornerstone of professional, maintainable, and team-friendly code. When your file structure is predictable, you spend less time searching and more time coding.

Let's break down some simple but powerful file naming conventions from the official Angular style guide that will make your life (and your teammates' lives) much easier.

Separate Words with Hyphens (Kebab-Case)

This is the foundational rule. Always separate words in your file names with hyphens. This convention, often called kebab-case, is a standard in web development and makes file names easy to read.

For example, if you have a component class named UserProfileComponent, its file name should be:

user-profile.component.ts

This is much clearer and more conventional than userprofile.ts or user_profile.ts.

Name Test Files with `.spec`

Your unit tests are first-class citizens in your project and should be easy to find. The standard is to use the exact same name as the file you are testing, but with a .spec.ts suffix.

This pattern is instantly recognizable and is the default configuration for testing frameworks like Karma and Jest in the Angular ecosystem.

For our user-profile.component.ts file, the corresponding test file would be:

user-profile.component.spec.ts

Match the File Name to Its Contents

A file's name should be a clear signpost to what's inside. When a file contains a primary identifier, like a TypeScript class, the file name should be the kebab-case version of that identifier.

For instance, a file containing the class OrderHistoryService should be named:

order-history.service.ts

A quick tip: Avoid overly generic file names like helpers.ts, utils.ts, or common.ts. While tempting, these files often become a dumping ground for unrelated code, making them hard to maintain. If you have several unrelated helper functions, consider breaking them into separate, more specific files (e.g., string-formatters.ts, validation-rules.ts).

Group Component Files by Name

A typical Angular component is made up of several files: the TypeScript logic, the HTML template, and the CSS/SCSS styles. To keep these related files neatly grouped and easy to locate, they should all share the same base name.

Following our UserProfileComponent example, its complete set of files would look like this:

user-profile.component.ts (the component class)
user-profile.component.html (the template)
user-profile.component.scss (the styles)

This makes it incredibly simple to find all the pieces of a single component.

What if a component has multiple style files? Just append a descriptive word. For example, you might have styles specific to different themes or sections:

user-profile-light.scss
user-profile-dark.scss

Why Does This Matter? 🤔

Following these conventions brings huge benefits:

Readability: Your project becomes instantly easier to scan and understand.
Findability: You can find any file you need quickly, without guesswork.
Consistency: It creates a professional and predictable structure, which is crucial when working on a team.
Tooling: Many CLI commands and IDE extensions rely on these conventions to generate, find, and link code correctly.

By adopting these simple naming rules, you're not just organizing files—you're building a more professional, scalable, and enjoyable Angular application.

Happy coding! 🚀

Is ViewChild and Lifecycle Hooks in Angular Really Code Smells? No.

Damian Sire (Dev) — Fri, 18 Apr 2025 13:21:13 +0000

Demystifying `ViewChild` in Angular: Useful Tool or Code Smell?

In recent discussions within the Angular development community, the use of ViewChild has been labeled by some as a "code smell." Supporters of this view argue it's often unnecessary, even comparing it to the redundancy of certain lifecycle hooks like ngAfterViewInit, claiming that setter functions on the @ViewChild property are enough.

However, this perspective oversimplifies both the utility of ViewChild and the core purpose of Angular lifecycle hooks. ViewChild is a decorator provided by Angular to allow a parent component to access child component instances, directives, or DOM elements within its template. Like any powerful tool, misuse can lead to design issues, and it's this misuse that might be a code smell—not the tool itself.

When Can `ViewChild` Be Problematic?

Labeling ViewChild as always a code smell is an overgeneralization. However, some usage patterns should raise concerns:

Excessive Parent-to-Child Communication: If you're constantly using ViewChild to call methods or set properties on child components, you're likely creating tight coupling. Instead, consider using @Input() to pass data and @Output() with EventEmitter to notify the parent. Shared services are another excellent alternative.
Direct DOM Manipulation: Using ViewChild to access an ElementRef and manipulate the DOM goes against Angular's abstractions. While sometimes necessary (e.g., integrating third-party libraries), Angular often provides idiomatic alternatives like property binding, attribute binding, or custom directives.

In short, if you're using ViewChild for fine-grained control or DOM manipulation without a solid reason, it's time to reconsider. Explore @Input(), @Output(), or services instead.

Setter vs. `ngAfterViewInit`: Not Interchangeable

A ViewChild setter is not a replacement for ngAfterViewInit. Setters run when that specific reference becomes available. In contrast, ngAfterViewInit runs after the component's full view and all child views are initialized.

Why This Matters:

Multiple Dependencies: If your logic depends on several ViewChild or ViewChildren references, ngAfterViewInit ensures they’re all ready.
Full View State Dependency: Sometimes your code needs the final rendered view (e.g., dimensions or position). ngAfterViewInit is the right hook for this.

Valid Use Cases for `ViewChild` and `ngAfterViewInit`

Here are legitimate scenarios where ViewChild and ngAfterViewInit are appropriate:

1. Integrating External JavaScript Libraries

Chart.js or Swiper might require a direct DOM reference. Use ViewChild to grab it, and ngAfterViewInit to safely initialize.

import { Component, AfterViewInit, ViewChild, ElementRef } from '@angular/core';
import Chart from 'chart.js/auto'; // example with Chart.js

@Component({
  selector: 'app-chart',
  template: '<canvas #myCanvas></canvas>',
})
export class ChartComponent implements AfterViewInit {
  @ViewChild('myCanvas') myCanvas!: ElementRef<HTMLCanvasElement>;
  chart: any;

  ngAfterViewInit(): void {
    const context = this.myCanvas.nativeElement.getContext('2d');
    if (context) {
      this.chart = new Chart(context, {
        type: 'bar',
        data: { /* data */ },
        options: { /* options */ }
      });
    } else {
       console.error('Could not get the 2D context from the canvas.');
    }
  }
}

From the previous case, there is no doubt that it is a good path. Now come cases where consensus is not entirely clear.

Possibles valid Use Case for ViewChild and ngAfterViewInit (Although frankly, I would use a directive)

1. Post-Render UI Logic (Also check example 5)

Tooltip positioning, layout adjustments, and viewport visibility checks require post-render DOM access. ngAfterViewInit ensures proper timing.

2. Directives Affecting Multiple Children

For example, a directive that styles table rows via @for. You need ngAfterViewInit or ngAfterContentInit and @ViewChildren or @ContentChildren.

3. Dynamic Dimension Calculations and Positioning

You often encounter scenarios where you must perform tasks based on the actual size and position of elements only after the browser has rendered them. Common examples include calculating one element's height to adjust another's layout, checking if an element is currently visible within the viewport, dynamically positioning tooltips or popovers relative to their trigger elements, or implementing complex, responsive layouts such as a masonry grid. These operations depend critically on knowing the final computed dimensions and placement.

The reason these calculations require the fully rendered view is fundamental to how web browsers work. The true dimensions (obtainable via properties like offsetWidth, offsetHeight, or methods like getBoundingClientRect()) and exact positions of elements are only finalized once the browser has processed the HTML structure, applied all relevant CSS styles, and completed the layout rendering pass. Attempting to measure elements before this stage often yields inaccurate or incomplete data.

Within an Angular application, the ngAfterViewInit lifecycle hook is specifically designed for these initial post-render calculations, firing after the component's view and child views are fully initialized. If dimensions or positions need to be recalculated later due to dynamic changes (like data updates or window resizing), you might use ngAfterViewChecked (being careful about performance) or, preferably, leverage more modern and efficient browser APIs like ResizeObserver to react specifically to element size modifications.

import { Component, AfterViewInit, ViewChild, ElementRef, Renderer2 } from '@angular/core';

@Component({
  selector: 'app-tooltip-host',
  template: `
    <button #trigger (mouseenter)="showTooltip()" (mouseleave)="hideTooltip()">Hover me</button>
    <div #tooltip class="tooltip" [style.visibility]="visible ? 'visible' : 'hidden'">
      Tooltip content!
    </div>
  `,
  styles: [`.tooltip { position: absolute; /* ... other styles ... */ }`]
})
export class TooltipHostComponent implements AfterViewInit {
  @ViewChild('trigger') trigger!: ElementRef;
  @ViewChild('tooltip') tooltip!: ElementRef;
  visible = false;

  constructor(private renderer: Renderer2) {}

  ngAfterViewInit(): void {
    // You could do an initial calculation here if necessary,
    // but the main logic is triggered by events.
  }


  showTooltip(): void {
    this.visible = true;
    // Short delay to ensure the tooltip is visible BEFORE measuring
    setTimeout(() => {
      this.positionTooltip(); // Call renamed function
    }, 0);
  }

  hideTooltip(): void {
    this.visible = false;
  }

  positionTooltip(): void {
    if (!this.visible) return; // Ensure it's visible to measure

    const triggerRect = this.trigger.nativeElement.getBoundingClientRect();
    // Needs to be rendered and visible!
    const tooltipRect = this.tooltip.nativeElement.getBoundingClientRect();
    const tooltipElement = this.tooltip.nativeElement;

    // Example: Position above the trigger
    let top = triggerRect.top - tooltipRect.height - 5; // 5px of space
    let left = triggerRect.left + (triggerRect.width / 2) - (tooltipRect.width / 2);

    // Simple logic to prevent it from going off the top (could be more complex)
    if (top < 0) {
        // Position below if it doesn't fit above
        top = triggerRect.bottom + 5;
    }

    // Adjust for scroll
    this.renderer.setStyle(tooltipElement, 'top', `${top + window.scrollY}px`);
    // Adjust for scroll
    this.renderer.setStyle(tooltipElement, 'left', `${left + window.scrollX}px`);
  }
}

Final Conclusion

ViewChild isn't inherently bad or a code smell. It’s a specific tool for specific jobs in Angular. Rejecting it entirely—or thinking a setter replaces it—ignores valid use cases and lifecycle guarantees.

The key is understanding its purpose and recognizing signs of design issues, like tight coupling or unjustified DOM manipulation.