DEV Community: sumeyye the developer

Angular Library Linking Made Easy: Paths, Workspaces, and Symlinks

sumeyye the developer — Wed, 22 Oct 2025 08:08:22 +0000

Managing local libraries and path references in Angular projects has evolved significantly with the introduction of the new Angular application builder. What once required manual path mappings, fragile symlinks, and node_modules references is now more structured, predictable, and aligned with modern TypeScript and workspace practices. This guide walks through how path mapping works, how it has changed, and the best ways to link and manage your local libraries in brand new Angular ecosystem.

Understanding TypeScript Path Mapping

Path aliases is a powerful feature in TypeScript that helps developers simplify and organize their import statements. Instead of dealing with long and error-prone relative paths like ../../../components/button, you can define a clear and descriptive alias that points directly to a specific directory or module.

This configuration is managed through the paths property in the TypeScript configuration file (tsconfig.json), allowing you to map custom names to local folders or compiled outputs. For example:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@my-package": ["./dist/my-package"],
      "@my-second-package": ["./projects/my-second-package/src/public-api.ts"]
    }
  }
}

In this setup, @my-package serves as a shorthand reference to your locally built library. Once configured, you can import modules using @my-package instead of long relative paths, which greatly improves readability and maintainability across large projects.

When working with multiple subdirectories or a more complex folder structure, you can also use wildcards to create flexible and dynamic mappings. This pattern is especially useful for modular libraries or mono-repos that contain multiple sub-packages:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@my-package/*": ["./dist/my-package/*"]
    }
  }
}

With this approach, imports like @my-package/utils or @my-package/components/button will automatically resolve to the corresponding directories in your build output. This makes your codebase more maintainable, portable, and consistent. This is useful especially when collaborating across teams or working with multiple libraries in the same workspace.

Step-by-Step Examples of Path Configuration

As this example provides a glimpse for the path mapping, this is not the only way for the aliases. Here are the other ways to utilize this feature.

Using package.json Exports for Library Mapping

When developing internal libraries within a mono-repo, another option is to use the exports field in each library’s package.json

This allows Node and modern bundlers to resolve imports cleanly when consuming the library, without depending solely on TypeScript configuration.

   // dist/my-lib/package.json
   {
     "name": "@my-org/my-lib",
     "version": "1.0.0",
     "exports": {
       ".": "./index.js",
       "./utils": "./utils/index.ts"
     }
   }

   import { formatDate } from "@my-org/my-lib/utils";

This approach becomes especially powerful when publishing your libraries or integrating them into larger Angular mono-repos. Because, it aligns both runtime (Node) and compile-time (TypeScript) resolution.

Linking Local Libraries via Symlinks

If you want to use a local library that is not yet published to npm, you can create a symbolic link between your library’s dist output and your consuming app.

This is useful when testing or developing multiple packages in parallel.

You can create a symlink using npm or yarn:

   # Inside your library folder
   npm link

   # Inside your consuming app
   npm link @my-org/my-lib

This effectively tells Node to resolve @my-org/my-lib from your local file system instead of the npm registry.

However, note that symlinks can sometimes lead to path resolution issues with certain Angular build configurations, especially before the new application builder. With the latest builder improvements, this approach is becoming more stable and predictable.

Combining Path Mapping with Workspace Configuration

In a structured Angular workspace, especially one created with Nx or Angular CLI using multiple projects, you can combine the approaches above.

For instance, your tsconfig.base.json can define local references for in-repo libraries, while each library’s package.json provides external mappings for reuse outside the workspace.

This hybrid setup ensures that:

The workspace remains easy to navigate and refactor locally.
External consumers (or CI builds) can still resolve imports correctly once libraries are built.

For larger Angular projects or mono-repos, Workspaces (supported by both Yarn and npm) offer a clean way to manage multiple local packages within the same repository. Workspaces automatically link internal libraries together, so you can reference them by name instead of using manual file: paths or complex TypeScript aliases. This approach keeps dependencies consistent, simplifies cross-project development, and scales well for enterprise or multi-package setups.

Each of these methods has its strengths:

TypeScript paths: This is great for local development and quick imports.
package.json exports: This is ideal for libraries meant to be distributed.
Symlinks: These are convenient for local testing between projects.

Choosing the right one, or even combining them depends on the scale of your project and whether you are building internal libraries, or a full mono-repo setup.

How Path References Worked Before the New Angular Application Builder

Angular used to support path aliases to the locally installed packages by referencing to the node_modules folder like this:

// tsconfig.json
{
  "compilerOptions": {
    "paths": {
      "@angular/*": ["./node_modules/@angular/*"]
    }
  }
}

However, this approach is not recommended, hence not supported, by the TypeScript. You can find detailed guidance on this topic in the TypeScript documentation, which notes that paths should not reference mono-repo packages or those inside node_modules: Paths should not point to monorepo packages or node_modules packages.

Giving a real life example would explain the situation better. Suppose that you have such structure:

Amain angular app that consumes several npm dependencies and holds registered local paths that reference to another library locally like this:

  // angular/tsconfig.json
  {
    "compileOnSave": false,
    "compilerOptions": {
      "paths": {
        "@abp/ng.identity": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
        ],
        "@abp/ng.identity/config": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
        ],
        "@abp/ng.identity/proxy": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
        ]
      }
    }
  }

This simply references to this package physically https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages/identity

This library is also using these dependencies

  // npm/ng-packs/packages/identity/package.json
  {
    "name": "@abp/ng.identity",
    "version": "10.0.0-rc.1",
    "homepage": "https://abp.io",
    "repository": {
      "type": "git",
      "url": "https://github.com/abpframework/abp.git"
    },
    "dependencies": {
      "@abp/ng.components": "~10.0.0-rc.1",
      "@abp/ng.permission-management": "~10.0.0-rc.1",
      "@abp/ng.theme.shared": "~10.0.0-rc.1",
      "tslib": "^2.0.0"
    },
    "publishConfig": {
      "access": "public"
    }
  }

As these libraries also have their own dependencies, the identity package needs to consume them in itself. Before the application builder migration, you could register the path configuration like this

  // angular/tsconfig.json
  {
    "compileOnSave": false,
    "compilerOptions": {
      "paths": {
        "@angular/*": ["node_modules/@angular/*"],
        "@abp/*": ["node_modules/@abp/*"],
        "@swimlane/*": ["node_modules/@swimlane/*"],
        "@ngx-validate/core": ["node_modules/@ngx-validate/core"],
        "@ng-bootstrap/ng-bootstrap": [
          "node_modules/@ng-bootstrap/ng-bootstrap"
        ],
        "@abp/ng.identity": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
        ],
        "@abp/ng.identity/config": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
        ],
        "@abp/ng.identity/proxy": [
          "../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
        ]
      }
    }
  }

However, the latest builder forces more strict rules. So, it does not resolve the paths that reference to the node_modules causing a common DI error as mentioned here:

In this case, we recommend using a symlink script. You can reach them through this example application: 🔗 Angular Sample Path Reference

These scripts help you share dependencies from the main Angular app to local library projects via symlinks:

symlink-config.ps1 centralizes which library directories to touch (e.g., ../../modules/Volo.Abp.Identity/angular/projects/identity) and which packages to link (e.g., @angular, @abp, rxjs)
setup-symlinks.ps1 reads that config and, for each library, creates a node_modules folder if needed and symlinks only the listed packages from the node_modules of the app to avoid duplicate installs
remove-symlinks.ps1 cleans up by deleting those library node_modules directories so they can use their own local deps again
In angular/package.json, the symlinks:setup and symlinks:remove npm scripts simply run those two PowerShell scripts so you can execute them conveniently with your package manager.

Best Practices and Recommendations

As we have explained each way of path mapping, this part of the article aims to summarize the best practices. Here are the points you need to consider:

Prefer workspace references for large projects and mono-repos.
Use TypeScript path aliases only for local development convenience.
Strictly avoid referencing node_modules directly; let the Angular builder manage package resolution.
Maintain consistent library structures with clear package.json exports for reusable libraries.
Automate symlink creation/removal if needed to reduce manual errors.

Here is the list of common pitfalls and how you could troubleshoot them:

DI errors after path configurations for typescript config: Ensure that only one copy of each library is resolved. Avoid duplicate modules by checking node_modules and symlinks.
IDE not recognizing aliases: Confirm that tsconfig.json or tsconfig.base.json includes the correct paths configuration and that your IDE is using the correct tsconfig.
Build errors with old paths: Migrate paths pointing to node_modules to either workspace references or local library paths.
Symlink issues in CI/CD: Use automated scripts to create/remove symlinks consistently; do not rely on manual linking.
Module resolution conflicts: Check library dependencies for mismatched versions and align them using a package manager workspace strategy.

As Angular’s build system continues to mature, developers are encouraged to move away from outdated path configurations and manual symlink setups. By embracing workspace references, consistent library exports, and TypeScript path mapping, teams can build scalable, maintainable applications without wrestling with complex import paths or dependency conflicts. With the right configuration, local development becomes faster, cleaner, and far more reliable.

Building Scalable Angular Apps with Reusable UI Components

sumeyye the developer — Wed, 22 Oct 2025 07:58:30 +0000

Frontend development keeps evolving at an incredible pace, and with every new update, our implementation standards improve as well. But even as tools and frameworks change, the core principles stay the same, and one of the most important is reusability.

Reusability means building components and utilities that can be used in multiple places instead of using the same logic repeatedly. This approach not only saves time but also keeps your code clean, consistent, and easier to maintain as your project grows.

Angular fully embraces this idea by offering modern features like standalone components, signals, hybrid rendering, and component-level lazy loading.

In this article, we will explore how these features make it easier to build reusable UI components. We will also look at how to style them and organize them into shared libraries for scalable, long-term development.

🧩 Breaking Down Components for True Reusability

The first approach to make an Angular component reusable is to use standalone components. As this feature has been supported for a long time, it is now the default behavior for the latest Angular versions. Keeping that in mind, we can ensure reusability by separating a big component into smaller ones to make the small pieces usable across the application.

Here is a quick example:

Imagine you start with a single UserProfileComponent that does everything including displaying user info, recent posts, a list of friends, and even handling profile editing.

// 📖 Compact user profile component
import { Component } from "@angular/core";

@Component({
  selector: "app-user-profile",
  template: `
    <section class="profile">
      <div class="header">
        <img [src]="user.avatar" alt="User avatar" />
        <h2>{{ user.name }}</h2>
        <button (click)="editProfile()">Edit</button>
      </div>

      <div class="posts">
        <h3>Recent Posts</h3>
        <ul>
          @for (post of user.posts; track post) {
          <li>{{ post }}</li>
          }
        </ul>
      </div>

      <div class="friends">
        <h3>Friends</h3>
        <ul>
          @for (friend of user.friends; track friend) {
          <li>{{ friend }}</li>
          }
        </ul>
      </div>
    </section>
  `,
})
export class UserProfileComponent {
  user = {
    name: "Jane Doe",
    avatar: "/assets/avatar.png",
    posts: ["Angular Tips", "Reusable Components FTW!"],
    friends: ["John", "Mary", "Steve"],
  };

  editProfile() {
    console.log("Editing profile...");
  }
}

Instead of this, you can create small components like these:

user-avatar.component.ts
user-posts.component.ts
user-friends.component.ts

// 🧩 user-avatar.component.ts
import { Component, input } from "@angular/core";

@Component({
  selector: "app-user-avatar",
  template: `
    <div class="user-avatar">
      <img [src]="avatar()" alt="User avatar" />
      <h2>{{ name() }}</h2>
    </div>
  `,
})
export class UserAvatarComponent {
  name = input.required<string>();
  avatar = input.required<string>();
}

// 🧩 user-posts.component.ts
import { Component, input } from "@angular/core";

@Component({
  selector: "app-user-posts",
  template: `
    <div class="user-posts">
      <h3>Recent Posts</h3>
      <ul>
        @for (post of posts(); track post) {
        <li>{{ post }}</li>
        }
      </ul>
    </div>
  `,
})
export class UserPostsComponent {
  posts = input<string[]>([]);
}

// 🧩 user-friends.component.ts
import { Component, input, output } from "@angular/core";

@Component({
  selector: "app-user-friends",
  template: `
    <div class="user-friends">
      <h3>Friends</h3>
      <ul>
        @for (friend of friends(); track friend) {
        <li (click)="selectFriend(friend)">{{ friend }}</li>
        }
      </ul>
    </div>
  `,
})
export class UserFriendsComponent {
  friends = input<string[]>([]);
  friendSelected = output<string>();

  selectFriend(friend: string) {
    this.friendSelected.emit(friend);
  }
}

Then, you can use them in a container component like this

// 🧩 new user profile components that uses other user components
import { Component } from "@angular/core";
import { signal } from "@angular/core";
import { UserAvatarComponent } from "./user-avatar.component";
import { UserPostsComponent } from "./user-posts.component";
import { UserFriendsComponent } from "./user-friends.component";

@Component({
  selector: "app-user-profile",
  imports: [UserAvatarComponent, UserPostsComponent, UserFriendsComponent],
  template: `
    <section class="profile">
      <app-user-avatar [name]="user().name" [avatar]="user().avatar" />
      <app-user-posts [posts]="user().posts" />
      <app-user-friends
        [friends]="user().friends"
        (friendSelected)="onFriendSelected($event)"
      />
    </section>
  `,
})
export class UserProfileComponent {
  user = signal({
    name: "Jane Doe",
    avatar: "/assets/avatar.png",
    posts: ["Angular Tips", "Reusable Components FTW!"],
    friends: ["John", "Mary", "Steve"],
  });

  onFriendSelected(friend: string) {
    console.log(`Selected friend: ${friend}`);
  }
}

The most common problem of creating such components is over-creating new elements when you actually do not need them. So, it is a design decision that needs to be carefully taken while building the application. If misused, it can lead to:

a management nightmare
unnecessary lifecycle hook complexity
extra indirect data flow (makes debugging harder)

Nevertheless, this makes the app more scalable and maintainable if correctly used. Such structure will provide:

a clear separation of concerns as each component will maintain decided tasks
faster feature development
shared libraries or elements across the application

🚀 Why Standalone Components Matter

As Angular has announced standalone components starting from version 17, they have been gradually developing features that support reusability. This important feature brings a great migration for components, directives, and pipes.

Since it allows these elements to be used directly inside an imports array rather than through a module structure, it reinforces reusability patterns and simplifies management.

Back in the module-based structure, we used to create these components and declare them in modules. This still offers some reusability, as we can import the modules where needed. However, standalone components can be consumed both by other standalone components and modules. For this reason, migrating from the module-based structure to a fully standalone architecture brings many benefits for this concern.

🧠 Designing Components That Scale and Reuse Well

The first point you need to consider here is to encapsulate and isolate logic.

For example:

This counter component isolates the concept of incrementing/decrementing so the parent component will not take care of this logic except showing the result.

   import { Component, signal } from "@angular/core";

   @Component({
     selector: "app-counter",
     template: `
       <button (click)="decrement()">-</button>
       <span>{{ count() }}</span>
       <button (click)="increment()">+</button>
     `,
   })
   export class CounterComponent {
     private count = signal(0); // internal state

     increment() {
       this.count.update((v) => v + 1);
     }
     decrement() {
       this.count.update((v) => v - 1);
     }
   }

This component isolates the styles and makes the badge reusable. Styles in this component will not leak out to others, and global styles will not affect it.

   import { Component, ViewEncapsulation } from "@angular/core";

   @Component({
     selector: "app-badge",
     template: `<span class="badge">{{ label }}</span>`,
     styles: [
       `
         .badge {
           background: #007bff;
           color: white;
           padding: 4px 8px;
           border-radius: 4px;
         }
       `,
     ],
     encapsulation: ViewEncapsulation.Emulated, // default; isolates CSS
   })
   export class BadgeComponent {
     label = "New";
   }

The search component below is a very common example since it handles a business logic exposing simple inputs/outputs

   import { Component, input, output } from "@angular/core";

   @Component({
     selector: "app-search-box",
     template: `
       <input
         type="text"
         [value]="query()"
         (input)="onChange($event)"
         placeholder="Search..."
       />
     `,
   })
   export class SearchBoxComponent {
     query = input<string>("");
     changed = output<string>();

     onChange(event: Event) {
       const value = (event.target as HTMLInputElement).value;
       this.changed.emit(value);
     }
   }

Encapsulation ensures that each component manages its own logic without leaking details to the outside. By keeping behavior self-contained, components become easier to understand, test, and reuse. This isolation prevents unexpected side effects, keeps your UI predictable, and allows each component to evolve independently as your application grows.

At this point, we can also briefly mention smart and dumb components. Smart components handle business logic, while dumb components take care of displaying data and emitting user actions.

This separation keeps your UI structure scalable. Smart components can change how data is loaded or handled without affecting presentation components, and dumb components can be reused anywhere since they just rely on inputs and outputs.

// smart component (container)
@Component({
  selector: "app-user-profile",
  imports: [UserCardComponent],
  template: `<app-user-card [user]="user()" (select)="onSelect($event)" />`,
})
export class UserProfileComponent {
  user = signal({ name: "Jane", role: "Admin" });

  onSelect(user: any) {
    console.log("Selected user:", user);
  }
}

// dumb component (presentation)
@Component({
  selector: "app-user-card",
  standalone: true,
  template: `
    <div (click)="select.emit(user())" class="card">
      <h3>{{ user().name }}</h3>
      <p>{{ user().role }}</p>
    </div>
  `,
})
export class UserCardComponent {
  user = input.required<{ name: string; role: string }>();
  select = output<{ name: string; role: string }>();
}

🔁 Reusing Components Across the Application

As there are many ways of reusing a component in the project, we will go over a real-life example.

Here are two very common ABP components that can be reused anywhere in the app:

//...
import { ABP } from "@abp/ng.core";

@Component({
  selector: "abp-button",
  template: `
    <button
      #button
      [id]="buttonId"
      [attr.type]="buttonType"
      [attr.form]="formName"
      [ngClass]="buttonClass"
      [disabled]="loading || disabled"
      (click.stop)="click.next($event); abpClick.next($event)"
      (focus)="focus.next($event); abpFocus.next($event)"
      (blur)="blur.next($event); abpBlur.next($event)"
    >
      <i [ngClass]="icon" class="me-1" aria-hidden="true"></i
      ><ng-content></ng-content>
    </button>
  `,
  imports: [NgClass],
})
export class ButtonComponent implements OnInit {
  private renderer = inject(Renderer2);

  @Input()
  buttonId = "";

  @Input()
  buttonClass = "btn btn-primary";

  @Input()
  buttonType = "button";

  @Input()
  formName?: string = undefined;

  @Input()
  iconClass?: string;

  @Input()
  loading = false;

  @Input()
  disabled: boolean | undefined = false;

  @Input()
  attributes?: ABP.Dictionary<string>;

  @Output() readonly click = new EventEmitter<MouseEvent>();

  @Output() readonly focus = new EventEmitter<FocusEvent>();

  @Output() readonly blur = new EventEmitter<FocusEvent>();

  @Output() readonly abpClick = new EventEmitter<MouseEvent>();

  @Output() readonly abpFocus = new EventEmitter<FocusEvent>();

  @Output() readonly abpBlur = new EventEmitter<FocusEvent>();

  @ViewChild("button", { static: true })
  buttonRef!: ElementRef<HTMLButtonElement>;

  get icon(): string {
    return `${
      this.loading ? "fa fa-spinner fa-spin" : this.iconClass || "d-none"
    }`;
  }

  ngOnInit() {
    if (this.attributes) {
      Object.keys(this.attributes).forEach((key) => {
        if (this.attributes?.[key]) {
          this.renderer.setAttribute(
            this.buttonRef.nativeElement,
            key,
            this.attributes[key]
          );
        }
      });
    }
  }
}

This button component can be used by simply importing the ButtonComponent and using the <abp-button /> tag.

You can reach the source code here.

This modal component is also commonly used. The source code is here.

//...
export type ModalSize = "sm" | "md" | "lg" | "xl";

@Component({
  selector: "abp-modal",
  templateUrl: "./modal.component.html",
  styleUrls: ["./modal.component.scss"],
  providers: [SubscriptionService],
  imports: [NgTemplateOutlet],
})
export class ModalComponent implements OnInit, OnDestroy, DismissableModal {
  protected readonly confirmationService = inject(ConfirmationService);
  protected readonly modal = inject(NgbModal);
  protected readonly modalRefService = inject(ModalRefService);
  protected readonly suppressUnsavedChangesWarningToken = inject(
    SUPPRESS_UNSAVED_CHANGES_WARNING,
    {
      optional: true,
    }
  );
  protected readonly destroyRef = inject(DestroyRef);
  private document = inject(DOCUMENT);

  visible = model<boolean>(false);

  busy = input(false, {
    transform: (value: boolean) => {
      if (this.abpSubmit() && this.abpSubmit() instanceof ButtonComponent) {
        this.abpSubmit().loading = value;
      }
      return value;
    },
  });

  options = input<NgbModalOptions>({ keyboard: true });

  suppressUnsavedChangesWarning = input(
    this.suppressUnsavedChangesWarningToken
  );

  modalContent = viewChild<TemplateRef<any>>("modalContent");

  abpHeader = contentChild<TemplateRef<any>>("abpHeader");

  abpBody = contentChild<TemplateRef<any>>("abpBody");

  abpFooter = contentChild<TemplateRef<any>>("abpFooter");

  abpSubmit = contentChild(ButtonComponent, { read: ButtonComponent });

  readonly init = output();

  readonly appear = output();

  readonly disappear = output();

  modalRef!: NgbModalRef;

  isConfirmationOpen = false;

  modalIdentifier = `modal-${uuid()}`;

  get modalWindowRef() {
    return this.document.querySelector(
      `ngb-modal-window.${this.modalIdentifier}`
    );
  }

  get isFormDirty(): boolean {
    return Boolean(this.modalWindowRef?.querySelector(".ng-dirty"));
  }

  constructor() {
    effect(() => {
      this.toggle(this.visible());
    });
  }

  ngOnInit(): void {
    this.modalRefService.register(this);
  }

  dismiss(mode: ModalDismissMode) {
    switch (mode) {
      case "hard":
        this.visible.set(false);
        break;
      case "soft":
        this.close();
        break;
      default:
        break;
    }
  }

  protected toggle(value: boolean) {
    this.visible.set(value);

    if (!value) {
      this.modalRef?.dismiss();
      this.disappear.emit();
      return;
    }

    setTimeout(() => this.listen(), 0);
    this.modalRef = this.modal.open(this.modalContent(), {
      size: "md",
      centered: false,
      keyboard: false,
      scrollable: true,
      beforeDismiss: () => {
        if (!this.visible()) return true;

        this.close();
        return !this.visible();
      },
      ...this.options(),
      windowClass: `${this.options().windowClass || ""} ${
        this.modalIdentifier
      }`,
    });

    this.appear.emit();
  }

  ngOnDestroy(): void {
    this.modalRefService.unregister(this);
    this.toggle(false);
  }

  close() {
    if (this.busy()) return;

    if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
      if (this.isConfirmationOpen) return;

      this.isConfirmationOpen = true;
      this.confirmationService
        .warn(
          "AbpUi::AreYouSureYouWantToCancelEditingWarningMessage",
          "AbpUi::AreYouSure",
          {
            dismissible: false,
          }
        )
        .subscribe((status: Confirmation.Status) => {
          this.isConfirmationOpen = false;
          if (status === Confirmation.Status.confirm) {
            this.visible.set(false);
          }
        });
    } else {
      this.visible.set(false);
    }
  }

  listen() {
    if (this.modalWindowRef) {
      fromEvent<KeyboardEvent>(this.modalWindowRef, "keyup")
        .pipe(
          takeUntilDestroyed(this.destroyRef),
          debounceTime(150),
          filter(
            (key: KeyboardEvent) =>
              key && key.key === "Escape" && this.options().keyboard
          )
        )
        .subscribe(() => this.close());
    }

    fromEvent(window, "beforeunload")
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe((event) => {
        if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
          event.preventDefault();
        }
      });

    this.init.emit();
  }
}

This concept differs slightly from the others mentioned above since these components are introduced within a library called theme-shared, which you can explore here.

Using shared libraries for such common components is one of the most effective ways to make your app modular and maintainable. By grouping frequently used elements into a dedicated library, you create a single source of truth for your UI and logic.

However, over-creating or prematurely abstracting small pieces of logic into separate libraries can lead to unnecessary complexity and dependency management overhead. When every feature has its own “mini-library,” updates and debugging become scattered and difficult to coordinate.

The key is to extract shared functionality only when it is proven to be reused across multiple contexts. Start small, let patterns emerge naturally, and then move them into a shared library when the benefits of reusability outweigh the maintenance cost.

⚙️ Best Practices and Common Pitfalls

✅ Best Practices

Start with real reuse: Extract components only after the pattern appears in multiple places.
Keep them focused: One clear responsibility per component—avoid “do-it-all” designs.
Use standalone components: Simplify imports and improve independence.
Promote through libraries: Move proven, stable components into shared libraries for wider use.

⚠️ Common Mistakes

Premature abstraction: Don't create components before actual reuse.
Too many input/output bindings: Overly generic components are hard to configure and maintain.
Neglecting performance: Too many micro-components can hurt performance.
Ignoring accessibility and semantics: Reusable does not mean usable—always consider ARIA roles and HTML structure.

📚 Further Reading and References

As this article has mentioned some concepts and best practices, you can explore these resources for more details:

You can also check these open-source libraries for a better understanding of reusability and modularity:

🏁 Conclusion

Reusability is one of the strongest architectural foundations for scalable Angular applications. By combining standalone components, signals, encapsulated logic, and shared libraries, you can create a modular system that grows gracefully over time.

The goal is not just to make components reusable. It is to make them meaningful, maintainable, and consistent across your app. Build only what truly adds value, reuse intentionally, and let Angular's evolving ecosystem handle the rest.

Supercharge Your Angular App: A Developer's Guide to Unlock Peak Performance

sumeyye the developer — Wed, 22 Oct 2025 07:45:36 +0000

Angular has consistently introduced new features to boost application performance, from lazy-loaded components to reactive change detection with signals. This article explores key optimization techniques, including lazy loading, on-demand element loading, signals-based state management, code splitting and tree shaking, and advanced change detection strategies. By understanding and implementing these practices, developers can significantly improve initial load time of the applicarion and overall responsiveness.

1. Lazy Loading Approach

As the name implies, lazy loading provides the elements only when they are needed, differentiating it from eager loading. By enabling this feature for routes or modules, the bundle size gets smaller and the loading time decreases.

🧘🏼‍♀️ Lazy Loaded Components

The first way to integrate lazy loading into your application is to load components this way. First, you can create a component using this command ng g component book, and it will look like a regular standalone component:

import { Component } from '@angular/core';

@Component({
  selector: 'app-book',
  imports: [],
  templateUrl: './book.html',
  styleUrl: './book.scss'
})
export class Book { }

Then, you can declare a routing for the component and use loadComponent instead of component to load it lazily.

//app.routes.ts
import { Routes } from '@angular/router';
export const APP_ROUTES: Routes = [
  {
    path: 'book',
    loadComponent: () => import('./book/book').then(c => c.Book),
  },
];

Once you navigate to the books route, the component will be loaded. Lazy loading a component is a key technique for reducing the initial bundle size of your application. Instead of including code of the component in the main bundle that is downloaded when a user first visits your site, Angular creates a separate, small bundle for the Book component. This bundle is only downloaded and parsed by the browser when the user actually navigates to the /book route. This approach results in a faster initial load time and a more responsive user experience, as the browser does not have to process a large amount of unnecessary code upfront. The import() syntax is a dynamic import, which tells a module bundler like Webpack or Vite to create a separate chunk for the imported file, enabling this lazy-loading behavior.

🚲 Lazy Loaded Modules

If you still continue using the module-based structure, you can load the modules lazily as well. However, this approach will be marked as deprecated in the future. For this reason, we recommend a migration where you can follow related steps.

First, you need to create a module using such command ng g module book. Then, you can create a component and connect to this module using this command ng g component book --module book. The final result will be like this:

//book.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BookComponent } from './book.component';

@NgModule({
  declarations: [],
  imports: [
    CommonModule,
    BookComponent
  ]
})
export class BookModule { }

//book.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'app-book',
  imports: [],
  templateUrl: './book.component.html',
  styleUrl: './book.component.scss'
})
export class BookComponent {}

Then, you can declare a routing for the module and use loadChildren instead of component to load it lazily.

//app-routing.module.ts
import { NgModule } from '@angular/core';
import { RouterModule, Routes } from '@angular/router';
const routes: Routes = [
  {
    path: 'book',
    loadChildren: () => import('./book/book.module').then(m => m.BookModule),
  },
];
@NgModule({
  imports: [RouterModule.forRoot(routes, {})],
  exports: [RouterModule],
})
export class AppRoutingModule {}

2. Code Splitting and Tree Shaking

Code splitting and tree shaking are two powerful techniques that work hand-in-hand to ensure your users download and execute only the JavaScript they truly need.

📘 Code Splitting

Code splitting is the process of breaking a large JavaScript bundle into smaller, more manageable chunks. Instead of sending one massive file to the browser at load time, Angular delivers only what is necessary at the moment.

Loading components or modules lazily, using deferrable views and signals are examples of code splitting.

📈 The benefits are:

Faster initial load time (reduced bundle size).
More efficient use of network bandwidth.
Scales better as applications grow in features.

📘 Tree Shaking

Tree shaking is a form of dead code elimination. It analyzes your imports, detects which parts of a library or file are unused, and removes them from the final build. The metaphor comes from shaking a tree: the dead leaves fall off, leaving only what’s alive (used code).

import { usefulFunction } from './helpers';
import { unusedFunction } from './helpers';

usefulFunction();

Here, unusedFunction is never called. With tree shaking, the Angular compiler ensures that this unused code won’t appear in the final production bundle.

📈 The benefits are:

Reduced JavaScript size.
Less parsing and execution time for the browser.
Lower memory usage.

Code Splitting decides when to load code, while Tree Shaking decides what code gets included in the first place. Together, they ensure the Angular app is both lean and efficient.

3. Loading Elements on Demand using `@defer` block

The aim of using this view kind is also to reduce the initial bundle size of the application. Angular documentation claims that the initial load becomes faster, and it enhances the Core Web Vitals (CVW), especially for Largest Contentful Paint (LCP) and Time to First Byte (TTFB).

In order to use this block, your component needs to be standalone, and you cannot re-use the component outside of the deferring block. Here is how you can use it in your template:

@defer {
  <large-component />
}

You can also propose loading, error, and placeholder states out of the box.

@defer {
  <large-component />
} @loading {
  <img alt="loading..." src="loading.gif" />
} @placeholder {
  <p>Placeholder content</p>
} @error {
  <p>Failed to load large component.</p>
}

The framework also provides content loading based on triggers. These are on and when. Basically, the on property option relies on the user interaction, and the when property relies on the specified condition.

4. Using Signals for State Management

Angular introduced signals as part of its reactivity model to make state management and change detection more precise and performant compared to the traditional Zone.js-based approach. Signals shift Angular from a 'check everything on every event' model to a 'react only to what changed' model. This makes applications more efficient, faster, and often simpler to reason about. Here are the benefits of signals in terms of performance optimization:

✅ Reduces unnecessary work and makes faster UI updates.

Traditionally, Angular relies on zone-based change detection, which means that any asynchronous event (e.g., click, HTTP request, timer) triggers a full change detection cycle across the entire component tree. Since Angular knows exactly which component property depends on which reactive value, this allows Angular to update only the affected components/elements when the signal changes, instead of re-checking everything.

✅ Dependencies are tracked explicitly.

A signal records its dependencies at runtime. When a computed signal or template expression reads a signal, Angular automatically tracks that dependency. If the value changes, only consumers of that signal re-run. So, the unrelated computations are prevented, and the performance is optimized.

✅ The updates are synchronous and predictable.

When you set a new value in a signal, all dependent computations and template updates happen immediately and predictably. So, it is easy to debug and determine the performance in that sense.

5. Change Detection

Angular uses a change detection mechanism to keep the view in sync with the component state. By default, Angular uses the default change detection strategy for every component.

Default Strategy Mechanism

When an event happens (like a user input, HTTP response, setTimeout, etc.), Angular runs change detection. It starts from the root component and traverses every component in the tree to check if any bound data has changed. Angular compares the current property values with the previous ones for each component. As can be perceived, if something changed, Angular updates the DOM. Even if a change occurs in one component, Angular will still go through all components down the tree unless properly optimized.

The good side is that it keeps the UI of the application constant with the state no matter where the change is coming from. However, it becomes a bottleneck for large applications as all components are going to be checked.

Optimizing the Default Strategy

Even with the Default strategy, you can improve performance by:

Breaking up elements into smaller, reusable ones, so Angular checks smaller trees.
Using track in @for blocks to prevent re-rendering on unchanged list items.
Not adding heavy computations on templates or making them into smaller ones in services.

The other change detection strategy is OnPush. This will allow you to make checks when needed. By this means, Angular would check only if:

an input reference is changed
an event is triggered
or you trigger it manually by using markForCheck utility

Manual Change Detection Triggers

Angular provides these controls by ChangeDetectorRef class injection.

markForCheck()

This marks the component along its ancestors as dirty. The component will be checked in the next change detection cycle. In this example case, a component uses the OnPush strategy, and something is updated directly (e.g. a service emits a new value without changing the input() reference).

private cdr = inject(ChangeDetectorRef);

updateData() {
  this.data.someProp = 'newValue';
  this.cdr.markForCheck();  // schedule re-check
}

detectChanges()

Immediately runs change detection synchronously on the component and its children. In this example, the DOM is reflected by the change immediately that could be after a dialog closing, or measuring the size of the element.

private cdr = inject(ChangeDetectorRef);

updateData() {
  this.data.someProp = 'newValue';
  this.cdr.detectChanges();  // run CD immediately
}

In short:

Use markForCheck() when performance is the key and you want to stay within the normal change detection cycle of Angular.
Use detectChanges() when you absolutely need the update immediately after the change occurs.

Conclusion

By implementing these strategies, developers can build Angular applications that are not only feature-rich but also fast and efficient. Lazy loading, code splitting, and tree shaking work together to reduce initial load times, while signals and optimized change detection ensure the application remains responsive and performant as it grows in complexity. Embracing these modern Angular features is crucial for delivering a high-quality user experience and maintaining a scalable codebase.

DEV Community: sumeyye the developer

Angular Library Linking Made Easy: Paths, Workspaces, and Symlinks

Understanding TypeScript Path Mapping

Step-by-Step Examples of Path Configuration

How Path References Worked Before the New Angular Application Builder

Best Practices and Recommendations

Building Scalable Angular Apps with Reusable UI Components

🧩 Breaking Down Components for True Reusability

🚀 Why Standalone Components Matter

🧠 Designing Components That Scale and Reuse Well

🔁 Reusing Components Across the Application

⚙️ Best Practices and Common Pitfalls

✅ Best Practices

⚠️ Common Mistakes

📚 Further Reading and References

🏁 Conclusion

Supercharge Your Angular App: A Developer's Guide to Unlock Peak Performance

1. Lazy Loading Approach

🧘🏼‍♀️ Lazy Loaded Components

🚲 Lazy Loaded Modules

2. Code Splitting and Tree Shaking

📘 Code Splitting

📈 The benefits are:

📘 Tree Shaking

📈 The benefits are:

3. Loading Elements on Demand using @defer block

4. Using Signals for State Management

✅ Reduces unnecessary work and makes faster UI updates.

✅ Dependencies are tracked explicitly.

✅ The updates are synchronous and predictable.

5. Change Detection

Default Strategy Mechanism

Optimizing the Default Strategy

Manual Change Detection Triggers

Conclusion

3. Loading Elements on Demand using `@defer` block