DEV Community: Kalyan P C

Understanding Reactive Context in Angular(v21)

Kalyan P C — Mon, 02 Feb 2026 19:02:46 +0000

In the Angular Signal system, a Reactive Context is a special environment where Angular’s "dependency tracking engine" is turned on. It is the invisible bubble that allows Signals to know who is watching them.

If you read a Signal inside a reactive context, you are automatically "subscribed" to it. If you read a Signal outside of one, it’s just a normal function call with no future updates.

What creates a Reactive Context?

Only a few specific places in Angular create this special environment:

template: When you call mySignal() in your HTML, the template creates a reactive context.
computed(): The function inside a computed signal is a reactive context.
effect(): The function body of an effect is a reactive context.

Things to remember when working in reactive context

Its Ok to use signals inside effect

constructor() {
   effect(() => {
      const x = mySignal() // ✅ this is fine
   });
}

Don't do this

❌ Causing side effects.
❌ Creating or updating signals inside reactive context

readonly x = signal(0);
readonly y = signal(0);

  readonly c = computed(() => {
    const total = this.x() + this.y();
    return {sum : signal(total)}; // ❌ BAD practice
  });

readonly x = signal(0);

  readonly c = computed(() => {
    this.x.update(v => v + 1); // ❌ BAD practice
  });

❌ Calling API which could update signals
❌ Changing DOM directly
Avoid conditional effects like:
- ❌ Creating effect inside effect. It’s technically possible but creates a nightmare for memory management and logic flow.
- ❌ Creating signal inside effect

effect(()=> {
    if (this.x() > 10) {
      effect(() => console.log(this.x())); // ❌ BAD practice
    }
  });

Effects are meant to trigger changes but not to other signals

Signal change batching in Angular

It refers to the process where angular groups multiple signal changes together and process them at once rather than individually. This helps to improve performance by reducing unnecessary re-execution of effects and re-computations. And because of batching, you should not change signals in side effects.

Angular lets you run your code synchronously. It tracks all the signals that you modify and then when the task is completed, it schedules a code that checks for changes and then decides which effects to run.

If inside one of the effects you modify a signal, you can think about it as doing it too late. This can cause cyclic dependencies or infinite loops.
So effects should only focus on things like logging, rendering things that do not affect changes in signals.
It is a good practice not to run, not to trigger business logic inside effects, because you can never know which services or APIs in your business logic may cause signals to change.

So you might ask yourself, what should I do with effects?

Effects should mostly be used for things like logging, rendering, updating local storage. And in fact, when you think about rendering, this is exactly what angular does. Every one of your templates is run like an effect. So when you change signals, the template is re-evaluated pretty much like any other code running inside an effect.

So this is how the mechanism of change detection without zone works.

Thanks for reading. Happy coding!!!

References:

Effects and InjectionContext in Angular(v21)

Kalyan P C — Sat, 31 Jan 2026 19:42:58 +0000

Mastering the Life of an Effect: Injection Context and Beyond

To understand why an effect() behaves the way it does, we have to look at the "hidden" environment it lives in. In Angular, an effect isn't just a function; it’s a managed resource that depends on the framework's Dependency Injection (DI) system to survive and clean up after itself.

1. The Injector: The "Source of Truth"

The Injector is a container that holds instances of services and dependencies. In Angular, there is a hierarchy of injectors (Environment Injector, Component Injector, etc.).

When you create an effect, it needs to be "anchored" to an Injector. The Injector provides the effect with the services it might need and, more importantly, determines the lifetime of the effect.

2. Injection Context: The "Where" and "When"

Injection Context is a specific state during code execution where the inject() function is available. Also think of it as the period of time when the object(Component or Directive etc) is constructed.
By default, you have an Injection Context in:

The constructor of a class.
Field initializers (e.g., myService = inject(MyService)).
The factory function of a Provider.

Why does effect need it?
When you call effect(() => { ... }) in a constructor, Angular implicitly looks for the current Injection Context to find and "inject" the DestroyRef. It uses this to know exactly when to "kill" the effect so it doesn't cause memory leaks.

3. The inject() Function: The Modern Fetcher

The inject() function is the programmatic way to get a dependency from the current Injection Context.

If you try to create an effect inside a regular method (like a button click), it will fail because that method doesn't have an Injection Context.

// ✅ WORKS: In the constructor/class init
count = signal(0);
myEffect = effect(() => console.log(this.count())); 

// ❌ FAILS: Outside injection context
updateData() {
  effect(() => { ... }); // Error: inject() must be called from an injection context
}

To fix this, you have to "capture" the injector manually:

export class MyComponent {
  private injector = inject(Injector); // Capture the injector in the constructor

  startManualEffect() {
    // We pass the captured injector to the effect
    effect(() => {
      console.log('Manual effect running!');
    }, { injector: this.injector }); 
  }
}

4. DestroyRef: The "Clean-up Crew"

DestroyRef is a modern replacement for the OnDestroy lifecycle hook. It allows you to register cleanup logic anywhere in your code, not just in the class definition.

When an effect is created, it internally "subscribes" to the DestroyRef of its context. When the component or service holding that effect is destroyed, the DestroyRef fires, and the effect is automatically stopped.

Manual Cleanup with DestroyRef
If you are building a custom utility that uses effects, you might use DestroyRef like this:

const dr = inject(DestroyRef);
const sub = mySignal.subscribe(...);

dr.onDestroy(() => {
  console.log('Cleaning up resources!');
  sub.unsubscribe();
});

The runInInjectionContext Helper
Sometimes you have an Injector but you don't want to pass it as an option to every single function. You can "force" a context:

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

runInInjectionContext(this.injector, () => {
  // Anything called in here now has access to inject()
  effect(() => console.log('I have context!'));
});

Code PlayGround:

Key points to remember:

Effects are tied to the Injector.
Injectors use DestroyRef to clean up.
inject() only works when the Injection Context is active.
If you create an effect outside a constructor, you must provide the injector manually.

Happy coding!!!

Linkedsignal in Angular(v21)

Kalyan P C — Thu, 29 Jan 2026 10:04:13 +0000

In the evolving world of Angular Signals, linkedSignal is a specialized tool introduced to solve a specific, frustrating problem: How do I have a Signal that can be updated manually, but also "resets" automatically when another Signal changes?

Before linkedSignal (introduced as an experimental feature in Angular v18.2/19, stable in v20), achieving this required messy workarounds using effect or ngOnChanges.

How `linkedSignal` Works

A linkedSignal is a Writable Signal that is "linked" to a source signal. It behaves like a normal signal (you can .set() it), but it has a built-in "reset" trigger.

Basic Syntax

import { signal, linkedSignal } from '@angular/core';

const shippingOptions = signal(['Standard', 'Express', 'Overnight']);

// This signal is linked to shippingOptions
const selectedOption = linkedSignal(() => shippingOptions()[0]);

// 1. User can change it manually
selectedOption.set('Express');

// 2. If shippingOptions changes, selectedOption resets to the first item automatically!
shippingOptions.set(['Drone', 'Teleport']); 
// selectedOption() is now 'Drone'

Two Ways to Use It

1. Shorthand (Basic Reset)
If you just want the signal to reset to a specific value whenever the source changes, you pass a "computation" function.

const count = signal(0);
const message = linkedSignal(() => `Count is currently ${count()}`);

2. Full Configuration (Custom Reset Logic)
Sometimes you don't just want to reset to a value; you want to decide how to reset based on the previous value.

const options = linkedSignal({
  source: this.shippingOptions,
  computation: (newOptions, previous) => {
    // Logic to decide the new value
    return newOptions.includes(previous?.value) 
      ? previous.value 
      : newOptions[0];
  }
});

When using the previous parameter, it is necessary to provide the generic type arguments of linkedSignal explicitly. The first generic type corresponds with the type of source and the second generic type determines the output type of computation.

Why is it better than an effect?
Before linkedSignal, developers often did this:

// THE OLD, MESSY WAY
effect(() => {
  const source = this.sourceSignal();
  untracked(() => {
    this.writableSignal.set(source); // Manual sync is prone to bugs and loops
  });
});

Custom equality comparison

linkedSignal, as any other signal, can be configured with a custom equality function. This function is used by downstream dependencies to determine if that value of the linkedSignal (result of a computation) changed:

const activeUser = signal({id: 123, name: 'Morgan', isAdmin: true});
const activeUserEditCopy = linkedSignal(() => activeUser(), {
  // Consider the user as the same if it's the same `id`.
  equal: (a, b) => a.id === b.id,
});
// Or, if separating `source` and `computation`
const activeUserEditCopy = linkedSignal({
  source: activeUser,
  computation: (user) => user,
  equal: (a, b) => a.id === b.id,
});

When should you use it?

Use linkedSignal whenever you have Derived State that must remain editable.

Forms: Resetting a "Current Email" field when the "Selected User" changes.
Pagination: Resetting the "Current Page" to 1 when the "Search Query" changes.
Default Values: A "Settings" toggle that defaults to a value from the server but can be overriden by the user.

Code Playground

Hope this helps. Happy coding!!!

References

Angular Docs

What is "effect" in Angular(v21)?

Kalyan P C — Wed, 28 Jan 2026 18:20:46 +0000

While Writable Signals hold data and Computed Signals transform data, an Effect is the "performer".

1. What is an Effect?

An Effect is a function that runs automatically whenever the signals it uses change. Unlike the other two types of signals, an effect doesn't return a value. Instead, it performs a task.

Think of it as a loyal assistant watching your signals. The moment a signal changes, the assistant jumps up and executes the specific job you gave them—like saving a file, updating a chart, or logging a message.

2. Basic Syntax

You define an effect using the effect() function, usually inside a component's constructor.

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

@Component({...})
export class UserProfile {
  username = signal('Harry');

  constructor() {
    // This effect runs immediately once, then every time 'username' changes
    effect(() => {
      console.log(`The username is now: ${this.username()}`);
    });
  }
}

3. What can you do with Effects?

Effects are designed for "side effects"—actions that need to happen because data changed, but aren't part of the UI rendering itself. Can use async functions as well

// async code
effect( async () => await service.set(x) )

// side effects
effect(() => storage.save() )

Effects trigger only once after all the dependent signals are updated(even when updated in multiple places in the code). It will trigger once when the thread is ideal and empty.

Effects are asynchronous and batched
When you update a signal, the effect is "scheduled" to run. It doesn't jump the line and execute immediately. Instead, it waits for the current Microtask to finish.

Think of it like a waiter at a restaurant: if three people at the table order water at different times during the conversation, the waiter doesn't run to the kitchen three times. They wait for you to finish talking, take the whole order, and then make one trip.

count = signal(0);

constructor() {
  effect(() => {
    console.log('Effect ran with:', this.count());
  });
}

updateMultipleTimes() {
  this.count.set(1);
  this.count.set(2);
  this.count.set(3);
  // The console will NOT show 1 and 2. 
  // It will wait until this function is DONE, then log "3".
}

Angular batches updates naturally during any code execution (like an event handler or an HTTP response).

// Even if you update two completely different signals
updateBoth() {
  this.firstName.set('Jane');
  this.lastName.set('Doe');
}

// An effect listening to both 
// will only trigger ONCE after updateBoth() finishes.

Common use cases include:

Logging/Analytics: Sending data to a server when a user reaches a certain milestone.
External APIs: Manually manipulating a non-Angular library (like a D3.js chart or a Google Map).
LocalStorage: Saving the state of a form so the user doesn't lose progress if they refresh.
Custom Notifications: Triggering a "toast" message or a sound effect.

4. The Rules of Effects

To keep your app stable, Angular enforces a few "safety rails" for effects:

No Signal Writes (By Default)
You cannot update a signal inside an effect.

Why? If Signal A triggers an Effect that updates Signal A, you create an infinite loop that crashes your browser.
Exception: If you absolutely must, you can enable allowSignalWrites: true, but it's generally a sign that you should be using a computed signal instead.

Injection Context
Effects must be created where Angular has access to "injection context" (usually the constructor or as a class member). If you try to create an effect inside a random method like onClick(), it will fail unless you manually pass it a reference to the app's injector.

5. Cleaning Up (The `onCleanup` function)

Sometimes an effect starts a task that needs to be stopped before the next run (like a timer or a network request). Effects give you a onCleanup function for this:

effect((onCleanup) => {
  const timer = setInterval(() => {
    console.log('Ping!');
  }, 1000);

  // This runs right before the effect re-runs or the component is destroyed
  onCleanup(() => {
    clearInterval(timer);
  });
});

Code Playground

Think of effect as your bridge to the outside world. It’s the designated spot for "side effects"—like logging or API syncing—that should run automatically and efficiently in the background whenever your state changes.

Thanks for reading. Happy coding!!!

Computed signals in Angular(v21)

Kalyan P C — Wed, 28 Jan 2026 16:52:39 +0000

While Writable Signals are the "storage units" of your application, Computed Signals are the "brains."

Think of a spreadsheet: a Writable Signal is a cell where you type a number (like A1), and a Computed Signal is a formula (like =A1 * 10). You don't manually change the formula's result; it just "knows" to update whenever the source cell changes.

What is a Computed Signal?

A Computed Signal is a reactive value that is derived from other signals. It is read-only—you cannot use .set() or .update() on it. Its value is always synchronized with the signals it depends on.

The Syntax
You create one by passing a derivation function to the computed() helper:

import { signal, computed } from '@angular/core';

const price = signal(100);
const quantity = signal(2);

// This signal automatically tracks price() and quantity()
const total = computed(() => price() * quantity());

<p>Items: {{ total() }}</p>

Why are they so powerful?

1. Lazy Evaluation
This is the "secret sauce" for performance. A computed signal does not calculate its value until you actually read it.

If price changes 100 times but you never show total on the screen, the multiplication logic never runs.

Once you read it, the result is memoized (cached). If you read it again and the price hasn't changed, it returns the cached value instantly.

2. Dynamic Dependency Tracking
Computed signals are incredibly smart. They only track signals that were actually used during the last execution.

const showDiscount = signal(false);
const discount = signal(20);

const finalPrice = computed(() => {
  if (showDiscount()) {
    return price() - discount();
  }
  return price();
});

Note: If showDiscount is false, the finalPrice signal will stop listening to the discount signal entirely. It won't re-calculate even if the discount value changes, saving CPU cycles.

Do's and Don'ts

Do's

It's ok to use more than one signal.

computed(() => x() * y() )

It's ok to use writable or computed signals

computed(() => x() * derived() )

It's ok to use constants or immutable non signal data, because signals are not notified if non signal data changes.

computed(() => x() * Math.PI )

Don'ts

Don't use asynchronous code.

// computed is synchronous, async functions will create another task
// DON'T do this
computed( async () => x() * await calc() })

Don't use changeable data that is not a signal.

// DON'T do this
computed(() => x() * Date.now() )

Don't cause side effects, because angular should be able call computed many times without having to worry about side effects.

// DON'T do this
computed(() =>  x() * j++ )

Don't create or modify other signals.

// DON'T do this
computed(() =>  {
  x.update(v => v + 1);
  x() * 10;
})

Computed Signals are for deriving data. Use them when you need a new value based on other signals (e.g., a filtered list or a total price). They are fast, lazy, and pure.

Thanks for reading. Happy coding!!!

Reference:

Writable signals in Angular(v21)

Kalyan P C — Tue, 27 Jan 2026 14:51:02 +0000

A Writable Signal is the foundation of the new reactive system. While computed signals are for reading and effects are for reacting, Writable Signals are where your data actually lives and breathes.

Think of a Writable Signal as a smart container. You don't just put a value in it; you give the container the ability to broadcast its status to the rest of the app.

1. Creating a Writable Signal

You initialize a signal by calling the signal() function with an initial value. This can be a primitive (string, number, boolean), an array, or a complex object.

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

// A simple counter
const count = signal(7);

// A complex object
const user = signal({ id: 1, name: 'Alex' });

To use the signal in HTML template we need to call the function(as signal is a function that returns a function)

<p>Count: {{count()}}</p>

2. Methods

.set(newValue)

This is the "sledgehammer" approach. It replaces the current value with an entirely new one. It doesn't care what the old value was.
Example: count.set(10);

.update(fn)

This is the most common way to change a signal. You provide a function that takes the current value and returns a new value.
Best for: Mathematical operations or appending to strings.
Example: count.update(current => current + 1);

.asReadonly

Sometimes you want a component to own a signal but prevent other components from changing it. You can expose a read-only version of your writable signal.
Effect: It returns a version of the signal that lacks the .set() and .update() methods.
Example: public readonlyCount = this.count.asReadonly();

3. Handling Objects and Arrays

Because Angular Signals rely on referential integrity to know when to trigger updates, how you update objects matters.

Updating Objects
If you change a property inside an object without changing the object reference, the signal might not realize it needs to notify consumers. The standard practice is to use the spread operator:

// Changing a username
user.update(currentValue => ({ 
  ...currentValue, 
  name: 'Sam' 
}));

Updating Arrays
Similarly, for arrays, you should return a new array reference rather than just pushing into the old one:

const list = signal(['Item 1']);

// Correct way (creates a new array)
list.update(items => [...items, 'Item 2']);

4. Equality Functions (The Secret Power)

By default, signals use a "strict equality" check (===) to decide if they should notify their followers. However, you can give a Writable Signal a custom "brain" to decide what counts as a change.

If you are working with data where === isn't enough (like complex nested objects), you can pass a custom equality function during initialization:

const mySignal = signal({ id: 1 }, {
  equal: (a, b) => a.id === b.id // Only notifies if the ID actually changed
});

Code Playground

In the latest versions of Angular, you can use Signals with two-way data binding. This is incredibly useful for forms. When a user types into an input, the Writable Signal updates automatically.

<input [(ngModel)]="username" />

<p>Hello, {{ username() }}!</p>

This should help you get started working with signals. Thanks for reading. Happy coding!!!.

Introduction to Angular Signals

Kalyan P C — Tue, 27 Jan 2026 14:21:17 +0000

In the world of Angular, Signals represent the biggest shift in how the framework handles data since its inception. Think of a Signal as a "wrapper" around a value that can notify anyone interested when that value changes.

Angular Signals were introduced as a developer preview in Angular 16(released in May 2023). The feature became stable and generally available with the release of Angular 17. Also signal based forms was introduced in Angular 21 (released in November 2025)

Signals provide three main building blocks for managing your application state:

Writable Signals: These are your primary data sources where you can directly set or update values.
Computed Signals: These are read-only signals that derive their value from other signals. They are "lazy"—they only re-calculate when you actually read them and only if their dependencies have changed.
Example: const doubleCount = computed(() => count() * 2);
Effects: An effect is a function that runs whenever the signals it calls change. This is perfect for "side effects" like logging, syncing with LocalStorage, or manual DOM manipulations.

The ultimate goal is to allow Angular to run without Zone.js. This leads to:

Smaller bundle sizes.
Faster initial load times.
Easier debugging (since you aren't digging through massive Zone.js stack traces)

Angular provides a very good documentation and interactive environment to test and understand these concepts. Angular Docs

Thanks for reading. Happy coding!!!

Understanding Promises in JavaScript

Kalyan P C — Sun, 25 Jan 2026 18:00:08 +0000

Promises are a fundamental part of modern JavaScript, introduced in ECMAScript 2015 (ES6). They provide a way to handle asynchronous operations more cleanly and predictably than traditional callbacks.

A Promise is an object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value. It's like a "placeholder" for a value that might not be available yet.

Promises were created to solve callback hell (deeply nested callbacks in async code).
They allow you to write asynchronous code that looks more like synchronous code (especially with async/await, but we'll focus on raw promises here).
Promises are immutable once settled — their value or reason can't change after fulfillment or rejection.

Promise States

Every Promise goes through one of the three states(it starts in "pending" and moves to one of the other two):

Pending: Initial state — the operation is ongoing, neither fulfilled nor rejected.
Fulfilled(Resolved): The operation completed successfully, and the Promise has a value.
Rejected: The operation failed, and the Promise has a reason (usually an Error object)

Creating a Promise

you create a Promise using the Promise constructor, which takes and executor funtion:

const myPromise = new Promise((resolve, reject) => {
  // Async operation here...
  if (success) {
    resolve(value);  // Fulfill with value
  } else {
    reject(reason);  // Reject with reason (e.g., new Error("Failed"))
  }
}

resolve(value): Settles to fulfilled.
reject(reason): Settles to rejected.
the executor runs immediately(synchronously) when the Promise is created.

Handling Promise Outcomes

You attach handlers using methods (these return new Promises for chaining):

.then(onFulfilled, onRejected): Handles fulfillment (first arg) or rejection (second arg).
- If fulfilled → calls onFulfilled(value)
- If rejected → calls onRejected(reason)
.catch(onRejected): Shortcut for .then(null, onRejected) — only handles rejection. Always use .catch — uncaught rejections are bad.
.finally(onFinally): Runs regardless of outcome (no access to value/reason) — useful for cleanup.

Chaining and Error Propagation

Each .then/.catch/.finally returns a new Promise, allowing chaining.
If a handler returns a value → next .then gets that value.
If a handler throws an error or returns a rejected Promise → skips to next .catch.
Unhandled rejections trigger a console warning (and in Node.js, can crash the process if not handled).

Here are some examples to understand how it works

Example 1: Basic Promise Creation and Resolution

A simple Promise that resolves after a delay (simulating async like setTimeout).

const myPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("Success! Data loaded.");
  }, 1000);  // 1 second delay
});

myPromise
  .then(result => {
    console.log("Fulfilled:", result);  // "Fulfilled: Success! Data loaded."
  })
  .catch(error => {
    console.error("Rejected:", error);
  })
  .finally(() => {
    console.log("Finally: Operation complete.");  // Always runs
  });

What happens: Promise starts pending → resolves after 1s → .then runs → .finally runs.

Example 2: Rejection and Error Handling

Simulate a failure.

const failingPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    reject(new Error("Failed to load data."));
  }, 1000);
});

failingPromise
  .then(result => console.log("Won't run:", result))
  .catch(error => console.error("Caught error:", error.message))  // "Caught error: Failed to load data."
  .finally(() => console.log("Cleanup done."));

Key: .then's first handler skips on rejection → .catch handles it.

Example 3: Chaining Promises

Chain multiple async operations.

function fetchUser(id) {
  return new Promise(resolve => {
    setTimeout(() => resolve({ id, name: "Alice" }), 500);
  });
}

function fetchPosts(user) {
  return new Promise(resolve => {
    setTimeout(() => resolve(["Post 1", "Post 2"]), 500);
  });
}

fetchUser(1)
  .then(user => {
    console.log("User:", user);
    return fetchPosts(user);  // Return a new Promise for chaining
  })
  .then(posts => {
    console.log("Posts:", posts);
  })
  .catch(error => console.error("Error in chain:", error));

Output: Logs user after 500ms → posts after another 500ms.
Propagation: If fetchUser rejects → skips to .catch.

Example 4: Error in Chain

Throw inside a handler → propagates.

Promise.resolve(10)
  .then(value => {
    console.log("First:", value);  // 10
    throw new Error("Oops!");     // Throws → rejects next Promise
  })
  .then(value => console.log("Won't run:", value))
  .catch(error => console.error("Caught:", error.message));  // "Caught: Oops!"

Code Playground

Key Concepts

Promise handlers (.then/.catch) run in the microtask queue — higher priority than macrotasks (e.g., setTimeout). They execute after current sync code but before next event loop tick.

async/await (ES2017) builds on Promises, making them look synchronous (e.g., const value = await myPromise;).

Thanks for reading. Happy coding!!!

Build Live search Input with API fetching & cancelling using JavaScript

Kalyan P C — Fri, 23 Jan 2026 12:41:24 +0000

Modern web applications often feature live search or autocomplete fields: as the user types, results appear almost instantly.
To provide a smooth experience we need to solve two important problems:

Don't send an HTTP request after every single keystroke.
When the user types quickly → cancel outdated requests so the UI doesn't show stale or wrong results.

In this article we'll implement exactly this behavior using only vanilla JavaScript — no libraries, no frameworks, no build tools.

Goals of the implementation

Listen and Debounce input (wait a short time after typing stops)
Cancel previous fetch requests when a new search starts
Handle network errors gracefully

Let begin step by step

1. Listen and Debounce input

Add a HTML element to listen

<input type="text" id="searchInput" placeholder="Type to search..." />

Lets create debounce functionality. Debounce waits a certain amount of time after the last keystroke.To create a debounce functionality we can create a timer when input is received and clear the old timer

function debounce(fn, delayMs) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delayMs);
  };
}

Listen to the HTML element and perform debounce behavior and API call fetching

const debouncedSearch = debounce(fetchData, 350); // ← adjust delay to taste

// Event listener
searchInput.addEventListener('input', (e) => {
  const query = e.target.value;
  debouncedSearch(query);
});

2. Cancel previous fetch requests when a new search starts

To achieve the behavior of cancelling the previous request, we will make use of AbortController. It helps in signaling the fetch request to cancel.

Create a new AbortController which has a property called signal (which is an instance of AbortSignal)

let currentAbortController = null; // To track & abort previous requests


currentAbortController = new AbortController();
const signal = currentAbortController.signal;

Perform API call and provide the AbortController's signal

const response = await fetch(
      `https://jsonplaceholder.typicode.com/posts?q=${encodeURIComponent(
        query
      )}`,
      {
        method: 'GET',
        mode: 'cors', // Explicit for CORS compatibility
        signal: signal, // For aborting
      }
    );

To cancel the API call when new input is provided we need to call AbortController's abort method.

When you call .abort(): The signal.aborted boolean switches from false to true. An abort event is fired on the signal object.

// Abort previous request if exists
  if (currentAbortController) {
    currentAbortController.abort();
  }

Then the browser "Unplugs" the request
If you passed that signal to a fetch() call, the browser is "listening" to that signal. As soon as the signal changes:

The HTTP Connection: The browser immediately stops the data transfer. If the request was still uploading or downloading bytes, the browser closes the TCP socket or stops the stream.
Network Activity: If you look at the Network Tab in your browser's Developer Tools, you will see the status of the request change to (canceled).

In your JavaScript code, the fetch() promise (which was "pending") is immediately rejected.

It throws a specific error: DOMException with the name **AbortError**.

3. Handle network errors gracefully

We need to add try/catch logic as AbortError can help trigger the .catch() block

try {
    // fetch data logic ....

    // handle http errors
    if (!response.ok) {
      throw new Error(`HTTP error! Status: ${response.status}`);
    }

    const data = await response.json();
    // handle logic using data ....
  } catch (error) {
    if (error.name !== 'AbortError') {
      // Ignore abort errors
    }
  } finally {
    currentAbortController = null; // Reset after completion
  }

Make sure to abort previous controller before creating new one.

// Function to make API call
async function fetchData(query) {
  // Abort previous request if exists
  if (currentAbortController) {
    currentAbortController.abort();
  }

  // Create new AbortController for this request
  currentAbortController = new AbortController();
  const signal = currentAbortController.signal;

  // fetch data logic...
}

Code Playground

Using this approach only the last meaningful request completes and updates the UI. No dependencies, no build step, works in every modern browser.

Thanks for reading. Happy coding!!!

Evolution of making API Calls in JavaScript

Kalyan P C — Fri, 23 Jan 2026 09:57:46 +0000

The Evolution of API Calls in JavaScript

The ability to fetch data from a server without refreshing the page is what transformed the web from a collection of static documents into the interactive "Web 2.0" we use today.

1. The Early Days: XMLHTTPRequest (AJAX)

In the early 2000s, Microsoft introduced XMLHttpRequest (XHR). It was the first time developers could send and receive data after a page had loaded. This technique became known as AJAX (Asynchronous JavaScript and XML).

Characteristics:

Uses a "callback" based system.
Very verbose and difficult to read.
Handling errors and multiple nested requests led to "Callback Hell."

// The "Old School" Way
// IE5–IE6 style (ActiveX)
var xhr = new ActiveXObject("Msxml2.XMLHTTP");
// or
var xhr = new ActiveXObject("Microsoft.XMLHTTP");

// Modern cross-browser (2006+)
var xhr = new XMLHttpRequest();

xhr.open('GET', 'https://api.example.com/users/123', true);  // true = asynchronous

xhr.onload = function () {
  if (xhr.status >= 200 && xhr.status < 300) {
    var data = JSON.parse(xhr.responseText);
    console.log('Success:', data);
  } else {
    console.error('Request failed. Status:', xhr.status);
  }
};

xhr.onerror = function () {
  console.error('Network error');
};

xhr.send();   // actually sends the request

Pain points → lots of boilerplate, manual state checking, no promises.

2. The Library Era: jQuery AJAX

To solve the verbosity and browser inconsistency issues of the original XMLHttpRequest (XHR), libraries like jQuery became the industry standard. It simplified the syntax significantly and handled cross-browser compatibility behind the scenes.

Characteristics:

Cleaner, more readable code: Much less boilerplate than raw XHR.
Simplified error handling: Integrated success and error callbacks.
Callback-based: Still relied on callbacks (until later versions introduced deferreds/promises).

// The "jQuery" Way
$.ajax({
    url: '[https://api.example.com/data](https://api.example.com/data)',
    method: 'GET',
    success: function(data) {
        console.log(data);
    },
    error: function(err) {
        console.error("Something went wrong");
    }
});

→ Huge productivity boost, but still callback-based.

3. Axios – Promise-based comfort (2014+)

Very popular bridge before Fetch was everywhere.

axios.get("/api/users")
  .then(response => console.log(response.data))
  .catch(error => console.error(error.response?.data));

axios.post("/api/login", { email, password }, {
  headers: { Authorization: "Bearer token" }
});

Features like interceptors, auto JSON, timeout built-in made it win many codebases.

4. Fetch API – the native modern standard (2015 → now)

Promise-based, stream-aware, no extra library.

// Basic GET
fetch("https://api.example.com/data")
  .then(response => {
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return response.json();
  })
  .then(data => console.log(data))
  .catch(err => console.error(err));

// Modern async/await style (2017+)
async function getUsers() {
  try {
    const response = await fetch("/api/users", {
      method: "GET",
      headers: { "Accept": "application/json" },
      credentials: "include" // cookies, etc.
    });

    if (!response.ok) {
      throw new Error(`Error ${response.status}`);
    }

    const data = await response.json();
    return data;
  } catch (err) {
    console.error("Fetch failed:", err);
  }
}

Fetch improvements over XHR

Promise-based → works beautifully with async/await
Stream support (response.body is ReadableStream)
Cleaner aborting (AbortController)
No automatic JSON rejection on 404/500 → you must check response.ok

Code Playground

Current status (2026)

Fetch is the recommended native way in browsers (all modern browsers 100% support since ~2017–2018)
Node.js made Fetch stable in v18 (2022) → v21+ it's the default
Axios still widely used (especially in large codebases needing interceptors, better defaults)
Raw XHR is considered legacy — only used for very specific low-level needs

Thanks for reading. Happy coding!!!

Basic Asynchronous JavaScript

Kalyan P C — Fri, 23 Jan 2026 06:56:18 +0000

In standard JavaScript, code runs line-by-line, waiting for each task to finish before moving to the next. Asynchronous JavaScript breaks this "blocking" behavior, allowing your application to handle time-consuming tasks—like fetching data or loading images—without freezing the user interface.

1. JavaScript is single-threaded

There is only one main thread that executes JavaScript code.
That means only one piece of code can run at a time.

console.log("A");
console.log("B");
console.log("C");
// → A → B → C  (always in this exact order)

2. Most interesting things are asynchronous

Things that take time usually don't block the main thread:

setTimeout, setInterval
DOM events (click, input, scroll…)
Network requests (fetch, XMLHttpRequest)
Promise resolution
File reading/writing (Node.js)
Database queries (Node.js)

These operations are handed off to the browser (Web APIs) or to libuv (Node.js), and JavaScript continues running immediately.

3. Classic example – setTimeout(…, 0)

Even with delay = 0, the callback does not run immediately.

console.log("1 - sync");

setTimeout(() => {
  console.log("3 - timeout callback");
}, 0);

console.log("2 - sync");

// Output:
// 1 - sync
// 2 - sync
// 3 - timeout callback

Why?
setTimeout is a macrotask.
Even with 0 ms delay, it goes to the task queue and only runs after the current call stack is empty.

4. Promises run faster than setTimeout (microtasks vs macrotasks)

console.log("1");

setTimeout(() => console.log("5 - macrotask"), 0);

Promise.resolve()
  .then(() => console.log("3 - microtask"))
  .then(() => console.log("4 - microtask"));

console.log("2");

// Output:
// 1
// 2
// 3 - microtask
// 4 - microtask
// 5 - macrotask

Example to understand the execution flow

async function asyncTask() {
  console.log('Async Start'); // 2. Synchronous
  await Promise.resolve();    // Execution pauses here, rest moves to Microtask Queue
  console.log('Async End');   // 4. Microtask
}

console.log('Start');         // 1. Synchronous

setTimeout(() => {
  console.log('Timeout 1');   // 6. Macrotask

  setTimeout(() => {
    console.log('Timeout 2'); // 10. Macrotask (queued after T1 & T3 runs)
  }, 0);

  Promise.resolve().then(() => {
    console.log('Promise 1'); // 7. Microtask (runs before next Macrotask)
  });
}, 0);

asyncTask();

Promise.resolve().then(() => {
  console.log('Promise 2');   // 5. Microtask
});

setTimeout(() => {
  console.log('Timeout 3');   // 8. Macrotask

  setTimeout(() => {
    console.log('Timeout 4'); // 11. Macrotask (queued after T1 & T3 & T2 runs)
  }, 0);

  Promise.resolve().then(() => {
    console.log('Promise 2'); // 9. Microtask (runs before next Macrotask)
  });
}, 0);


console.log('End');           // 3. Synchronous

Code Playground:

Task Priority Table

Type	Queue	Priority	When it runs	Examples
Synchronous code	Call stack	Highest	Immediately	`console.log`, variable assignments
Microtasks	Microtask queue	Very high	After current task, before next macrotask	`Promise.then`, `queueMicrotask`, `MutationObserver`
Macrotasks	Macrotask / Task queue	Normal	One at a time after microtasks are empty	`setTimeout`, `setInterval`, DOM events, I/O

Key Takeaway:

Synchronous code runs first

Then all microtasks are drained (Promise callbacks, queueMicrotask, MutationObserver)

Then one macrotask is executed (setTimeout, setInterval, events, I/O callbacks…)

Then again all microtasks, then next macrotask, and so on…

The Event Loop will always exhaust the Microtask Queue before moving on to the next item in the Macrotask Queue. This is why a promise resolution will almost always execute before a setTimeout(..., 0).

Thanks for reading. Happy coding!!!

Evolution of Asynchronous JavaScript

Kalyan P C — Thu, 22 Jan 2026 05:30:59 +0000

Asynchronous JavaScript refers to the ability of JavaScript (a single-threaded, event-driven language) to perform non-blocking operations — especially I/O tasks like fetching data from a server, reading files, timers, user events, database queries — without freezing the entire program while waiting for those operations to complete.

JavaScript achieves this through the event loop, call stack, task queues (macrotasks & microtasks), and various language constructs that evolved dramatically over time.

Why Asynchronous Programming Became Necessary

JavaScript was born in 1995 as a browser scripting language. Early web pages were mostly static, but as the web became interactive (AJAX in 2005, Node.js in 2009, SPAs), developers needed to:

Fetch data from servers without reloading the page
Handle user input while background tasks run
Avoid blocking the UI thread (freezing the browser)

This led to a 20+ year evolution of async patterns.

Timeline & Evolution of Asynchronous JavaScript

Year / ECMAScript Version	Feature / Pattern	Introduced in / Standardized	Main Purpose & Why It Was Created	Key Problems It Solved	Main Drawbacks It Introduced
1995–2004	Basic event handlers & `setTimeout`	JavaScript 1.0 → early browsers	Handle clicks, timers, basic interactivity	Simple non-blocking events	No real "async flow control"
~2005–2006	AJAX + XMLHttpRequest callbacks	Browser APIs (not ECMAScript)	Fetch data from server without page reload (Google Maps, Gmail popularized it)	Made dynamic web apps possible	Nested callbacks ("callback hell") started
2009	Node.js popularizes callbacks	Ryan Dahl's Node.js	Server-side JavaScript needed heavy I/O (files, networks) → callbacks everywhere	Non-blocking I/O on server	Callback hell became infamous
~2010–2013	Callback Hell peak	—	Deep nesting for sequential async operations (e.g., multiple API calls)	—	Code became pyramid-shaped, hard to read/debug
2012–2015	Promises (early libraries)	Q, When.js, Bluebird, RSVP	Libraries tried to fix callback hell with chainable objects	Better error handling & chaining	No standard — fragmentation
2015 (ES6 / ES2015)	Native Promises	ECMAScript 2015	Official `Promise` object + `then`, `catch`, `finally`, `Promise.all`, `Promise.race`	Standardized chaining, error propagation, parallel ops	Still verbose for complex flows, no `try/catch`
2015 (ES6)	Generators + `yield`	ECMAScript 2015	Pause/resume functions → early "synchronous-looking" async (with libraries like co)	Avoid nesting, experimental async flow	Required extra library (co, koa), not native async
2017 (ES2017 / ES8)	async / await	ECMAScript 2017	`async function` + `await` keyword → write async code that looks synchronous	Readable sequential code, native try/catch, best developer experience	Built on Promises (still microtask-based)
2017–2020	Async Iterators & `for await...of`	ECMAScript 2018	Handle streams of async data (e.g., fetch streams, WebSockets)	Async iterables/streams	Niche but important for modern APIs
2020–2025	Top-level await	ECMAScript 2022	Use `await` directly at module top-level (no wrapping function needed)	Cleaner module initialization	Only in modules, not scripts
2024–2026	Continued refinements	ECMAScript 2025 / 2026	Better `Promise.allSettled`, explicit resource management, improved async stack traces	Error handling, performance	Mostly incremental

Detailed Explanation of Each Major Step

1. Callbacks (1990s–2010s)

Simplest: pass a function to be called later
Example:

setTimeout(() => console.log("Done"), 1000);
xhr.onload = () => { /* handle response */ };

Problem → Callback Hell (Pyramid of Doom):

api1((res1) => {
  api2(res1.data, (res2) => {
    api3(res2.data, (res3) => { ... });
  });
});

2. Promises (ES2015 – the big turning point)

A Promise is an object representing eventual completion/failure
Chaining + centralized error handling:

fetch(url)
  .then(r => r.json())
  .then(data => process(data))
  .catch(err => console.error(err))
  .finally(() => console.log("Done"));

Solved: Inversion of control, better composition, parallel with Promise.all

3. Generators (ES2015) – experimental bridge

Functions that can pause (yield) and resume
Libraries like co made them look async

co(function* () {
  const res1 = yield fetch(url1);
  const res2 = yield fetch(url2);
});

Mostly a stepping stone — not widely used directly for async

4. async / await (ES2017 – current standard)

Syntactic sugar over Promises
Looks synchronous, but still non-blocking

async function fetchData() {
  try {
    const res = await fetch(url);
    const data = await res.json();
    return data;
  } catch (err) {
    console.error(err);
  }
}

Why it won: Most readable, native try/catch, easiest to reason about

Current State (2026)

async/await + Promises is the dominant pattern for almost all asynchronous JavaScript
Callbacks still exist in older APIs (some event listeners, older libraries)
Generators are rarely used for async flow (more for iterators)
The event loop + microtask queue (Promise callbacks) remains the underlying machinery

In short:

Callbacks → solved non-blocking
Promises → solved readability & errors
async/await → solved developer experience

The journey was about making asynchronous code feel more like synchronous code while preserving JavaScript's non-blocking nature.

Thanks for reading

DEV Community: Kalyan P C

Understanding Reactive Context in Angular(v21)

What creates a Reactive Context?

Things to remember when working in reactive context

Don't do this

Signal change batching in Angular

Effects and InjectionContext in Angular(v21)

Mastering the Life of an Effect: Injection Context and Beyond

1. The Injector: The "Source of Truth"

2. Injection Context: The "Where" and "When"

3. The inject() Function: The Modern Fetcher

4. DestroyRef: The "Clean-up Crew"

Linkedsignal in Angular(v21)

How linkedSignal Works

Two Ways to Use It

Custom equality comparison

When should you use it?

What is "effect" in Angular(v21)?

1. What is an Effect?

2. Basic Syntax

3. What can you do with Effects?

4. The Rules of Effects

5. Cleaning Up (The onCleanup function)

Computed signals in Angular(v21)

What is a Computed Signal?

Why are they so powerful?

Do's and Don'ts

Writable signals in Angular(v21)

1. Creating a Writable Signal

2. Methods

3. Handling Objects and Arrays

4. Equality Functions (The Secret Power)

Introduction to Angular Signals

Understanding Promises in JavaScript

Promise States

Creating a Promise

Handling Promise Outcomes

Chaining and Error Propagation

Example 1: Basic Promise Creation and Resolution

Example 2: Rejection and Error Handling

Example 3: Chaining Promises

Example 4: Error in Chain

Code Playground

Key Concepts

Build Live search Input with API fetching & cancelling using JavaScript

1. Listen and Debounce input

2. Cancel previous fetch requests when a new search starts

3. Handle network errors gracefully

Evolution of making API Calls in JavaScript

The Evolution of API Calls in JavaScript

1. The Early Days: XMLHTTPRequest (AJAX)

Characteristics:

2. The Library Era: jQuery AJAX

Characteristics:

3. Axios – Promise-based comfort (2014+)

4. Fetch API – the native modern standard (2015 → now)

Code Playground

Basic Asynchronous JavaScript

1. JavaScript is single-threaded

2. Most interesting things are asynchronous

3. Classic example – setTimeout(…, 0)

4. Promises run faster than setTimeout (microtasks vs macrotasks)

Example to understand the execution flow

Task Priority Table

Evolution of Asynchronous JavaScript

Why Asynchronous Programming Became Necessary

Timeline & Evolution of Asynchronous JavaScript

Detailed Explanation of Each Major Step

1. Callbacks (1990s–2010s)

2. Promises (ES2015 – the big turning point)

3. Generators (ES2015) – experimental bridge

4. async / await (ES2017 – current standard)

Current State (2026)

References

How `linkedSignal` Works

5. Cleaning Up (The `onCleanup` function)