Angular Standalone Components: A Practical Architecture

Standalone components are the default path for new Angular apps. The architectural win is not “no modules”—it is explicit dependencies and lazy boundaries.

Feature folders that scale

A durable layout:

feature/
  pages/
  components/
  data/
  models/
  feature.routes.ts

Pages own composition. Presentational components stay dumb. Data modules export typed constants or services—not HTTP calls from templates.

Routing with loadComponent

import { Routes } from '@angular/router';

export const PROJECT_ROUTES: Routes = [
  {
    path: '',
    loadComponent: () =>
      import('./projects-list/projects-list').then((m) => m.ProjectsListPage),
  },
  {
    path: ':slug',
    loadComponent: () =>
      import('./project-detail/project-detail').then(
        (m) => m.ProjectDetailPage,
      ),
  },
];

Static segments belong before parameterized ones. Keep federation remotes behind browser-only loaders when SSR cannot execute them.

Shared vs feature-local

Promote to shared/ only when two features need the same UI with the same API. Premature shared kits become dumping grounds.

Prefer:

• Feature-local components first
• Copy once if needed, extract on the second real reuse

Imports stay honest

Standalone imports: [] arrays make accidental coupling visible. If a “simple” page imports twelve widgets, the template is probably doing too much.

Testing mental model

Test pages with TestBed and the same standalone imports the component declares. Avoid recreating NgModule test beds unless you maintain legacy modules.

Conclusion

Standalone architecture works when routes define boundaries, features own their UI, and shared code earns its place through reuse—not convenience.