DEV Community: Damian Sire (Dev)

Do you still need SCSS? What Next.js and Angular 22.2 actually do with native CSS nesting

Damian Sire (Dev) — Fri, 09 Oct 2026 07:45:07 +0000

Another comparison between Angular 22.2 and React/Next.js. The previous one covered @boundary, the new block for template errors: Template errors: React and Next.js vs Angular 22.2's @boundary.

Browsers now support nested CSS without a preprocessor:

.card {
  padding: 1rem;
  .title { font-weight: 600; }
  &:hover { outline: 1px solid; }
}

Cross-browser support for the relaxed nesting syntax arrived in Firefox 117, Chrome 120 and Safari 17.2, according to MDN's compatibility data. Chrome 112 and Safari 16.5 already handled nested class selectors like .title; the later versions added nested rules that start with a tag, like h2 {}. Since June 2026, nesting is Baseline widely available. (Baseline "newly available" means it works in the latest Chrome, Edge, Firefox and Safari; "widely available" comes 30 months later.)

Nesting was probably one of the most common reasons to use Sass (the language behind your .scss files). Now it's native. The question is what happens when you combine it with each framework's style isolation.

TL;DR

Next.js: CSS Modules rename every local class, nested ones included, so nesting just works; the build also flattens it.
Angular: the CLI flattens nesting before encapsulating, so it works in component styles. Avoid nesting under ::ng-deep, and know the 22.2 :host trap if raw nesting reaches the compiler.
Sass: still worth it for mixins, loops, BEM names with &__, breakpoint variables and custom Angular Material themes. For the rest, native CSS is enough.

React and Next.js: you pick the isolation

React doesn't scope styles. className works like the HTML class attribute (react.dev), so a CSS class applies to the whole page. The Next.js styling docs list several options:

Tailwind CSS: recommended "for most styling needs".
CSS Modules: a .module.css file generates unique class names, so you can use .card in different files without collisions.
Global CSS: for what is truly global.
External stylesheets, Sass and CSS-in-JS: the other options.

import styles from './card.module.css';

<div className={styles.card}>
  <h2 className={styles.title}>…</h2>
</div>

Isolation comes from renaming the classes, and that covers nesting too: the build renames every local class it finds (anything not wrapped in :global()), nested or not. We put the .card snippet from the top in a card.module.css and ran next build (Next.js 16.4 with default settings; Turbopack, the default bundler, compiles CSS with Lightning CSS). This is the output, reformatted:

.mXu7RW_card { padding: 1rem; }
.mXu7RW_card .mXu7RW_title { font-weight: 600; }
.mXu7RW_card:hover { outline: 1px solid; }

Both classes got the file's prefix, and the build also flattened the nesting. It flattened it even with a browserslist of modern browsers only: Turbopack lowers nesting regardless of your targets.

Angular: emulated encapsulation by default

Angular scopes each component's styles with no setup. Emulated encapsulation generates a unique HTML attribute per component (_ngcontent-X), adds it to the elements in its template, and inserts it into every selector in its styles. It adds a second one, _nghost-X, to the component's own host element (like <app-card>), and that's what :host selects.

Up to Angular 22.1, that rewrite didn't process style rules nested inside other style rules (rules inside at-rules such as @media were fine), as the description of PR #50693 says. With the .card snippet from the top, .title got no attribute, so it also styled the .title of any child component inside the card.

So the CLI took a shortcut: since @angular/build 19.2.8, released in April 2025, the default esbuild-based builders always flatten nesting in component styles before they reach the compiler (commit). .card { .title {} } reaches it as .card .title {}. It doesn't depend on which browsers you support: we tested a 22.2.1 project with a .browserslistrc of modern Chrome only, and it still flattened.

Angular 22.2: the fix, more than three years later

Angular 22.2 scopes nested rules when they reach the compiler. If the parent selector uses ::ng-deep (Angular's deprecated escape hatch that turns encapsulation off for the rest of the selector), nested rules aren't encapsulated: :host ::ng-deep { .foo {} } behaves like :host ::ng-deep .foo {} (commit). In 22.2.0 and 22.2.1, a nested rule under ::ng-deep could still get the attribute when an earlier rule also used ::ng-deep; 22.2.2 fixed it (commit).

That exception only helps when raw nesting reaches the compiler. In a default CLI project, don't nest under ::ng-deep at all: the CLI's flattening turns :host ::ng-deep { .foo {} } into :is() .foo {}, which matches nothing (issue #58996, open since November 2024).

The first attempt dates from June 2023. A month later, Google's internal tests found a failure in a file with base64 images; the PR was marked as blocked in 2024 and closed in 2025. The second attempt was merged in August 2026 and shipped with Angular 22.2 in September: more than three years.

In a default CLI project you'll barely notice the fix, because your component styles already arrived flattened. It matters when raw nested CSS reaches the compiler: JIT components whose styles isn't a string literal (the CLI can't see those at build time), dev builds on the webpack builders (@angular-devkit/build-angular, which don't force flattening; production builds may still flatten it when minifying for your browser targets), or libraries built with ng-packagr that target only modern browsers, which ship nesting as is.

The `:host` and `&` trap

In those cases, 22.2 brings a new side effect. We ran the same CSS through the compiler from 22.1.8 and from 22.2.0:

/* what you write */
:host { &.active { color: red; } }

/* 22.1.8: works, the browser resolves [_nghost-X].active */
[_nghost-X] { &.active { color: red; } }

/* 22.2.0: no match, the host doesn't have _ngcontent-X */
[_nghost-X] { &.active[_ngcontent-X] { color: red; } }

We confirmed it in Chromium with a JIT build of 22.2.1 whose styles was a constant, so the CLI couldn't flatten it: the rule stops applying. The same happens with :host { &:hover {} }. It's already reported as issue #71050, still unfixed in 22.2.2 (a fix, PR #71152, is open). Use the function form of :host instead: :host(.active) and :host(:hover), which is also the form that works with Shadow DOM. Your own component styles in a default CLI build (AOT or JIT with literal styles) aren't affected, because the CLI flattens them first.

This story shows how fragile it is to emulate encapsulation by rewriting selectors: every new CSS syntax has to be taught to the compiler, and every fix can break another combination.

Do you still need SCSS?

Sass is the most common preprocessor, so it's the one we compare. Less offers the same features discussed below (mixins with parameters, and loops through recursive mixins or each()), so the same reasoning applies. One practical difference: the Angular CLI compiles both (Less after you install the less package), while Next.js doesn't support Less out of the box (for Turbopack, its default bundler, it's "planned via plugins").

What Sass used to give you that is now native:

Nesting: native, with two differences. & doesn't concatenate, so there's no BEM-style &__title, and its specificity is computed like :is() (MDN).
Variables: custom properties (--brand-color), which also change at runtime. But you can't use them in a media query condition: @media (min-width: var(--bp)) doesn't work, while a Sass variable does.
Math: calc(), min(), max(), clamp() and trigonometric functions like sin() are Baseline widely available. round(), mod() and rem() are newer: Baseline newly available since May 2024, widely available from November 2026.
Color functions: color-mix() (Baseline widely available) can lighten or darken by mixing with white or black. For exact adjustments like Sass's color.adjust() (the old, now deprecated lighten() and darken()), there's relative color syntax, which works in all current major browsers (Baseline since September 2024) but won't be widely available until March 2027.

What is still Sass:

Mixins: reusable blocks of styles with parameters.

@mixin truncate($lines) {
  display: -webkit-box;
  -webkit-line-clamp: $lines;
  -webkit-box-orient: vertical;
  overflow: hidden;
}
.description { @include truncate(2); }

Loops: generating many rules from a list.

@each $name, $color in (ok: green, error: red, warning: orange) {
  .badge-#{$name} { background: $color; }
}

Custom properties cover part of what a mixin did (a reusable value you can change per component), but CSS has no way to include a parameterized block inside another rule; the closest is a utility class that reads custom properties, which you have to add in the markup. There's also no way to generate rules in a loop. Native mixins (@mixin) aren't enabled by default in any browser (Chrome has them only as a prototype behind a flag), and @function, which returns a value rather than a block of declarations, ships only in Chrome and Edge 139+. And if you want a custom Angular Material theme through its supported theming API, you still need Sass (a file with the mat.theme mixin); without it, the supported alternative is one of the prebuilt CSS themes (guide).

Beyond emulated encapsulation

The platform has two native ways to keep styles in their place.

Shadow DOM, available today. Angular offers ViewEncapsulation.ShadowDom, which affects event propagation and content projection. Angular also registers each regular shadow root with its shared style host, so Angular-managed component styles are copied into it. ExperimentalIsolatedShadowDom skips that shared-style injection, although normal CSS inheritance, including custom properties, still crosses the shadow boundary (guide, implementation).

@scope, looking ahead. @scope limits styles to a DOM subtree. It works since Chrome 118, Firefox 146 and Safari 17.4 (Safari 26.0 to 26.3 didn't apply it to <input> and <textarea>; 26.4 fixed it), and it's Baseline newly available since March 2026. There's an open request to add an encapsulation mode based on it, and a team member replied that it's something they've been thinking about. It isn't on the roadmap, and some developers already switch Angular's encapsulation off and scope components with @scope by hand (example).

Our take

New project, React or Angular: native CSS is enough for most cases. Add a preprocessor if you need mixins, loops, BEM names built with &__, breakpoints as variables in media queries, or a custom Angular Material theme.
You write nesting, the browser gets flat CSS. With default settings, both Next.js and the Angular CLI (in component styles) flatten nesting at build time, and both keep the styles isolated.
In Angular, you can already use native nesting in component styles, because the default CLI builder flattens it before encapsulating. The exception is nesting under ::ng-deep (#58996). If raw nesting reaches your compiler (non-literal JIT styles, webpack dev builds, some libraries), move to 22.2.2 or later and write host states with :host(...). On the webpack builders, moving to the esbuild-based @angular/build:application builder also avoids the problem, because it flattens first.

The underlying difference remains. React lets you choose the isolation mechanism (and choosing well is on you). Angular solves it for you (and adapting it to new CSS is on the framework, sometimes years late).

Template errors: React and Next.js vs Angular 22.2's @boundary

Damian Sire (Dev) — Fri, 02 Oct 2026 07:25:51 +0000

A dashboard with three widgets. The sales widget reads data.points.length, and one day the backend returns { points: null }. On render, null.length throws a TypeError.

The question is what the user sees: the whole screen broken, or just that widget with an error message. Each framework answers differently, and the answer says a lot about how each one is designed.

React: a class component

If a component throws while rendering and nobody catches it, React removes the UI of that root from the screen, which in a typical app means all of it. To prevent that, there's the Error Boundary: a component that implements getDerivedStateFromError to show a fallback and componentDidCatch to log the error.

import { Component } from 'react';

class ErrorBoundary extends Component {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error, info) {
    logError(error, info.componentStack);
  }

  render() {
    return this.state.hasError ? this.props.fallback : this.props.children;
  }
}

<ErrorBoundary fallback={<p>We couldn't load sales.</p>}>
  <Sales data={sales} />
</ErrorBoundary>

Two details that surprise people coming from hooks:

It has to be a class. The React docs say it plainly: there's currently no way to write an Error Boundary as a function component. The usual way out is the react-error-boundary library.
It doesn't catch everything. Event handlers, async code (setTimeout), server-side rendering and errors thrown by the boundary itself are left out. The exception is the startTransition returned by useTransition: errors thrown there do reach the boundary (the standalone startTransition imported from react doesn't: it goes to reportError).

Why it works this way: in React, error handling lives in the component lifecycle. Hooks have no equivalent of getDerivedStateFromError, so the only piece that can catch its children's errors is a class component.

Next.js: one file per route segment

Next.js builds its boundaries on top of folder-based routing. An error.tsx inside a segment wraps that segment's page and its children in a boundary; it doesn't cover the layout.tsx of the same segment, which is handled by the parent's error.tsx (Next.js docs):

'use client'; // error boundaries must be Client Components

export default function ErrorPage({
  error,
  retry,
}: {
  error: Error & { digest?: string };
  retry: () => void;
}) {
  return (
    <div>
      <h2>Something went wrong</h2>
      <button onClick={() => retry()}>Try again</button>
    </div>
  );
}

Errors bubble up to the nearest error.tsx, and global-error.tsx covers the root layout. To contain errors at the component level, not just the route level, Next.js has catchError (stable since 16.3), which turns a function into a boundary without writing the class. Its fallback receives retry(), which re-fetches and re-renders the children, so it also recovers from Server Component errors, and reset(), which only clears the error state (docs).

Why it works this way: in Next.js, the structure of the app is its folders. It makes sense for the route segment to be the natural unit of error.

Angular before 22.2: only a global handler

Angular only had ErrorHandler.handleError(): a central place to find out about an error and report it, but no built-in way to replace the broken part with a local fallback. As Ninja Squad describes it, if a component threw while rendering, the rest of its subtree wasn't rendered and the page ended up partially blank.

Angular 22.2: `@boundary`

Angular 22.2, released on September 23, 2026, adds @boundary in developer preview (official guide):

<h1>Dashboard</h1>

@boundary {
  <app-sales [data]="sales()" />
} @error (let err; when isNetworkError(err)) {
  <p>Network problem.</p>
  <button (click)="$reset()">Retry</button>
} @error {
  <p>We couldn't load sales: {{ $error.message }}</p>
}

<app-users />
<app-alerts />

Only the sales box shows the fallback; users and alerts render normally. The @error blocks are evaluated in order, and if none matches and there's no @error without when at the end, the error keeps going, wrapped in a BoundaryError with the original in .cause (source).

Before the fallback, the error reaches your ErrorHandler: onViewError() if you implement it, handleError() otherwise (source). According to the framework's tests, the block catches errors thrown by the constructors of the components inside it, their lifecycle hooks, template bindings and their effect()s.

It's not just a template block: three pieces ship together.

Piece	What it's for
`@boundary` / `@error`	The declarative version, in the template
`onError` in `createComponent` and `createEmbeddedView`	The equivalent for views created in code: you get the error in a callback and build the fallback yourself. It doesn't cover the creation phase (the constructor, or creating the view in `createEmbeddedView`): that throws synchronously from the same call
`ErrorHandler.onViewError()`	Optional hook that receives every error a boundary intercepts, so you can send it to monitoring. If you implement it, those errors no longer go through `handleError()`; if you don't, they go there

viewContainerRef.createComponent(Widget, {
  onError: (error, details) => report(error),
});

Why it works this way: in Angular, the template compiler already owns control flow (@if, @for, @defer), and a boundary is one more block, not a component. The programmatic API completes the picture: a component you insert into a ViewContainerRef located inside a @boundary is already covered (a framework test checks exactly that), but not every dynamic view has a block around it, and that's what onError is for.

Where to put them: Angular's guide doesn't say, but react.dev's criterion applies just as well. You don't need to wrap every component: a boundary goes where it makes sense to show an error message, like a widget or a third-party component. And errors you can anticipate, like a failing fetch, Angular recommends handling where they happen, with try/catch. The ErrorHandler is for reporting the unexpected.

Why we prefer Angular's approach

This section is opinion:

You don't need a class or a library. It's template syntax, just like @if.
You discriminate by error type in the template. Several @error (when ...) blocks with a catch-all at the end. In React, that logic goes inside the fallback.
Declarative, programmatic and global are part of the same feature. No need to assemble the puzzle from loose pieces.

To be fair:

@boundary is in developer preview: per the versioning policy, it can change even in a patch release. React's boundaries have years in production.
Use 22.2.2 or later. In 22.2.0 and 22.2.1, writing to a signal while a boundary handled an error threw NG0600 (#71199); 22.2.2 fixed it (PR #71204).
Next.js's catchError already solves the "I don't want to write a class" problem. And React also has a global callback: createRoot accepts onCaughtError, which receives the errors a boundary catches.
It doesn't catch event handlers either. In Angular 22.2's code, an error inside a listener goes straight to the global ErrorHandler, without going through any boundary (listeners.ts). Same limit as React.
Watch out for content projection. Wrapping <ng-content> in a @boundary doesn't catch errors from projected content: that content belongs to the view that declares it. You have to wrap the container component from the parent template (guide). In React, a boundary that wraps children does catch their errors.

Summary

React: a class component, or react-error-boundary.
Next.js: error.tsx per route and catchError per component.
Angular 22.2: a template block, with a programmatic equivalent and a global hook.

Three different designs for the same problem, each one stemming from how its framework is built.

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.