DEV Community: Jack Pritom Soren

RAG Explained: How to Give Your LLM a Memory It Can Actually Trust

Jack Pritom Soren — Sat, 25 Jul 2026 13:12:35 +0000

You're building a chatbot for a company's internal documentation — hundreds of pages of engineering specs, HR policies, product guides. You plug in ChatGPT, write a clean system prompt,launch a demo. Someone asks "What's the reimbursement limit for travel expenses?" and the model confidently answers with a number. The number is wrong. It's not from your docs — it's from the model's general training data, some pattern absorbed from the internet years ago that roughly sounds like a reasonable reimbursement policy.

This is the fundamental problem with raw LLMs in production: they don't know your data. They know what was in their training set — a snapshot of text from months or years ago, with no awareness of your internal docs, your product specs, your latest pricing, your customer records, or anything else that lives inside your organization. And when they don't know something, they don't say "I don't know" — they say something plausible-sounding that might be completely fabricated.

The fix has a name: Retrieval-Augmented Generation, almost universally abbreviated as RAG. The idea is elegant: before asking the model to answer a question, find the relevant pieces of your actual data and hand them to the model as context. Now, instead of guessing, the model is summarizing and reasoning over the real information you provided.

The gap between "RAG sounds simple" and "RAG actually works reliably in production" is where most teams spend weeks of engineering time. Understanding the full pipeline — every
stage, every design decision, every place it quietly breaks — is what this article is about.

What We'll Cover

The RAG Mental Model — Why It Works at All
The Full RAG Development Pipeline (Both Phases)
Document Loaders — Getting Your Data In
Text Splitting and Chunking — The Stage Everyone Underestimates
Embeddings and Vector Stores — Where Your Data Lives at Query Time
Retrievers — Finding the Right Chunks When It Matters
Putting It All Together — A Working RAG Chain
Where RAG Breaks and How to Diagnose It

Chapter 1: The RAG Mental Model — Why It Works at All

Before code, you need the right mental model, because RAG is counterintuitive until it clicks.

Think about how you answer questions as a consultant. If someone asks you a question about a client's contract terms, you don't try to recall everything from memory — you pull up the contract, skim for the relevant section and answer based on what's in front of you. You're not generating from memory; you're reading and summarizing from a source.

RAG turns an LLM into that consultant. You build a system that:

Ingests your documents (PDFs, web pages, databases, whatever) and stores them in a searchable format.
When a user asks a question, retrieves the most relevant pieces of those documents.
Augments the model's prompt with those retrieved pieces.
Lets the model generate an answer based on the context you just handed it. The LLM's role shifts from "know everything" to "read what I gave you and reason over it." That's a job LLMs are genuinely very good at.

Without RAG:
User question  →  LLM (guesses from training data)  →  Response (possibly hallucinated)

With RAG:
User question  →  Retrieve relevant docs  →  LLM (reads your actual docs)  →  Grounded response

This is why RAG is the dominant pattern for enterprise AI applications. It doesn't eliminate the LLM's tendency to hallucinate — but it gives the model true ground to stand on,and makes it much easier to audit: if the answer is wrong, you can trace it back to exactly which chunk was retrieved and why.

The full pipeline has two distinct phases that most beginners conflate into one. Let's separate them.

Chapter 2: The Full RAG Development Pipeline — Two Phases

Almost every RAG confusion I've seen in teams comes from mixing up what happens before a user ever sends a message versus what happens when they do. These are two fundamentally different processes with different triggers, different costs, and different failure modes.

Phase 1 — Indexing (Offline, Runs Once)

This is the preparation phase. You run it ahead of time — sometimes once, sometimes on a schedule, sometimes triggered by new document uploads. It does not happen in response to user queries.

[ Your Raw Documents ]
        │
        ▼
[ Document Loader ]      ← Pull documents in from wherever they live
        │
        ▼
[ Text Splitter ]        ← Break documents into manageable chunks
        │
        ▼
[ Embedding Model ]      ← Convert each chunk into a numeric vector
        │
        ▼
[ Vector Store ]         ← Store vectors + original text in a searchable database

The result: a vector store that contains your entire knowledge base in a format where "find me content similar to this question" is a fast, cheap operation.

Phase 2 — Retrieval + Generation (Online, Runs Per Query)

This is the live path. It runs every time a user sends a message.

[ User Question ]
        │
        ▼
[ Embedding Model ]      ← Convert the question into a vector
        │
        ▼
[ Vector Store Retriever ]  ← Find the chunks most similar to the question
        │
        ▼
[ Prompt Template ]      ← Inject retrieved chunks + question into a prompt
        │
        ▼
[ LLM ]                  ← Generates answer grounded in the retrieved context
        │
        ▼
[ Response to User ]

These two phases have completely different performance characteristics. Indexing is slow and expensive per document but runs offline. Retrieval + generation must be fast — it's the live user experience. Every design decision in RAG falls into one of these two phases. Keep this separation in mind as we go through each component.

Chapter 3: Document Loaders — Getting Your Data In

The first problem in any real RAG system is always the same: your data doesn't live in a clean text file. It lives in PDFs, Word documents, Notion pages, Confluence wikis,Google Drive folders, databases, Slack threads, web pages, and half a dozen other formats
— each requiring different handling to extract usable text.

Document loaders in LangChain are the abstraction that handles this — they give you a consistent load() interface regardless of the source, returning a list of Document objects (each containing a page_content string and a metadata dict).

from langchain_community.document_loaders import (
    PyPDFLoader,         # PDFs — extracts text page by page
    WebBaseLoader,       # Web pages — fetches and strips HTML
    TextLoader,          # Plain .txt files
    CSVLoader,           # Spreadsheets — each row becomes a Document
    UnstructuredWordDocumentLoader,  # .docx files
    NotionDirectoryLoader,           # Exported Notion workspace
)

# Every loader shares the same interface — .load() returns List[Document]

# Load a PDF — returns one Document per page, with page number in metadata
pdf_loader = PyPDFLoader("engineering_spec.pdf")
pdf_docs = pdf_loader.load()
# pdf_docs[0].page_content → "Chapter 1: System Architecture..."
# pdf_docs[0].metadata     → {"source": "engineering_spec.pdf", "page": 0}

# Load a web page — strips HTML, extracts main text content
web_loader = WebBaseLoader("https://docs.mycompany.com/api-reference")
web_docs = web_loader.load()

# Load a CSV — useful for structured data like FAQs or product catalogs
csv_loader = CSVLoader("product_faq.csv", source_column="url")
csv_docs = csv_loader.load()

The metadata dict is not an afterthought — it's critical for production systems. Every document you ingest should carry metadata: its source URL, file name, creation date, author, document type, whatever is relevant. You'll use this metadata later for filtering ("only retrieve from documents tagged HR policy") and for citations in your responses ("according to engineering_spec.pdf, page 12").

# Always inspect what your loader actually produced before moving on.
# Loaders fail silently in surprising ways — PDFs with scanned images return empty
# page_content strings; HTML with JavaScript-rendered content may come back blank.
for doc in pdf_docs[:3]:
    print(f"Content length: {len(doc.page_content)} chars")
    print(f"Metadata: {doc.metadata}")
    print(f"Preview: {doc.page_content[:200]}")
    print("---")

⚠️ Heads up: PDFs are the most common source and the most problematic. Scanned PDFs
(images of text rather than actual text) will return empty strings with most loaders —
you'll need OCR processing before the text is even extractable. Always validate that
your loader is actually getting text, not silence.

Chapter 4: Text Splitting and Chunking — The Stage Everyone Underestimates

Here's where most RAG beginners make their biggest architectural mistake, because this stage looks trivial and isn't.

You have your documents loaded. They might be entire 80-page PDFs or multi-thousand-word web pages. You can't stuff all of that into a prompt — LLMs have context limits, and even if you could, you don't want to. You want to retrieve the specific relevant section, not an entire document.

So you split documents into chunks — smaller pieces of text that can be independently retrieved and included in a prompt. The decisions you make here — how big each chunk is, how they overlap, how they respect the document's natural structure — have a bigger impact on RAG quality than almost any other single variable.

Chunk Size: The Core Trade-off

This is a genuine tension with no universal right answer:

Too small (e.g., 100 tokens): Each chunk has very little context. You might retrieve a sentence that perfectly matches the query but doesn't contain enough surrounding information to answer it meaningfully. The model gets fragments.
Too large (e.g., 2000 tokens): Each chunk contains more context, but semantic similarity search becomes less precise — a chunk about three different topics might score as a moderate match for many queries rather than a strong match for any. You also use more of your LLM's context window per retrieved chunk.
Sweet spot in practice: 200–500 tokens per chunk for most knowledge-base use cases, with experimentation required for your specific content type and query patterns.

Chunk Overlap: Handling Boundary Problems

When you split at token/character boundaries, you'll slice through sentences, sometimes mid-thought. The sentence that contains the key information might end up half in chunk 12 and half in chunk 13, and neither chunk retrieves well. Overlap addresses this by
repeating the last N tokens of each chunk at the start of the next.

from langchain.text_splitter import RecursiveCharacterTextSplitter

# The workhorse of LangChain splitting — tries to split on natural boundaries
# first (paragraphs → sentences → words) before falling back to raw characters.
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,      # Target max characters per chunk
    chunk_overlap=50,    # Last 50 chars of chunk N repeated at start of chunk N+1
    separators=["\n\n", "\n", ". ", " ", ""]  # Try these in order
)

chunks = splitter.split_documents(pdf_docs)

print(f"Original: {len(pdf_docs)} pages")
print(f"After splitting: {len(chunks)} chunks")

# Good habit: sanity-check your chunks before continuing
for i, chunk in enumerate(chunks[:3]):
    print(f"\n--- Chunk {i} ({len(chunk.page_content)} chars) ---")
    print(chunk.page_content)

Splitting Strategies: Not All Text Is Flat Prose

RecursiveCharacterTextSplitter is the general-purpose default, but different content
types benefit from different strategies:

from langchain.text_splitter import (
    RecursiveCharacterTextSplitter,   # General prose — paragraphs, articles, docs
    MarkdownHeaderTextSplitter,       # Markdown — splits on headings, preserves structure
    Language,                         # Code — splits on functions/classes, not mid-line
)

# For technical documentation in Markdown — splits on headers rather than character count
md_splitter = MarkdownHeaderTextSplitter(
    headers_to_split_on=[
        ("#", "h1"),
        ("##", "h2"),
        ("###", "h3"),
    ]
)
# Each resulting chunk carries header metadata — great for citations later

# For code repositories — respects function/class boundaries
code_splitter = RecursiveCharacterTextSplitter.from_language(
    language=Language.PYTHON,
    chunk_size=1000,
    chunk_overlap=100,
)

💡 Pro tip: Add the source metadata to every chunk explicitly — once you've split
200 documents into 5,000 chunks, you need to know which chunk came from where.
LangChain's splitters preserve metadata from the parent Document, but always verify.

Chapter 5: Embeddings and Vector Stores — Where Your Data Lives

You now have thousands of text chunks. The next problem: how do you find the chunks relevant to a specific user question, fast, at query time?

The answer is semantic search, and it works through embeddings.

What Embeddings Actually Are

Remember from the first article: each chunk of text can be converted into a vector — a list of hundreds or thousands of numbers — that represents its meaning in mathematical space. This conversion is done by an embedding model (a different, smaller model than your LLM — its only job is text → vector).

The key property: semantically similar text produces mathematically similar vectors. "How do I reset my password?" and "Steps to change my account credentials" are worded completely differently but mean similar things — their embedding vectors will be close together in vector space, close enough to find each other via similarity search.

This is why RAG can retrieve relevant content even when the user's question uses completely different words from your documentation. You're not searching for matching keywords; you're searching for matching meaning.

from langchain_openai import OpenAIEmbeddings
from langchain_community.embeddings import HuggingFaceEmbeddings

# OpenAI's embedding model — cloud API, very good quality
openai_embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# Or a local HuggingFace model — free, runs on your hardware, great for cost-sensitive
# or privacy-sensitive use cases (your documents never leave your infrastructure) local_embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")

# What actually happens under the hood (you usually don't call this directly):
vector = openai_embeddings.embed_query("How do I reset my password?")
# vector is a list of ~1500 floats — the "meaning fingerprint" of that sentence print(f"Vector dimensions: {len(vector)}")  # e.g., 1536 for text-embedding-3-small

Vector Stores

Embeddings are only useful if you can search through them efficiently. A vector store is a database built for this — you insert vectors + their associated text, and at query time you give it a query vector and it returns the N most similar stored vectors.

from langchain_community.vectorstores import (
    FAISS,       # Facebook AI Similarity Search — in-memory, great for dev/small scale
    Chroma,      # Lightweight persistent vector store — good for local development
    Pinecone,    # Managed cloud vector database — production scale
    Weaviate,    # Open-source cloud/self-hosted — good for complex filtering
    pgvector,    # Postgres extension — great if you're already on Postgres
)

# Building a FAISS vector store from chunks — this runs your embedding model
# on every chunk and stores the result. This is the slow, expensive indexing step. 
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings()

# This call: embeds every chunk + builds the search index
vectorstore = FAISS.from_documents(
    documents=chunks,      # Your split documents from Chapter 4
    embedding=embeddings   # The model that converts text → vector
)

# Persist to disk so you don't re-embed every time your app restarts
vectorstore.save_local("my_knowledge_base")

# Load it back later — no re-embedding needed
vectorstore = FAISS.load_local("my_knowledge_base", embeddings,
                                allow_dangerous_deserialization=True)

⚠️ Heads up: Embedding your entire document set costs money and takes time —
OpenAI's embedding API charges per token, and embedding 10,000 chunks can take minutes.
Always persist your vector store to disk (or use a managed service) so the indexing
phase runs once, not on every app restart.

Chapter 6: Retrievers — Finding the Right Chunks When It Matters

A retriever is the interface that sits in front of your vector store and answers one question: given this query, what chunks should I surface? It's what Phase 2 of the pipeline calls when a user sends a message.

The simplest retriever is just a vector store wrapper:

# The most basic retriever — pure semantic similarity search
retriever = vectorstore.as_retriever(
    search_type="similarity",   # Find the N most semantically similar chunks
    search_kwargs={"k": 4}      # Return the top 4 chunks
)

# Test it — this is what runs at query time:
relevant_chunks = retriever.invoke("What is the reimbursement limit for travel?")
for chunk in relevant_chunks:
    print(chunk.page_content[:300])
    print(f"Source: {chunk.metadata.get('source', 'unknown')}")
    print("---")

But "top 4 by similarity" is actually a pretty naive strategy, and there are several retrieval approaches that meaningfully improve quality in practice.

MMR — Maximum Marginal Relevance

Pure similarity search has a hidden flaw: if your knowledge base has five paragraphs that all say the same thing slightly differently, you'll retrieve all five of them instead of
getting diverse, complementary information. MMR trades off between relevance (is this chunk similar to the query?) and diversity (is this chunk different from what I've already retrieved?).

retriever = vectorstore.as_retriever(
    search_type="mmr",          # Maximum Marginal Relevance
    search_kwargs={
        "k": 4,                  # Return 4 chunks
        "fetch_k": 20,           # Consider top 20 by similarity first
        "lambda_mult": 0.7       # 0 = pure diversity, 1 = pure similarity
    }
)

Similarity Score Threshold

Don't retrieve bad chunks just to hit your k target. If nothing in your knowledge base is actually relevant to the query, it's better to return nothing than to return vaguely-related content that confuses the model.

retriever = vectorstore.as_retriever(
    search_type="similarity_score_threshold",
    search_kwargs={
        "score_threshold": 0.7,  # Only return chunks above this similarity score
        "k": 4
    }
)

Metadata Filtering

Vector search finds semantically similar content, but sometimes you need to constrain which documents are even eligible — only search HR policies, or only search documents updated in the last 30 days, or only search content in English. This is where metadata filters come in.

retriever = vectorstore.as_retriever(
    search_kwargs={
        "k": 4,
        "filter": {"department": "HR", "document_type": "policy"}
        # Only consider chunks where metadata matches these conditions
    }
)

Multi-Query Retrieval

One underrated technique: the user's question, as phrased, might not be the best query for semantic search. Multi-query retrieval uses the LLM itself to generate multiple alternative phrasings of the question, runs all of them as separate queries, and takes the union of results. This catches relevant chunks that a single query might miss due to phrasing mismatches.

from langchain.retrievers import MultiQueryRetriever
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0)

multi_retriever = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
    llm=llm
    # Under the hood: generates 3-5 alternative phrasings of the query,
    # retrieves for each, deduplicates results
)

Chapter 7: Putting It All Together — A Working RAG Chain

Here's a complete, minimal, working RAG chain using LangChain's modern interface. This is the skeleton of nearly every document Q&A system you'll ever build.

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser

# ─── PHASE 1: INDEXING (run once, offline) ───────────────────────────────────

# 1. Load documents
loader = PyPDFLoader("company_handbook.pdf")
raw_docs = loader.load()

# 2. Split into chunks
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(raw_docs)

# 3. Embed and store
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(chunks, embeddings)
vectorstore.save_local("handbook_index")

# ─── PHASE 2: RETRIEVAL + GENERATION (runs per query) ────────────────────────

# Load the pre-built index (skip re-embedding)
vectorstore = FAISS.load_local("handbook_index", embeddings,
                                allow_dangerous_deserialization=True)

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

# The prompt that instructs the model to answer ONLY from retrieved context
rag_prompt = ChatPromptTemplate.from_messages([
    ("system",
     "You are a helpful assistant answering questions about company policy. "
     "Use ONLY the following retrieved context to answer the question. "
     "If the answer is not in the context, say: 'I don't have that information.' "
     "Do not use any knowledge outside of what's provided below.\n\n"
     "Context:\n{context}"),
    ("user", "{question}")
])

llm = ChatOpenAI(model="gpt-4o", temperature=0)  # temp=0 for consistent, factual answers

def format_docs(docs):
    # Combine retrieved chunks into a single context string
    return "\n\n".join(
        f"[Source: {doc.metadata.get('source', 'unknown')}, "
        f"Page: {doc.metadata.get('page', '?')}]\n{doc.page_content}"
        for doc in docs
    )

# Build the chain using LangChain Expression Language (LCEL)
rag_chain = (
    {
        "context": retriever | format_docs,  # retrieve → format as string
        "question": RunnablePassthrough()    # pass question through unchanged
    }
    | rag_prompt         # fill the template
    | llm                # call the model
    | StrOutputParser()  # parse response to plain string
)

# Use it
response = rag_chain.invoke("What is the reimbursement limit for travel expenses?") print(response)
# "According to the handbook, the travel reimbursement limit is $350 per night
#  for hotels and $75 per day for meals..."

This chain is clean, auditable, and straightforward to swap out individual pieces — change the loader, the splitter settings, the retriever strategy, or the underlying LLM without touching the rest of the pipeline.

Chapter 8: Where RAG Breaks and How to Diagnose It

RAG systems fail in consistent, diagnosable ways. Knowing the failure modes ahead of time saves days of debugging.

"The model ignores the retrieved context and makes things up anyway." Your system prompt isn't firm enough. Add explicit grounding instructions: "Answer only from the context below. If the answer is not in the context, say so." Setting temperature=0
on the LLM also helps with consistency.

"Retrieval returns irrelevant chunks."
This is the most common failure, and it almost always traces to chunking. Chunks are too large (low retrieval precision), too small (not enough context per chunk), or split at bad boundaries (sentences split mid-idea). Try smaller chunks, increase overlap, or switch to a structure-aware splitter (markdown header, code-aware).

"The right information is in the document but retrieval never finds it." Your query phrasing and your document phrasing are too semantically distant. Try the multi-query retriever to cast a wider net. Also check: was this section actually indexed? Loaders silently fail on scanned PDFs, complex tables, and certain layouts.

"The model's answer is correct but I can't trace where it came from." Always include source metadata in your formatted context and instruct the model to cite it. Without attribution, RAG is a black box — with attribution, it's auditable.

"It works in testing but gives bad answers on long documents at scale." Your k value (number of retrieved chunks) is hitting the LLM's context window limit. Either reduce k, reduce chunk size, or use a model with a larger context window. Also check for embedding model mismatch — if you indexed with one embedding model and query with another, the vector space is incompatible.

Where This Takes You Next

You now have a mental model of the complete RAG pipeline from ingestion to response — not just what the pieces are called, but why each one exists and what breaks when it's wrong.

The natural next step is building something real with this. Start with a single clean PDF and a handful of test questions whose correct answers you already know. Run the full pipeline, check whether your retriever surfaces the right chunks for each question, then tune chunk size and overlap until retrieval quality is solid. Get that working before touching retriever strategies or advanced techniques.

Once retrieval is reliable, the rest — getting the model to answer well, adding conversation memory, citing sources — falls into place quickly. The retrieval quality is the foundation. Everything else is downstream from it.

RAG isn't magic. It's plumbing — well-designed plumbing that lets a language model answer questions about your actual data instead of guessing. Build the plumbing carefully, and the magic takes care of itself.

RxJS in Angular — Chapter 10 (Final) | Real-World Patterns, Best Practices & Everything That Actually Matters

Jack Pritom Soren — Wed, 15 Jul 2026 07:38:29 +0000

👋 Welcome to the Final Chapter!

You've made it. 🎉

Over the past 9 chapters, you've learned Observables, subscribe, pipe, map, filter, tap, switchMap, mergeMap, concatMap, Subject, BehaviorSubject, error handling, combining operators, forms, and timing operators.

Now let's put it ALL together. This chapter is about real patterns you'll use every single day in production Angular apps — and the mistakes you must avoid.

🏗️ Pattern 1: The State Service Pattern (Mini State Management)

In large Angular apps, managing shared state is the biggest challenge. You don't always need NgRx — a simple service with BehaviorSubject is often enough.

The Pattern

// feature-state.service.ts
import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable } from 'rxjs';
import { map } from 'rxjs/operators';

// Define the shape of your state
interface ProductState {
  products: Product[];
  selectedProduct: Product | null;
  isLoading: boolean;
  error: string | null;
  filters: {
    category: string;
    maxPrice: number;
    searchTerm: string;
  };
}

// Initial state
const initialState: ProductState = {
  products: [],
  selectedProduct: null,
  isLoading: false,
  error: null,
  filters: {
    category: 'all',
    maxPrice: 999999,
    searchTerm: ''
  }
};

@Injectable({ providedIn: 'root' })
export class ProductStateService {

  // The one source of truth
  private state$ = new BehaviorSubject<ProductState>(initialState);

  // Derived selectors — computed from state
  products$ = this.state$.pipe(map(s => s.products));
  selectedProduct$ = this.state$.pipe(map(s => s.selectedProduct));
  isLoading$ = this.state$.pipe(map(s => s.isLoading));
  error$ = this.state$.pipe(map(s => s.error));

  // Filtered products — automatically recomputes when state changes
  filteredProducts$ = this.state$.pipe(
    map(state => {
      return state.products
        .filter(p =>
          (state.filters.category === 'all' || p.category === state.filters.category) &&
          p.price <= state.filters.maxPrice &&
          p.name.toLowerCase().includes(state.filters.searchTerm.toLowerCase())
        );
    })
  );

  // State updaters — the only way to change state
  setLoading(isLoading: boolean): void {
    this.updateState({ isLoading });
  }

  setProducts(products: Product[]): void {
    this.updateState({ products, isLoading: false, error: null });
  }

  setError(error: string): void {
    this.updateState({ error, isLoading: false });
  }

  selectProduct(product: Product | null): void {
    this.updateState({ selectedProduct: product });
  }

  updateFilters(filters: Partial<ProductState['filters']>): void {
    const currentFilters = this.state$.value.filters;
    this.updateState({ filters: { ...currentFilters, ...filters } });
  }

  // Private helper — immutable state update
  private updateState(partialState: Partial<ProductState>): void {
    this.state$.next({
      ...this.state$.value,
      ...partialState
    });
  }

  // Synchronous getter for imperative code
  get currentState(): ProductState {
    return this.state$.value;
  }
}

Using the State Service in Components

// product-list.component.ts
@Component({
  template: `
    <div *ngIf="state.isLoading$ | async">Loading... ⏳</div>
    <div *ngIf="state.error$ | async as err" class="error">{{ err }}</div>

    <div *ngFor="let product of state.filteredProducts$ | async">
      <h3>{{ product.name }}</h3>
      <button (click)="state.selectProduct(product)">View</button>
    </div>
  `
})
export class ProductListComponent implements OnInit {

  constructor(
    public state: ProductStateService,
    private productService: ProductService
  ) {}

  ngOnInit(): void {
    this.state.setLoading(true);

    this.productService.getAll().subscribe({
      next: products => this.state.setProducts(products),
      error: err => this.state.setError(err.message)
    });
  }
}

// filter-bar.component.ts
@Component({
  template: `
    <input
      [formControl]="search"
      placeholder="Search...">

    <select [formControl]="category">
      <option value="all">All</option>
      <option value="electronics">Electronics</option>
      <option value="clothing">Clothing</option>
    </select>
  `
})
export class FilterBarComponent implements OnInit, OnDestroy {

  search = new FormControl('');
  category = new FormControl('all');

  private destroy$ = new Subject<void>();

  constructor(private state: ProductStateService) {}

  ngOnInit(): void {
    this.search.valueChanges
      .pipe(debounceTime(300), takeUntil(this.destroy$))
      .subscribe(term => this.state.updateFilters({ searchTerm: term || '' }));

    this.category.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(cat => this.state.updateFilters({ category: cat || 'all' }));
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

The filter component and the list component are completely decoupled — they communicate through the state service! 🎯

🏗️ Pattern 2: The Smart/Dumb Component Pattern

Smart components manage data and subscriptions.
Dumb components just display data via @Input and emit events via @Output.

// SMART component — manages data
@Component({
  selector: 'app-users-page',
  template: `
    <!-- Pass data DOWN to dumb component via @Input -->
    <app-user-list
      [users]="users$ | async"
      [isLoading]="isLoading$ | async"
      (userSelected)="onUserSelected($event)"
      (deleteRequested)="onDeleteUser($event)">
    </app-user-list>
  `
})
export class UsersPageComponent {
  users$ = this.userService.getUsers();
  isLoading$ = new BehaviorSubject(true);

  constructor(private userService: UserService) {
    this.users$.subscribe(() => this.isLoading$.next(false));
  }

  onUserSelected(user: User): void { ... }
  onDeleteUser(userId: number): void { ... }
}

// DUMB component — only displays, zero knowledge of services
@Component({
  selector: 'app-user-list',
  template: `
    <div *ngIf="isLoading">Loading...</div>
    <div *ngFor="let user of users">
      {{ user.name }}
      <button (click)="userSelected.emit(user)">View</button>
      <button (click)="deleteRequested.emit(user.id)">Delete</button>
    </div>
  `
})
export class UserListComponent {
  @Input() users: User[] | null = [];
  @Input() isLoading: boolean | null = false;
  @Output() userSelected = new EventEmitter<User>();
  @Output() deleteRequested = new EventEmitter<number>();
}

Dumb components are easy to test, reuse, and understand! 💡

🏗️ Pattern 3: The Loading/Error/Success State Pattern

Every page that fetches data should handle 3 states. Here's the cleanest way:

// Shared types
interface AsyncState<T> {
  data: T | null;
  isLoading: boolean;
  error: string | null;
}

// Helper function
function createLoadingState<T>(): AsyncState<T> {
  return { data: null, isLoading: true, error: null };
}

// In your component
@Component({
  template: `
    <ng-container *ngIf="state$ | async as s">

      <app-skeleton *ngIf="s.isLoading"></app-skeleton>

      <app-error-message
        *ngIf="s.error"
        [message]="s.error"
        (retry)="load()">
      </app-error-message>

      <app-product-grid
        *ngIf="s.data && !s.isLoading"
        [products]="s.data">
      </app-product-grid>

    </ng-container>
  `
})
export class ProductPageComponent implements OnInit {

  state$!: Observable<AsyncState<Product[]>>;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.load();
  }

  load(): void {
    this.state$ = this.productService.getProducts().pipe(
      map(products => ({ data: products, isLoading: false, error: null })),
      catchError(err => of({ data: null, isLoading: false, error: err.message })),
      startWith(createLoadingState<Product[]>())
    );
  }
}

🛑 The Top 10 RxJS Mistakes to Avoid

Mistake 1: Not Unsubscribing

// ❌ Memory leak!
ngOnInit() {
  interval(1000).subscribe(n => console.log(n));
}

// ✅ Proper cleanup
ngOnInit() {
  interval(1000)
    .pipe(takeUntil(this.destroy$))
    .subscribe(n => console.log(n));
}

Mistake 2: Nested Subscribes

// ❌ Never do this — nested subscribes!
this.route.params.subscribe(params => {
  this.userService.getUser(params['id']).subscribe(user => {
    this.user = user;
  });
});

// ✅ Use switchMap
this.route.params.pipe(
  switchMap(params => this.userService.getUser(params['id']))
).subscribe(user => this.user = user);

Mistake 3: Subscribing in Services

// ❌ Bad — subscribing in service creates untraceable subscriptions
@Injectable()
export class UserService {
  loadUsers() {
    this.http.get('/api/users').subscribe(users => {
      this.users = users; // Mutating service state in subscribe!
    });
  }
}

// ✅ Good — return the Observable, let the component decide
@Injectable()
export class UserService {
  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users');
  }
}

Mistake 4: Forgetting startWith in combineLatest

// ❌ combineLatest won't emit until ALL observables have emitted at least once
combineLatest([
  this.searchControl.valueChanges,  // Won't emit until user types!
  this.categoryControl.valueChanges
])

// ✅ Use startWith so combineLatest fires immediately
combineLatest([
  this.searchControl.valueChanges.pipe(startWith('')),
  this.categoryControl.valueChanges.pipe(startWith('all'))
])

Mistake 5: Using switchMap When You Should Use mergeMap

// ❌ Wrong — switchMap cancels previous file uploads!
from(files).pipe(
  switchMap(file => this.upload(file))  // Each new file cancels the previous upload!
)

// ✅ Correct — mergeMap runs all uploads in parallel
from(files).pipe(
  mergeMap(file => this.upload(file))
)

Mistake 6: Not Handling Errors

// ❌ If API fails, the entire Observable dies — no recovery
this.http.get('/api/data').subscribe(data => this.data = data);

// ✅ Always catch errors
this.http.get('/api/data').pipe(
  catchError(err => {
    this.error = 'Failed to load';
    return of([]);
  })
).subscribe(data => this.data = data);

Mistake 7: Overcomplicating Simple Things

// ❌ Too complex for a simple HTTP call
this.http.get('/api/users').pipe(
  take(1),  // Not needed — HTTP already completes after one emission
  first(),  // Also not needed
  shareReplay(1)  // Also unnecessary for a one-time load
)

// ✅ Keep it simple
this.http.get('/api/users')

Mistake 8: Not Using async Pipe

// ❌ Manual subscribe = manual unsubscribe burden
ngOnInit() {
  this.userService.getUsers().subscribe(users => this.users = users);
}

// ✅ async pipe handles everything
users$ = this.userService.getUsers();
// Template: *ngFor="let user of users$ | async"

Mistake 9: Exposing Subject Directly

// ❌ Any component can push values — breaks encapsulation!
cartItems$ = new BehaviorSubject<CartItem[]>([]);

// ✅ Private subject, public Observable
private cartItemsSubject = new BehaviorSubject<CartItem[]>([]);
cartItems$ = this.cartItemsSubject.asObservable();

Mistake 10: Using tap to Extract Data

// ❌ tap should not be used to extract values like this
let userData: User;
this.getUser().pipe(
  tap(user => userData = user)  // Side effect to extract — bad pattern!
).subscribe();

// ✅ Use the data in subscribe or map
this.getUser().subscribe(user => {
  this.userData = user;
});

📋 The Complete RxJS Cheat Sheet

Creating Observables

of(1,2,3) — from static values
from([1,2,3]) — from array or Promise
interval(ms) — ticks every N ms
timer(ms) — emits once after delay
fromEvent(el, 'click') — from DOM event
new Observable(observer => ...) — custom

Transforming

map(fn) — transform each value
filter(fn) — keep only matching values
tap(fn) — side effects, no change

Flattening (Observables of Observables)

switchMap(fn) — cancel old, start new (search, route)
mergeMap(fn) — run all in parallel (uploads)
concatMap(fn) — run one at a time (sequential)

Timing

debounceTime(ms) — wait for silence (search box)
throttleTime(ms) — limit rate (scroll events)
distinctUntilChanged() — skip duplicates
take(n) — take first N, then complete
takeUntil(obs$) — take until signal

Combining

forkJoin({...}) — parallel, wait for all
combineLatest([...]) — emit on any change
withLatestFrom(obs$) — snapshot on trigger
zip(obs1, obs2) — pair by position

Error Handling

catchError(fn) — catch and recover
retry(n) — retry N times
finalize(fn) — always runs last

Subjects

Subject — multicast, no memory
BehaviorSubject(init) — remembers latest
ReplaySubject(n) — remembers last N

🎓 Your Journey So Far — The Complete Series

Here's everything you've learned across all 10 chapters:

Chapter 1 — Observables: the data stream
Chapter 2 — Subscribe & unsubscribe: open and close the tap
Chapter 3 — pipe, map, filter, tap: transform your data
Chapter 4 — switchMap, mergeMap, concatMap: handle nested streams
Chapter 5 — Subject & BehaviorSubject: broadcast to many
Chapter 6 — Error handling: catchError, retry, finalize
Chapter 7 — forkJoin, combineLatest: combine multiple streams
Chapter 8 — Reactive Forms + RxJS: live validation and dynamic forms
Chapter 9 — Timing operators: debounceTime, throttleTime, interval
Chapter 10 — Real-world patterns and best practices (this chapter!)

🚀 What to Learn Next

You're no longer a beginner! Here's your roadmap to RxJS mastery:

1. NgRx — Formal state management built on RxJS (for very large apps)

2. Angular Signals — Angular's newer reactivity system (complements RxJS)

3. shareReplay() — Share a single HTTP response between multiple subscribers

4. Custom Operators — Build your own reusable operators

5. Testing RxJS — Use TestScheduler and marble testing

6. RxJS in Node.js — Use the same patterns on the backend

💌 Thank You for Reading!

You've completed the entire RxJS in Angular Deep Dive series.

Remember: RxJS seems complex at first, but once you see the patterns — Observable → pipe → subscribe, BehaviorSubject in services, async pipe in templates — everything clicks.

The best way to get better is to build. Take a real project and apply what you've learned here.

Good luck, and happy coding! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 10 of 10 — The Final Chapter

Share this series with your team! Every Angular developer needs to understand RxJS.

RxJS in Angular — Chapter 9 | Timing Operators — debounceTime, throttleTime, interval & More

Jack Pritom Soren — Fri, 10 Jul 2026 06:38:36 +0000

👋 Welcome to Chapter 9!

Imagine a user typing in a search box. They type "i", "ip", "iph", "ipho", "iphon", "iphone" — 6 keystrokes in 2 seconds.

Do you really want to make 6 API calls? Of course not! You want to wait until they stop typing and then search once.

That's what timing operators solve. They control when and how often values flow through your stream.

⏱️ `debounceTime()` — Wait for the Silence

debounceTime(ms) waits until there's a pause of ms milliseconds, THEN lets the latest value through.

Think of it like this: "Ignore everything until they stop for a moment."

Like a person who waits for you to finish talking before responding.

import { debounceTime } from 'rxjs/operators';

// User types fast: 'i' → 'ip' → 'iph' → 'ipho' → 'iphon' → 'iphone'
// debounceTime(400) waits 400ms of silence, then sends 'iphone' only
searchControl.valueChanges
  .pipe(debounceTime(400))
  .subscribe(term => {
    this.searchProducts(term);  // Only called ONCE with 'iphone'!
  });

Timeline:

Type 'i'     →  [400ms timer starts]
Type 'ip'    →  [reset timer]
Type 'iph'   →  [reset timer]
Type 'iphone'→  [reset timer]
... 400ms silence ...
EMIT: 'iphone' ✅

Real Angular Example — Smart Search Box

import { Component, OnInit, OnDestroy } from '@angular/core';
import { FormControl } from '@angular/forms';
import { Observable, Subject } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap, startWith, takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-search-box',
  template: `
    <div class="search-wrapper">
      <input
        [formControl]="searchControl"
        placeholder="Search products..."
        (keyup.escape)="clearSearch()">

      <span *ngIf="isLoading" class="spinner">🔄</span>
      <button *ngIf="searchControl.value" (click)="clearSearch()">✕</button>
    </div>

    <div class="results-count" *ngIf="(results$ | async) as results">
      Found {{ results.length }} results
    </div>

    <div class="results">
      <div *ngFor="let item of results$ | async" class="result-item">
        <strong>{{ item.name }}</strong>
        <span>৳{{ item.price }}</span>
      </div>
    </div>
  `
})
export class SearchBoxComponent implements OnInit, OnDestroy {

  searchControl = new FormControl('');
  results$!: Observable<Product[]>;
  isLoading = false;

  private destroy$ = new Subject<void>();

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.results$ = this.searchControl.valueChanges.pipe(
      startWith(''),
      debounceTime(400),           // Wait 400ms after typing stops
      distinctUntilChanged(),      // Don't search if value is the same
      tap(() => this.isLoading = true),
      switchMap(term =>
        this.productService.search(term || '').pipe(
          catchError(() => of([]))
        )
      ),
      tap(() => this.isLoading = false),
      takeUntil(this.destroy$)
    );
  }

  clearSearch(): void {
    this.searchControl.setValue('');
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

Without debounceTime, a user typing "iphone 14" (8 keystrokes) would make 8 API calls. With it: 1 call. 🎉

⚡ `throttleTime()` — Only Once Per Time Window

throttleTime(ms) lets the FIRST value through, then ignores everything for ms milliseconds.

"One value per window — take the first, ignore the rest."

Like a bouncer who lets one person in, then waits before letting the next.

import { throttleTime } from 'rxjs/operators';
import { fromEvent } from 'rxjs';

// User scrolls constantly — fire only once every 200ms
fromEvent(window, 'scroll')
  .pipe(throttleTime(200))
  .subscribe(() => {
    this.checkIfNearBottom();
  });

`debounceTime` vs `throttleTime`:

User clicks rapidly: click, click, click, click, click
                     (every 100ms)

debounceTime(300):   ................ EMIT (only after 300ms silence)
throttleTime(300):   EMIT ............. EMIT (first click, then every 300ms)

Use debounceTime when you want to wait for the user to FINISH (search, form input)
Use throttleTime when you want regular updates while something is happening (scroll, resize, mouse move)

🎯 `distinctUntilChanged()` — Skip Identical Values

This one is simple: don't emit if the value is the same as the last one.

import { distinctUntilChanged } from 'rxjs/operators';

// User clicks in the same input field without changing value
searchControl.valueChanges
  .pipe(
    debounceTime(400),
    distinctUntilChanged()  // Don't search again if value didn't change!
  )
  .subscribe(term => this.search(term));

You can also compare objects with a custom comparator:

this.filterForm.valueChanges.pipe(
  debounceTime(300),
  distinctUntilChanged((prev, curr) =>
    prev.category === curr.category && prev.maxPrice === curr.maxPrice
  )
)

🕐 `interval()` — Emit on a Schedule

interval(ms) emits incrementing numbers (0, 1, 2, 3...) every ms milliseconds. It runs forever until you unsubscribe.

import { interval } from 'rxjs';
import { takeUntil, take } from 'rxjs/operators';

// Emit every 1 second: 0, 1, 2, 3...
interval(1000).subscribe(n => console.log(n));

Real Example — Auto-Refresh Dashboard

@Component({
  selector: 'app-live-dashboard',
  template: `
    <div class="dashboard">
      <h2>🔴 Live Orders</h2>
      <p class="last-updated">Last updated: {{ lastUpdated | date:'HH:mm:ss' }}</p>

      <div *ngFor="let order of orders$ | async" class="order-row">
        #{{ order.id }} — {{ order.status }} — ৳{{ order.total }}
      </div>
    </div>
  `
})
export class LiveDashboardComponent implements OnInit, OnDestroy {

  orders$!: Observable<Order[]>;
  lastUpdated = new Date();

  private destroy$ = new Subject<void>();

  constructor(private orderService: OrderService) {}

  ngOnInit(): void {
    // Load immediately, then refresh every 30 seconds
    this.orders$ = interval(30000).pipe(
      startWith(0),  // Emit immediately (don't wait for first interval)
      switchMap(() => {
        this.lastUpdated = new Date();
        return this.orderService.getLiveOrders();
      }),
      takeUntil(this.destroy$)
    );
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

The dashboard refreshes every 30 seconds automatically — no manual button needed!

⏲️ `timer()` — Emit Once After a Delay

timer(delay) emits once after the specified delay.
timer(delay, interval) emits once after delay, then every interval.

import { timer } from 'rxjs';

// Show a toast notification, then hide it after 3 seconds
this.showToast = true;

timer(3000).pipe(
  takeUntil(this.destroy$)
).subscribe(() => {
  this.showToast = false;
});

Real Example — Auto-dismiss Notifications

@Component({
  selector: 'app-toast',
  template: `
    <div *ngFor="let toast of toasts" class="toast" [class]="toast.type">
      {{ toast.message }}
      <button (click)="dismiss(toast.id)">✕</button>
    </div>
  `
})
export class ToastComponent implements OnInit, OnDestroy {

  toasts: Toast[] = [];
  private destroy$ = new Subject<void>();

  constructor(private toastService: ToastService) {}

  ngOnInit(): void {
    this.toastService.toasts$
      .pipe(takeUntil(this.destroy$))
      .subscribe(toast => {
        this.toasts.push(toast);

        // Auto-remove after 4 seconds
        timer(4000)
          .pipe(takeUntil(this.destroy$))
          .subscribe(() => {
            this.dismiss(toast.id);
          });
      });
  }

  dismiss(id: number): void {
    this.toasts = this.toasts.filter(t => t.id !== id);
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

📡 `fromEvent()` — Turn DOM Events into Observables

fromEvent converts any DOM event into an Observable stream!

import { fromEvent } from 'rxjs';
import { debounceTime, map } from 'rxjs/operators';

// Infinite scroll — detect when user is near bottom
const scroll$ = fromEvent(window, 'scroll').pipe(
  throttleTime(200),
  map(() => {
    const scrollTop = window.scrollY;
    const windowHeight = window.innerHeight;
    const docHeight = document.documentElement.scrollHeight;
    return (scrollTop + windowHeight) / docHeight * 100; // % scrolled
  }),
  filter(pct => pct > 80)  // Only when 80% scrolled
);

scroll$.pipe(
  takeUntil(this.destroy$)
).subscribe(() => {
  this.loadMoreItems();
});

🏗️ Full Real-World Example — Infinite Scroll List

@Component({
  selector: 'app-infinite-list',
  template: `
    <div class="scroll-container" #scrollContainer>
      <div *ngFor="let item of items" class="list-item">
        <strong>{{ item.title }}</strong>
        <p>{{ item.body }}</p>
      </div>

      <div *ngIf="isLoadingMore" class="loading-more">
        Loading more... ⏳
      </div>

      <div *ngIf="noMoreItems" class="end-message">
        🏁 You've reached the end!
      </div>
    </div>
  `
})
export class InfiniteListComponent implements OnInit, OnDestroy {

  items: Item[] = [];
  currentPage = 1;
  isLoadingMore = false;
  noMoreItems = false;

  private destroy$ = new Subject<void>();

  constructor(
    private itemService: ItemService,
    private el: ElementRef
  ) {}

  ngOnInit(): void {
    // Load initial items
    this.loadPage(1);

    // Watch for scroll near bottom
    fromEvent(this.el.nativeElement.querySelector('.scroll-container'), 'scroll')
      .pipe(
        throttleTime(300),
        filter(() => !this.isLoadingMore && !this.noMoreItems),
        filter((event: any) => {
          const el = event.target;
          const nearBottom = el.scrollTop + el.clientHeight >= el.scrollHeight - 200;
          return nearBottom;
        }),
        takeUntil(this.destroy$)
      )
      .subscribe(() => {
        this.currentPage++;
        this.loadPage(this.currentPage);
      });
  }

  private loadPage(page: number): void {
    this.isLoadingMore = true;

    this.itemService.getItems(page).subscribe({
      next: (newItems) => {
        if (newItems.length === 0) {
          this.noMoreItems = true;
        } else {
          this.items = [...this.items, ...newItems];
        }
        this.isLoadingMore = false;
      },
      error: () => {
        this.isLoadingMore = false;
      }
    });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🧠 Quick Reference — When to Use Which

debounceTime(400) — User is typing in a search box. Wait for them to pause before searching.

throttleTime(200) — User is scrolling or resizing. Handle events at most once per 200ms.

distinctUntilChanged() — Don't trigger again if the value hasn't actually changed.

interval(30000) — Refresh dashboard data every 30 seconds.

timer(3000) — Auto-dismiss a notification after 3 seconds.

fromEvent(el, 'scroll') — Convert a DOM scroll event into an Observable.

🧠 Chapter 9 Summary — What You Learned

debounceTime(ms) — emits only after the stream is silent for ms milliseconds. Best for search inputs.
throttleTime(ms) — emits the first value, then ignores for ms milliseconds. Best for scroll/resize events.
distinctUntilChanged() — skips emission if value is same as previous. Essential for search and forms.
interval(ms) — emits 0, 1, 2... every ms milliseconds. Best for polling/auto-refresh.
timer(ms) — emits once after delay. Best for auto-dismiss notifications.
fromEvent(element, event) — turns any DOM event into an Observable. Best for scroll, click, resize.

📚 Coming Up in Chapter 10 — The Final Chapter!

We wrap up the series with the most important real-world patterns every Angular developer should know:

The async pipe + loading state pattern
The smart/dumb component pattern with Observables
The state management pattern using BehaviorSubject
Performance tips — avoiding common RxJS pitfalls

See you in the final chapter! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 9 of 10

RxJS in Angular — Chapter 8 | RxJS + Angular Reactive Forms — Live Validation ও Dynamic Forms

Jack Pritom Soren — Sat, 04 Jul 2026 05:42:49 +0000

"RxJS + Angular Reactive Forms — Live Validation & Dynamic Forms"

👋 Welcome to Chapter 8!

Forms are EVERYWHERE in web apps — login, registration, checkout, search, settings.

Angular's Reactive Forms are powered by RxJS under the hood. Every FormControl has streams you can subscribe to — valueChanges, statusChanges. This unlocks incredibly powerful form behavior that would be painfully difficult to build any other way.

Today we build real, production-quality forms with RxJS superpowers!

🎛️ The Reactive Forms Quick Setup

First, let's make sure we have the right setup:

app.module.ts

import { ReactiveFormsModule } from '@angular/forms';

@NgModule({
  imports: [ReactiveFormsModule]
})
export class AppModule {}

💡 The Key Streams on Every FormControl

Every FormControl, FormGroup, and FormArray has two key Observable streams:

valueChanges — emits every time the value changes
statusChanges — emits every time the validation status changes ('VALID', 'INVALID', 'PENDING', 'DISABLED')

const emailControl = new FormControl('');

// Watch the value
emailControl.valueChanges.subscribe(value => {
  console.log('Email is now:', value);
});

// Watch the validation status
emailControl.statusChanges.subscribe(status => {
  console.log('Status:', status); // 'VALID', 'INVALID', 'PENDING', 'DISABLED'
});

🔍 Real Example 1 — Live Username Availability Check

This is extremely common: as the user types a username, check if it's available.

// register.component.ts
import { Component, OnInit, OnDestroy } from '@angular/core';
import { FormBuilder, FormGroup, Validators, AbstractControl } from '@angular/forms';
import { Subject } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap, takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-register',
  template: `
    <form [formGroup]="registerForm" (ngSubmit)="onSubmit()">

      <div class="field">
        <label>Username</label>
        <input formControlName="username" placeholder="Choose a username" />

        <!-- Checking availability -->
        <span *ngIf="isCheckingUsername" class="checking">
          Checking availability... ⏳
        </span>

        <!-- Available -->
        <span *ngIf="usernameAvailable === true" class="available">
          ✅ Username is available!
        </span>

        <!-- Taken -->
        <span *ngIf="usernameAvailable === false" class="taken">
          ❌ Username is already taken
        </span>

        <!-- Validation errors -->
        <span *ngIf="registerForm.get('username')?.errors?.['required'] &&
                     registerForm.get('username')?.touched">
          Username is required
        </span>
        <span *ngIf="registerForm.get('username')?.errors?.['minlength']">
          At least 3 characters required
        </span>
      </div>

      <div class="field">
        <label>Email</label>
        <input formControlName="email" type="email" placeholder="Enter email" />
        <span *ngIf="registerForm.get('email')?.errors?.['email'] &&
                     registerForm.get('email')?.touched">
          Invalid email address
        </span>
      </div>

      <div class="field">
        <label>Password</label>
        <input formControlName="password" type="password" placeholder="Password" />
        <div class="password-strength" [class]="passwordStrength">
          {{ passwordStrengthLabel }}
        </div>
      </div>

      <div class="field">
        <label>Confirm Password</label>
        <input formControlName="confirmPassword" type="password" />
        <span *ngIf="registerForm.errors?.['passwordMismatch'] &&
                     registerForm.get('confirmPassword')?.touched">
          Passwords do not match
        </span>
      </div>

      <button type="submit" [disabled]="registerForm.invalid || isCheckingUsername">
        Create Account
      </button>

    </form>
  `
})
export class RegisterComponent implements OnInit, OnDestroy {

  registerForm!: FormGroup;
  isCheckingUsername = false;
  usernameAvailable: boolean | null = null;
  passwordStrength = 'weak';
  passwordStrengthLabel = '';

  private destroy$ = new Subject<void>();

  constructor(
    private fb: FormBuilder,
    private authService: AuthService
  ) {}

  ngOnInit(): void {
    this.registerForm = this.fb.group({
      username: ['', [Validators.required, Validators.minLength(3)]],
      email: ['', [Validators.required, Validators.email]],
      password: ['', [Validators.required, Validators.minLength(8)]],
      confirmPassword: ['', Validators.required]
    }, {
      validators: this.passwordMatchValidator
    });

    // --- RxJS Magic: Username availability check ---
    this.registerForm.get('username')!.valueChanges
      .pipe(
        debounceTime(500),                   // Wait 500ms after typing
        distinctUntilChanged(),              // Don't check if same value
        takeUntil(this.destroy$)
      )
      .subscribe(username => {
        if (username && username.length >= 3) {
          this.isCheckingUsername = true;
          this.usernameAvailable = null;

          this.authService.checkUsername(username)
            .pipe(takeUntil(this.destroy$))
            .subscribe({
              next: (isAvailable) => {
                this.usernameAvailable = isAvailable;
                this.isCheckingUsername = false;
              },
              error: () => {
                this.isCheckingUsername = false;
              }
            });
        } else {
          this.usernameAvailable = null;
        }
      });

    // --- RxJS Magic: Password strength meter ---
    this.registerForm.get('password')!.valueChanges
      .pipe(takeUntil(this.destroy$))
      .subscribe(password => {
        this.updatePasswordStrength(password || '');
      });
  }

  private updatePasswordStrength(password: string): void {
    let score = 0;
    if (password.length >= 8) score++;
    if (/[A-Z]/.test(password)) score++;
    if (/[0-9]/.test(password)) score++;
    if (/[^A-Za-z0-9]/.test(password)) score++;

    if (score <= 1) {
      this.passwordStrength = 'weak';
      this.passwordStrengthLabel = '🔴 Weak';
    } else if (score === 2) {
      this.passwordStrength = 'fair';
      this.passwordStrengthLabel = '🟡 Fair';
    } else if (score === 3) {
      this.passwordStrength = 'good';
      this.passwordStrengthLabel = '🟢 Good';
    } else {
      this.passwordStrength = 'strong';
      this.passwordStrengthLabel = '💪 Strong';
    }
  }

  private passwordMatchValidator(group: AbstractControl) {
    const password = group.get('password')?.value;
    const confirm = group.get('confirmPassword')?.value;
    return password === confirm ? null : { passwordMismatch: true };
  }

  onSubmit(): void {
    if (this.registerForm.valid && this.usernameAvailable) {
      console.log('Register:', this.registerForm.value);
    }
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🏙️ Real Example 2 — Dependent Dropdowns (Country → City)

When selecting a country should dynamically load cities for that country:

@Component({
  template: `
    <form [formGroup]="addressForm">

      <select formControlName="country">
        <option value="">Select Country</option>
        <option *ngFor="let c of countries" [value]="c.code">
          {{ c.name }}
        </option>
      </select>

      <select formControlName="city">
        <option value="">
          {{ isLoadingCities ? 'Loading cities...' : 'Select City' }}
        </option>
        <option *ngFor="let city of cities" [value]="city.id">
          {{ city.name }}
        </option>
      </select>

    </form>
  `
})
export class AddressFormComponent implements OnInit, OnDestroy {

  addressForm = this.fb.group({
    country: [''],
    city: [{ value: '', disabled: true }]
  });

  countries = [
    { code: 'BD', name: 'Bangladesh' },
    { code: 'IN', name: 'India' },
    { code: 'US', name: 'USA' }
  ];

  cities: any[] = [];
  isLoadingCities = false;

  private destroy$ = new Subject<void>();

  constructor(
    private fb: FormBuilder,
    private locationService: LocationService
  ) {}

  ngOnInit(): void {

    // When country changes — load its cities
    this.addressForm.get('country')!.valueChanges
      .pipe(
        takeUntil(this.destroy$),
        tap(() => {
          // Reset city when country changes
          this.cities = [];
          this.addressForm.get('city')!.disable();
          this.addressForm.get('city')!.setValue('');
          this.isLoadingCities = true;
        }),
        switchMap(countryCode => {
          if (!countryCode) return of([]);
          return this.locationService.getCitiesByCountry(countryCode)
            .pipe(catchError(() => of([])));
        })
      )
      .subscribe(cities => {
        this.cities = cities;
        this.isLoadingCities = false;
        if (cities.length > 0) {
          this.addressForm.get('city')!.enable();
        }
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

When the country changes, the city dropdown automatically:

Resets to empty
Shows "Loading cities..."
Disables itself
Loads new cities from API
Re-enables with new options

All powered by valueChanges + switchMap!

💰 Real Example 3 — Live Price Calculator

A checkout form where the price updates as you change quantity and select options:

@Component({
  template: `
    <form [formGroup]="orderForm">
      <label>Quantity</label>
      <input type="number" formControlName="quantity" min="1">

      <label>Size</label>
      <select formControlName="size">
        <option value="small">Small</option>
        <option value="medium">Medium (+৳200)</option>
        <option value="large">Large (+৳400)</option>
      </select>

      <label>
        <input type="checkbox" formControlName="giftWrap">
        Gift Wrap (+৳50)
      </label>

      <div class="price-summary">
        <p>Base price: ৳{{ basePrice }}</p>
        <p>Total: <strong>৳{{ liveTotal$ | async }}</strong></p>
      </div>
    </form>
  `
})
export class OrderFormComponent implements OnInit {

  basePrice = 500;

  orderForm = this.fb.group({
    quantity: [1],
    size: ['small'],
    giftWrap: [false]
  });

  liveTotal$!: Observable<number>;

  constructor(private fb: FormBuilder) {}

  ngOnInit(): void {
    const sizeAddon: Record<string, number> = {
      small: 0,
      medium: 200,
      large: 400
    };

    // Calculate total every time ANY field changes
    this.liveTotal$ = this.orderForm.valueChanges.pipe(
      startWith(this.orderForm.value),
      map(values => {
        const qty = values.quantity || 1;
        const sizeExtra = sizeAddon[values.size] || 0;
        const giftExtra = values.giftWrap ? 50 : 0;
        return (this.basePrice + sizeExtra + giftExtra) * qty;
      })
    );
  }
}

The total updates instantly as the user changes any field — no button, no event handlers, just pure reactive magic!

🔧 Using `statusChanges` for Async Validators

ngOnInit(): void {
  // React to form validity changes
  this.registerForm.statusChanges
    .pipe(
      distinctUntilChanged(),
      takeUntil(this.destroy$)
    )
    .subscribe(status => {
      // 'VALID', 'INVALID', 'PENDING', 'DISABLED'
      if (status === 'VALID') {
        this.canSubmit = true;
        this.showSuccessHint = true;
      } else {
        this.canSubmit = false;
        this.showSuccessHint = false;
      }
    });
}

🧠 Chapter 8 Summary — What You Learned

FormControl.valueChanges is an Observable — you can use all RxJS operators on it
FormControl.statusChanges tells you when validity changes
Use debounceTime + switchMap for async validation (username check, email uniqueness)
Use valueChanges + switchMap for dependent dropdowns (country → city)
Use valueChanges + map + startWith for live price calculators and previews
Always clean up form subscriptions with takeUntil or async pipe

📚 Coming Up in Chapter 9...

Chapter 9 covers debounceTime, throttleTime, distinctUntilChanged — the timing operators.

These are essential for search boxes, scroll events, resize events, and any situation where you need to control HOW OFTEN your code runs.

See you in Chapter 9! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 8 of 10
Follow me on : Github Linkedin Threads Youtube Channel

What Actually Happens When You Type "What is Python?" Into ChatGPT

Jack Pritom Soren — Thu, 25 Jun 2026 13:36:51 +0000

You type a question. A few seconds later, an answer streams back — fluent, confident,
occasionally wrong. Most developers use this every single day without ever asking what's
actually happening between the keystroke and the response. And honestly, you don't need
to know. Until the day you do — the day your manager says "let's add an AI feature to the
product" and suddenly you're the one who has to build it, not just use it.

That's the moment most engineers hit a wall. Using ChatGPT is trivial. Building on top of
an LLM is a different beast entirely — you're suddenly dealing with API contracts, token
limits, inconsistent outputs, five different providers with five different SDKs, and a
model that occasionally decides your perfectly valid JSON request deserves a poem instead.

This article is the article I wish someone had handed me before I started. We're going to
go top to bottom: what an LLM actually is, what happens behind the scenes when you ask one
a question, why every provider's API feels like a slightly different flavor of the same
headache, and how a framework called LangChain showed up to make that headache
manageable. By the end, you'll understand not just the theory but the actual building
blocks — models, prompts, prompt templates, and structured output — that you'll use to
ship a real AI application.

No math. No model training. This is the practical, application-builder's view of
generative AI — the view from where you, the engineer integrating these models into
products, actually stand.

What We'll Cover

The Three Layers of the Generative AI World
What an LLM Actually Is
What Happens When You Type "What is Python?"
The Provider Problem — Why Every API Feels Different
Enter LangChain: What It Actually Solves
LangChain's Core Components
Prompts, Prompt Templates, and Structured Output
Common Pitfalls When You're Starting Out

Chapter 1: The Three Layers of the Generative AI World

Before touching any code, it helps to mentally split the generative AI landscape into
three layers. Almost every confusion beginners have comes from mixing these up.

Layer 1 — Research. This is where new model architectures get invented. Think of the
teams that publish papers on attention mechanisms, new training techniques, or ways to
make models reason better. This is heavy math, heavy compute, and frankly — most
application developers will never touch this layer, and that's completely fine.

Layer 2 — Foundation Models (the "bedrock"). This is where research turns into
actual trained models — GPT-4, Claude, Gemini, Llama, and so on. These are massive neural
networks trained on enormous amounts of text, trained once (at huge cost), and then
exposed to the world either as downloadable weights or, more commonly, as a hosted
service. You don't train these. You consume them.

Layer 3 — Providers. This is the business layer — companies that take a foundation
model and wrap it in an API you can actually call. OpenAI serves GPT models through their
API. Anthropic serves Claude. Google serves Gemini. Same underlying idea — "send text in,
get text out" — but every provider wraps it differently.

Layer 4 — You. This is where application engineers live. You don't do research. You
don't train models. You take a provider's API, combine it with your product's logic, your
data, your users' inputs, and you build something useful on top — a chatbot, a document
summarizer, an autonomous agent, whatever your product needs.

💡 Pro tip: If you ever feel like you "need to learn machine learning" to build AI
products, you usually don't. You need to learn Layer 4 well — APIs, prompting,
orchestration, and your product domain. ML research skills matter for Layers 1 and 2,
which is a completely different career path.

Here's the mental model as a quick diagram:

[ Research ]  →  [ Foundation Models ]  →  [ Providers ]  →  [ You: the App Builder ]
  (papers,         (GPT-4, Claude,           (OpenAI API,      (your product, your
   training         Gemini — trained          Anthropic API,    business logic, your
   techniques)       once, expensive)         Google API)       users)

Everything in this article lives at Layer 4. That's the layer where LangChain operates,
and it's the layer where most AI Engineering jobs actually sit.

Chapter 2: What an LLM Actually Is

Strip away the hype and an LLM (Large Language Model) is, at its core, a very
sophisticated next-word predictor. That's it. That's the whole trick.

Here's the analogy that actually makes this click: think about your phone's keyboard
autocomplete. You type "I'm running" and it suggests "late." That's a tiny, dumb version
of what an LLM does. Now imagine that same autocomplete, except instead of being trained
on a few thousand text messages, it was trained on a meaningful chunk of the publicly
available internet — books, code, articles, forums, documentation. And instead of
predicting one word ahead with a simple lookup table, it predicts the next word (technically,
the next token — a word piece) using a neural network with billions of parameters that
has learned deep statistical patterns about how language, logic, and even code tend to
flow.

That's it. An LLM doesn't "know" facts the way a database does. It doesn't "look things
up." It generates the statistically most plausible continuation of the text you gave it,
one token at a time, based on patterns absorbed during training.

This explains so much of LLM behavior that confuses beginners:

Why LLMs hallucinate: They're not retrieving facts, they're generating plausible text. If the plausible-sounding continuation happens to be false, the model has no internal alarm bell — it has no concept of "true" vs "false," only "likely" vs "unlikely" given its training.
Why phrasing your prompt differently changes the answer: You're changing the starting point of the prediction, which changes what's statistically "next."
Why longer context helps: More context = more signal for the model to condition its next-token predictions on.

⚠️ Heads up: Treating an LLM as a search engine or a database is the single most
common beginner mistake. It's a text-completion engine with extraordinary pattern
recognition — powerful, but fundamentally different from a system that retrieves
ground-truth facts. This is exactly why techniques like RAG (Retrieval-Augmented
Generation) exist — to bolt real, retrievable facts onto a model that otherwise just
predicts plausible text.

Chapter 3: What Happens When You Type "What is Python?"

Let's make this concrete. You open ChatGPT, type "What is Python?", hit enter. Here's the
actual pipeline, simplified but accurate:

Step 1 — Tokenization. Your text isn't fed to the model as English words. It's broken
into tokens — sub-word chunks. "What is Python?" might become something like
["What", " is", " Python", "?"], each mapped to a numeric ID the model actually
understands. Models don't read letters; they read numbers.

Step 2 — Embedding. Each token ID gets converted into a vector — a long list of
numbers (think hundreds or thousands of dimensions) that represents that token's meaning
in a mathematical space. Tokens with similar meanings end up with mathematically similar
vectors. This is how the model captures meaning, not just spelling.

Step 3 — The Forward Pass (the actual "thinking"). These vectors flow through the
model's neural network layers — for modern LLMs, this is a transformer architecture,
which uses a mechanism called attention to weigh how much every word in your input
should influence every other word. This is the expensive, GPU-hungry computation step.

Step 4 — Next-Token Prediction. The model outputs a probability distribution over its
entire vocabulary — essentially "given everything so far, here's how likely each possible
next token is." Maybe "Python" has a 40% chance of being followed by " is", a 25%
chance of " was", and so on across thousands of candidate tokens.

Step 5 — Sampling. The system picks one token from that distribution (not always the
single most likely one — there's controlled randomness, governed by a setting called
temperature, which is why asking the same question twice can give slightly different
answers).

Step 6 — Repeat. That chosen token gets appended to the input, and the entire process
runs again to predict the next token. This repeats — token by token — until the model
produces a stop signal or hits a length limit.

That's why responses stream in word by word — that's not a UI trick, that's literally
how the generation works under the hood. Every word you see appear is a fresh pass through
billions of parameters.

# A wildly simplified mental model of what's happening — NOT real model code,
# just illustrating the loop structure of autoregressive generation.

prompt_tokens = tokenize("What is Python?")  # Step 1: text -> tokens
generated = prompt_tokens

while not is_stop_token(generated[-1]) and len(generated) < max_length:
    vectors = embed(generated)                 # Step 2: tokens -> meaning vectors
    probabilities = model.forward(vectors)      # Steps 3-4: the transformer "thinks"
    next_token = sample(probabilities, temperature=0.7)  # Step 5: pick next token
    generated.append(next_token)                # Step 6: repeat with new context

response = detokenize(generated)

Every single API call you make to OpenAI, Anthropic, or Google is, underneath all the
infrastructure, running this loop.

Chapter 4: The Provider Problem — Why Every API Feels Different

Once you decide to build something real, you quickly discover that "calling an LLM" isn't
standardized. Here's what that looks like in practice:

OpenAI's chat completion format wraps messages in a messages array with role and
content fields, and you call client.chat.completions.create(...). Anthropic's Claude
API looks similar on the surface but has different parameter names, a different way of
handling system prompts, and different response object structures. Google's Gemini API
differs again — different SDK, different conventions for multi-turn conversation, different
ways of handling function calling.

Now multiply that by the actual problems teams run into:

Switching cost. You build your app on OpenAI, then your company wants to evaluate Claude for better reasoning on a specific task, or Gemini for cost reasons. Now you're rewriting your integration layer from scratch.
Inconsistent output formats. Getting reliable structured JSON out of one provider doesn't mean the same prompting trick works on another. Each model has its own quirks.
No standard for memory. If you want a chatbot that remembers earlier turns in a conversation, you have to manually manage and re-send conversation history — and every provider expects that history shaped slightly differently.
No standard for tools/agents. Letting a model call external functions (e.g., "look up the weather," "query a database") is implemented differently across providers.
Chaining is manual. Real applications rarely call an LLM once. You might retrieve documents, feed them into a prompt, get a response, parse it, feed that into another prompt. Wiring this by hand, per provider, gets messy fast.

This is the exact pain point that gave rise to orchestration frameworks — and the most
widely adopted one is LangChain.

Chapter 5: Enter LangChain — What It Actually Solves

LangChain is a framework that sits between you and the raw LLM provider APIs, giving
you a consistent set of abstractions regardless of which model is powering things
underneath. Think of it less like "a new way to talk to AI" and more like an ORM (like
SQLAlchemy or Prisma) — except instead of abstracting away different SQL databases, it
abstracts away different LLM providers.

The pitch is simple: write your application logic once, swap the underlying model with
minimal code changes. Switch from GPT-4 to Claude to test which gives better results?
In a well-structured LangChain app, that can be close to a one-line change, not a rewrite.

But LangChain solves more than just "different APIs." It gives you standardized,
composable building blocks for the patterns that show up in every real LLM application:
managing prompts as reusable templates, chaining multiple steps together, maintaining
conversation memory, retrieving relevant data before generating a response, and letting
models call external tools as agents.

⚠️ Heads up: LangChain is not magic and it's not the only way to build AI
applications — you can absolutely call provider SDKs directly, and for simple use cases,
that's sometimes the better call (less abstraction overhead, fewer dependencies). Treat
LangChain as a productivity tool for composable, provider-agnostic applications, not
a mandatory layer for every project.

Chapter 6: LangChain's Core Components

LangChain is organized around a handful of core building blocks. If you understand these
six, you understand the framework's mental model.

Models — The interface to the actual LLM. LangChain splits this into a few types:

Chat/Language models — text in, text out (or more precisely, message-in, message-out for chat models). This is your GPT-4, Claude, Gemini connections.
Embedding models — instead of generating text, these convert text into those numeric vectors we discussed in Chapter 3, used for search and retrieval (this is the backbone of RAG systems).
Multimodal models — models that accept more than just text: images, audio, sometimes video, alongside text.

Prompts — The input you construct to send to the model. We'll go deep on this in the
next chapter since it's where most of your day-to-day engineering time actually goes.

Chains — A sequence of calls linked together, where the output of one step becomes the
input of the next. Classic example: take a user's question → retrieve relevant documents →
stuff those documents into a prompt → send to the LLM → parse the response. That's a chain.

Memory — A mechanism for persisting conversation history across multiple turns, so your
chatbot doesn't forget what the user said three messages ago. Without memory, every API
call is stateless — the model has zero awareness of anything outside the current prompt.

Indexes — Structures (usually backed by vector databases) that let you store and
efficiently search large amounts of external data — your documents, your knowledge base —
so the model can retrieve relevant pieces instead of trying to "know" everything.

Agents — The most advanced building block. Instead of you hardcoding the sequence of
steps, an agent uses the LLM itself to decide what action to take next — which tool to
call, in what order — based on the user's request. This is how you get an AI that can
"search the web, then do math, then write a summary" without you scripting that exact flow.

User question
     │
     ▼
[ Prompt Template ]  ← fills in variables (user input, retrieved context, etc.)
     │
     ▼
[ Chat Model ]  ← OpenAI, Claude, Gemini — swappable
     │
     ▼
[ Output Parser ]  ← turns raw text into structured data your app can use
     │
     ▼
Your application logic

That diagram is, roughly, 80% of real-world LangChain usage. The remaining 20% layers in
memory, retrieval, and agentic decision-making on top.

Chapter 7: Prompts, Prompt Templates, and Structured Output

This is the part that actually consumes most of your engineering time once you start
building, so let's slow down here.

Simple Prompts vs. System + User Prompts

The crudest way to prompt a model is a single block of text — you just write what you
want and send it. That works for quick experiments but falls apart fast in production.

Modern chat models instead expect a structured message format, typically split into
roles:

System prompt — instructions that set the model's behavior, persona, and constraints before the conversation starts. Think of it as the model's "job description." ("You are a customer support assistant for a SaaS billing platform. Only answer questions related to billing. Keep responses under 100 words.")
User prompt — the actual input from the end user. ("Why was I charged twice this month?")

Separating these matters enormously. Mixing instructions and user input into one giant
blob makes the model more likely to follow user instructions that override your intended
behavior (a real security concern — this is part of how prompt injection attacks work).
Keeping them separate is both cleaner and safer.

# Simple prompt — works, but rigid and hard to reuse or secure
simple_prompt = "You are a billing assistant. Why was I charged twice?"

# System + User separation — the standard production pattern
messages = [
    {
        "role": "system",
        "content": "You are a customer support assistant for a SaaS billing platform. "
                    "Only answer questions related to billing. Keep responses concise."
    },
    {
        "role": "user",
        "content": "Why was I charged twice this month?"
    }
]

Prompt Templates

Here's a problem you'll hit on day one of building anything real: your system prompt is
mostly static, but parts of it need to change based on context — the user's name, the
retrieved documents, the current date, the product they're asking about. Hardcoding
f-strings everywhere gets messy and error-prone fast, especially once you have dozens of
prompts across your codebase.

Prompt templates solve this by treating prompts like reusable functions with
parameters — define the structure once, fill in the variables at call time.

from langchain.prompts import ChatPromptTemplate

# Define the template ONCE, with placeholders for dynamic values
template = ChatPromptTemplate.from_messages([
    ("system", "You are a support assistant for {product_name}. "
               "Today's date is {current_date}. Be concise and friendly."),
    ("user", "{user_question}")
])

# Reuse it for every request — just swap in the variables
filled_prompt = template.format_messages(
    product_name="Acme Billing",
    current_date="2026-06-21",
    user_question="Why was I charged twice this month?"
)

This isn't just convenience. Templates make prompts testable (you can version them,
diff them, A/B test wording changes), consistent (every call follows the same
structure, reducing weird edge-case outputs), and maintainable (update the template in
one place instead of hunting through scattered strings across your codebase).

💡 Pro tip: Treat your prompt templates the way you'd treat SQL queries or API
contracts — version-controlled, reviewed in pull requests, and tested. A "small" wording
tweak in a system prompt can meaningfully change model behavior in production.

Structured Output

Here's the next wall every builder hits: LLMs naturally produce free-flowing text, but
your application needs data — a JSON object you can parse, validate, and plug into a
database or UI. "Just ask the model to return JSON" sounds simple and, often, isn't — models
sometimes wrap JSON in explanatory prose, use inconsistent field names, or produce
almost-valid-but-broken JSON.

LangChain addresses this with structured output tooling — you define the shape of
data you want (often using a schema, like a Pydantic model in Python), and LangChain
handles instructing the model to conform to it and parsing/validating the result.

from pydantic import BaseModel, Field
from langchain.chat_models import init_chat_model

# Define the EXACT shape of data you want back — not free text
class SupportTicketSummary(BaseModel):
    issue_category: str = Field(description="One of: billing, technical, account, other")
    urgency: str = Field(description="One of: low, medium, high")
    summary: str = Field(description="One sentence summary of the user's issue")

model = init_chat_model("gpt-4", model_provider="openai")

# Bind the schema — the model's response will be coerced into this structure
structured_model = model.with_structured_output(SupportTicketSummary)

result = structured_model.invoke(
    "Why was I charged twice this month? This is really frustrating, "
    "I need this fixed before my card gets declined again."
)

# 'result' is now a validated SupportTicketSummary object, not raw text:
# SupportTicketSummary(
#     issue_category="billing",
#     urgency="high",
#     summary="User was double-charged and needs urgent resolution."
# )

This is the difference between "an AI feature that's a fun demo" and "an AI feature that
reliably feeds your database without crashing on a malformed response." Structured output
is, in practice, one of the highest-leverage things to get right early — almost every real
AI feature eventually needs the model's output to plug into something downstream:
a UI component, a database row, an API call to another system.

Chapter 8: Common Pitfalls When You're Starting Out

A few things that trip up almost everyone in their first few weeks of AI application
development:

Treating the system prompt as a suggestion, not a contract. Vague system prompts ("be helpful") produce inconsistent behavior. Specific, constrained system prompts produce reliable behavior. Be explicit about scope, tone, format, and what the model should refuse to do.
Skipping output validation. Even with structured output tooling, always validate what comes back before trusting it downstream — models can still fail to conform perfectly, especially with complex nested schemas.
Forgetting that "memory" isn't automatic. Without explicit memory handling, every API call is a blank slate. If your chatbot seems to have amnesia, it's because you're not re-sending prior conversation turns.
Over-engineering with agents too early. Agents are powerful but unpredictable and harder to debug than a fixed chain. Start with a simple, deterministic chain. Reach for agents only when the task genuinely requires dynamic decision-making.
Ignoring token costs and limits. Every provider charges per token and enforces context length limits. Long conversation histories, large retrieved documents, and verbose system prompts all add up fast — both in cost and in risk of hitting context limits.

Wrapping Up

If there's one mental model to walk away with, it's this: an LLM is a next-token predictor
wrapped behind a provider's API, and everything you build sits on top of that simple loop.
The real engineering work — the part that actually makes a product good — isn't in the
model itself. It's in how well you structure your prompts, how reliably you turn model
output into usable data, and how thoughtfully you chain steps together to solve an actual
user problem.

LangChain doesn't replace that thinking — it gives you a consistent vocabulary and toolkit
to express it, regardless of which provider's model happens to sit underneath. Learn the
six building blocks — models, prompts, chains, memory, indexes, agents — and you'll find
that almost every AI application you encounter, no matter how complex it looks from the
outside, is built from some combination of these same simple pieces.

The next step from here is hands-on: pick a tiny project — a document Q&A bot, a
structured data extractor from messy text, anything real — and build it with a prompt
template and structured output from the start. That's where this stuff actually clicks.

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 7 | Combining Observables — `forkJoin`, `combineLatest`, `zip` & More

Jack Pritom Soren — Sun, 21 Jun 2026 13:31:12 +0000

"Combining Observables — `forkJoin`, `combineLatest`, `zip` & More"

👋 Welcome to Chapter 7!

Real apps rarely get data from just one place. A product page might need:

The product details (from /api/products/5)
The user's wishlist (from /api/wishlist)
The store's discount config (from /api/config)

How do you handle multiple Observables at the same time?

That's what today's combination operators are for!

🍽️ The Restaurant Kitchen Analogy

Imagine a chef 👨‍🍳 preparing a 3-course meal:

forkJoin — "Start cooking all 3 dishes at the same time. Serve the full meal ONLY when ALL dishes are ready."
→ Wait for ALL to complete, then give you all results together

combineLatest — "Whenever ANY dish is updated, bring out the current status of all dishes."
→ Every time any Observable emits, give you the latest value from all

zip — "Match dish from kitchen 1 with dish from kitchen 2, one pair at a time."
→ Pairs values by position

Let's see each one in detail.

🍴 `forkJoin` — Wait for All, Then Done

forkJoin runs multiple Observables in parallel and waits until all of them complete. Then it emits all the results at once.

Like Promise.all() but for Observables!

Simple Example

import { forkJoin, of } from 'rxjs';
import { delay } from 'rxjs/operators';

forkJoin({
  users: of(['Alice', 'Bob']).pipe(delay(1000)),
  products: of(['Apple', 'Banana']).pipe(delay(500)),
  config: of({ theme: 'dark' }).pipe(delay(200))
}).subscribe(results => {
  console.log(results.users);    // ['Alice', 'Bob']
  console.log(results.products); // ['Apple', 'Banana']
  console.log(results.config);   // { theme: 'dark' }
});
// All three run in PARALLEL. Total wait time = 1000ms (the slowest)
// If it were sequential, total = 1700ms

Real Angular Example — Loading a Dashboard

// dashboard.component.ts
import { Component, OnInit } from '@angular/core';
import { forkJoin } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `
    <div *ngIf="!isLoading">
      <div class="stats-card">
        <h3>Total Users</h3>
        <p>{{ stats?.totalUsers }}</p>
      </div>
      <div class="stats-card">
        <h3>Orders Today</h3>
        <p>{{ stats?.ordersToday }}</p>
      </div>
      <div class="stats-card">
        <h3>Revenue</h3>
        <p>৳{{ stats?.revenue }}</p>
      </div>
      <div class="recent-orders">
        <h3>Recent Orders</h3>
        <div *ngFor="let order of recentOrders">
          {{ order.id }} — {{ order.status }}
        </div>
      </div>
    </div>

    <div *ngIf="isLoading">Loading dashboard... ⏳</div>
    <div *ngIf="error">{{ error }}</div>
  `
})
export class DashboardComponent implements OnInit {

  stats: any = null;
  recentOrders: any[] = [];
  isLoading = true;
  error = '';

  constructor(
    private statsService: StatsService,
    private orderService: OrderService
  ) {}

  ngOnInit(): void {
    // Load BOTH at the same time — wait for both to finish
    forkJoin({
      stats: this.statsService.getDashboardStats(),
      orders: this.orderService.getRecentOrders(5)
    }).subscribe({
      next: ({ stats, orders }) => {
        this.stats = stats;
        this.recentOrders = orders;
        this.isLoading = false;
      },
      error: (err) => {
        this.error = 'Failed to load dashboard data';
        this.isLoading = false;
      }
    });
  }
}

⚠️ Important: forkJoin only works with Observables that COMPLETE!

HttpClient calls complete after one response ✅
BehaviorSubject never completes ❌ (use combineLatest instead)

🔄 `combineLatest` — React to Any Change

combineLatest watches multiple Observables and every time any one of them emits, it gives you the latest values from ALL of them.

It's perfect for filter/search UIs where changing any filter should update the results.

Simple Example

import { combineLatest, BehaviorSubject } from 'rxjs';

const searchTerm$ = new BehaviorSubject<string>('');
const category$ = new BehaviorSubject<string>('all');
const priceMax$ = new BehaviorSubject<number>(1000);

combineLatest([searchTerm$, category$, priceMax$])
  .subscribe(([search, category, maxPrice]) => {
    console.log(`Search: ${search}, Category: ${category}, Max: ${maxPrice}`);
  });

// Output immediately: Search: , Category: all, Max: 1000

searchTerm$.next('phone');
// Output: Search: phone, Category: all, Max: 1000

category$.next('electronics');
// Output: Search: phone, Category: electronics, Max: 1000

priceMax$.next(500);
// Output: Search: phone, Category: electronics, Max: 500

Every time any filter changes, you get all three latest values!

Real Angular Example — Product Filter Page

// product-filter.component.ts
import { Component, OnInit } from '@angular/core';
import { FormControl } from '@angular/forms';
import { combineLatest, Observable } from 'rxjs';
import { map, startWith, debounceTime } from 'rxjs/operators';

@Component({
  selector: 'app-product-filter',
  template: `
    <div class="filters">
      <input [formControl]="searchControl" placeholder="Search...">

      <select [formControl]="categoryControl">
        <option value="all">All Categories</option>
        <option value="electronics">Electronics</option>
        <option value="clothing">Clothing</option>
        <option value="food">Food</option>
      </select>

      <label>Max Price: ৳{{ priceControl.value }}</label>
      <input type="range" [formControl]="priceControl" min="0" max="10000" step="100">
    </div>

    <p>Showing {{ (filteredProducts$ | async)?.length }} products</p>

    <div *ngFor="let product of filteredProducts$ | async" class="product-card">
      <h3>{{ product.name }}</h3>
      <span>৳{{ product.price }}</span>
      <span class="tag">{{ product.category }}</span>
    </div>
  `
})
export class ProductFilterComponent implements OnInit {

  searchControl = new FormControl('');
  categoryControl = new FormControl('all');
  priceControl = new FormControl(10000);

  allProducts: Product[] = [];
  filteredProducts$!: Observable<Product[]>;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    // First, load all products
    this.productService.getProducts().subscribe(products => {
      this.allProducts = products;
    });

    // Watch all three filters — update results whenever any changes
    this.filteredProducts$ = combineLatest([
      this.searchControl.valueChanges.pipe(startWith(''), debounceTime(300)),
      this.categoryControl.valueChanges.pipe(startWith('all')),
      this.priceControl.valueChanges.pipe(startWith(10000))
    ]).pipe(
      map(([search, category, maxPrice]) => {
        return this.allProducts.filter(product => {

          const matchesSearch = !search ||
            product.name.toLowerCase().includes(search.toLowerCase());

          const matchesCategory = category === 'all' ||
            product.category === category;

          const matchesPrice = product.price <= (maxPrice || 10000);

          return matchesSearch && matchesCategory && matchesPrice;
        });
      })
    );
  }
}

This is real production-grade code! The filter UI updates instantly as the user adjusts any control — no button needed!

🤝 `withLatestFrom` — Use the Latest Value Without Triggering

withLatestFrom is like combineLatest, but it only triggers when the first Observable emits — it just grabs the latest value from the others as a "snapshot".

import { withLatestFrom } from 'rxjs/operators';

// When a button is clicked, grab the current user and filter state
buttonClick$
  .pipe(
    withLatestFrom(currentUser$, activeFilters$)
  )
  .subscribe(([clickEvent, user, filters]) => {
    // Only triggered by clicks, but we have user and filters available
    this.logUserAction(user, filters, 'EXPORT');
  });

Real Example — Save Button with Form State

// When save is clicked, capture the CURRENT form values
this.saveButton.clicks$
  .pipe(
    withLatestFrom(this.form.valueChanges.pipe(startWith(this.form.value)))
  )
  .subscribe(([_, formValues]) => {
    this.save(formValues);
  });

🤐 `zip` — Pair by Position

zip waits for ALL Observables to emit one value, then combines them by position. Like a zipper — left tooth, right tooth, left tooth, right tooth...

import { zip, of } from 'rxjs';

const names$ = of('Alice', 'Bob', 'Charlie');
const scores$ = of(95, 87, 92);
const grades$ = of('A', 'B+', 'A-');

zip(names$, scores$, grades$).subscribe(([name, score, grade]) => {
  console.log(`${name}: ${score} (${grade})`);
});

// Output:
// Alice: 95 (A)
// Bob: 87 (B+)
// Charlie: 92 (A-)

zip is less commonly used in Angular, but handy when you need to pair corresponding items.

🏗️ Full Real-World Example — Product Detail Page

A product detail page often needs data from multiple APIs. Here's the complete pattern:

// product-detail.component.ts
import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { forkJoin, combineLatest, Observable, EMPTY } from 'rxjs';
import { switchMap, catchError, map } from 'rxjs/operators';

interface PageData {
  product: Product;
  reviews: Review[];
  isInWishlist: boolean;
  relatedProducts: Product[];
}

@Component({
  selector: 'app-product-detail',
  template: `
    <ng-container *ngIf="pageData$ | async as data">
      <div class="product-hero">
        <h1>{{ data.product.name }}</h1>
        <p>{{ data.product.description }}</p>
        <p class="price">৳{{ data.product.price }}</p>

        <button [class.active]="data.isInWishlist" (click)="toggleWishlist()">
          {{ data.isInWishlist ? '❤️ Wishlisted' : '🤍 Add to Wishlist' }}
        </button>
      </div>

      <section class="reviews">
        <h2>Reviews ({{ data.reviews.length }})</h2>
        <div *ngFor="let review of data.reviews">
          <strong>{{ review.author }}</strong>
          <span>⭐ {{ review.rating }}</span>
          <p>{{ review.comment }}</p>
        </div>
      </section>

      <section class="related">
        <h2>Related Products</h2>
        <div *ngFor="let related of data.relatedProducts" class="mini-card">
          {{ related.name }} — ৳{{ related.price }}
        </div>
      </section>
    </ng-container>

    <div *ngIf="isLoading">Loading... ⏳</div>
    <div *ngIf="errorMessage">{{ errorMessage }}</div>
  `
})
export class ProductDetailComponent implements OnInit {

  pageData$!: Observable<PageData>;
  isLoading = true;
  errorMessage = '';

  constructor(
    private route: ActivatedRoute,
    private productService: ProductService,
    private reviewService: ReviewService,
    private wishlistService: WishlistService
  ) {}

  ngOnInit(): void {

    this.pageData$ = this.route.params.pipe(
      switchMap(params => {
        const id = params['id'];

        // Load ALL data for this product in parallel
        return forkJoin({
          product: this.productService.getProduct(id),
          reviews: this.reviewService.getReviews(id),
          isInWishlist: this.wishlistService.isInWishlist(id),
          relatedProducts: this.productService.getRelated(id)
        });
      }),
      catchError(err => {
        this.errorMessage = 'Failed to load product details';
        this.isLoading = false;
        return EMPTY;
      })
    );

    // Track loading state
    this.pageData$.subscribe(() => {
      this.isLoading = false;
    });
  }

  toggleWishlist(): void {
    // ... toggle logic
  }
}

Everything loads in parallel, the route handles navigation, and errors are caught gracefully — all in one clean stream!

🧠 Choosing the Right Combination Operator

forkJoin — "Load everything once, wait for all to finish, give me all results"
Best for: page initialization, loading multiple API resources at once

combineLatest — "Every time ANYTHING changes, give me all the latest values"
Best for: filter/search UIs, forms with live preview, dashboards with real-time updates

withLatestFrom — "When THIS happens, also give me the latest value of THAT"
Best for: button clicks that need current state, actions that depend on form values

zip — "Match item 1 with item 1, item 2 with item 2..."
Best for: combining two arrays where order corresponds

🧠 Chapter 7 Summary — What You Learned

forkJoin runs multiple Observables in parallel and emits all results when ALL complete — like Promise.all()
combineLatest emits whenever any Observable emits, always giving you the latest from all — perfect for filter UIs
withLatestFrom only triggers from one source, but snapshots the latest value from others
zip pairs values by position from multiple Observables
These operators are essential for building real-world pages that need data from multiple sources

📚 Coming Up in Chapter 8...

One of the most powerful and real-world RxJS patterns in Angular:

Angular Forms + RxJS — how to build reactive forms with live validation, dependent fields, and dynamic behavior using valueChanges, statusChanges, and the operators we've learned!

See you in Chapter 8! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 7 of 10

Follow me on : Github Linkedin Threads Youtube Channel

The JavaScript Event Loop: Why Your Code Doesn't Do What You Think It Does

Jack Pritom Soren — Fri, 15 May 2026 13:00:03 +0000

JavaScript is single-threaded. One thread. One call stack. One thing at a time.

And yet — you've written code that fetches data from an API while animating a loading spinner while handling button clicks while running a countdown timer. How? How does one thread do all of that without freezing?

The answer is the event loop — arguably the most misunderstood piece of the JavaScript runtime. Most developers use it every day without ever truly seeing it. They write setTimeout, Promise.then(), async/await, and fetch() like they're magic spells, and they mostly work — until they don't.

Until you've hit a bug where a setTimeout(..., 0) fires after something it should have fired before. Until a Promise resolves in an order that makes no logical sense to you. Until your UI freezes solid because a loop ran too long. That's when you realize: you've been flying blind.

Understanding the event loop isn't just academic. It's the difference between writing JavaScript that works and writing JavaScript that you understand. It explains why async/await is not the same as threads, why microtasks beat macrotasks, and why your beautiful Promise chain sometimes feels like it has a mind of its own.

This article is the deep dive nobody wrote clearly enough. By the end, you'll be able to look at any piece of async JavaScript and trace — in your head, step by step — exactly what order things will execute and why.

What We'll Cover

The Single-Threaded Reality
The Call Stack — JavaScript's Working Memory
The Web APIs Layer — Where Async Work Actually Happens
The Callback Queue (Macrotask Queue)
The Microtask Queue — The Queue That Jumps the Line
The Event Loop — The Conductor Tying It All Together
setTimeout and setInterval — What They Actually Promise
Promises and the Microtask Queue
async/await — Syntactic Sugar with Real Consequences
Real-World Execution Order Puzzles (With Solutions)
Pitfalls That Will Bite You in Production
Conclusion — The Mental Model You'll Keep Forever

1. The Single-Threaded Reality

Let's start with what "single-threaded" actually means, because it's more nuanced than it sounds.

A thread is a sequence of instructions a CPU can execute. Some languages — Java, Go, C++ — are multi-threaded, meaning they can genuinely run multiple instruction sequences simultaneously on different CPU cores. They share memory, they can race each other, and you need mutexes and semaphores and all sorts of painful synchronization primitives to keep them from stepping on each other.

JavaScript deliberately chose not to do that. One thread. No shared memory races. No deadlocks. No mutexes.

But here's the thing people miss: JavaScript is single-threaded, but the browser (or Node.js) is not. The runtime environment — Chrome, Firefox, Node — is heavily multi-threaded. It has threads for network I/O, file I/O, timers, rendering, garbage collection, and more. JavaScript itself runs on one thread, but it delegates slow work to those other threads.

The event loop is the mechanism by which results from those other threads get handed back to your JavaScript code, safely, one at a time.

2. The Call Stack — JavaScript's Working Memory

The call stack is where JavaScript tracks what it's currently executing. It's a stack data structure — last in, first out — and every time you call a function, a new stack frame gets pushed on top. When the function returns, that frame gets popped off.

function greet(name) {
    return `Hello, ${name}!`;         // 3. This executes, returns
}

function main() {
    const message = greet("Fatima");  // 2. greet() is pushed onto stack
    console.log(message);             // 4. console.log is pushed, executes, pops
}

main();                               // 1. main() is pushed onto stack

Execution trace:

[] → [main] → [main, greet] → [main] → [main, console.log] → [main] → []

The call stack is synchronous and blocking. If you put a while(true) loop in there, the stack never clears. Nothing else runs. Your UI freezes. The browser tab hangs.

This is why long-running synchronous operations are the enemy. They hold the stack hostage.

3. The Web APIs Layer — Where Async Work Actually Happens

When you call fetch(), setTimeout(), addEventListener(), or fs.readFile() — you are not running JavaScript. You're calling into the Web APIs layer (in the browser) or the Node.js C++ APIs layer.

Think of it like handing off a task to a dedicated department:

"Go make this HTTP request. Come back when you have a response."
"Set a timer for 500ms. Come back when it fires."
"Watch this DOM element for a click. Come back when it happens."

JavaScript doesn't wait. It just hands off the task, registers a callback, and moves on. The API does the work — off the main thread, in the background — and when it's done, it puts your callback in a queue.

console.log("1 — Starting");

// This call goes to the Timer Web API.
// JavaScript does NOT wait here. It just registers the callback and moves on.
setTimeout(() => {
    console.log("3 — Timer fired");
}, 1000);

console.log("2 — Already past the setTimeout");

// Output:
// 1 — Starting
// 2 — Already past the setTimeout
// (1 second later...)
// 3 — Timer fired

JavaScript handed the timer to the browser, said "call me back in 1000ms," and kept running. That's non-blocking I/O in a nutshell.

4. The Callback Queue (Macrotask Queue)

When an async operation completes — a timer fires, a network response arrives, a click event triggers — the callback associated with it gets placed in the callback queue (also called the macrotask queue or task queue).

This queue holds tasks waiting for their turn to run. They can't jump onto the call stack directly. They have to wait.

Common sources of macrotasks:

setTimeout callbacks
setInterval callbacks
I/O callbacks (file reads, network responses in Node.js)
UI event handlers (click, keydown, scroll)
postMessage callbacks
setImmediate (Node.js only)

The queue is processed one task at a time. Each task runs to completion — no interruption. If a task takes 500ms, the browser is locked for 500ms. This is why you'll sometimes see the browser devtools warn about "long tasks."

5. The Microtask Queue — The Queue That Jumps the Line

Here's where most developers' mental models break down.

There are two queues, not one. The second is the microtask queue, and it has priority over the callback queue. Every single time.

Sources of microtasks:

Promise.then() / Promise.catch() / Promise.finally() callbacks
queueMicrotask()
MutationObserver callbacks
await (under the hood, it's a promise)

The rule is this: after every task completes (or after the initial script finishes), the entire microtask queue is drained before the next macrotask runs.

Not one microtask. All of them. And if a microtask schedules another microtask, that one runs too, before any macrotask.

console.log("1 — Script start");

setTimeout(() => console.log("5 — setTimeout"), 0);  // Macrotask

Promise.resolve()
    .then(() => console.log("3 — Promise 1"))         // Microtask
    .then(() => console.log("4 — Promise 2"));        // Microtask (scheduled by microtask)

console.log("2 — Script end");

// Output:
// 1 — Script start
// 2 — Script end
// 3 — Promise 1
// 4 — Promise 2
// 5 — setTimeout

Even though setTimeout was registered before the Promise chain, it fires after both promise callbacks. The entire microtask queue empties first.

6. The Event Loop — The Conductor Tying It All Together

The event loop is the algorithm that orchestrates all of this. Here it is, in pseudocode:

while (true) {
    // 1. Run the current task (or the initial script)
    executeCurrentTask();

    // 2. Drain the entire microtask queue
    while (microtaskQueue.isNotEmpty()) {
        microtaskQueue.dequeue().execute();
        // Note: if this microtask adds more microtasks, those run too
    }

    // 3. Maybe render (browser decides, typically ~60fps)
    if (renderingNeeded) {
        render();
    }

    // 4. Pick the next macrotask from the callback queue
    if (callbackQueue.isNotEmpty()) {
        currentTask = callbackQueue.dequeue();
    }
}

The loop is always watching. When the call stack is empty and there are tasks waiting, it picks the next one and runs it. But it always drains microtasks first.

Here's the full picture as a diagram:

┌─────────────────────────────────────────────────┐
│                 Your JS Code                    │
│                  Call Stack                     │
└────────────────────┬────────────────────────────┘
                     │
           calls Web APIs / Node APIs
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│            Web APIs / C++ APIs                  │
│   (setTimeout, fetch, fs.readFile, events...)   │
└──────┬──────────────────────┬───────────────────┘
       │                      │
       ▼                      ▼
┌─────────────┐      ┌──────────────────┐
│  Microtask  │      │  Callback Queue  │
│    Queue    │      │  (Macrotask Q.)  │
│  (Promises) │      │  (setTimeout,    │
│             │      │   I/O, events)   │
└──────┬──────┘      └────────┬─────────┘
       │                      │
       └──────────┬───────────┘
                  │
                  ▼
           ┌──────────────┐
           │  Event Loop  │ ◄── "Is the stack empty?
           │              │      Drain microtasks.
           └──────────────┘      Then run next macrotask."

7. `setTimeout` and `setInterval` — What They Actually Promise

setTimeout(fn, delay) does not guarantee your callback runs after exactly delay milliseconds. It guarantees the callback will be added to the macrotask queue no sooner than delay milliseconds from now.

If the call stack is busy, the callback waits — no matter how long.

const start = Date.now();

// This timer should fire after 100ms.
setTimeout(() => {
    // In reality, this will log something much larger than 100.
    console.log(`Fired after ${Date.now() - start}ms`);
}, 100);

// This synchronous loop blocks the call stack for ~500ms.
// The setTimeout callback is in the queue, but it can't run yet.
const blockUntil = Date.now() + 500;
while (Date.now() < blockUntil) {
    // spinning — this is exactly the kind of code that freezes UIs
}

// Output: something like "Fired after 502ms" — not 100ms

setTimeout(..., 0) is often used as a trick to defer code to the next iteration of the event loop — but it's still a macrotask, so it yields to all pending microtasks first.

8. Promises and the Microtask Queue

Every .then(), .catch(), and .finally() callback is a microtask. This is baked into the Promise specification — not a browser decision.

console.log("start");

const p = new Promise((resolve) => {
    // The executor function runs SYNCHRONOUSLY, right now.
    console.log("inside Promise constructor");
    resolve("done");
});

p.then((value) => {
    // This runs as a MICROTASK — after the current synchronous code finishes.
    console.log("then:", value);
});

console.log("end");

// Output:
// start
// inside Promise constructor
// end
// then: done

The Promise constructor runs synchronously. The .then() callback does not — it queues as a microtask and runs after the current call stack empties.

This surprises a lot of developers. They expect the .then() to run right after resolve(). It doesn't. It politely waits its turn.

9. `async/await` — Syntactic Sugar with Real Consequences

async/await is beautiful syntax. But it's crucial to understand what it compiles to, because the semantics are the same as Promises — just dressed up.

// This async function...
async function fetchUser(id) {
    const response = await fetch(`/api/users/${id}`);
    const user = await response.json();
    return user;
}

// ...is roughly equivalent to this Promise chain:
function fetchUser(id) {
    return fetch(`/api/users/${id}`)
        .then(response => response.json())
        .then(user => user);
}

Every await is a suspension point. When you await something, the async function pauses and hands control back to the caller. The code after the await is scheduled as a microtask to run when the awaited Promise resolves.

async function main() {
    console.log("1 — before await");

    await Promise.resolve();  // Suspends here. Resumes as microtask.

    console.log("3 — after await");  // Runs as microtask
}

main();
console.log("2 — after calling main()");

// Output:
// 1 — before await
// 2 — after calling main()
// 3 — after await

When main() hits the await, it suspends. JavaScript keeps running synchronously past the main() call and logs "2". Then the microtask runs and logs "3".

async/await does not make code run on a different thread. It's still single-threaded. It just makes asynchronous code look synchronous while still yielding the call stack between operations.

10. Real-World Execution Order Puzzles

Let's put it all together. Work through these before peeking at the answers.

Puzzle 1

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => {
    console.log("C");
    setTimeout(() => console.log("D"), 0);
});

console.log("E");

Answer

A
E
C
B
D

Why:

A — synchronous
setTimeout B → macrotask queue
Promise → microtask queue
E — synchronous
Call stack empty → drain microtasks: C logs, setTimeout D → macrotask queue
No more microtasks → run next macrotask: B
No more microtasks → run next macrotask: D

Puzzle 2

async function alpha() {
    console.log("alpha 1");
    await null;
    console.log("alpha 2");
}

async function beta() {
    console.log("beta 1");
    await null;
    console.log("beta 2");
}

console.log("start");
alpha();
beta();
console.log("end");

Answer

start
alpha 1
beta 1
end
alpha 2
beta 2

Why:

start — sync
alpha() runs: logs alpha 1, hits await, suspends → schedules microtask
beta() runs: logs beta 1, hits await, suspends → schedules microtask
end — sync
Call stack empty → drain microtasks: alpha 2, then beta 2

11. Pitfalls That Will Bite You in Production

Starving the render with too many microtasks

Because microtasks all run before the browser gets a chance to render, an infinite microtask loop will lock up the UI just as badly as a synchronous loop — possibly worse, because it looks like async code.

// ❌ Don't do this — infinite microtask loop, browser never renders
function infiniteMicrotasks() {
    Promise.resolve().then(infiniteMicrotasks);
}
infiniteMicrotasks();

// ✅ If you need to yield to rendering, use setTimeout or requestAnimationFrame
function yieldToRender(fn) {
    requestAnimationFrame(fn);  // Runs after the next render frame
}

Unhandled Promise rejections are silent killers

// ❌ This rejection is unhandled. In older Node versions it silently fails.
//    In modern Node, it crashes the process.
async function riskyOperation() {
    throw new Error("Something went wrong");
}

riskyOperation(); // Missing await AND missing .catch()

// ✅ Always handle rejections
riskyOperation().catch(err => console.error("Caught:", err));

// ✅ Or use try/catch with await
try {
    await riskyOperation();
} catch (err) {
    console.error("Caught:", err);
}

`await` inside loops — sequential vs parallel

const userIds = [1, 2, 3, 4, 5];

// ❌ Sequential — each fetch waits for the previous to finish.
//    Total time: sum of all request times. Slow.
async function fetchSequential(ids) {
    const results = [];
    for (const id of ids) {
        const user = await fetchUser(id);  // Waits here before next iteration
        results.push(user);
    }
    return results;
}

// ✅ Parallel — all requests fire at once.
//    Total time: slowest single request. Fast.
async function fetchParallel(ids) {
    const promises = ids.map(id => fetchUser(id));  // Fire all, don't await yet
    return await Promise.all(promises);              // Wait for all to complete
}

The `forEach` async trap

const data = [1, 2, 3];

// ❌ forEach doesn't await async callbacks. It fires them all and moves on.
//    "Done" prints before any of the async work finishes.
data.forEach(async (item) => {
    await processItem(item);
});
console.log("Done");  // Prints immediately — not actually done

// ✅ Use for...of when you need to await inside a loop
for (const item of data) {
    await processItem(item);
}
console.log("Done");  // Now actually done

12. Conclusion — The Mental Model You'll Keep Forever

Here's the mental model, distilled:

JavaScript has one thread, one call stack. It can only do one thing at a time. Async operations — timers, network calls, I/O — get delegated to the browser/Node runtime, which handles them off the main thread. When they complete, callbacks get queued.

Two queues exist. The microtask queue (Promises, await) and the macrotask queue (setTimeout, I/O, events). After every task — including the initial script — the entire microtask queue drains before the next macrotask runs.

async/await is Promises in a costume. Beautiful, readable, but the same underlying semantics. Every await suspends the function and schedules the rest as a microtask.

Once this model clicks, async JavaScript stops being magic. You can trace any execution order in your head. You know why setTimeout(..., 0) doesn't always mean "immediately." You know why a Promise resolves after your synchronous code. You know why that forEach with await inside was never actually doing what you thought.

The event loop is the heartbeat of JavaScript. Understanding it doesn't just make you better at debugging async bugs — it makes you better at writing async code in the first place. You start structuring things around how JavaScript actually works, rather than how you wish it worked.

Go write something async. Then trace through it mentally. If you get the order right — you've got it.

Further reading: MDN's Concurrency model and the event loop, Jake Archibald's classic talk "In The Loop" (JSConf Asia), and the WHATWG HTML spec on the event loop processing model if you really want to go deep.

RxJS in Angular — Chapter 6 | Error Handling — Building Apps That Don't Break

Jack Pritom Soren — Fri, 10 Apr 2026 05:24:20 +0000

"Error Handling — Building Apps That Don't Break"

👋 Welcome to Chapter 6!

You've built beautiful features using Observables. But what happens when the internet goes down? What if the API server crashes? What if the user has no signal?

In the real world, things go wrong. All the time.

This chapter teaches you how to handle errors gracefully — so your app stays alive even when everything around it falls apart.

💥 What Happens When an Observable Errors?

When an Observable encounters an error, it:

Emits the error to the error handler in subscribe
Stops completely — no more values, ever

this.http.get('/api/users').subscribe({
  next: (users) => { this.users = users; },
  error: (err) => {
    // ❌ Error happened here
    // The Observable is now dead. It will never emit again.
    console.error(err);
  },
  complete: () => {
    // This will NOT be called if there was an error
  }
});

The problem? If you handle errors only in subscribe, you can't retry, you can't provide fallback data, and you can't do complex error logic.

That's where catchError and retry come in.

🥅 `catchError` — Catch it Before it Reaches subscribe

catchError goes inside pipe() and intercepts errors before they reach subscribe. It gives you a chance to:

Provide fallback data so the app keeps working
Rethrow the error if you want subscribe to handle it
Log the error and recover

import { catchError } from 'rxjs/operators';
import { of, EMPTY, throwError } from 'rxjs';

this.http.get<User[]>('/api/users')
  .pipe(
    catchError(error => {
      console.error('API failed:', error);

      // Option 1: Return fallback data — app keeps working
      return of([]);  // Return empty array

      // Option 2: Return EMPTY — complete without any value
      // return EMPTY;

      // Option 3: Re-throw — let subscribe handle it
      // return throwError(() => error);
    })
  )
  .subscribe(users => {
    // If API failed, users = [] (empty array from fallback)
    // App still works!
    this.users = users;
  });

🏗️ Real-World Pattern — Service with Error Handling

user.service.ts

import { Injectable } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError, tap } from 'rxjs/operators';

@Injectable({ providedIn: 'root' })
export class UserService {

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    return this.http.get<User[]>('/api/users')
      .pipe(
        catchError(this.handleError)
      );
  }

  getUserById(id: number): Observable<User> {
    return this.http.get<User>(`/api/users/${id}`)
      .pipe(
        catchError(this.handleError)
      );
  }

  // Centralized error handler — reused across all methods
  private handleError(error: HttpErrorResponse): Observable<never> {

    let userFriendlyMessage = 'Something went wrong. Please try again.';

    if (error.status === 0) {
      // Network error (no internet, server unreachable)
      userFriendlyMessage = 'No internet connection. Please check your network.';
    } else if (error.status === 404) {
      userFriendlyMessage = 'The requested data was not found.';
    } else if (error.status === 401) {
      userFriendlyMessage = 'You are not authorized. Please log in.';
    } else if (error.status === 403) {
      userFriendlyMessage = 'Access denied. You do not have permission.';
    } else if (error.status === 500) {
      userFriendlyMessage = 'Server error. Please try again later.';
    }

    // Log technical details for developers
    console.error(`HTTP Error ${error.status}:`, error.message);

    // Re-throw with user-friendly message
    return throwError(() => new Error(userFriendlyMessage));
  }
}

users.component.ts

@Component({
  template: `
    <!-- Loading state -->
    <div *ngIf="isLoading" class="loading">
      <div class="spinner"></div>
      Loading users...
    </div>

    <!-- Error state -->
    <div *ngIf="errorMessage" class="error-card">
      <p>⚠️ {{ errorMessage }}</p>
      <button (click)="loadUsers()">Try Again 🔄</button>
    </div>

    <!-- Success state -->
    <div *ngIf="!isLoading && !errorMessage">
      <div *ngFor="let user of users" class="user-card">
        {{ user.name }}
      </div>
    </div>
  `
})
export class UsersComponent implements OnInit {

  users: User[] = [];
  isLoading = false;
  errorMessage = '';

  constructor(private userService: UserService) {}

  ngOnInit(): void {
    this.loadUsers();
  }

  loadUsers(): void {
    this.isLoading = true;
    this.errorMessage = '';

    this.userService.getUsers().subscribe({
      next: (users) => {
        this.users = users;
        this.isLoading = false;
      },
      error: (err) => {
        this.errorMessage = err.message;
        this.isLoading = false;
      }
    });
  }
}

🔄 `retry()` — Automatically Try Again

Sometimes errors are temporary — a brief network hiccup, a server that's momentarily busy. retry() tells the Observable to try again automatically.

import { retry } from 'rxjs/operators';

this.http.get('/api/data')
  .pipe(
    retry(3),       // Try up to 3 times before giving up
    catchError(err => {
      // Only reaches here if all 3 retries fail
      return of({ fallback: true, data: [] });
    })
  )
  .subscribe(data => this.data = data);

Timeline:

Attempt 1 → ❌ fails
Attempt 2 → ❌ fails  
Attempt 3 → ❌ fails
→ catchError takes over → returns fallback data

⏱️ `retryWhen` / `retry` with Delay — Smart Retrying

Retrying immediately might not help. Often you want to wait a bit before retrying. In modern RxJS, you can pass a config to retry:

import { retry, catchError } from 'rxjs/operators';
import { timer } from 'rxjs';

this.http.get('/api/data')
  .pipe(
    retry({
      count: 3,          // Max 3 retries
      delay: 2000        // Wait 2 seconds between each retry
    }),
    catchError(err => {
      console.error('Failed after 3 retries:', err);
      return of([]);
    })
  )
  .subscribe(data => this.data = data);

Exponential Backoff (Advanced) — Wait longer each time

import { retry } from 'rxjs/operators';
import { timer } from 'rxjs';

this.http.get('/api/critical-data')
  .pipe(
    retry({
      count: 4,
      delay: (error, retryCount) => {
        // Wait 1s, then 2s, then 4s, then 8s (exponential)
        const waitMs = Math.pow(2, retryCount) * 1000;
        console.log(`Retry ${retryCount} in ${waitMs}ms`);
        return timer(waitMs);
      }
    }),
    catchError(err => of({ error: true, message: err.message }))
  )
  .subscribe(data => this.data = data);

🔁 `finalize()` — Always Runs, Error or Not

finalize() runs when an Observable completes — whether successfully or with an error. It's like finally in try/catch.

Perfect for: hiding loading spinners

import { finalize } from 'rxjs/operators';

this.isLoading = true;

this.http.get('/api/data')
  .pipe(
    catchError(err => {
      this.error = err.message;
      return EMPTY;
    }),
    finalize(() => {
      // Always runs — success or failure!
      this.isLoading = false;
      console.log('Request complete (success or error)');
    })
  )
  .subscribe(data => this.data = data);

No more duplicating this.isLoading = false in both next and error handlers! 🎉

🌐 Global HTTP Error Handling with Interceptors

In a real app, you don't want to handle auth errors (401) in every single component. Use an HTTP Interceptor to handle errors globally:

auth.interceptor.ts

import { Injectable } from '@angular/core';
import {
  HttpRequest,
  HttpHandler,
  HttpEvent,
  HttpInterceptor,
  HttpErrorResponse
} from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
import { Router } from '@angular/router';
import { AuthService } from './auth.service';

@Injectable()
export class AuthInterceptor implements HttpInterceptor {

  constructor(private router: Router, private authService: AuthService) {}

  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {

    // Add auth token to every request
    const token = localStorage.getItem('token');
    if (token) {
      request = request.clone({
        setHeaders: { Authorization: `Bearer ${token}` }
      });
    }

    return next.handle(request).pipe(
      catchError((error: HttpErrorResponse) => {

        if (error.status === 401) {
          // Token expired — log out and redirect to login
          this.authService.logout();
          this.router.navigate(['/login']);
        }

        if (error.status === 403) {
          // No permission — redirect to forbidden page
          this.router.navigate(['/forbidden']);
        }

        if (error.status >= 500) {
          // Server error — show a global toast notification
          this.notificationService.showError('Server error. Please try again later.');
        }

        return throwError(() => error);
      })
    );
  }
}

Register it in app.module.ts

@NgModule({
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: AuthInterceptor,
      multi: true
    }
  ]
})
export class AppModule {}

Now ALL HTTP errors in your entire app are handled in one place! 🎯

🎨 Real-World Complete Example — Product Page with Full Error Handling

import { Component, OnInit } from '@angular/core';
import { Observable, of } from 'rxjs';
import { catchError, retry, finalize, tap } from 'rxjs/operators';

interface PageState {
  products: Product[];
  isLoading: boolean;
  error: string | null;
}

@Component({
  selector: 'app-product-page',
  template: `
    <ng-container *ngIf="state$ | async as state">

      <!-- Loading -->
      <div *ngIf="state.isLoading" class="loading-container">
        <div class="spinner"></div>
        <p>Loading products...</p>
      </div>

      <!-- Error with retry button -->
      <div *ngIf="state.error && !state.isLoading" class="error-container">
        <h3>😕 Oops! Something went wrong</h3>
        <p>{{ state.error }}</p>
        <button (click)="reload()">🔄 Try Again</button>
      </div>

      <!-- Empty state -->
      <div *ngIf="!state.isLoading && !state.error && state.products.length === 0">
        <p>No products found.</p>
      </div>

      <!-- Product list -->
      <div *ngIf="!state.isLoading && !state.error && state.products.length > 0">
        <div *ngFor="let product of state.products" class="product-card">
          <h3>{{ product.name }}</h3>
          <p>৳{{ product.price }}</p>
        </div>
      </div>

    </ng-container>
  `
})
export class ProductPageComponent implements OnInit {

  state$!: Observable<PageState>;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.load();
  }

  reload(): void {
    this.load();
  }

  private load(): void {
    // Start with loading state
    const initialState: PageState = {
      products: [],
      isLoading: true,
      error: null
    };

    this.state$ = this.productService.getProducts()
      .pipe(
        retry(2),   // Try 2 more times on failure
        tap(products => {
          // Could log analytics here
          console.log(`Loaded ${products.length} products`);
        }),
        map(products => ({
          products,
          isLoading: false,
          error: null
        } as PageState)),
        catchError(err => of({
          products: [],
          isLoading: false,
          error: err.message || 'Failed to load products'
        } as PageState)),
        startWith(initialState)
      );
  }
}

This component handles every possible state: loading, error, empty, and success — all through a single Observable stream! 🏆

🧠 Chapter 6 Summary — What You Learned

When an Observable errors, it stops permanently — no more values
catchError() intercepts errors in the pipe and lets you provide fallback data or rethrow
retry(n) automatically retries the Observable up to N times before giving up
Use retry with a delay config for production-grade retry logic with exponential backoff
finalize() always runs whether the Observable succeeded or failed — perfect for hiding loading spinners
Use HTTP Interceptors to handle common errors (401, 500) globally for the whole app
Pattern: retry → catchError → finalize — this chain covers almost every real-world case

📚 Coming Up in Chapter 7...

We've handled errors. Now let's talk about combining multiple Observables — what if you need data from TWO different APIs at the same time?

Chapter 7 covers forkJoin, combineLatest, zip, and withLatestFrom — the combination operators!

See you in Chapter 7! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 6 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 5 | Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio

Jack Pritom Soren — Sun, 05 Apr 2026 04:15:45 +0000

"Subject, BehaviorSubject & ReplaySubject — The Two-Way Radio"

👋 Welcome to Chapter 5!

So far, everything we've done has been one-directional: an Observable produces data and you subscribe to receive it.

But what if YOU want to push data into a stream? What if you need to broadcast data to multiple components — like a shared shopping cart?

Enter: Subject 🎙️

📻 The Two-Way Radio Analogy

A regular Observable is like a radio broadcast station:

The station sends signals
You tune in (subscribe) to receive
You can't talk back to the station

A Subject is like a two-way radio:

You can SEND data into it
AND you can RECEIVE data from it
Multiple people can listen to the same channel

This makes Subject perfect for sharing data between components and event broadcasting.

🔴 What is a Subject?

A Subject is both an Observable AND an Observer at the same time.

As an Observable — you can subscribe to it
As an Observer — you can push values into it using .next()

import { Subject } from 'rxjs';

// Create a Subject
const mySubject = new Subject<string>();

// Subscribe to it (like a regular Observable)
mySubject.subscribe(value => console.log('Subscriber A got:', value));
mySubject.subscribe(value => console.log('Subscriber B got:', value));

// Push values INTO it (this is the special part!)
mySubject.next('Hello!');
mySubject.next('How are you?');

// Output:
// Subscriber A got: Hello!
// Subscriber B got: Hello!
// Subscriber A got: How are you?
// Subscriber B got: How are you?

Both subscribers got both values! This is called multicasting — one source, many listeners.

⚠️ Subject's Big Limitation

A regular Subject only delivers values to subscribers that are currently listening.

If you subscribe AFTER a value was emitted, you missed it.

const subject = new Subject<number>();

subject.next(1);  // Emitted before anyone subscribed!
subject.next(2);  // Also emitted before anyone subscribed!

// Subscribe now — too late for 1 and 2
subject.subscribe(v => console.log('Got:', v));

subject.next(3);  // ✅ This one gets received

// Output: Got: 3
// 1 and 2 are gone forever

This is like tuning into a radio broadcast after a song already played. You missed it.

That's why we have BehaviorSubject and ReplaySubject.

🎯 BehaviorSubject — Remembers the Last Value

BehaviorSubject always remembers its latest value and gives it immediately to any new subscriber.

Think of it like a whiteboard 📋 — it always shows the most recent thing written on it, even if you just walked into the room.

Rules of BehaviorSubject:

Must be initialized with a starting value
Always has a current value (accessible via .value)
New subscribers get the current value immediately upon subscribing
Emits new values to all current subscribers

import { BehaviorSubject } from 'rxjs';

// Must provide an initial value
const userStatus = new BehaviorSubject<string>('offline');

console.log('Current value:', userStatus.value); // 'offline'

// Subscribe now
userStatus.subscribe(status => console.log('Subscriber 1:', status));
// Output immediately: Subscriber 1: offline (gets current value!)

// Update the value
userStatus.next('online');
// Output: Subscriber 1: online

// New subscriber AFTER 'online' was emitted
userStatus.subscribe(status => console.log('Subscriber 2:', status));
// Output immediately: Subscriber 2: online (gets latest value, not 'offline'!)

🛒 Real-World Example — Shopping Cart Service

BehaviorSubject is PERFECT for shared state like a shopping cart:

cart.service.ts

import { Injectable } from '@angular/core';
import { BehaviorSubject, Observable } from 'rxjs';
import { map } from 'rxjs/operators';

export interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

@Injectable({
  providedIn: 'root'
})
export class CartService {

  // BehaviorSubject: starts with empty array
  // Private so only this service can push values
  private cartItemsSubject = new BehaviorSubject<CartItem[]>([]);

  // Public Observable: components can SUBSCRIBE but NOT push values
  // This is the security pattern — expose Observable, not Subject
  cartItems$ = this.cartItemsSubject.asObservable();

  // Derived Observables — automatically calculated from cartItems$
  cartCount$ = this.cartItems$.pipe(
    map(items => items.reduce((total, item) => total + item.quantity, 0))
  );

  cartTotal$ = this.cartItems$.pipe(
    map(items => items.reduce((total, item) => total + (item.price * item.quantity), 0))
  );

  // Add item to cart
  addItem(newItem: CartItem): void {
    const currentItems = this.cartItemsSubject.value; // Get current cart

    const existingItem = currentItems.find(item => item.id === newItem.id);

    if (existingItem) {
      // Item already in cart — increase quantity
      const updated = currentItems.map(item =>
        item.id === newItem.id
          ? { ...item, quantity: item.quantity + 1 }
          : item
      );
      this.cartItemsSubject.next(updated); // Push new value!
    } else {
      // New item — add to cart
      this.cartItemsSubject.next([...currentItems, newItem]);
    }
  }

  // Remove item from cart
  removeItem(itemId: number): void {
    const updated = this.cartItemsSubject.value
      .filter(item => item.id !== itemId);
    this.cartItemsSubject.next(updated);
  }

  // Clear cart
  clearCart(): void {
    this.cartItemsSubject.next([]);
  }
}

cart-icon.component.ts (in the header)

@Component({
  selector: 'app-cart-icon',
  template: `
    <div class="cart-icon">
      🛒
      <span class="badge" *ngIf="(cartService.cartCount$ | async) as count">
        {{ count }}
      </span>
    </div>
  `
})
export class CartIconComponent {
  constructor(public cartService: CartService) {}
  // No ngOnDestroy needed — async pipe handles it!
}

cart-total.component.ts (in the checkout area)

@Component({
  selector: 'app-cart-total',
  template: `
    <div class="cart-summary">
      <p>Items: {{ cartService.cartCount$ | async }}</p>
      <p class="total">Total: ৳{{ cartService.cartTotal$ | async }}</p>
      <button (click)="cartService.clearCart()">Clear Cart 🗑️</button>
    </div>
  `
})
export class CartTotalComponent {
  constructor(public cartService: CartService) {}
}

product-card.component.ts (on product pages)

@Component({
  selector: 'app-product-card',
  template: `
    <div class="card">
      <h3>{{ product.name }}</h3>
      <p>৳{{ product.price }}</p>
      <button (click)="addToCart()">Add to Cart 🛒</button>
    </div>
  `
})
export class ProductCardComponent {
  @Input() product!: CartItem;

  constructor(private cartService: CartService) {}

  addToCart(): void {
    this.cartService.addItem(this.product);
    // The cart icon in the header updates AUTOMATICALLY!
    // The cart total updates AUTOMATICALLY!
    // BehaviorSubject broadcasts to ALL subscribers!
  }
}

When a user adds a product, the cart icon in the header and the total in the checkout area both update instantly — without any EventEmitter, @Input/@Output, or complex communication! 🎉

🔄 ReplaySubject — Remembers Multiple Past Values

ReplaySubject is like a DVR recording 📼 — it saves the last N values and plays them back to any new subscriber.

import { ReplaySubject } from 'rxjs';

// Remember the last 3 values
const replay = new ReplaySubject<number>(3);

replay.next(1);
replay.next(2);
replay.next(3);
replay.next(4);
replay.next(5);

// Subscribe now — gets the last 3 values replayed immediately
replay.subscribe(v => console.log('Got:', v));

// Output:
// Got: 3
// Got: 4
// Got: 5
// (Values 1 and 2 are gone, but 3, 4, 5 are replayed)

Real Use Case — Message History / Notifications

@Injectable({ providedIn: 'root' })
export class NotificationService {

  // Keep the last 5 notifications so late subscribers see recent history
  private notificationsSubject = new ReplaySubject<Notification>(5);

  notifications$ = this.notificationsSubject.asObservable();

  addNotification(message: string, type: 'success' | 'error' | 'info'): void {
    this.notificationsSubject.next({
      id: Date.now(),
      message,
      type,
      timestamp: new Date()
    });
  }
}

Even if a component subscribes after 3 notifications were emitted, it still gets those 3 notifications to display.

📡 AsyncSubject — Only Emits the Last Value on Complete

AsyncSubject only emits the LAST value, and ONLY when .complete() is called.

import { AsyncSubject } from 'rxjs';

const async$ = new AsyncSubject<number>();

async$.subscribe(v => console.log('Got:', v));

async$.next(1);
async$.next(2);
async$.next(3);

// Nothing logged yet...

async$.complete(); // NOW it emits!

// Output: Got: 3 (only the last value!)

This is rarely used but good to know.

🔐 The Security Pattern — Hide Your Subject!

A best practice: never expose a Subject directly to components. Use .asObservable() to expose a read-only view.

// ❌ BAD — any component can push data into this!
userSubject = new BehaviorSubject<User>(null);

// ✅ GOOD — only this service controls the data
private userSubject = new BehaviorSubject<User | null>(null);
user$ = this.userSubject.asObservable(); // Read-only!

// Only this service's methods can change the user
setUser(user: User): void {
  this.userSubject.next(user);
}

🏗️ Real-World Example — Auth Service with BehaviorSubject

This pattern is used in almost every real Angular app:

auth.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { BehaviorSubject, Observable } from 'rxjs';
import { tap, map } from 'rxjs/operators';

export interface User {
  id: number;
  name: string;
  email: string;
  role: 'admin' | 'user';
}

@Injectable({ providedIn: 'root' })
export class AuthService {

  private currentUserSubject = new BehaviorSubject<User | null>(null);

  // Read-only public streams
  currentUser$ = this.currentUserSubject.asObservable();
  isLoggedIn$ = this.currentUser$.pipe(map(user => user !== null));
  isAdmin$ = this.currentUser$.pipe(map(user => user?.role === 'admin'));

  constructor(private http: HttpClient) {
    // Restore user from localStorage on app start
    const savedUser = localStorage.getItem('currentUser');
    if (savedUser) {
      this.currentUserSubject.next(JSON.parse(savedUser));
    }
  }

  login(email: string, password: string): Observable<User> {
    return this.http.post<User>('/api/login', { email, password })
      .pipe(
        tap(user => {
          localStorage.setItem('currentUser', JSON.stringify(user));
          this.currentUserSubject.next(user); // 📡 Broadcast to all listeners!
        })
      );
  }

  logout(): void {
    localStorage.removeItem('currentUser');
    this.currentUserSubject.next(null); // 📡 Broadcast logout to all!
  }

  get currentUser(): User | null {
    return this.currentUserSubject.value; // Synchronous access
  }
}

nav.component.ts

@Component({
  template: `
    <nav>
      <a routerLink="/">Home</a>
      <a routerLink="/products">Products</a>

      <!-- Only show if logged in -->
      <a *ngIf="authService.isLoggedIn$ | async" routerLink="/profile">
        Profile
      </a>

      <!-- Only show if admin -->
      <a *ngIf="authService.isAdmin$ | async" routerLink="/admin">
        Admin Panel
      </a>

      <span *ngIf="authService.currentUser$ | async as user">
        Hello, {{ user.name }}!
      </span>

      <button *ngIf="authService.isLoggedIn$ | async" (click)="logout()">
        Logout
      </button>
    </nav>
  `
})
export class NavComponent {
  constructor(public authService: AuthService) {}

  logout(): void {
    this.authService.logout();
    // Nav updates automatically because BehaviorSubject broadcast the change!
  }
}

When the user logs in, the navigation bar, user profile page, and admin section all update automatically and simultaneously — no complex event passing needed!

🧠 Choosing the Right Subject

Use Subject when:

You just need to broadcast events (button clicks, action triggers)
Late subscribers don't need previous values
Example: Notification popup triggers

Use BehaviorSubject when:

Shared state that always has a current value
New subscribers should get the current state immediately
Example: Shopping cart, auth state, theme preference, language selection

Use ReplaySubject when:

New subscribers need to see recent history
Example: Chat messages, audit log, recent notifications

🧠 Chapter 5 Summary — What You Learned

Subject is both Observable and Observer — you can push data into it AND subscribe to it
Subject only delivers to current subscribers — late subscribers miss old values
BehaviorSubject always has a current value and gives it to new subscribers immediately — perfect for shared state
ReplaySubject remembers the last N values and replays them to late subscribers
Use .asObservable() to hide the Subject and expose a read-only stream
BehaviorSubject is used in almost every real Angular app for auth state, cart, settings, etc.

📚 Coming Up in Chapter 6...

We've covered the core building blocks. Now let's tackle a very common real-world challenge:

Error Handling — What do you do when an API fails? How do you show user-friendly errors? How do you retry?

Chapter 6 covers catchError, retry, retryWhen, and best practices for bulletproof Angular apps.

See you in Chapter 6! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 5 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 4 | switchMap, mergeMap, concatMap — Observables Inside Observables

Jack Pritom Soren — Wed, 01 Apr 2026 16:53:49 +0000

👋 Welcome to Chapter 4!

Buckle up — this is the chapter that trips up even experienced developers. But don't worry. By the end, it will make total sense.

The question today is: What do you do when you have an Observable that produces values… and each value needs to trigger ANOTHER Observable?

Sounds weird? Let's make it concrete.

🤔 The Problem — Observable Inside Observable

Imagine this scenario:

You have a search box. Every time the user types, you want to search the API for results.

The user typing = Observable (stream of text values)
The API call = another Observable

So you have an Observable that needs to trigger another Observable. This is called a higher-order Observable — an Observable of Observables.

// What you WANT to do (but this DOESN'T work properly):
searchInput.valueChanges
  .pipe(
    map(searchTerm => this.http.get(`/api/search?q=${searchTerm}`))
    // ❌ Now you have an Observable of Observables! 😱
    // subscribe would give you Observable objects, not the actual data!
  )
  .subscribe(result => {
    // result is an Observable, not the search results!
    console.log(result); // Observable { ... } ← NOT what we want
  });

To fix this, we need flattening operators — switchMap, mergeMap, and concatMap.

They all do the same basic thing: subscribe to the inner Observable automatically and give you the final result.

But they behave very differently when multiple requests overlap.

🔀 The Three Brothers — An Analogy

Imagine you're asking a waiter to bring you food from 3 different restaurants.

switchMap — "Actually, cancel that last order. I changed my mind, bring me this new one instead."
→ Cancels the previous request when a new one comes in

mergeMap — "Yes, get all three orders! Bring them as they're ready, any order."
→ Runs all requests simultaneously, results come in any order

concatMap — "Wait for the first order to arrive, THEN go get the second one, THEN the third."
→ Runs requests one at a time, in order

🔀 `switchMap` — Cancel the Old, Start the New

switchMap is the most commonly used flattening operator in Angular. Use it when you only care about the most recent request.

Perfect for: Search boxes, autocomplete, navigation triggers

import { switchMap } from 'rxjs/operators';
import { fromEvent } from 'rxjs';

// Every time the user types, CANCEL the old search, start a new one
searchInput.valueChanges
  .pipe(
    debounceTime(300),  // Wait 300ms after typing stops
    switchMap(searchTerm =>
      // switchMap subscribes to the HTTP call automatically
      // If a new value comes in BEFORE this finishes, it CANCELS this request
      this.http.get<Product[]>(`/api/products?search=${searchTerm}`)
    )
  )
  .subscribe(products => {
    this.searchResults = products;  // ✅ Actual products, not an Observable!
  });

Why switchMap here?
User types "iph" → request starts. Then they type "ipho" → cancel the "iph" request and start "ipho". No outdated results! No race conditions!

Full Real-World Search Component

import { Component, OnInit } from '@angular/core';
import { FormControl } from '@angular/forms';
import { Observable } from 'rxjs';
import { debounceTime, distinctUntilChanged, switchMap, startWith } from 'rxjs/operators';

@Component({
  selector: 'app-search',
  template: `
    <input [formControl]="searchControl" placeholder="Search products..." />

    <div *ngIf="isLoading">Searching... 🔍</div>

    <div *ngFor="let product of results$ | async" class="result-item">
      <strong>{{ product.name }}</strong>
      <span>৳{{ product.price }}</span>
    </div>
  `
})
export class SearchComponent implements OnInit {

  searchControl = new FormControl('');
  results$!: Observable<Product[]>;
  isLoading = false;

  constructor(private productService: ProductService) {}

  ngOnInit(): void {
    this.results$ = this.searchControl.valueChanges.pipe(
      startWith(''),                          // Start with empty string (show all)
      debounceTime(400),                      // Wait 400ms after typing
      distinctUntilChanged(),                 // Don't search if value didn't change
      switchMap(term => {
        this.isLoading = true;
        return this.productService.search(term || '');
      }),
      tap(() => this.isLoading = false)       // Turn off loading when results arrive
    );
  }
}

⚡ `mergeMap` (aka `flatMap`) — Run Everything Simultaneously

mergeMap starts every new Observable immediately without cancelling old ones. Results come in as they finish — order is not guaranteed.

Perfect for: Parallel uploads, multiple simultaneous requests

import { mergeMap, from } from 'rxjs';

// Upload multiple files AT THE SAME TIME
const files = [file1, file2, file3];

from(files)  // from() converts an array to an Observable
  .pipe(
    mergeMap(file => this.uploadService.upload(file))
    // All 3 uploads start at the same time!
    // Results come in as each one finishes
  )
  .subscribe(uploadResult => {
    console.log('Upload complete:', uploadResult.fileName);
  });

Real Example — Load User Profiles in Parallel

// You have an array of user IDs, and want to load all profiles at once
const userIds = [1, 2, 3, 4, 5];

from(userIds)
  .pipe(
    mergeMap(id => this.http.get<User>(`/api/users/${id}`))
    // All 5 HTTP calls fire simultaneously!
  )
  .subscribe(user => {
    this.users.push(user);
    // Users appear as they load — might be out of order (5 before 3, etc.)
  });

⚠️ Warning: mergeMap can overwhelm your server if you have too many items. Use mergeMap(fn, 3) to limit concurrent requests to 3 at a time.

🚶 `concatMap` — One at a Time, In Order

concatMap waits for each Observable to complete before starting the next one. Results are always in order.

Perfect for: Sequential operations, guaranteed ordering

import { concatMap, from } from 'rxjs';

// Process steps one at a time, in order
const steps = ['step1', 'step2', 'step3'];

from(steps)
  .pipe(
    concatMap(step => this.processStep(step))
    // step1 must complete before step2 starts
    // step2 must complete before step3 starts
  )
  .subscribe(result => {
    console.log('Step completed:', result);
  });

Real Example — Onboarding Steps in Order

// After registration, run these steps IN ORDER:
// 1. Create user account
// 2. Send welcome email  
// 3. Set up default preferences

this.registrationService.register(formData)
  .pipe(
    concatMap(user => this.emailService.sendWelcome(user.email)),
    concatMap(() => this.prefService.setupDefaults())
  )
  .subscribe(() => {
    this.router.navigate(['/dashboard']);
  });

Here, the email is sent only after account creation succeeds. Preferences are set only after the email is sent. Perfect ordering! ✅

🆚 Side-by-Side Comparison

Let's say you click a button 3 times quickly (A, B, C), and each click triggers an API call.

Click A starts → [Request A takes 3 seconds]
Click B starts → [Request B takes 1 second]  
Click C starts → [Request C takes 2 seconds]

switchMap — Cancels previous

A starts → B starts (A cancelled) → C starts (B cancelled) → C finishes ✅
You get: only C's result

mergeMap — All run at once

A, B, C all run simultaneously
B finishes first → A finishes → C finishes
You get: B, A, C (out of order!)

concatMap — One at a time in order

A starts → A finishes → B starts → B finishes → C starts → C finishes
You get: A, B, C (in perfect order, but slowest)

🛍️ Complete Real-World Example — Product Detail Page with Related Items

This example uses switchMap to load a product, then mergeMap to load related items in parallel:

product-detail.component.ts

import { Component, OnInit } from '@angular/core';
import { ActivatedRoute } from '@angular/router';
import { Observable, EMPTY } from 'rxjs';
import { switchMap, mergeMap, toArray, catchError } from 'rxjs/operators';
import { from } from 'rxjs';

@Component({
  selector: 'app-product-detail',
  template: `
    <div *ngIf="product$ | async as product">
      <h1>{{ product.name }}</h1>
      <p>{{ product.description }}</p>
      <p class="price">৳{{ product.price }}</p>

      <h2>Related Products</h2>
      <div *ngFor="let related of relatedProducts$ | async">
        {{ related.name }} — ৳{{ related.price }}
      </div>
    </div>
  `
})
export class ProductDetailComponent implements OnInit {

  product$!: Observable<Product>;
  relatedProducts$!: Observable<Product[]>;

  constructor(
    private route: ActivatedRoute,
    private productService: ProductService
  ) {}

  ngOnInit(): void {

    // switchMap: When the route param changes, cancel old request, load new product
    this.product$ = this.route.params.pipe(
      switchMap(params => {
        const productId = params['id'];
        return this.productService.getProduct(productId);
      }),
      catchError(err => {
        console.error('Failed to load product', err);
        return EMPTY; // Return empty Observable on error
      })
    );

    // Load related products in parallel using mergeMap
    this.relatedProducts$ = this.product$.pipe(
      switchMap(product =>
        // Get all related IDs and load them simultaneously
        from(product.relatedIds).pipe(
          mergeMap(id => this.productService.getProduct(id)),
          toArray()  // Collect all results into one array
        )
      )
    );
  }
}

🚦 Route-Based Loading with switchMap

One of the most common real-world uses of switchMap in Angular is loading data based on route parameters:

@Component({ ... })
export class UserProfileComponent implements OnInit {

  user$!: Observable<User>;
  posts$!: Observable<Post[]>;

  constructor(
    private route: ActivatedRoute,
    private userService: UserService
  ) {}

  ngOnInit(): void {
    // Every time the URL changes (e.g., /users/1 → /users/2)
    // switchMap cancels the old request and starts a new one
    this.user$ = this.route.paramMap.pipe(
      switchMap(params => {
        const userId = params.get('id')!;
        return this.userService.getUser(userId);
      })
    );

    // Load user's posts whenever the user changes
    this.posts$ = this.user$.pipe(
      switchMap(user => this.userService.getPosts(user.id))
    );
  }
}

This is incredibly elegant! When the user navigates to /users/3, the old request for /users/2 gets automatically cancelled. No stale data. ✨

🧠 Quick Decision Guide

Use switchMap when:

Search box / autocomplete
Loading data from route params
You only care about the latest request
Cancelling outdated requests is desirable

Use mergeMap when:

Parallel uploads
Loading multiple independent items simultaneously
Order doesn't matter
You want maximum speed

Use concatMap when:

Steps must happen in order
Sequential processing
Like a queue — first in, first out

🧠 Chapter 4 Summary — What You Learned

Sometimes you need an Observable that triggers another Observable — called a higher-order Observable
switchMap — cancels the previous inner Observable when a new one starts (best for search)
mergeMap — runs all inner Observables simultaneously (best for parallel tasks)
concatMap — runs inner Observables one at a time in order (best for sequential steps)
switchMap is the most commonly used in Angular — especially for HTTP + route params
All three operators automatically subscribe to the inner Observable and give you the unwrapped result

📚 Coming Up in Chapter 5...

We've covered transformation operators. Now let's learn about Subject — the two-way radio of RxJS.

A Subject is an Observable that you can manually push values into. It's essential for sharing data between components and services!

See you in Chapter 5! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 4 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 3 | pipe()` and Operators — The Superpowers of RxJS

Jack Pritom Soren — Sat, 21 Mar 2026 19:03:10 +0000

"`pipe()` and Operators — The Superpowers of RxJS"

👋 Welcome to Chapter 3!

So far you know:

Observable = a stream of data (Chapter 1)
subscribe = how you receive data (Chapter 2)

Now here's the real magic: What if you want to transform, filter, or modify the data before it reaches you?

That's what pipe() and operators are for!

🍋 Think of it Like Making Lemonade

You have a lemon 🍋 (raw data from an API).

You don't want to eat a raw lemon. You want to:

Squeeze it (transform the data)
Filter out the seeds (filter the data)
Add sugar (modify the data)

That's what pipe() does — it's a processing pipeline that your data flows through before reaching your subscribe().

Observable → [pipe: squeeze → filter → add sugar] → subscribe gets lemonade 🍹

🔧 What is `pipe()`?

pipe() is a method on every Observable. You use it to chain operators together.

someObservable
  .pipe(
    operator1(),
    operator2(),
    operator3()
  )
  .subscribe(result => {
    console.log(result); // result has been processed by all 3 operators
  });

Think of it like an assembly line 🏭:

Raw data comes in on one end
Each operator does its job
Processed data comes out on the other end
subscribe() picks it up

🗺️ Operator #1: `map()` — Transform Your Data

map() takes every value from the Observable and transforms it into something else.

It's exactly like Array.map() — but for streams.

Simple Example:

import { of } from 'rxjs';
import { map } from 'rxjs/operators';

// of() creates an Observable that emits these values one by one
of(1, 2, 3, 4, 5)
  .pipe(
    map(number => number * 10)  // Multiply every number by 10
  )
  .subscribe(result => {
    console.log(result);
  });

// Output:
// 10
// 20
// 30
// 40
// 50

Real Angular Example — Transforming API Response

Imagine the API gives you user data but you only need the name and email:

// user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map } from 'rxjs/operators';

interface ApiUser {
  id: number;
  name: string;
  username: string;
  email: string;
  phone: string;
  website: string;
  address: object; // We don't need this!
  company: object; // We don't need this either!
}

interface SimpleUser {
  name: string;
  email: string;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) {}

  // Returns only the fields we need — not the whole messy API response
  getSimpleUsers(): Observable<SimpleUser[]> {
    return this.http.get<ApiUser[]>('https://jsonplaceholder.typicode.com/users')
      .pipe(
        map(users => users.map(user => ({
          name: user.name,
          email: user.email
          // We dropped id, phone, website, address, company
        })))
      );
  }
}

// users.component.ts
@Component({
  template: `
    <div *ngFor="let user of users$ | async">
      <strong>{{ user.name }}</strong> — {{ user.email }}
    </div>
  `
})
export class UsersComponent {
  users$ = this.userService.getSimpleUsers();
  constructor(private userService: UserService) {}
}

The template only sees name and email — clean and simple! 🧹

🔍 Operator #2: `filter()` — Only Let Certain Values Through

filter() is like a bouncer at a club — only values that pass the test get through.

import { of } from 'rxjs';
import { filter } from 'rxjs/operators';

of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
  .pipe(
    filter(number => number % 2 === 0) // Only even numbers
  )
  .subscribe(n => console.log(n));

// Output: 2, 4, 6, 8, 10

Real Angular Example — Filter Active Products

// product.service.ts
getActiveProducts(): Observable<Product[]> {
  return this.http.get<Product[]>('/api/products')
    .pipe(
      map(products => products.filter(p => p.isActive === true))
      // Or using RxJS filter:
      // This filters the ARRAY inside the stream
    );
}

Or if the API emits products one at a time:

// Filter individual emissions
productStream$
  .pipe(
    filter(product => product.price > 0),     // Skip free products
    filter(product => product.stock > 0)      // Skip out-of-stock
  )
  .subscribe(product => {
    this.availableProducts.push(product);
  });

👀 Operator #3: `tap()` — Peek Without Changing Anything

tap() lets you look at the data as it flows through the pipe without modifying it.

It's perfect for debugging or doing side effects (like showing a loading spinner, logging, etc.)

import { of } from 'rxjs';
import { tap, map } from 'rxjs/operators';

of(1, 2, 3)
  .pipe(
    tap(n => console.log('Before map:', n)),  // Peek at raw value
    map(n => n * 10),
    tap(n => console.log('After map:', n))    // Peek at transformed value
  )
  .subscribe(n => console.log('Final:', n));

// Output:
// Before map: 1
// After map: 10
// Final: 10
// Before map: 2
// After map: 20
// Final: 20
// ...

Real Angular Example — Loading State with tap

// user.service.ts
getUsers(): Observable<User[]> {
  return this.http.get<User[]>('/api/users')
    .pipe(
      tap(() => console.log('HTTP request made!')),  // Debugging
      tap(users => console.log(`Received ${users.length} users`))
    );
}

// users.component.ts
@Component({
  template: `
    <div *ngIf="isLoading">Loading... ⏳</div>
    <ul *ngIf="!isLoading">
      <li *ngFor="let user of users">{{ user.name }}</li>
    </ul>
  `
})
export class UsersComponent implements OnInit {
  users: User[] = [];
  isLoading = false;

  ngOnInit() {
    this.isLoading = true;

    this.userService.getUsers()
      .pipe(
        tap(() => {
          // Side effect: set loading to false when data arrives
          this.isLoading = false;
        })
      )
      .subscribe(users => {
        this.users = users;
      });
  }
}

💡 Golden Rule of tap(): It never changes the data. It's just for peeking and side effects.

🔢 Chaining Multiple Operators

The real power is when you chain operators together:

this.http.get<Product[]>('/api/products')
  .pipe(
    tap(() => console.log('Fetching products...')),    // 1. Log it
    map(products => products.filter(p => p.active)),   // 2. Only active
    map(products => products.sort((a, b) =>            // 3. Sort by price
      a.price - b.price
    )),
    tap(products => console.log(`${products.length} products ready`)) // 4. Log result
  )
  .subscribe(products => {
    this.products = products;  // 5. Clean, sorted, active products!
  });

Data flows through each operator like water through filters 💧

🏪 Full Real-World Example — Product Catalog Page

Let's build a complete product catalog that uses pipe, map, filter, and tap:

product.service.ts

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';
import { map, filter, tap } from 'rxjs/operators';

export interface Product {
  id: number;
  name: string;
  price: number;
  category: string;
  inStock: boolean;
  rating: number;
}

@Injectable({ providedIn: 'root' })
export class ProductService {

  constructor(private http: HttpClient) {}

  getFeaturedProducts(): Observable<Product[]> {
    return this.http.get<Product[]>('/api/products')
      .pipe(
        // Step 1: Log for debugging
        tap(products => console.log('Raw data:', products.length, 'items')),

        // Step 2: Only get in-stock products
        map(products => products.filter(p => p.inStock)),

        // Step 3: Only get high-rated products (4 stars and above)
        map(products => products.filter(p => p.rating >= 4)),

        // Step 4: Sort by rating, highest first
        map(products => [...products].sort((a, b) => b.rating - a.rating)),

        // Step 5: Take only top 10
        map(products => products.slice(0, 10)),

        // Step 6: Log final result
        tap(products => console.log('Featured products ready:', products.length))
      );
  }
}

product-catalog.component.ts

import { Component } from '@angular/core';
import { Observable } from 'rxjs';
import { Product, ProductService } from './product.service';

@Component({
  selector: 'app-product-catalog',
  template: `
    <h1>⭐ Featured Products</h1>

    <div class="product-grid">
      <div *ngFor="let product of products$ | async" class="product-card">
        <h3>{{ product.name }}</h3>
        <p class="price">৳{{ product.price }}</p>
        <p class="category">{{ product.category }}</p>
        <div class="rating">
          ⭐ {{ product.rating }}/5
        </div>
        <button>Add to Cart 🛒</button>
      </div>
    </div>

    <p *ngIf="(products$ | async)?.length === 0">
      No featured products available right now.
    </p>
  `
})
export class ProductCatalogComponent {

  products$: Observable<Product[]>;

  constructor(private productService: ProductService) {
    this.products$ = this.productService.getFeaturedProducts();
  }
}

Clean, readable, and all the messy filtering/sorting logic is in the service — not the template!

🧩 More Useful Operators — Quick Overview

Here are a few more operators you'll use frequently:

`take(n)` — Only Take First N Values

import { interval } from 'rxjs';
import { take } from 'rxjs/operators';

// interval() emits 0, 1, 2, 3... every second FOREVER
// take(5) stops it after 5 values
interval(1000)
  .pipe(take(5))
  .subscribe(n => console.log(n));
// Output: 0, 1, 2, 3, 4 (then automatically completes!)

`distinctUntilChanged()` — Skip Duplicate Values

import { of } from 'rxjs';
import { distinctUntilChanged } from 'rxjs/operators';

// Great for search inputs — don't search if the value hasn't changed
of('apple', 'apple', 'banana', 'banana', 'cherry')
  .pipe(distinctUntilChanged())
  .subscribe(v => console.log(v));
// Output: apple, banana, cherry (duplicates skipped!)

`debounceTime()` — Wait Before Processing

import { debounceTime } from 'rxjs/operators';

// Wait 300ms after the last keystroke before searching
searchInput.valueChanges
  .pipe(debounceTime(300))
  .subscribe(value => this.search(value));

`catchError()` — Handle Errors Gracefully

import { catchError } from 'rxjs/operators';
import { of } from 'rxjs';

this.http.get('/api/users')
  .pipe(
    catchError(error => {
      console.error('API failed:', error);
      return of([]); // Return empty array instead of crashing
    })
  )
  .subscribe(users => this.users = users);

🎯 When to Use What

map() — Anytime you want to transform or reshape data from the API
"I got raw API data, let me turn it into what my component needs"

filter() — When you want to skip certain values
"Only show me products that are in stock"

tap() — For debugging or side effects that shouldn't change data
"Log this, show a spinner, but don't touch the actual data"

take(n) — When you only need the first few values
"I only need the first response, then stop"

catchError() — Always use this for HTTP calls in production apps
"If the API breaks, show a nice message instead of crashing"

🧠 Chapter 3 Summary — What You Learned

pipe() is an assembly line that processes data before it reaches subscribe()
map() transforms every value into something new
filter() lets only certain values through
tap() lets you peek at data or do side effects without changing anything
You can chain multiple operators inside one pipe()
Common patterns: use map() for data transformation, filter() for filtering arrays, tap() for logging and side effects

📚 Coming Up in Chapter 4...

We've covered the basics of operators. Now it's time for one of the most confusing yet important operators in all of RxJS:

switchMap, mergeMap, and concatMap — the "flattening operators" that handle Observables inside Observables.

These are used in almost every real Angular app. Don't miss it!

See you in Chapter 4! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 3 of 10

Follow me on : Github Linkedin Threads Youtube Channel

RxJS in Angular — Chapter 2 | Subscribe & Unsubscribe — The Secret to No Memory Leaks

Jack Pritom Soren — Tue, 17 Mar 2026 06:24:45 +0000

Subscribe & Unsubscribe — The Secret to No Memory Leaks

Newsletter Series: RxJS Deep Dive for Angular Developers
Written so clearly, even a 5th grader can understand it.

👋 Welcome Back!

In Chapter 1, we learned that an Observable is like a water pipe — and subscribe() is how you open the tap to receive data.

But here's the thing nobody tells beginners:

If you forget to CLOSE the tap, water keeps flowing forever — even after you leave the room.

In code, that's called a memory leak. 💧 And it's one of the most common bugs in Angular apps.

Today we're going deep into subscribe() — how it works, all its options, and the right way to unsubscribe to keep your app healthy.

🔁 Quick Recap from Chapter 1

// Open the tap — start receiving data
this.userService.getUsers().subscribe((users) => {
  this.users = users;
});

Simple. But what happens when the component is destroyed? The subscription is still alive! Like a leaking tap 💧

🧠 Understanding Subscriptions — The Full Picture

When you call .subscribe(), it returns a Subscription object.

import { Subscription } from 'rxjs';

const subscription: Subscription = someObservable.subscribe(value => {
  console.log(value);
});

This subscription object is your remote control for the data stream. With it, you can:

Check if it's still active: subscription.closed
Stop receiving data: subscription.unsubscribe()

🍿 Story Time: The Never-Ending Movie

Imagine you went to a cinema 🎬 and started watching a movie. Then you got up and left — but the cinema kept charging you for the seat even though you're gone!

That's a memory leak. The movie (Observable) is still playing (running), and you're still paying (using memory), even though you left (component destroyed).

Unsubscribing is like telling the cinema: "I'm leaving, stop charging me."

🔴 The Problem — Memory Leak in Action

Here's a BAD example that causes a memory leak:

// ❌ BAD — causes memory leak!
@Component({
  selector: 'app-dashboard',
  template: `<p>Dashboard loaded!</p>`
})
export class DashboardComponent implements OnInit {

  constructor(private dataService: DataService) {}

  ngOnInit(): void {
    // This subscription is NEVER cleaned up!
    // Even when the component is destroyed, this keeps running.
    this.dataService.getLiveData().subscribe(data => {
      console.log('New data:', data);
    });
  }
}

When the user navigates away from this component, Angular destroys it. But the subscription to getLiveData() is still alive, still calling the callback, still using memory. If the user navigates back and forth 10 times, there are now 10 subscriptions all running at once! 😱

✅ Fix #1 — Manual Unsubscribe

The most basic way: store the subscription and unsubscribe in ngOnDestroy

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `<p>Dashboard: {{ latestData }}</p>`
})
export class DashboardComponent implements OnInit, OnDestroy {

  latestData: any;

  // Store the subscription so we can cancel it later
  private dataSubscription: Subscription = new Subscription();

  constructor(private dataService: DataService) {}

  ngOnInit(): void {
    // Start the subscription and SAVE it
    this.dataSubscription = this.dataService.getLiveData().subscribe(data => {
      this.latestData = data;
    });
  }

  ngOnDestroy(): void {
    // ✅ Component is being destroyed — CANCEL the subscription!
    this.dataSubscription.unsubscribe();
    console.log('Subscription cleaned up!');
  }
}

✅ Fix #2 — Managing Multiple Subscriptions

What if you have 3 different subscriptions? You can use one Subscription object to manage all of them using .add():

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';

@Component({
  selector: 'app-dashboard',
  template: `...`
})
export class DashboardComponent implements OnInit, OnDestroy {

  // One Subscription object to rule them all
  private subscriptions = new Subscription();

  ngOnInit(): void {

    // Add subscription 1
    this.subscriptions.add(
      this.userService.getUsers().subscribe(users => {
        this.users = users;
      })
    );

    // Add subscription 2
    this.subscriptions.add(
      this.productService.getProducts().subscribe(products => {
        this.products = products;
      })
    );

    // Add subscription 3
    this.subscriptions.add(
      this.notificationService.getAlerts().subscribe(alerts => {
        this.alerts = alerts;
      })
    );
  }

  ngOnDestroy(): void {
    // ✅ One line cancels ALL subscriptions
    this.subscriptions.unsubscribe();
  }
}

✅ Fix #3 — The Angular Way: `async` Pipe (Recommended!)

Angular has a magical pipe called async that automatically subscribes AND unsubscribes for you!

No need to manually call .subscribe() or .unsubscribe() at all!

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

@Component({
  selector: 'app-users',
  template: `
    <!-- async pipe handles subscribe AND unsubscribe automatically! -->
    <ul>
      <li *ngFor="let user of users$ | async">
        {{ user.name }}
      </li>
    </ul>

    <!-- Show loading -->
    <p *ngIf="(users$ | async) === null">Loading... ⏳</p>
  `
})
export class UsersComponent {

  // Note the $ suffix — convention for Observables
  users$: Observable<User[]>;

  constructor(private userService: UserService) {
    // Just assign the Observable — don't subscribe!
    this.users$ = this.userService.getUsers();
  }

  // No ngOnDestroy needed! async pipe handles cleanup.
}

💡 Pro Tip: In Angular, variables that hold Observables are usually named with a $ at the end (like users$, data$). It's just a convention — it tells other developers "hey, this is an Observable!"

✅ Fix #4 — `takeUntil` Pattern (Advanced but Powerful)

This is the pattern used in large Angular applications. You create a special "destroy signal" Subject (we'll cover Subject later), and use takeUntil to automatically unsubscribe from everything when the component dies.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

@Component({
  selector: 'app-dashboard',
  template: `...`
})
export class DashboardComponent implements OnInit, OnDestroy {

  // This is our "destroy signal"
  private destroy$ = new Subject<void>();

  ngOnInit(): void {

    // takeUntil(this.destroy$) means:
    // "Keep subscribing UNTIL destroy$ emits a value"
    this.userService.getUsers()
      .pipe(takeUntil(this.destroy$))
      .subscribe(users => {
        this.users = users;
      });

    this.productService.getProducts()
      .pipe(takeUntil(this.destroy$))
      .subscribe(products => {
        this.products = products;
      });
  }

  ngOnDestroy(): void {
    // 🔔 Fire the destroy signal — ALL subscriptions with takeUntil cancel
    this.destroy$.next();
    this.destroy$.complete();
  }
}

📋 The Full Subscribe Syntax — All Options

.subscribe() can take a full object with three handlers:

someObservable.subscribe({
  next: (value) => {
    // ✅ Called every time a new value arrives
    console.log('Got value:', value);
  },
  error: (err) => {
    // ❌ Called if something goes wrong
    console.error('Something broke:', err);
    // Note: After an error, the Observable STOPS.
    // complete() will NOT be called after error()
  },
  complete: () => {
    // 🏁 Called when the Observable says it's done
    // This is NOT called if there was an error
    console.log('Stream finished!');
  }
});

Or the shorthand (just pass a function for next):

// Short version — only handles next values
someObservable.subscribe(value => {
  console.log(value);
});

🛍️ Real World Example — E-commerce Cart Watcher

In a real e-commerce app, you might want to watch the shopping cart for changes:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';
import { CartService } from './cart.service';

@Component({
  selector: 'app-cart-icon',
  template: `
    <div class="cart-icon">
      🛒 <span class="badge">{{ cartCount }}</span>
    </div>
  `
})
export class CartIconComponent implements OnInit, OnDestroy {

  cartCount = 0;
  private cartSub: Subscription = new Subscription();

  constructor(private cartService: CartService) {}

  ngOnInit(): void {
    // Watch the cart — update count whenever cart changes
    this.cartSub = this.cartService.cartItems$.subscribe(items => {
      this.cartCount = items.length;
    });
  }

  ngOnDestroy(): void {
    // Clean up when header component is removed
    this.cartSub.unsubscribe();
  }
}

🔍 When Do You NOT Need to Unsubscribe?

Great question! Some Observables complete themselves automatically and don't need unsubscribing:

HTTP Requests — they emit once and complete

// ✅ Safe — HTTP observables complete after one response
this.http.get('/api/users').subscribe(data => { ... });
// No need to unsubscribe — it completes on its own!

Finite Observables — they have a natural end

// ✅ Safe — of() completes immediately
of(1, 2, 3).subscribe(n => console.log(n));

You DO need to unsubscribe from:

interval() — ticks forever
fromEvent() — fires on every click/keypress forever
Custom Observables that never complete
BehaviorSubject / Subject streams from services

🧪 Full Real-World Component Example

Here's a real-world notification bell component that handles everything properly:

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { NotificationService } from './notification.service';

interface Notification {
  id: number;
  message: string;
  isRead: boolean;
}

@Component({
  selector: 'app-notification-bell',
  template: `
    <div class="bell-wrapper">
      <button (click)="togglePanel()">
        🔔
        <span *ngIf="unreadCount > 0" class="badge">{{ unreadCount }}</span>
      </button>

      <div *ngIf="isPanelOpen" class="notification-panel">
        <h3>Notifications</h3>
        <div *ngFor="let n of notifications"
             [class.unread]="!n.isRead">
          {{ n.message }}
        </div>
        <p *ngIf="notifications.length === 0">No notifications!</p>
      </div>
    </div>
  `
})
export class NotificationBellComponent implements OnInit, OnDestroy {

  notifications: Notification[] = [];
  unreadCount = 0;
  isPanelOpen = false;

  private destroy$ = new Subject<void>();

  constructor(private notifService: NotificationService) {}

  ngOnInit(): void {
    // Subscribe to live notifications — auto-cleanup with takeUntil
    this.notifService.notifications$
      .pipe(takeUntil(this.destroy$))
      .subscribe({
        next: (notifs) => {
          this.notifications = notifs;
          this.unreadCount = notifs.filter(n => !n.isRead).length;
        },
        error: (err) => {
          console.error('Notification error:', err);
        }
      });
  }

  togglePanel(): void {
    this.isPanelOpen = !this.isPanelOpen;
  }

  ngOnDestroy(): void {
    // All subscriptions clean up automatically
    this.destroy$.next();
    this.destroy$.complete();
  }
}

🎯 Which Method Should You Use?

Here's a simple guide:

Use async pipe when you're displaying data directly in the template — it's the cleanest, most Angular-idiomatic way.

Use takeUntil when you have logic inside the subscription that can't go in the template — this is the most popular pattern in large apps.

Use manual Subscription when you need fine-grained control over a specific subscription.

🧠 Chapter 2 Summary — What You Learned

.subscribe() returns a Subscription object
Forgetting to unsubscribe = memory leak — subscriptions keep running even after the component is gone
Use ngOnDestroy() to clean up subscriptions when a component is destroyed
The async pipe is the easiest way — it handles subscribe AND unsubscribe automatically
The takeUntil + Subject pattern is the most popular in large apps
HTTP Observables are safe — they complete themselves after one response
Interval, fromEvent, and Service streams must be manually unsubscribed

📚 Coming Up in Chapter 3...

You know how to subscribe and unsubscribe. Now it's time to learn about pipe() and operators — the superpowers that make RxJS incredibly powerful!

We'll cover map, filter, tap, and more — with real-world examples.

See you in Chapter 3! 🚀

💌 RxJS Deep Dive Newsletter Series | Chapter 2 of 10

Follow me on : Github Linkedin Threads Youtube Channel

DEV Community: Jack Pritom Soren

RAG Explained: How to Give Your LLM a Memory It Can Actually Trust

What We'll Cover

Chapter 1: The RAG Mental Model — Why It Works at All

Chapter 2: The Full RAG Development Pipeline — Two Phases

Phase 1 — Indexing (Offline, Runs Once)

Phase 2 — Retrieval + Generation (Online, Runs Per Query)

Chapter 3: Document Loaders — Getting Your Data In

Chapter 4: Text Splitting and Chunking — The Stage Everyone Underestimates

Chunk Size: The Core Trade-off

Chunk Overlap: Handling Boundary Problems

Splitting Strategies: Not All Text Is Flat Prose

Chapter 5: Embeddings and Vector Stores — Where Your Data Lives

What Embeddings Actually Are

Vector Stores

Chapter 6: Retrievers — Finding the Right Chunks When It Matters

MMR — Maximum Marginal Relevance

Similarity Score Threshold

Metadata Filtering

Multi-Query Retrieval

Chapter 7: Putting It All Together — A Working RAG Chain

Chapter 8: Where RAG Breaks and How to Diagnose It

Where This Takes You Next

RxJS in Angular — Chapter 10 (Final) | Real-World Patterns, Best Practices & Everything That Actually Matters

👋 Welcome to the Final Chapter!

🏗️ Pattern 1: The State Service Pattern (Mini State Management)

The Pattern

Using the State Service in Components

🏗️ Pattern 2: The Smart/Dumb Component Pattern

🏗️ Pattern 3: The Loading/Error/Success State Pattern

🛑 The Top 10 RxJS Mistakes to Avoid

Mistake 1: Not Unsubscribing

Mistake 2: Nested Subscribes

Mistake 3: Subscribing in Services

Mistake 4: Forgetting startWith in combineLatest

Mistake 5: Using switchMap When You Should Use mergeMap

Mistake 6: Not Handling Errors

Mistake 7: Overcomplicating Simple Things

Mistake 8: Not Using async Pipe

Mistake 9: Exposing Subject Directly

Mistake 10: Using tap to Extract Data

📋 The Complete RxJS Cheat Sheet

🎓 Your Journey So Far — The Complete Series

🚀 What to Learn Next

💌 Thank You for Reading!

RxJS in Angular — Chapter 9 | Timing Operators — debounceTime, throttleTime, interval & More

👋 Welcome to Chapter 9!

⏱️ debounceTime() — Wait for the Silence

Timeline:

Real Angular Example — Smart Search Box

⚡ throttleTime() — Only Once Per Time Window

debounceTime vs throttleTime:

🎯 distinctUntilChanged() — Skip Identical Values

🕐 interval() — Emit on a Schedule

Real Example — Auto-Refresh Dashboard

⏲️ timer() — Emit Once After a Delay

Real Example — Auto-dismiss Notifications

📡 fromEvent() — Turn DOM Events into Observables

🏗️ Full Real-World Example — Infinite Scroll List

🧠 Quick Reference — When to Use Which

🧠 Chapter 9 Summary — What You Learned

📚 Coming Up in Chapter 10 — The Final Chapter!

RxJS in Angular — Chapter 8 | RxJS + Angular Reactive Forms — Live Validation ও Dynamic Forms

"RxJS + Angular Reactive Forms — Live Validation & Dynamic Forms"

👋 Welcome to Chapter 8!

🎛️ The Reactive Forms Quick Setup

app.module.ts

💡 The Key Streams on Every FormControl

🔍 Real Example 1 — Live Username Availability Check

🏙️ Real Example 2 — Dependent Dropdowns (Country → City)

💰 Real Example 3 — Live Price Calculator

🔧 Using statusChanges for Async Validators

🧠 Chapter 8 Summary — What You Learned

📚 Coming Up in Chapter 9...

What Actually Happens When You Type "What is Python?" Into ChatGPT

What We'll Cover

Chapter 1: The Three Layers of the Generative AI World

Chapter 2: What an LLM Actually Is

Chapter 3: What Happens When You Type "What is Python?"

Chapter 4: The Provider Problem — Why Every API Feels Different

⏱️ `debounceTime()` — Wait for the Silence

⚡ `throttleTime()` — Only Once Per Time Window

`debounceTime` vs `throttleTime`:

🎯 `distinctUntilChanged()` — Skip Identical Values

🕐 `interval()` — Emit on a Schedule

⏲️ `timer()` — Emit Once After a Delay

📡 `fromEvent()` — Turn DOM Events into Observables

🔧 Using `statusChanges` for Async Validators

"Combining Observables — `forkJoin`, `combineLatest`, `zip` & More"

🍴 `forkJoin` — Wait for All, Then Done

🔄 `combineLatest` — React to Any Change

🤝 `withLatestFrom` — Use the Latest Value Without Triggering

🤐 `zip` — Pair by Position

7. `setTimeout` and `setInterval` — What They Actually Promise

9. `async/await` — Syntactic Sugar with Real Consequences

`await` inside loops — sequential vs parallel

The `forEach` async trap

🥅 `catchError` — Catch it Before it Reaches subscribe

🔄 `retry()` — Automatically Try Again

⏱️ `retryWhen` / `retry` with Delay — Smart Retrying

🔁 `finalize()` — Always Runs, Error or Not