The Truth About Angular Selectorless Components

Heard about "selectorless components" in Angular? You're not alone. The term has been floating around social media for a few major Angular versions now, often presented as the next big thing for how we write components.

The problem is that "selectorless" currently describes two completely different ideas that get mixed together in discussions:

1. A community practice, dropping the selector property from the @Component decorator
2. An official Angular feature prototype, a new syntax to author components and directives directly by class name in templates

Let's untangle both, starting with the one that has no official definition.

Two Meanings, One Confusing Name

Before diving in, here's the mental model:

Keep this table in mind as we go through each meaning in detail.

Meaning #1: Omitting the Component Selector

There is no official Angular documentation defining "selectorless" as the practice of leaving out the selector in your component decorator. It's a convention some teams adopted, and it spread through blog posts and social media over time.

The selector is optional

Technically, defining a selector in the @Component decorator is not mandatory. Your application will compile and run normally without it.

@Component({
  template: `<h1>User profile</h1>`,
})
export class UserPage {}

This is valid Angular. Nothing breaks at compile time.

When you actually need a selector

In most situations, your component is used inside another component's template. Angular needs a way to recognize which class to instantiate when it encounters a tag like <app-header />. That's what the selector is for.

@Component({
  selector: "app-header",
  template: `<header>...</header>`,
})
export class Header {}

<!-- parent template -->
<app-header />

Without a selector, Angular has no tag to match in the parent template. You can't drop it on shared, reusable components.

Routed components are the exception

Routed components are loaded through the router configuration, referenced by their class, not by a template tag.

export const USER_ROUTES: Routes = [
  { path: "", component: UserPage },
  {
    path: "settings",
    loadComponent: () =>
      import("./user-settings-page").then((m) => m.UserSettingsPage),
  },
];

The router instantiates UserPage directly. Nobody writes <app-user-page /> in a parent template. From a template-authoring perspective, the selector feels unused.

Some developers prefer to remove it entirely, treating it as dead weight on page components that only ever exist behind a route.

The selector still matters in the DOM

Even when a component is only routed, the selector still defines the host element that appears in the browser DOM when the component renders.

With a selector:

@Component({
  selector: "app-user-page",
  template: `<h1>User profile</h1>`,
})
export class UserPage {}

The DOM will contain <app-user-page>...</app-user-page>.

Without a selector, Angular falls back to a generic host element:

<ng-component>...</ng-component>

Removing the selector on routed pages is a stylistic choice, not a framework requirement. Be aware that <ng-component> is less semantic in DevTools and may complicate identifying the component in the DOM.

A quick contrast

// Reusable component — selector required for template usage
@Component({
  selector: "app-user-card",
  template: `<div class="card">{{ user().name }}</div>`,
})
export class UserCard {
  user = input.required<User>();
}

// Routed page — selector optional
@Component({
  template: `<app-user-card [user]="currentUser()" />`,
  imports: [UserCard],
})
export class UserPage {
  currentUser = signal<User>({ name: "Alice" });
}

UserCard needs its selector because UserPage references it in a template. UserPage itself only needs to exist as a class in the route config.

Meaning #2: The Official Selectorless Feature

This is where things get more interesting, and where the naming collision causes the most confusion.

In 2025, the Angular team introduced an experimental prototype for a genuinely new way to author templates. This is the feature that was actually called "selectorless components" in roadmap discussions and compiler PRs.

It is not the same as deleting the selector property from your decorator.

What the prototype proposed

The idea: reference components and directives by their TypeScript class name directly in templates, instead of going through CSS selectors.

An initial implementation landed in April 2025 with PR #60724. The PR carried an explicit disclaimer:

This PR implements syntax that is still being designed and discussed. It's an initial prototype that will allow us to experiment with the runtime and run user studies.

Here's the example from that PR, showing most of the proposed syntax:

<MatButton:a
  href="/admin"
  @HasRipple
  @Tooltip(message="Cannot navigate" [disabled]="hasPermissions")
>
  Admin
</MatButton:a>

Let's break it down:

• <MatButton:a>, instantiate the MatButton component, but render it as an <a> element. The parent template chooses the host tag.
• @HasRipple, apply the HasRipple directive with no inputs, using an @ prefix instead of a selector attribute.
• @Tooltip(...), apply the Tooltip directive with inputs, again without a CSS selector.

Compared to today's syntax, the same intent might look like:

<a mat-button hasRipple [tooltip]="'Cannot navigate'" [tooltipDisabled]="hasPermissions" href="/admin">
  Admin
</a>

The prototype syntax aimed to make the component/directive relationship explicit at the template level and remove the indirection of CSS selector strings.

It was actively explored, not a one-off spike

The compiler work didn't stop at parsing. Follow-up PRs added dependency resolution, type checking, and scope analysis for selectorless templates, for example PR #61100, which wired up end-to-end template type checking for the new syntax.

This was a serious exploration, not a throwaway experiment.

What you can already do today

Worth noting from the PR discussion: you don't need selectorless syntax to apply a component to a native HTML element. Multi-selector components already support this:

@Component({
  selector: "a[mat-button], button[mat-button]",
  template: `<ng-content />`,
})
export class MatButton {}

<a mat-button href="/admin">Admin</a>
<button mat-button>Submit</button>

The prototype wasn't solving a problem that's impossible today, it was proposing a different authoring model with potential build-time optimization benefits.

Current Status: On Hold

The official selectorless feature has been removed from the Angular roadmap and placed on hold.

During the Angular monthly Q&A (April edition), Alex Rickabaugh (tech lead of the Angular framework) explained the reasoning: introducing yet another way to author Angular templates would delay the ecosystem, and AI tooling in particular, from fully adopting the standards Angular has been pushing over recent years (signals, control flow, standalone components, Signal Forms, and more).

The concern was practical: every new authoring syntax is another pattern that AI agents, linters, migration tools, and developers need to learn. The DX benefits of selectorless didn't outweigh that cost, at least for now.

The feature isn't permanently cancelled, it may be re-evaluated in the future. But you should not plan migrations or architectural decisions around it today.

Impact on the v20 style guide

The suffixless naming convention introduced in Angular v20 was partly motivated by this future feature, the idea that you'd reference <Home /> directly in a template instead of <HomeComponent />.

That motivation is now hypothetical. The naming guide still has value on its own (avoiding lazy Component/Service suffixes), but don't rename your components today expecting selectorless template syntax to arrive soon.

Summary

Omitting the selector in @Component is a valid pattern today, mainly useful for routed page components. The app compiles fine, but the DOM host element becomes <ng-component> instead of a custom tag. It's a team preference, not a framework feature.

The official selectorless template syntax was a 2025 prototype for referencing components and directives by class name. Compiler work was merged, but the feature is on hold, removed from the roadmap because another authoring model would slow down AI and tooling adoption of modern Angular.

When someone mentions "selectorless components," ask which meaning they mean. The answer changes everything about whether it's something you can use today or something to wait on.

Related Resources:

• PR #60724 — Selectorless template parsing
• PR #61100 — Selectorless dependency resolution
• Angular monthly Q&A (April edition) — selectorless on hold
• Angular File Naming Style Guide