Angular Shared Modules

What Is a Shared Module?

In NgModule-based Angular, a "shared module" is a module that declares and exports common, reusable building blocks, so any feature module can import it once and get access to everything it exports, rather than each feature reimplementing the same button or pipe.

In standalone-component Angular, the same idea exists without a formal SharedModule class: reusable components/directives/pipes are simply standalone, and any component that needs one imports it directly.

// classic shared module
@NgModule({
  declarations: [ButtonComponent, TruncatePipe],
  exports: [ButtonComponent, TruncatePipe, CommonModule],
})
export class SharedModule {}

// standalone equivalent: nothing to declare, just import directly
@Component({
  selector: 'app-order-summary',
  standalone: true,
  imports: [ButtonComponent, TruncatePipe],
  template: '...',
})
export class OrderSummaryComponent {}

The standalone version needs no shared module at all, each consumer imports exactly what it uses.

Organizing Reusable Building Blocks

// classic: one shared module, imported everywhere
imports: [SharedModule]

// standalone: import specific pieces directly
imports: [ButtonComponent, IconComponent, TruncatePipe]

• Classic shared modules bundle multiple reusable exports behind a single imports: [SharedModule] line.
• Standalone components skip the bundling step, consumers import exactly what they need, and nothing more.
• Barrel files (an index.ts re-exporting multiple standalone pieces) can still simplify import statements without creating an actual NgModule.
• Both approaches aim for the same goal: avoid re-implementing the same reusable UI piece in multiple features.

Shared Building Blocks Cheatsheet

Comparing the classic and modern approaches to sharing reusable pieces.

Why the Shared Module Pattern Existed

Before standalone components, every component had to belong to exactly one NgModule. Re-declaring the same ButtonComponent in multiple feature modules was not allowed, so a dedicated shared module, imported by every feature that needed those common pieces, became the standard workaround.

The Standalone Equivalent: Just Import What You Need

With standalone components, there's no declaration conflict to work around, any component can simply import any other standalone component, directive, or pipe directly. This removes the shared module layer entirely while keeping the same reuse benefit.

// shared/ui/button.component.ts
@Component({ selector: 'app-button', standalone: true, template: '<button><ng-content /></button>' })
export class ButtonComponent {}

// feature/orders/order-list.component.ts
@Component({
  selector: 'app-order-list',
  standalone: true,
  imports: [ButtonComponent],
  template: '<app-button>Refresh</app-button>',
})
export class OrderListComponent {}

Using Barrel Files for Convenience

While not strictly necessary, a barrel index.ts re-exporting several related standalone pieces from a shared UI folder can make imports slightly tidier, without recreating NgModule-style coupling.

// shared/ui/index.ts
export * from './button.component';
export * from './icon.component';

// consumer
import { ButtonComponent, IconComponent } from '../shared/ui';

Common Mistakes

• Recreating a monolithic SharedModule-style barrel that re-exports far more than a given component actually needs, working against tree-shaking.
• Declaring the same reusable component in multiple NgModules in a legacy codebase, which Angular does not allow.
• Forgetting that standalone components need direct imports; there's no implicit "shared module" providing them automatically.
• Mixing classic shared modules and ad hoc standalone imports inconsistently across a codebase without a clear convention.

Key Takeaways

• Shared modules bundled common, reusable components/directives/pipes for classic NgModule-based Angular.
• Standalone components remove the need for a dedicated shared module, consumers import exactly what they use.
• Barrel index.ts files can still simplify imports for a folder of related standalone pieces.
• Both approaches serve the same underlying goal: avoid duplicating common UI building blocks across features.