DEV Community: Priya Khanna

🧠 Understanding the JavaScript Event Loop — The Backbone of Asynchronous JavaScript

Priya Khanna — Fri, 02 Jan 2026 10:56:53 +0000

JavaScript is single-threaded, yet it powers highly interactive, non-blocking applications. The secret is the Event Loop.

At a high level, JavaScript executes code in three phases:
synchronous code → microtasks → macrotasks — and repeats this cycle continuously.

The call stack runs all synchronous code first. Once empty, the engine immediately drains the microtask queue, which contains Promise reactions (then, catch, finally) and async/await continuations. Only after all microtasks finish does the engine execute *one macrotask *(such as setTimeout, setInterval, or a UI event). Then the process repeats.

This strict priority model prevents race conditions and ensures application state is always consistent before timers or UI updates occur.

Example

console.log('A');

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

Promise.resolve().then(() => console.log('C'));

console.log('D');

Output

A
D
C
B

Why?
Because Promises (microtasks) always run before timers (macrotasks).

Understanding this model unlocks better debugging, predictable behavior, and high-performance UI development — especially in modern frameworks like React and Vue where state consistency is critical.

Master the Event Loop, and you master JavaScript.

Mastering Array.prototype.filter: A Deep Dive into a Custom Implementation

Priya Khanna — Thu, 04 Dec 2025 12:45:59 +0000

The filter() method is a cornerstone of modern JavaScript development, making array manipulation declarative and clean. But have you ever stopped to consider exactly how it works under the hood?
Implementing standard library functions yourself is an excellent way to understand the subtleties of the language, especially around edge cases like sparse arrays and explicit execution context (thisArg).
Today, we will implement our own version, Array.prototype.myFilter, adhering closely to the official ECMAScript specification.

The Core Requirements

A robust filter implementation needs to satisfy three main criteria:

Immutability: It must return a new array and leave the original untouched.
The Callback: It must execute a provided function for every element and use the return value (true/false) to decide whether to keep the element.
Edge Cases: It must handle the optional thisArg parameter for setting the this context within the callback, and crucially, it must ignore sparse array entries.

The Implementation: Array.prototype.myFilter

Here is the complete, production-grade code:

/**
 * Custom implementation of Array.prototype.filter.
 * Adheres to the ECMAScript specification for sparse arrays and thisArg.
 */
Array.prototype.myFilter = function (callbackFn, thisArg) {
  'use strict';

  if (typeof callbackFn !== 'function') {
    throw new TypeError(callbackFn + ' is not a function');
  }

  // 'this' refers to the array instance the method was called on.
  const O = Object(this);
  const len = O.length >>> 0; // Robust way to get length (handles edge cases like non-numbers)

  const result = [];
  let k = 0; // Source array index
  let N = 0; // Result array index

  while (k < len) {
    // *** The Crucial Sparsity Check ***
    // We use hasOwnProperty to ensure we only process elements that actually exist
    if (Object.prototype.hasOwnProperty.call(O, k)) {
      const kValue = O[k];

      // Call the callback with the correct arguments and context:
      // (currentValue, index, originalArray)
      const testPassed = callbackFn.call(
        thisArg,
        kValue,
        k,
        O
      );

      if (testPassed) {
        result[N] = kValue;
        N++;
      }
    }
    k++; // Move to the next index
  }

  return result;
};

Demystifying the Edge Cases

Let's look at how this implementation handles specific scenarios that simpler implementations often miss.

1. Handling Sparse Arrays
A sparse array has "empty slots," like [, 1, , 3]. Native .filter() ignores these slots entirely, never calling the callback function for them.
The line if (Object.prototype.hasOwnProperty.call(O, k)) is vital here. It differentiates between:

A missing index (e.g., index 0 in [, 1]) -> hasOwnProperty returns false.
An existing index that simply holds an undefined value (e.g., index 0 in [undefined, 1]) -> hasOwnProperty returns true.

const sparse = [1, , 3, undefined, 5];

const result = sparse.myFilter(item => item !== undefined);

// Only index 3 gets processed by the callback; indices 1 and 4 are skipped entirely.
console.log(result);
// Output: [1, 3, 5]

2. Using thisArg (Execution Context)
The second argument to filter allows you to explicitly set what the keyword this refers to inside your callback function. This is powerful for object-oriented filtering.
Our implementation handles this using callbackFn.call(thisArg, ...).

const data =;
const validator = {
  threshold: 30,
  isValid(value) {
    // 'this' here is set to the validator object by myFilter's thisArg
    return value > this.threshold;
  },
};

const validReadings = data.myFilter(
  validator.isValid,
  validator // <-- The thisArg we pass in
);

console.log(validReadings);
// Output: [35, 42]

3. Accessing Index and Array Arguments
Our implementation passes kValue, k (the index), and O (the original array) to the callback. This allows for complex filtering logic:

const array = [1, 2, 3, 4];

const squareEvens = array.myFilter((value, index, arr) => {
  // We can use all arguments provided by the filter implementation
  const square = value * value;
  console.log(`Processing index ${index} with value ${value}`);
  return square % 2 === 0;
});

console.log(squareEvens);
// Output:
// Processing index 0 with value 1
// Processing index 1 with value 2
// Processing index 2 with value 3
// Processing index 3 with value 4
// [2, 4]

Conclusion

Implementing core JavaScript methods from scratch is an illuminating exercise. It highlights the care taken in the ECMAScript specification to handle edge cases predictably.
By using hasOwnProperty and Function.prototype.call, our myFilter implementation is robust, accurate, and ready for prime time (if the native one weren't already built in!).
Happy filtering!

Taming the "God Component": A Framework-Agnostic Guide to the Component Responsibility Score (CRS)

Priya Khanna — Fri, 28 Nov 2025 19:59:19 +0000

Hello fellow front-end engineers!
Whether you build your interfaces with React Hooks, Vue Composition API, Angular Components, or Svelte Stores, we all share a common challenge: preventing our components from becoming sprawling, monolithic nightmares.

These overly complex components—the "God Components"—violate the fundamental principle of Single Responsibility. They handle too much state, too much logic, and too many concerns. This leads to codebases that are frustrating to work with, slow to test, and expensive to maintain.
To combat this, we need an objective, unified metric that transcends specific framework syntax. That metric is the Component Responsibility Score (CRS).

What is the Component Responsibility Score (CRS)?

The Component Responsibility Score (CRS) is a custom, data-driven metric used to quantify how complex and overly scoped a front-end component is. It acts as a health check for component architecture, providing an objective number that signals when a component must be broken down.

The goal is simple:
High CRS = Refactor Alert.

The beauty of the CRS is that it focuses on structural and logical properties, not specific API calls (like useState vs. data()). This makes it universally applicable.

The Four Pillars of the Framework-Agnostic CRS
The CRS is calculated as a weighted sum of four core metrics that exist in every component, regardless of the framework.

1. Lines of Code (LoC)

What it measures: The raw size of the component file (logic + template/JSX).
- Why it matters: Excessive lines of code signal a component that is handling too many visual elements or contains verbose boilerplate.
- Universal Relevance : A file with 500 lines is difficult to read in any language. **
Cyclomatic Complexity (CC)**
- What it measures : The number of independent decision paths in the component's imperative logic. This is counted by checking the number of conditional statements and loops (e.g., if/else, switch, for, ternary operators).
- Why it matters : High complexity directly translates to complex conditional rendering and tricky state transitions. This is the #1 driver of bugs and testing difficulty.
- Universal Relevance: Logic complexity is a programming concept, not a framework one. A complex computed property in Vue is just as risky as a complex useEffect in React. **
State Count (SC)**
- What it measures: The total number of distinct pieces of local, mutable state the component manages.
- Why it matters: Every piece of state increases the component's permutations and side-effects. High state count often means the component is acting as a miniature state manager itself.
- Universal Relevance: This applies to this.state in Angular/React classes, useState hooks in React, data() properties in Vue, or exported let bindings in Svelte.

4. Dependency Count (DC)

What it measures: The number of external services or modules the component imports and uses (excluding framework core imports). This includes API services, utility helpers, third-party libraries, and shared stores.
Why it matters: High dependency count shows the component is responsible for orchestrating too many external systems, violating the SRP.
Universal Relevance: This applies whether you are injecting services in Angular, importing custom hooks in React, or using import statements in any framework.

How to Apply CRS to Your Codebase
The true power of CRS is realized when you set objective thresholds and integrate them into your development lifecycle.

Here are the recommended actions based on the score range:

Low CRS: \bm{< 50}
• Health Status: Healthy/Atomic.
• Action: The component is well-scoped and adheres perfectly to the Single Responsibility Principle. Focus should be on testing and documentation.
Moderate CRS: \bm{50 - 100}
• Health Status: Functional/Boundary.
• Action: The scope is acceptable but should be monitored. It is a critical component managing a specific boundary. Prioritize robust testing and be wary of any changes that push the score higher.
High CRS: \bm{> 100}
• Health Status: Refactor Alert! (e.g., God Component)
• Action: This is a mandatory call to action. The component is doing too much and is now a liability. It must be broken down into smaller, single-purpose units (e.g., separating logic into custom hooks/services and UI into presentation components)

The Universal Benefits of Low CRS
Regardless of your framework preference, adopting the CRS philosophy delivers consistent dividends:

1. Improves Testing: Testing a component with low CC and SC is trivial. You mock fewer dependencies and test fewer execution paths.
2. Enforces Patterns: It naturally pushes developers toward separating Container (logic, state management, fetching) components from Presentation (UI, pure function) components.
3. Enhances Code Review: Code reviewers shift from subjective debates ("This looks big...") to objective numbers ("Your CRS is 145; let's split the data fetching logic into a custom hook/service").
4. Boosts Performance: By keeping components simple and minimizing logic, you inherently reduce the chance of complex side effects and unnecessary re-renders. The "God Component" is a universal anti-pattern in modern web development. By standardizing on the Component Responsibility Score, we equip our teams with the data needed to build cleaner, faster, and more scalable front-ends, no matter which framework is under the hood. What are your thoughts? What other metrics do you use to measure component health in your preferred framework? Let's discuss below!

🚀 Getting Started with Foundation Models on Amazon Bedrock

Priya Khanna — Thu, 18 Sep 2025 07:30:02 +0000

AI without the hassle. That’s the promise of Amazon Bedrock. Instead of building or managing your own AI models, Bedrock gives you direct access to foundation models (FMs)—huge AI systems trained on massive datasets that can handle tasks like:

• ✍️ Text generation – write content or respond to prompts

• 🔎 Text embeddings – turn text into numbers for smarter search

• ❓ Question answering – pull answers from knowledge

• 📝 Summarization – shrink long documents into key points

• 🌍 Translation – switch languages instantly

• 🎨 *Image & video generation *– create visuals from text

• 💬 Chatbots – build conversational assistants

⸻

📦 Supported Foundation Models

Amazon Bedrock integrates models from multiple providers, each with unique strengths:

⚙️ Customization & Integration

The real power of Bedrock is customization:

• Fine-tune models on your own data for more relevant answers

• Integrate into workflows for automation

• Use with RAG systems (Retrieval-Augmented Generation) to pull real-time info from your databases or docs.

🔑 How to Access Bedrock
1. Log into your AWS account
2. Open Amazon Bedrock console
3. Go to Model Catalog
4. Explore models, capabilities, and pricing
5. Enable access (not on by default—see AWS docs for steps)

⸻

🌟 Why Bedrock Matters

For developers, startups, and enterprises, Bedrock removes barriers to AI adoption. You don’t need GPUs, ML experts, or complex infrastructure. Just pick a model, integrate it, and start building.

👉 Bottom line: Amazon Bedrock makes enterprise-grade AI as simple as an API call.

A Quick guide to Dependency injection in JavaScript

Priya Khanna — Mon, 14 Jul 2025 10:25:29 +0000

Introduction: Dependency Injection(DI) might sound like a complex design pattern, but at its core, its a simple technique to make your code more modular, testable and maintainable. Lets look at how DI works in JavaScript and why it's worth using.

What is DI?
Its a pattern where an object or function receives its dependencies from the outside rather than creating them internally.

Without DI

class UserService{
   constructor(){
     this.api= new API();// tightly coupled
   }
}

using DI

class UserService{
   constructor(api){
     this.api= api;// Dependency injected
   }
}

here when we use DI userservice doesn't care how api is created- it gets and use when called.

Why use DI?

Maintainability: You don’t hardcode dependencies — you swap them without rewriting core logic.
Testability: You can inject mocks or stubs, making unit tests a breeze.
Loose coupling: Your components/services aren’t stuck to concrete implementations.

Simple DI example in javaScript

js

// API service that fetches a user (mock implementation)
class API(){
  getUser(){
   return {id:1, name:'Priya khanna'}
  }
}

//UserService depends on API but does not create it internally

class UserService(){
  constructor(api){
   this.api=api;// Dependency injected
  }

  getUserInfo(){
   const user= this.api.getUser();
   return 'User : ${user.name}- ${user.id}'
  }
}

//application entry point
function main(){
 const api= new API();//create the dependency
 const userService= new UserService(api);// DI 

console.log(userService.getUserInfo());



}


main();

Note:

the API class simulates a service that returns the data.
UserService expects an API instance passed in- this is constructor injection.
this pattern makes UserService easily testable and decoupled from API

bash

node di-example.js

Key points:-

Dependency Injection (DI) isn’t exclusive to Angular; it’s a powerful design pattern used across many JavaScript frameworks and libraries to improve modularity, testability, and maintainability.

Here’s a quick overview of how DI appears beyond Angular:

React: While React doesn’t have a built-in DI system like Angular, you can achieve DI-like behavior using Context API or third-party libraries like InversifyJS or BottleJS. These let you inject dependencies into components or hooks, improving decoupling.
Vue.js: Vue supports DI through its provide/inject API, allowing parent components to provide dependencies that child components can inject, enabling flexible dependency management across component trees.
Svelte: Svelte offers a context API similar to Vue’s provide/inject, enabling simple dependency passing without prop drilling.
Node.js: On the backend, frameworks like NestJS (built on top of Express) implement DI extensively, inspired by Angular’s system, to manage service lifecycles and dependencies efficiently.

So, DI is a broadly applicable pattern in the JavaScript ecosystem, implemented differently depending on the framework’s architecture but always aiming to make code cleaner, more modular, and easier to test.

Keeping Your Angular App Up-to-Date: A Practical Guide

Priya Khanna — Tue, 17 Jun 2025 08:30:09 +0000

Upgrading an existing Angular project to the latest stable release sounds daunting, but with the right approach and the power of the Angular CLI, you can move from Angular X to Angular Y in just a few steps—without breaking your build or losing sleep. As a TypeScript-loving Angular dev.

Check Your Current Versions

ng version

Make note of:

Angular CLI version
Framework packages (@angular/core, @angular/cli, etc.)
TypeScript version
Update the Angular CLI Globally
Always start by syncing your global CLI to the latest stable:

npm uninstall -g @angular/cli
npm cache clean --force
npm install -g @angular/cli@latest

Update Your Local CLI & Core Packages

Inside your project directory, run:

ng update @angular/cli @angular/core --allow-dirty

• The CLI will analyze your package.json and suggest peer-dependency updates.
• It applies automatic code migrations (e.g., RxJS imports, template syntax changes).

Tip: If you’ve made local changes to configuration files (like angular.json), remove --allow-dirty and commit/ stash first.

Address Peer Dependencies

After the core update, you might see warnings for libraries like:
• @angular/material
• @ngrx/store
• Third-party modules

Upgrade them individually:

ng update @angular/material
ng update @ngrx/store

Or use npm outdated and bump versions manually in package.json, then:

npm install

Upgrade TypeScript & RxJS

Angular’s latest often requires new TypeScript:

npm install typescript@~5.1 rxjs@~7.8

Double-check tsconfig.json for any deprecated compiler flags (e.g., useDefineForClassFields).

Run & Fix Compiler Errors

ng serve

• Look for template errors (binding syntax, removed APIs).
• Update imports that moved packages (e.g., import { mergeMap } from 'rxjs/operators').
• Refactor any deprecated lifecycle hooks (e.g., replace ngOnChanges patterns).

Verify E2E & Unit Tests

ng test
ng e2e

• Update any test setup for TestBed.configureTestingModule changes.
• Adjust mock modules if the testing API surface changed.

Lint & Format

If you use ESLint:

npm install eslint@latest @angular-eslint/schematics@latest --save-dev
ng g @angular-eslint/schematics:convert-tslint-to-eslint
ng lint

Fix any new lint errors from updated rules.

Performance & Bundle Check

ng build --prod --stats-json
npx webpack-bundle-analyzer dist/stats.json

• Identify any large vendor chunks.
• Lazy-load new feature modules if bundle size spikes.

Final QA & Deploy

• Smoke-test critical flows in staging.
• Validate in multiple browsers.
• Deploy with confidence!

Pro Tips for a Seamless Upgrade
• Branch early: Always perform updates on a dedicated Git branch.
• Commit after each major step: Isolate changes so you can revert if needed.
• Read the Changelog: Angular’s update guide (update.angular.io) highlights breaking changes.
• Automate: Incorporate ng update into your CI for minor patch updates.

Upgrading doesn’t have to be a headache—embrace the CLI, follow structured steps, and keep your Angular app running on the cutting edge. 🚀

Why Front-End Developers Should Use TypeScript in 2025

Priya Khanna — Thu, 27 Mar 2025 07:33:43 +0000

Front-end development is evolving rapidly, and in 2025, TypeScript has become an essential tool for modern web development. While JavaScript remains the core language of the web, TypeScript extends its capabilities, making applications more maintainable, scalable, and bug-free.

If you’re a front-end developer still wondering whether TypeScript is worth the switch, this post will explain why it’s no longer optional in 2025.

Strong Typing Reduces Bugs JavaScript’s dynamic typing makes it easy to introduce runtime errors. TypeScript catches errors at compile time, preventing common mistakes before they even run in the browser.

Example: Preventing Type Errors

// JavaScript (No error until runtime)
function add(a, b) {
  return a + b;
}

console.log(add(5, "10")); // "510" (Oops! Not what we expected)

// TypeScript (Compile-time error)
function add(a: number, b: number): number {
  return a + b;
}

console.log(add(5, "10")); // Error: Argument of type 'string' is not assignable to parameter of type 'number'.

With TypeScript, you detect this issue early, reducing debugging time and making your code more reliable.

⸻

Better Code Completion & Developer Experience

Modern IDEs (VS Code, WebStorm) offer richer autocompletion, refactoring tools, and inline documentation with TypeScript, leading to a smoother development experience.
**
Example: Intellisense in VS Code**

With TypeScript, your editor knows the types of variables and functions, giving you better suggestions and reducing the need for documentation lookups.


const user = {
  name: "Priya",
  age: 30,
};

user. // VS Code will suggest `name` and `age`

In contrast, in JavaScript, you often rely on guesswork or manual documentation.

⸻

Scalability: Maintain Large Codebases Easily

As projects grow, maintaining JavaScript code becomes difficult due to the lack of structure. TypeScript enforces better design patterns, making large applications easier to manage.

Example: Enforcing a Consistent Data Model

// Define a reusable User interface
interface User {
  id: number;
  name: string;
  email: string;
}

// Function that only accepts a User object
function displayUser(user: User) {
  console.log(`User: ${user.name} (${user.email})`);
}

const newUser = { id: 1, name: "Alice", email: "alice@example.com" };
displayUser(newUser); // Works fine

const invalidUser = { id: 2, username: "Bob" };
displayUser(invalidUser); // TypeScript error: Property 'email' is missing

With TypeScript, teams can enforce data consistency, making it easier to onboard new developers and avoid unexpected bugs.

⸻

Seamless Integration with Modern Frameworks (React, Vue, Angular)

In 2025, React, Vue 3, and Angular fully support TypeScript, making it the default choice for large-scale projects.

Example: Type-Safe Props in React


interface ButtonProps {
  label: string;
  onClick: () => void;
}

const Button: React.FC<ButtonProps> = ({ label, onClick }) => (
  <button onClick={onClick}>{label}</button>
);

<Button label="Click Me" onClick={() => alert("Clicked!")} />;
<Button label={42} onClick={() => alert("Clicked!")} />; // Type error

In JavaScript, passing 42 as a label would lead to unexpected behavior at runtime. TypeScript catches the issue early.

⸻

TypeScript is Becoming the Industry Standard

• 80%+ of modern front-end projects use TypeScript as of 2025.

• Big companies (Google, Microsoft, Airbnb, Meta) prefer TypeScript for maintainability.

• New libraries are written in TypeScript, making it easier to adopt.

If you’re applying for high-paying front-end jobs, TypeScript is now a required skill rather than an optional one.

⸻

Future-Proofing: TypeScript Adapts Faster Than JavaScript

TypeScript adds cutting-edge JavaScript features before browsers support them.

Example: Using ECMAScript Features Early

type Fruit = "apple" | "banana" | "orange";

function getFruitColor(fruit: Fruit): string {
  const colors = {
    apple: "red",
    banana: "yellow",
    orange: "orange",
  } as const;

  return colors[fruit];
}

console.log(getFruitColor("banana")); // Works
console.log(getFruitColor("grape")); // TypeScript error

This kind of strict typing prevents errors and isn’t available in plain JavaScript.

⸻

Improved Testing & Debugging

TypeScript reduces reliance on unit tests by ensuring correct types at compile time. This means fewer edge case tests and less debugging.

Example: Catching Errors Without Tests

function getDiscount(price: number, discount: number): number {
  return price - discount;
}

console.log(getDiscount(100, "10%")); // Compile-time error

A JavaScript test suite wouldn’t catch this unless a test was specifically written for it, but TypeScript prevents it entirely.

⸻

Conclusion: TypeScript is a Must-Learn in 2025

If you’re a front-end developer in 2025, TypeScript is no longer a “nice-to-have” skill — it’s a must-have.

✅ Reduces runtime errors

✅ Improves developer experience

✅ Scales well for large projects

✅ Works seamlessly with React, Vue, and Angular

✅ Future-proofs your code

✅ Preferred by top tech companies

It’s time to stop writing buggy JavaScript and switch to TypeScript today!

⸻

💬 What do you think?

Are you already using TypeScript in your projects, or are you still on the fence? Let’s discuss in the comments!