DEV Community: Md Nafish Alam

Netflix vs. Live Broadcast: Understanding Cold and Hot Observables in RxJS 7

Md Nafish Alam — Sat, 21 Jun 2025 09:22:16 +0000

In the world of Angular development, particularly when dealing with asynchronous operations, RxJS is your best friend .But sometimes, RxJS concept can feel a bit abstract. Today let's demystify two fundamental concepts. Cold and Hot Observables.

Cold Observables: The On-Demand performers

Imagine a Cold Observables like a movie on Netflix. When you click play, a new instance of that movie starts just for you. If your friend clicks play on the same movie, they get their own independent stream from the beginning.

What it is: A Cold Observable starts producing value when a new subscriber subscribes to it. Each subscriber gets its own independent execution of the observable's underlying producer function.

Its Character:

Laxy: It doesn't do any work until explicitly asked(subscribed to).
Independent: Each subscription triggers a new , separate execution of the Observable.
Reproducible: The sequence of value is typically the same for each subscriber, starting from the beginning.

Real-World Examples When to Use it:

HTTP Requests: This is the most common example. When you make an HttpClient.get() request in Angular, it's a Cold Observable. Each time you subscribe, a new HTTP request is sent to the server.

// Each subscription sends a new GET request
this.http.get('/api/data').subscribe(data => console.log('Subscriber 1:', data));
this.http.get('/api/data').subscribe(data => console.log('Subscriber 2:', data));

DOM Events: While DOM events can be hot if using fromEvent directly on an existing element, if you're setting up an event listener based on a new element's creation, it's often cold.

Timer/Intervals (unshared): If you create a timer or interval observable and subscribe multiple times without sharing, each subscription gets its own independent timer.

Hot Observables: The Live Broadcast

Now, think of a Hot Observable like a live radio broadcast or a YouTube livestream. The broadcast is happening continuously, regardless of whether anyone is tuned in. If you tune in late, you'll join the stream in progress, you won't hear what's already been played.

What it is: A Hot Observable is already producing values before any subscriber subscribes to it. Subscribers simply listen to the ongoing streams of values.

Its Character:

Active: It's pushing values whether or not there are any listeners.
Shared: All subscribers share the same execution of the Observable.
Irreproducible(from the start): Subscribers might miss initial values if they subscribe late.

Real-World Examples When to Use it:

User Input Events (Shared): If you have a global search input and multiple components need to react to its changes, you'd typically make this a Hot Observable using shareReplay() or share() .

import { Subject } from 'rxjs';
// ...

// Imagine this is a service, e.g., search.service.ts
class SearchService {
  private searchInputSubject = new Subject<string>();

  // Expose the Subject as an Observable for components to subscribe to
  searchInput$ = this.searchInputSubject.asObservable();

  // Method to emit new search terms
  updateSearchTerm(term: string) {
    console.log(`SearchService: Emitting new term: "${term}"`);
    this.searchInputSubject.next(term);
  }
}

// --- How this would be used in your Angular components ---

// Assume SearchService is injected into your components' constructors
// constructor(private searchService: SearchService) {}

// In Component A's ngOnInit() or a similar lifecycle hook
// Component A subscribes
this.searchService.searchInput$.subscribe(term => {
  console.log('Component A received:', term);
  // Update UI or perform filtering based on the term
});

// In Component B's ngOnInit() (subscribing a little later)
this.searchService.searchInput$.subscribe(term => {
  console.log('Component B received:', term);
  // Perhaps update a different part of the UI
});

WebSockets: A WebSocket connection is inherently hot. Data is being streamed from the server continuously, and any client that connects simply starts receiving the current flow of data.
Stock Ticker Update: A continuous stream of stock prices would be a Hot Observable.
BehaviorSubject, ReplaySubject, Subject: These are built-in RxJS constructs that are inherently hot. They are designed to multicasting values to multiple observers.

The Key Difference: When Does the Work Begin?

The fundamental difference boils down to _ when the Observable's "work" or "data production" begins relative to a subscription:_

Cold:Work begins on subscription. Each subscription gets its own, fresh start.
Hot: Work is already in progress. Subscribers connect to an existing stream.

When to Make a Cold Observable Hot
Sometimes, you start with a Cold Observable (like an HTTP request) but realize you need to make it Hot because multiple parts of your application need the same data without triggering multiple backend calls. This is where multicasting operators come in:

share(): operator in RxJS is a powerful tool used to convert a unicast (cold) Observable into a multicast (hot) Observable. By default, Observables are "cold," meaning each subscription triggers a new, independent execution of the Observable's producer function. Subsequent subscribers will share the same underlying execution. If all subscribers unsubscribe, the source observable will be unsubscribed from, and a new subscription will restart the source observable for the next subscriber.
ShareReplay(): Similar to share(), but it also replays a specified number of past values to new subscribers. Ideal for scenarios where new subscribers need the "last known" state immediately.

// Example: Making an HTTP request hot with shareReplay
const data$ = this.http.get('/api/data').pipe(
  shareReplay(1) // Cache the last value and share the stream
);

// Both subscribers get the data from a single HTTP request
data$.subscribe(data => console.log('Subscriber 1 received:', data));
data$.subscribe(data => console.log('Subscriber 2 received:', data));

Conclusion

Understanding Cold and Hot Observables is crucial for writing robust and efficient RxJS code in Angular. It helps you anticipate side effects, optimize network calls, and design more predictable data flows. While Cold Observables are the default and often what you start with, knowing when and how to transform them into Hot Observables with multicasting operators is a powerful skill in your RxJS toolkit. So, the next time you're working with Observables, ask yourself: does this need to be on-demand (cold) or a live broadcast (hot)? Your answer will guide you to cleaner, more effective solutions.

Why memory Leaks

Md Nafish Alam — Sat, 24 May 2025 17:33:05 +0000

Md Nafish Alam

May 24 '25

Is Your Web App Leaking? A Beginner's Guide to Finding and Fixing Memory Issues (Part 1)

#webdev #javascript #devtools #memoryleaks

Comments 2

6 min read

Is Your Web App Leaking? A Beginner's Guide to Finding and Fixing Memory Issues (Part 1)

Md Nafish Alam — Sat, 24 May 2025 06:44:30 +0000

Ever noticed your web application getting sluggish over time? Or maybe it occasionally crashes for seemingly no reason? You might have a memory leak on your hands!

In the world of web development, especially with complex JavaScript frameworks, memory leaks can be sneaky culprits. They happen when your application holds onto memory it no longer needs. Over time, this unused memory builds up, slowing everything down and potentially leading to a frustrating crash for your users.

But don't worry! Detecting and fixing these leaks isn't some arcane art. In this first part of our guide (inspired by Metenski's excellent video on Decoded Frontend.), we'll explore the basics of memory leaks in web applications and introduce you to powerful tools in your browser's developer arsenal.

What Exactly is a Memory Leak?

A memory leak occurs when your application forgets to erase some of this information. It keeps holding onto it, even though it's no longer being used. Imagine leaving old notes all over the whiteboard – eventually, you'll run out of space!

In JavaScript, the language powering most web applications, there's a clever system called "garbage collection" that automatically tries to clean up this unused memory. However, leaks happen when unintended connections or "references" prevent the garbage collector from doing its job.

Common Culprits:Accidental Global Variables:

If you forget to declare a variable with let, const, or var inside a function, it can accidentally become a global variable. Global variables stick around for the entire lifespan of your application, potentially holding onto unnecessary data.

function doSomething() {
  message = "Hello!"; // Oops! 'message' becomes a global variable
  console.log(message);
}
doSomething();
console.log(message); // Still accessible globally!

Forgotten Timers and Intervals:

If you set up a setTimeout or setInterval function to run code repeatedly, and you don't clear it with clearTimeout or clearInterval when you're done with it, these functions can keep your application alive and prevent associated data from being garbage collected.

let intervalId = setInterval(() => {
  console.log("This keeps running...");
}, 1000);

// If we don't do this:
// clearInterval(intervalId);

Dangling Event Listeners:

When you add event listeners (like responding to a button click) to elements in your web page, and then you remove those elements from the page, the event listeners might still be hanging around in the background, holding references to the removed elements.

const button = document.getElementById('myButton');
function handleClick() {
  console.log('Button clicked!');
}
button.addEventListener('click', handleClick);

// Later, if the button is removed from the DOM:
// button.remove();
// The event listener might still be in memory if not explicitly removed:
// button.removeEventListener('click', handleClick);

Closures Holding Onto Too Much:

Closures in JavaScript are powerful, but if a function's inner scope (its "closure") retains access to large amounts of data even after the outer function has finished executing, it can lead to memory buildup.

function outerFunction(largeData) {
  return function innerFunction() {
    console.log('Data is still here:', largeData.length);
    // Even after outerFunction finishes, innerFunction can still access largeData
  };
}

const bigData = new Array(1000000).fill('*');
const closure = outerFunction(bigData);
// Even if we don't call closure immediately, it 'remembers' bigData

There are different types of leaks too. Some, called "static leaks," might have a fixed size. But the more concerning ones are "dynamic leaks," which grow over time as the user interacts with the application, eventually leading to noticeable performance issues or crashes.

Becoming a Memory Leak Detective: Your Debugging Toolkit

The good news is that modern web browsers come equipped with fantastic developer tools to help you track down these memory gremlins. We'll focus on Google Chrome's DevTools in this guide.

Before we dive into the tools, here are a few good practices to keep in mind:

Use Incognito Mode: This ensures a clean testing environment without browser extensions potentially interfering.
Test Your Production Build: Sometimes, optimizations in your development build can mask memory issues that only appear in the final, production version.
For Angular Users (and other frameworks with build processes): Consider temporarily disabling variable name mangling during your build process. This can make it much easier to understand object names in the DevTools.
Now, let's peek into the essential DevTools tabs for memory leak hunting:

1. The Performance Tab: Getting the Big Picture

The Performance tab gives you a timeline of your application's activity. When investigating memory, look for the "JS heap" graph (usually a blue line). This graph shows how much memory your JavaScript code is using over time.

A healthy application will show this line fluctuating – memory goes up when new things are created, and then dips down when the garbage collector kicks in and reclaims unused memory.

However, if you see the "JS heap" line steadily increasing over time, without significant dips even after periods of inactivity, this is a strong indicator of a potential memory leak. The memory just keeps growing, suggesting that something isn't being released properly.

2. The Memory Tab: Diving into the Details

The Memory tab provides more specific tools for examining your application's memory usage at a granular level. Here are the key instruments:

Heap Snapshots: Imagine taking a freeze-frame picture of all the objects and data currently residing in your application's memory. Heap snapshots allow you to do just that. You can take multiple snapshots at different points in your application's lifecycle and then compare them to see what objects are being created and, crucially, what objects are not being cleaned up. By comparing snapshots before and after performing a specific action in your app, you can identify objects that are accumulating unexpectedly. Look for a positive "Delta" – more objects created than deleted. Consistent patterns across multiple tests can strengthen your suspicion of a leak. You can also inspect the "Retainers" of an object to see what other objects are holding onto it, preventing it from being garbage collected.

Allocations on Timeline: This tool tracks memory allocations in real-time as you interact with your application. As you perform actions like navigating between pages or interacting with components, you'll see spikes in memory usage. This can help you pinpoint which actions are leading to memory being allocated. More importantly, you can see if the allocated memory is being freed afterward. Look for objects that show a consistently growing "Allocated Size" – this could be a sign that those objects are not being properly released.

By using these tools and carefully observing how your application's memory behaves, you can start to identify those sneaky memory leaks.

A Real-World Example: The Case of the Lingering Subscription

Metenski's video provides a great example of a common memory leak in Angular applications: an RxJS subscription that isn't properly unsubscribed when a component is destroyed. This means that even after the component is no longer visible on the screen, the subscription is still active in the background, holding onto the component's instance and preventing it from being garbage collected.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { interval, Subscription } from 'rxjs';
import { takeUntil } from 'rxjs/operators';
import { Subject } from 'rxjs';

@Component({
  selector: 'app-leaky',
  template: `<div>Leaky Component</div>`,
})
export class LeakyComponent implements OnInit, OnDestroy {
  private intervalSubscription: Subscription | undefined;
  private destroy$ = new Subject<void>();

  ngOnInit(): void {
    this.intervalSubscription = interval(1000)
      .pipe(takeUntil(this.destroy$)) // Prevents leak
      .subscribe(() => {
        console.log('Tick...');
      });
  }

  ngOnDestroy(): void {
    // Without this, the subscription would likely persist, causing a memory leak
    if (this.intervalSubscription) {
      this.intervalSubscription.unsubscribe();
    }
    this.destroy$.next();
    this.destroy$.complete();
  }
}

@Component({
  selector: 'app-fixed',
  template: `<div>Fixed Component</div>`,
})
export class FixedComponent implements OnInit, OnDestroy {
  private intervalSubscription: Subscription | undefined;

  ngOnInit(): void {
    this.intervalSubscription = interval(1000).subscribe(() => {
      console.log('Tick (fixed)...');
    });
  }

  ngOnDestroy(): void {
    if (this.intervalSubscription) {
      this.intervalSubscription.unsubscribe();
    }
  }
}

// Newer Angular versions often recommend using takeUntilDestroyed:
// import { takeUntilDestroyed } from '@angular/core/rxjs';
// ...
// ngOnInit(): void {
//   interval(1000)
//     .pipe(takeUntilDestroyed(this.destroyRef))
//     .subscribe(() => {
//       console.log('Tick (modern Angular)...');
//     });
// }

The solution? Using operators like takeUntilDestroyed (available in newer versions of Angular) or manually unsubscribing in the component's ngOnDestroy lifecycle hook ensures that the subscription is cleaned up when the component is no longer needed, preventing the memory leak.

What's Next?

This is just the beginning of our journey into the world of memory leak detection! In the next part of this guide , we'll delve into another common type of memory leak: detached DOM elements – elements that are no longer attached to the visible page but are still being held in memory.

So, keep an eye out for Part 2, and in the meantime, start experimenting with the Performance and Memory tabs in your browser's DevTools. Happy debugging!