DEV Community: Placide

Micro-Frontends with Angular: Is It Worth the Complexity?

Placide — Sun, 19 Apr 2026 14:19:41 +0000

Introduction

Micro-frontends have gone from a niche architectural pattern to a buzzword every senior frontend developer is expected to have an opinion on. And if you're building with Angular, you've probably wondered: should we go micro-frontend? Is it worth it? Where do we even start?
This article gives you an honest, practical answer — including when to use them, when to run away, and how to implement them in Angular when the time is right.

What Are Micro-Frontends?
Micro-frontends apply the principles of microservices to the frontend. Instead of one large Angular application, you split your UI into smaller, independently developed, deployed, and owned applications — each responsible for a specific business domain.

Each micro-frontend (MFE) is:

Developed independently by a dedicated team
Deployed on its own schedule
Loaded dynamically into a shell application at runtime

The Case For Micro-Frontends

Independent deployment: The biggest win. Team A can ship a fix to the Auth module without waiting for Team B to finish their Dashboard feature. No more deployment coordination nightmares.
Team autonomy: Each team owns their slice of the product end-to-end — from backend to frontend. This aligns perfectly with Conway's Law and reduces cross-team dependencies.
Incremental migration: If you're sitting on a legacy AngularJS or React app, micro-frontends let you migrate piece by piece to modern Angular — without a risky big-bang rewrite.
Independent scaling of teams :Onboarding a new team? Give them a bounded micro-frontend to own. They can work without needing to understand the entire codebase.

The Real Costs Nobody Talks About

Before you get excited, here's what production experience teaches you:
Shared state is painful :Micro-frontends are isolated by design. Sharing state between them — like the current user, a shopping cart, or global notifications — requires deliberate solutions: a shared event bus, a state management library exposed via the shell, or browser storage. None of these are elegant.
CSS bleeds if you're not careful: Without proper isolation (Shadow DOM, CSS Modules, or strict naming conventions), styles from one MFE can leak into another. This is a subtle but very real production problem.
Bundle size can explode: If each MFE bundles its own copy of Angular, RxJS, and other shared libraries, your users download the same code multiple times. Module Federation's shared dependencies solve this — but require careful configuration.
Debugging across boundaries is harder: Stack traces, error monitoring, and performance profiling become more complex when errors span multiple independently deployed applications.
Operational overhead: Instead of one CI/CD pipeline, you now have many. Instead of one deployment, you have many. This overhead is worth it at scale — but punishing for small teams.

How to Implement Micro-Frontends in Angular

The most mature approach today is Module Federation, available through two options:

Option 1: Webpack Module Federation**

Angular CLI supports Module Federation via @angular-architects/module-federation:

ng add @angular-architects/module-federation --project shell --port 4200 --type host
ng add @angular-architects/module-federation --project dashboard-mfe --port 4201 --type remote

Configure the remote in webpack.config.js:

// dashboard-mfe/webpack.config.js
module.exports = withModuleFederationPlugin({
  name: 'dashboardMfe',
  exposes: {
    './Module': './src/app/dashboard/dashboard.module.ts',
  },
  shared: share({
    '@angular/core': { singleton: true, strictVersion: true },
    '@angular/router': { singleton: true, strictVersion: true },
  })
});

Load it in the shell:

// shell/app.routes.ts
export const routes: Routes = [
  {
    path: 'dashboard',
    loadChildren: () =>
      loadRemoteModule({
        type: 'module',
        remoteEntry: 'http://localhost:4201/remoteEntry.js',
        exposedModule: './Module'
      }).then(m => m.DashboardModule)
  }
];

Option 2: Native Federation**

A newer, Vite-compatible alternative from the same team:

ng add @angular-architects/native-federation --project shell --port 4200 --type host
ng add @angular-architects/native-federation --project dashboard-mfe --port 4201 --type remote

Native Federation works with Angular's modern ESBuild pipeline and is the recommended path for new projects in 2026.

Sharing State Between Micro-Frontends

The most common challenge. Here are the three patterns ranked by simplicity:

1. Custom Events (simplest)

// Emitting from MFE
window.dispatchEvent(new CustomEvent('user:updated', { detail: { userId: 123 } }));

// Listening in shell or another MFE
window.addEventListener('user:updated', (e: CustomEvent) => {
  console.log(e.detail.userId);
});

2. Shared Service via Shell

Expose a singleton service from the shell and inject it into MFEs via a shared library.

3. External State Store

Use a lightweight external store (like a shared RxJS BehaviorSubject in a shared library) that all MFEs import as a singleton via Module Federation's shared config.

When Should You Actually Use Micro-Frontends?
Use them when:

You have 3+ teams working on the same frontend product
Different parts of your app need truly independent release cycles
You are migrating a legacy app and need to run old and new code side by side
Your Angular monorepo has become genuinely unmanageable

Skip them when:

You have one team — use Nx or Angular libraries instead
You want better code organization — NgModules or standalone component architecture solves this
You're building an MVP or early-stage product — the overhead will slow you down
Your team is new to Angular — master the fundamentals first

Alternatives Worth Considering

Before going micro-frontend, make sure you've explored:
Nx Monorepo with Angular Libraries:Nx gives you independent libraries, enforced boundaries, and separate build caching — solving most team-scale problems without the runtime complexity of micro-frontends.
Standalone Components + Lazy Loading:Angular's standalone components with granular lazy loading give you excellent code splitting and team separation without a micro-frontend architecture.
These cover 80% of the use cases teams think they need micro-frontends for.

Conclusion

Micro-frontends with Angular are a genuinely powerful pattern — but they come with real costs that are easy to underestimate. The technology is mature enough to use in production today, especially with Module Federation or Native Federation.
But the honest truth is: most teams don't need them yet.
Start with a well-structured Angular monorepo, enforce boundaries with Nx, and adopt lazy loading aggressively. When your team structure and deployment needs genuinely outgrow that — micro-frontends will be waiting for you.

Have you shipped micro-frontends with Angular in production? What was your biggest challenge? Drop it in the comments!

Angular State Management in 2026: NgRx vs Signals vs Services — A Practical Comparison

Placide — Sun, 15 Mar 2026 12:49:32 +0000

Every Angular developer faces it eventually: your app grows, components need to share state, and suddenly you're asking — how should I manage this?
In 2026, you have three solid options: plain Services, Angular Signals, and NgRx. Each has a sweet spot. This article breaks them down with real examples so you can make the right call for your project.

Option 1 — Services (The Classic Approach)

Services with BehaviorSubject have been the go-to solution for years, and for good reason — they're simple, well-understood, and require zero extra dependencies.

@Injectable({ providedIn: 'root' })
export class CartService {
  private _items = new BehaviorSubject<Item[]>([]);
  items$ = this._items.asObservable();

  addItem(item: Item) {
    this._items.next([...this._items.value, item]);
  }
}

They are best for:

Small to medium apps
Teams already comfortable with RxJS
State that lives in one or two places

But be carefull because:

No dev tools or traceability
Can get messy as the app scales
Easy to create inconsistencies across multiple services

Option 2 — Signals (The Modern Default)

Introduced in Angular 16 and now fully stable, Signals are Angular's built-in reactivity primitive. They eliminate most RxJS boilerplate for UI state and integrate natively with the template engine.

@Injectable({ providedIn: 'root' })
export class CartService {
  private _items = signal<Item[]>([]);
  items = this._items.asReadonly();
  total = computed(() => this._items().reduce((sum, i) => sum + i.price, 0));

  addItem(item: Item) {
    this._items.update(current => [...current, item]);
  }
}

Your template reacts automatically — no async pipe, no manual subscription:

@for (item of cartService.items(); track item.id) {
  <p>{{ item.name }} — {{ item.price }}</p>
}
<strong>Total: {{ cartService.total() }}</strong>

They are best for:

New Angular projects (17+)
Local and shared UI state
Teams wanting to reduce RxJS complexity

But be carefull because:

Not ideal for complex async flows (RxJS still wins there)
Relatively new — fewer patterns established in large codebases

Option 3 — NgRx (The Enterprise Powerhouse)

NgRx implements the Redux pattern in Angular. Actions, reducers, selectors, effects — everything is explicit, traceable, and testable.

// Action
export const addItem = createAction('[Cart] Add Item', props<{ item: Item }>());

// Reducer
export const cartReducer = createReducer(
  initialState,
  on(addItem, (state, { item }) => ({
    ...state,
    items: [...state.items, item]
  }))
);

// Selector
export const selectCartItems = createSelector(
  selectCartState,
  state => state.items
);

// In component
items$ = this.store.select(selectCartItems);

Best for:

Large enterprise apps
Big teams needing shared conventions
Complex async flows and side effects
When you need full state history & debugging via Redux DevTools

Be carefull about:

Significant boilerplate (NgRx Signals Store reduces this)
Steep learning curve for newcomers
Overkill for small/medium apps

Side-by-Side Comparison

	Services	Signals	NgRx
Boilerplate	Low	Very Low	High
Learning Curve	Low	Low	High
Scalability	Medium	Medium-High	Very High
Dev Tools	Nope	Nope	Yes
Async Handling	RxJS	Limited	Effects
Best App Size	Small	Small–Medium	Large

My Decision Framework

Is your app small or a prototype?

Services or Signals

Is your team new to Angular?

Signals (less to learn)

Do you have complex async flows (websockets, polling, chained HTTP)?

NgRx Effects or RxJS in a Service

Is your team large with multiple feature modules?

NgRx (with NgRx Signals Store to reduce boilerplate)

Can You Mix Them?
Absolutely — and many real-world apps do. A common pattern is:

Signals for local UI state (form state, toggles, UI flags)
Services for simple shared state
NgRx only for the most complex global state (auth, cart, notifications)

Don't feel pressured to pick one and apply it everywhere.

There's no single winner in Angular state management — the right tool depends on your app's complexity, your team's experience, and how much structure you need.
My personal default in 2026: start with Signals, reach for NgRx only when the complexity demands it.

This Trick That Made Me Understand signal() and computed() in Angular

Placide — Sun, 18 Jan 2026 10:12:24 +0000

When Angular introduced Signals, I was excited…
but also confused.

kept asking myself:

How is this different from Observables?
When should I use signal()?
Why do we need computed()?
Is this just another reactive API?

Then one simple trick changed everything for me:

Stop thinking in streams. Start thinking in state.

The Mental Model Shift

Here’s the trick:

signal() = State
computed() = Derived State
That’s it.

Nothing more complicated.

Example:

ts count = signal(0);
doubleCount = computed(() => this.count() * 2);

How to think about it:

count = the source of truth
doubleCount = a calculation based on the truth

Just like real life:

You store raw data
You derive insights from that data

Why This Made Everything Clear

signal()

Holds state
Can be read
Can be updated
Triggers updates automatically

this.count.set(1);
this.count.update(v => v + 1);

It’s your single source of truth.

computed()

Never stores state
Only derives state
Recalculates automatically
Always stays in sync

doubleCount = computed(() => this.count() * 2);

You never update computed() manually.
It updates itself.
The Big Realization

Before, I was thinking:

subscriptions
streams
emissions
operators
pipes

Now I think:

state
dependencies
derivations
reactivity graph
automatic updates

Signals are not trying to replace Observables.
They are solving a different problem:

Simple, synchronous, local state management inside components.

How This Changed My Angular Design

Now I design components like this:

Signals → store state
Computed → derive state
Effects → react to state
Observables → async flows / APIs / streams

This separation makes my apps:

more predictable
easier to debug
easier to test
easier to scale
easier to reason about

Understanding Signals is not about learning new syntax.

It’s about learning a new way to think:

Data - State - Derivation - Reaction

Once you get that mental model,
signal() and computed() become natural.

And Angular suddenly feels… simpler

Angular Signals vs Observables — What I Really Learned

Placide — Sat, 10 Jan 2026 07:17:35 +0000

When Angular introduced Signals, the community reaction was immediate.

Some were excited.
Some were confused.
Some assumed RxJS was on its way out.

After using both in real Angular applications, I realized something important:

Signals don’t replace Observables — they clarify how we should think about state and reactivity.

This article isn’t about syntax.
It’s about the mental shift Angular Signals introduced.

Understanding the Core Difference

At a high level:

Signals are about state
Observables are about streams over time

Once I understood this, many design decisions became clearer.

What Signals Really Changed for Me

Signals shine when dealing with:

local component state
derived values
template-driven reactivity

They are:

synchronous
explicit
easy to trace

When a signal changes, Angular knows exactly what to update.

This made my components:

smaller
easier to reason about
less dependent on RxJS operators

Signals encouraged me to keep UI state simple and intentional.

Why Observables Are Still Essential

Observables remain the right tool for:

HTTP requests
user events
WebSockets
async workflows

They model time, not just values.

Features like:

subscribe
switchMap
retry
debounceTime

are still critical in real-world applications.

Trying to replace Observables with Signals in these scenarios only adds confusion

The Most Important Lesson

The real improvement wasn’t performance.
It was clarity.

Instead of forcing RxJS everywhere, I now ask:

Is this state? ** Signal**
Is this async over time? Observable

That single question improved: readability, maintainability,team communication

How I Use Them Together
In practice, I recommend:

fetch data with Observables
convert results into Signals
let Signals drive the UI

This combination feels natural and balanced.

Angular didn’t remove power.
It redistributed responsibility.

Signals didn’t make Observables obsolete.
They made Angular more honest about intent.

And for me, that’s the real win.

Angular Is Opinionated — Here’s Why That Made Me a Better Developer

Placide — Sun, 28 Dec 2025 08:24:51 +0000

One of the most common criticisms of Angular is that it’s too opinionated.

People say it’s restrictive.
That it tells you how to do things instead of letting you decide.

I used to see that as a weakness.

Today, I see it as one of the main reasons Angular helped me grow—not just as a coder, but as a software engineer.

What Does “Opinionated” Really Mean?

An opinionated framework provides:

strong conventions
strong conventions
recommended patterns

Instead of asking “How should we organize this?”
on every project, Angular already answers many of those questions for you.

At first, this can feel uncomfortable.
But over time, it becomes a powerful learning tool.

Clear Project Structure

Angular encourages a predictable structure:

Components for UI
Services for business logic
Modules and shared folders for organization

This consistency matters.

When you open an Angular project—especially a large one—you immediately know where to look.
New developers onboard faster, and the codebase feels intentional instead of improvised.

Structure reduces cognitive load.
Less guessing = better focus.

Separation of Concerns

Angular strongly pushes you to separate responsibilities:

Components handle presentation and interaction
Services handle logic, data access, and state
Templates focus on rendering

This prevents components from turning into massive, unmaintainable files.

The result : cleaner code, easier testing, safer refactoring
Angular doesn’t force you to do this—but it makes the alternative painful enough that you quickly learn why separation matters.

Consistent Patterns Across the Codebase

Angular promotes consistency through:

Dependency injection
Lifecycle hooks
Input/output communication
Standardized tooling

When everyone follows the same patterns:

Code reviews are faster
Collaboration improves
Bugs become easier to spot

Instead of debating styles and architectures, teams can focus on delivering value.

Consistency is underrated—but it’s a superpower in team environments.

Predictable Architecture at Scale

As applications grow, chaos becomes expensive.

Angular’s opinions lead to:

Predictable data flow
Safer refactoring
Clearer boundaries

This predictability gives you confidence:

to change features
to clean old code
to scale without fear

When you trust the architecture, you move faster—even in complex systems.

What Angular Really Taught Me

Angular didn’t just teach me syntax or APIs.

It taught me:

to respect structure
to think long-term
to value consistency over cleverness
to understand that constraints can be guidance

In the real world, software isn’t written once—it’s maintained, extended, and shared.

Angular prepares you for that reality.

Opinionated frameworks aren’t about limiting developers.
They’re about protecting teams and codebases from chaos.

Angular made me a better developer because it forced me to slow down, think, and build with intention.

Sometimes, the best freedom comes from good constraints.

Let's connect on linkedIn

Why Angular Templates Make You a Better Developer (Not Just a Better Coder)

Placide — Sat, 22 Nov 2025 12:51:29 +0000

When developers talk about Angular, most conversations revolve around architecture, TypeScript, dependency injection, RxJS, signals, or modules.
But there’s one part of Angular that silently shapes the way you think—templates.

Angular templates are not just HTML with extra syntax.
They are a discipline.
A mindset.
A way of expressing logic clearly and intentionally.

Over time, I realized something important:

If you can keep your templates clean, you can keep your entire codebase clean.

Here’s why Angular templates make you a better developer.

1. They Force Clear Separation of Concerns

Angular templates naturally push you to separate:

UI logic
Business logic
State management

Anything heavy must be moved to the component or a service.

For example:

Mixing logic in the template:

{{ products.filter(p => p.inStock && p.price < 20).length }}

Clean separation:

inStockProducts = this.products.filter(p => p.inStock && p.price < 20);

{{ inStockProducts.length }}

Templates reward clarity and punish complexity — a core engineering skill.

2. You Learn to Think in Terms of State

Templates are state-driven.

If your UI breaks, it’s usually because your state is unclear or inconsistent.

Angular pushes you to:

Keep your state predictable
Use inputs and outputs properly
Structure your data so it flows cleanly through the UI

This is the foundation of scalable front-end development — no matter the framework.

3. Directives Teach You to Write Declarative UI

*ngIf, *ngFor, ngClass, ngStyle…
These teach you to express intent instead of implementation.

<div *ngIf="isLoggedIn">Welcome!</div>

You don’t tell Angular how to show the element.
You simply declare:

Show it when this condition is true.

That’s the essence of modern frontend engineering.

4. Pipes Make You Think More Functionally

Pipes encourage transforming data in a clean, reusable way.

{{ price | currency:'USD' }}

Instead of hiding formatting logic deep inside components, Angular hands you a better way:

Focused
Reusable
Testable

It’s functional programming made visible.

5. Clean Templates = Clean Components

If your template becomes messy, it reveals deeper issues:

too much responsibility
unclear state
poor architecture

Angular templates are like a mirror reflecting your thought process.

A clean template means:

your component is focused
your logic is modular
your architecture is solid

In other words…
your development habits are healthy.

Final Thoughts

Angular templates are more than a tool — they are an instructor.
They quietly teach you:

clarity
structure
discipline
predictable thinking

And these are the qualities that make someone not just a coder…
But a software engineer.

If you’re learning Angular, don’t just learn the syntax.
Learn the mindset it encourages.
Because mastering templates means mastering the way you think about UI, state, and architecture.

Want more posts like this?

I also share my technical content on LinkedIn — feel free to connect!

Angular Isn’t Just About Code — It’s About Discipline

Placide — Sun, 09 Nov 2025 07:22:15 +0000

When I started learning Angular, my goal was simple: make things work.
I was obsessed with getting components to render, data to flow, and routes to connect.

But as I grew more comfortable, I started to notice something subtle — Angular wasn’t just teaching me to code better. It was teaching me to think better.

Architecture Forces You to Think in Systems

In Angular, nothing stands alone.
Every service, module, and component fits into a larger ecosystem. You quickly learn that architecture matters — that the way you structure your code impacts how easily it scales, how readable it is for others, and how fast you can add new features later.

This mindset shift helped me stop writing “quick fixes” and start designing for the future.

Dependency Injection Teaches You Separation of Concerns

Angular’s dependency injection system might seem complex at first — but it’s actually a lesson in clean design.

It forces you to think:

Should this logic really live here?

By keeping your components lean and delegating responsibilities to services, you start building modular, testable, and maintainable codebases — the kind of projects teams love to work in.

Lifecycle Hooks Teach You Awareness

ngOnInit, ngOnDestroy, ngAfterViewInit — they’re not just methods, they’re reminders of how your app behaves over time.

Angular helps you become aware of what happens before, during, and after your components exist.
That level of awareness translates into writing more predictable, controlled code.

Strong Typing and Templates Encourage Discipline

Combine Angular with TypeScript, and suddenly, “anything goes” doesn’t work anymore.
You have to define, type, and think before you act.

This structure prevents chaos. It teaches patience. It rewards consistency.
And that’s what discipline is all about.

The Real Lesson

Angular isn’t just a front-end framework.
It’s a framework that cultivates professional habits.

It teaches:

How to respect structure
How to think in patterns
How to communicate through code

The same habits that make a good Angular developer often make a good software engineer in general.

If you’re learning Angular today, don’t just focus on syntax.
Focus on how it trains your mind — to write cleaner, think clearer, and build smarter.

Because at the end of the day,** Angular** isn’t just about code — it’s about discipline.

You can find me sharing more Angular lessons and experiences here and on my LinkedIn

Angular #WebDevelopment #SoftwareEngineering #TypeScript #CleanCode #DeveloperMindset

What Working with People from Different Backgrounds Taught Me as a #Developer

Placide — Sun, 26 Oct 2025 13:01:03 +0000

When we talk about being a developer, we often focus on frameworks, programming languages, and new tools.
But one of the most valuable experiences I’ve had in my journey hasn’t come from code — it came from people.

Working with teammates from different countries, cultures, and backgrounds has changed the way I think, build, and collaborate.

1. Different Backgrounds Mean Different Perspectives

When you work in an international or multicultural team, you quickly realize there isn’t just one right way to solve a problem.
People think differently because their education systems, work cultures, and life experiences shape how they approach challenges.

And that’s where innovation starts.

Sometimes, a teammate from another country proposes a solution I never would’ve imagined — not because it’s technically better, but because they see the problem differently.

It taught me to stay open-minded and listen before speaking.

2. Communication Is a Skill, Not an Assumption

When you work with people who don’t share your first language, you quickly learn the importance of clarity.
You start thinking about how to explain your ideas in simple, clear ways.

I realized that being a good communicator is not about speaking a lot — it’s about making sure others truly understand what you mean.

This skill has made me a better teammate and even improved how I write documentation and commit messages.

3. Empathy Builds Stronger Teams

In multicultural environments, empathy becomes essential.
Not everyone has the same comfort zone, sense of humor, or approach to teamwork.

By taking time to understand why someone acts or communicates a certain way, you build trust — and trust makes collaboration smoother than any project management tool ever could.

4. Tech Is Global — and So Are We

Whether you work in Angular, React, or Node.js, technology connects us beyond borders.
Our code might live in GitHub repos, but our ideas come from everywhere.

That’s why cultural diversity isn’t just “nice to have” — it’s a competitive advantage.

Working with people from different countries has taught me that diversity is not a challenge — it’s a strength.
Every time we share our unique perspectives, we grow — not only as developers, but as humans.

The best code doesn’t just come from one mind.
It comes from many** minds thinking together**.

I’m sharing more about my journey as a developer — from technical lessons in Angular to reflections on teamwork and growth.
You can also find me on LinkedIn where I share regular posts about development and personal growth in tech.

Mastering Angular Lifecycle Hooks — The Hidden Superpowers

Placide — Wed, 22 Oct 2025 09:53:28 +0000

Hey everyone. I’m Placide (@rigole), a full-stack developer passionate about Angular, TypeScript, Java And Python(Yeah that could be a lot but with passion you do not count).

When I first started using Angular, I thought lifecycle hooks were just “fancy methods” that Angular called automatically. But as I got experiences and grew more comfortable with the framework, I realized they’re actually the heartbeat of every Angular component. Understanding them can help you control how your app behaves from creation to destruction — and make your code much cleaner and more predictable.
Let’s dive in. Shall we ?

What Are Lifecycle Hooks ?

In Angular, lifecycle hooks are special methods that allow you to tap into key moments of a component’s life — from the moment it’s created, to when it’s updated, to when it’s destroyed.
Each hook represents a specific stage of the component’s “lifecycle.”

Here’s the full sequence:

ngOnChanges → ngOnInit → ngDoCheck → ngAfterContentInit → ngAfterContentChecked → ngAfterViewInit → ngAfterViewChecked → ngOnDestroy
It seems a lot but don’t worry — you don’t need all of them.
Let’s look at the ones you’ll use most often:

ngOnInit() — Initialization Magic

This is one of the most commonly used hooks.
It runs once, right after Angular initializes all data-bound properties.

export class ProductListComponent implements OnInit {
  products: Product[] = [];

  ngOnInit() {
    this.loadProducts();
  }

  private loadProducts() {
    this.products= [{ name: 'watches' }, { name: 'phones' }];
  }
}

Pro tip: Keep your initialization logic here — not in the constructor because the constructor should only handle dependency injection, not side effects.

ngOnChanges() — Reacting to Input Changes

Whenever a parent component updates an @Input() -A post about it is coming.We are going to talk about reusable component- value, Angular triggers ngOnChanges()


export class ProductDetailsComponent implements OnChanges {
  @Input() productName!: string;

  ngOnChanges(changes: SimpleChanges) {
    if (changes['productName']) {
      console.log('Product Name changed:', changes['productName'].currentValue);
    }
  }
}

Pro tip: Perfect for components that depend on dynamic input data (e.g., updating details when a user is selected).

ngOnDestroy() — The Cleanup Hero

This hook runs right before the component is destroyed.
It’s the best place to clean up anything that could cause memory leaks, like subscriptions or timers.


export class ChatComponent implements OnDestroy {
  private subscription!: Subscription;

  ngOnInit() {
    this.subscription = this.chatService.listen().subscribe();
  }

  ngOnDestroy() {
    this.subscription.unsubscribe();
    console.log('Chat component destroyed');
  }
}

Pro tip: Always clean up your observables and DOM listeners here.
You’ll thank yourself later.

ngAfterViewInit() — The View Is Ready

This hook is called after Angular initializes the component’s view and child views.
Use it for working with @ViewChild()-Articles is coming too- references or DOM elements.

export class DashboardComponent implements AfterViewInit {
  @ViewChild('chart') chart!: ElementRef;

  ngAfterViewInit() {
    this.chart.nativeElement.focus();
  }
}

Pro tip: If you try to access @ViewChild() before this hook, it’ll be undefined so be carefull

Why Lifecycle Hooks Matter

Lifecycle hooks are more than just Angular internals — they’re tools that help you:

Improve component reusability and testing
Understand how Angular manages your app’s state
Write cleaner, more predictable code
Avoid memory leaks

Understanding Angular’s lifecycle hooks is like learning how the engine of your car works.
You don’t need to be an expert mechanic, but knowing when to accelerate, pause, and stop makes you a better driver — and a better Angular developer.

If you found this useful, I share more tips like this on my LinkedIn — feel free to connect with me there! Here is the link

What’s your favorite lifecycle hook, and how has it helped you write cleaner Angular code?
Drop it in the comments — I’d love to learn from your experience too.

Angular #TypeScript #WebDevelopment #Frontend #DevelopersJourney #CodingTips