Angular Do's and Don'ts

Why a Do's and Don'ts List Helps

Best practices explain the reasoning behind a recommendation; a do's and don'ts list gives you a fast, scannable answer when you just need to make a quick decision and move on, especially useful during code review or when onboarding new team members.

Each pairing below reflects a decision covered in more depth elsewhere in this course, use this lesson as a quick lookup, and the linked topic lessons for the full reasoning.

// Don't: mutate state bound to an OnPush component
this.user.name = 'New Name';

// Do: create a new reference
this.user = { ...this.user, name: 'New Name' };

This single pairing prevents one of the most common "my OnPush component won't update" bugs.

How to Use This Reference

Do:   the recommended approach for a common situation
Don't: the tempting but problematic alternative to avoid

• Each row pairs a common situation with a clear recommendation.
• These are defaults, not absolute rules, real situations occasionally justify an exception.
• When in doubt, prefer the "Do" column unless you have a specific, well-understood reason not to.
• Refer back to the dedicated lesson on a topic for the full reasoning behind each recommendation.

Angular Do's and Don'ts Cheatsheet

Quick, scannable guidance across common Angular decisions.

State and Reactivity

Signals and services cover the vast majority of state needs; RxJS and NgRx are powerful but easy to reach for prematurely.

• Do keep component state local unless multiple components genuinely need to share it.
• Do use computed() for derived values instead of manually recalculating and storing them.
• Don't introduce NgRx before a feature's state complexity actually justifies the added structure.
• Don't expose a writable signal/Subject publicly, expose a readonly view instead.

HTTP and RxJS

Most HTTP-related bugs come from missing cleanup, the wrong flattening operator, or unhandled errors.

• Do wrap HttpClient calls in a dedicated service rather than calling it from components directly.
• Do choose switchMap for searches/lookups and exhaustMap to guard against duplicate submissions.
• Don't retry non-idempotent requests (like payments) automatically without careful thought.
• Don't nest .subscribe() calls, compose with operators like switchMap/forkJoin instead.

Performance

Small, consistent habits usually matter more than occasional large optimizations.

• Do lazy-load feature routes that aren't needed on initial load.
• Do profile with Angular DevTools before optimizing based on assumptions.
• Don't call expensive methods directly in template interpolation; use computed() or a pure pipe.
• Don't render very large lists without virtual scrolling.

Common Mistakes

• Treating this list as absolute rules rather than defaults that occasionally have legitimate exceptions.
• Applying a "don't" pattern out of habit without understanding why it's usually discouraged.
• Skipping the deeper topic lesson entirely and only relying on the short do/don't summary for unfamiliar concepts.
• Inconsistently applying these defaults across a team, reintroducing the exact confusion this list is meant to prevent.

Key Takeaways

• A do's and don'ts list is a fast, scannable reference for common Angular decisions.
• Most pairings map directly to a deeper topic covered elsewhere in this course.
• These are strong defaults, not absolute rules; use judgment for genuine exceptions.
• Consistent team-wide application of these defaults matters more than any single decision.