DEV Community: Nagendra Namburi

🚫 Stop Writing Old JavaScript — ✅ Start Using Modern Built-in APIs (Part 1)

Nagendra Namburi — Thu, 09 Apr 2026 17:42:23 +0000

You're probably writing more code than needed.
Modern JavaScript already solved most of these problems.

🚀 The Problem (Real Talk)

In many production codebases, I still see:

lodash for simple utilities
JSON hacks for deep cloning
manual formatting logic
mutation-heavy patterns

👉 This leads to:

bigger bundle sizes
harder debugging
subtle bugs (especially in React apps)

👉 Modern JavaScript already has built-in solutions for most of these problems.

🎯 What You'll Learn

In this post:

Replace outdated patterns
Write cleaner, safer code
Use modern APIs already available in JavaScript

🧩 Modern APIs You Should Already Be Using

1. Deep Copy Objects (Without Breaking Data)

❌ Old way

const copy = JSON.parse(JSON.stringify(obj));

⚠️ Why this is dangerous

Breaks Date, Map, Set
Removes undefined
Causes hidden bugs

const obj = {
  date: new Date(),
  role: undefined,
  scores: new Map([["math", 95]])
};

const copy = JSON.parse(JSON.stringify(obj));

console.log(copy.date instanceof Date);  // false ❌ — becomes a string
console.log(copy.role);                  // gone ❌  — undefined is stripped
console.log(copy.scores instanceof Map); // false ❌ — becomes {}

✅ Modern way

const copy = structuredClone(obj);

console.log(copy.date instanceof Date);  // true ✅
console.log(copy.role);                  // undefined ✅
console.log(copy.scores instanceof Map); // true ✅

🧠 Real-world use case

// Safely editing form state in React without mutating original
const handleEdit = (user) => {
  const draft = structuredClone(user); // deep copy
  draft.address.city = "Hyderabad";    // safe — original untouched
  setEditingUser(draft);
};

✅ Works with: Date, Map, Set, ArrayBuffer, nested objects
❌ Does NOT clone: functions, DOM nodes, class instances

2. Group Data Without Reduce Hell

❌ Old way

const grouped = users.reduce((acc, user) => {
  const key = user.role;
  acc[key] = acc[key] || [];
  acc[key].push(user);
  return acc;
}, {});

✅ Modern way

const grouped = Object.groupBy(users, user => user.role);

🧠 Real-world use cases

const orders = [
  { id: 1, status: "pending",   item: "Book" },
  { id: 2, status: "delivered", item: "Pen" },
  { id: 3, status: "pending",   item: "Laptop" },
  { id: 4, status: "cancelled", item: "Bag" },
];

const byStatus = Object.groupBy(orders, order => order.status);

console.log(byStatus.pending);
// [{ id: 1, item: "Book" }, { id: 3, item: "Laptop" }]

// Group by price range
const products = [
  { name: "Pen",    price: 20 },
  { name: "Book",   price: 250 },
  { name: "Laptop", price: 55000 },
];

const byRange = Object.groupBy(products, p =>
  p.price < 100 ? "cheap" : p.price < 1000 ? "mid" : "expensive"
);

console.log(byRange.cheap);     // [{ name: "Pen", price: 20 }]
console.log(byRange.expensive); // [{ name: "Laptop", price: 55000 }]

🔁 Also available as Map.groupBy(arr, fn) if you need a Map instead of a plain object

3. Access Last Element

❌ Old way

const last = arr[arr.length - 1];  // verbose
const last = arr.slice(-1)[0];     // creates a new array just for one item

✅ Modern way

const last = arr.at(-1);

🧠 Real-world use cases

const chatHistory = [
  { role: "user",      text: "Hi" },
  { role: "assistant", text: "Hello! How can I help?" },
  { role: "user",      text: "What is JavaScript?" },
];

const lastMessage = chatHistory.at(-1);
console.log(lastMessage.text); // "What is JavaScript?"

// Works on strings too
const filename = "profile-photo-final-v3.png";
const extension = filename.split(".").at(-1);
console.log(extension); // "png"

// Negative indexing
console.log(arr.at(-1)); // last
console.log(arr.at(-2)); // second to last
console.log(arr.at(-3)); // third to last

4. Cancel API Calls

❌ Old way — no real cancellation

// isCancelled flag doesn't stop the network request
let isCancelled = false;

fetch("/api/search?q=hello")
  .then(res => res.json())
  .then(data => {
    if (!isCancelled) updateUI(data); // request still happened ❌
  });

isCancelled = true; // too late, request already in flight

✅ Modern way

const controller = new AbortController();

fetch("/api/data", { signal: controller.signal });

// Actually cancels the network request
controller.abort();

🧠 Real-world use case — Search input

let controller;

searchInput.addEventListener("input", async (e) => {
  // Cancel previous request if user is still typing
  if (controller) controller.abort();

  controller = new AbortController();

  try {
    const res = await fetch(`/api/search?q=${e.target.value}`, {
      signal: controller.signal
    });
    const data = await res.json();
    renderResults(data);
  } catch (err) {
    if (err.name === "AbortError") return; // ignore cancelled requests
    console.error("Search failed:", err);
  }
});

// React useEffect cleanup — cancel fetch on unmount
useEffect(() => {
  const controller = new AbortController();

  fetch("/api/user/profile", { signal: controller.signal })
    .then(res => res.json())
    .then(setUser)
    .catch(err => {
      if (err.name !== "AbortError") console.error(err);
    });

  return () => controller.abort(); // ✅ clean cancel on unmount
}, []);

5. Copy to Clipboard

❌ Old way

// Deprecated — execCommand is removed in many browsers
const el = document.createElement("textarea");
el.value = text;
document.body.appendChild(el);
el.select();
document.execCommand("copy"); // ❌ deprecated
document.body.removeChild(el);

✅ Modern way

await navigator.clipboard.writeText("Hello World");

🧠 Real-world use case

async function copyToClipboard(text) {
  try {
    await navigator.clipboard.writeText(text);
    showToast("✅ Copied!");
  } catch (err) {
    showToast("❌ Failed to copy");
  }
}

// Copy code block on button click
copyBtn.addEventListener("click", () => {
  copyToClipboard(codeBlock.innerText);
});

// Read from clipboard
async function pasteFromClipboard() {
  const text = await navigator.clipboard.readText();
  inputField.value = text;
}

⚠️ Requires HTTPS or localhost
⚠️ User must grant clipboard permission for readText()

6. Style Parent Elements (CSS `:has()`)

❌ Old way — required JavaScript

// Had to use JS to style parents based on children
document.querySelectorAll(".card").forEach(card => {
  if (card.querySelector("img")) {
    card.classList.add("has-image"); // ❌ manual JS
  }
});

✅ Modern way — pure CSS

.card:has(img) {
  border: 2px solid green;
}

🧠 Real-world use cases

/* Style form group when input is focused */
.form-group:has(input:focus) {
  background: #f0f9ff;
  border-color: #3b82f6;
}

/* Highlight option row when its checkbox is checked */
.option:has(input[type="checkbox"]:checked) {
  background: #dcfce7;
  font-weight: bold;
}

/* Error card styling */
.card:has(.error-message) {
  border: 1px solid red;
  background: #fff5f5;
}

/* Nav item active state */
.nav-item:has(a.active) {
  background: var(--primary);
  border-radius: 8px;
}

/* Adjust layout when sidebar has an ad */
.sidebar:has(.ad-banner) ~ .content {
  margin-right: 260px;
}

✅ Supported in all modern browsers (Chrome 105+, Safari 15.4+, Firefox 121+)
🔥 Most powerful CSS selector added in years — eliminates entire JS workaround patterns

7. First Successful Promise

❌ Old way — `Promise.race()` rejects on first failure

// If the fastest promise fails, the whole thing rejects ❌
const result = await Promise.race([
  fetch("/cdn1/data"),
  fetch("/cdn2/data"),
]);

✅ Modern way

// Returns first SUCCESS — ignores failures ✅
const result = await Promise.any([
  fetch("/fast"),
  fetch("/slow")
]);

🧠 Real-world use cases

// Try multiple CDNs — use whichever responds successfully first
const image = await Promise.any([
  fetch("https://cdn1.example.com/logo.png"),
  fetch("https://cdn2.example.com/logo.png"),
  fetch("https://cdn3.example.com/logo.png"),
]);

// Try multiple API regions for lowest latency
const data = await Promise.any([
  fetch("https://api-us.example.com/users"),
  fetch("https://api-eu.example.com/users"),
  fetch("https://api-ap.example.com/users"),
]).then(res => res.json());

// Handle when ALL fail
try {
  const result = await Promise.any([
    fetch("/primary"),
    fetch("/fallback"),
  ]);
} catch (err) {
  if (err instanceof AggregateError) {
    console.log("All sources failed:", err.errors);
  }
}

📊 Promise method cheat sheet

Method	Resolves when	Rejects when
`Promise.all()`	ALL succeed	ANY fails
`Promise.race()`	FIRST settles	FIRST settles as failure
`Promise.allSettled()`	ALL settle	Never
`Promise.any()`	FIRST succeeds	ALL fail

8. Format Currency (and Numbers, Dates, Relative Time)

❌ Old way — fragile string building

// Not locale-aware, breaks for ₹, €, ¥
function formatCurrency(amount) {
  return "$" + amount.toFixed(2).replace(/\B(?=(\d{3})+(?!\d))/g, ",");
}

✅ Modern way

new Intl.NumberFormat("en-US", {
  style: "currency",
  currency: "USD"
}).format(1000);
// $1,000.00

🧠 Real-world use cases

// Multiple currencies — locale-aware automatically
formatCurrency(1000,   "en-US", "USD"); // $1,000.00
formatCurrency(1000,   "en-IN", "INR"); // ₹1,000.00
formatCurrency(1000,   "de-DE", "EUR"); // 1.000,00 €
formatCurrency(100000, "ja-JP", "JPY"); // ¥100,000

const formatCurrency = (amount, locale, currency) =>
  new Intl.NumberFormat(locale, { style: "currency", currency }).format(amount);

// Compact notation — great for dashboards
new Intl.NumberFormat("en", { notation: "compact" }).format(1500000); // 1.5M
new Intl.NumberFormat("en", { notation: "compact" }).format(8300);    // 8.3K
new Intl.NumberFormat("en", { notation: "compact" }).format(980);     // 980

// Percentages
new Intl.NumberFormat("en", { style: "percent" }).format(0.745); // 74.5%

// Format dates — no moment.js needed
new Intl.DateTimeFormat("en-US", {
  weekday: "long",
  year: "numeric",
  month: "long",
  day: "numeric"
}).format(new Date());
// Thursday, April 9, 2026

// Relative time — "2 days ago", "in 3 hours"
const rtf = new Intl.RelativeTimeFormat("en", { numeric: "auto" });

rtf.format(-2, "day");   // "2 days ago"
rtf.format(3,  "hour");  // "in 3 hours"
rtf.format(-1, "day");   // "yesterday"
rtf.format(1,  "week");  // "next week"

✅ Intl handles locale, currency symbols, decimal separators, RTL — all natively
❌ No more moment.js, numeral.js, or regex hacks for basic formatting

🔁 Quick Reference Table

Old Pattern	Modern Replacement	Why Better
`JSON.parse(JSON.stringify(obj))`	`structuredClone(obj)`	Handles Date, Map, Set, undefined
`arr.reduce()` for grouping	`Object.groupBy()`	Readable, zero boilerplate
`arr[arr.length - 1]`	`arr.at(-1)`	Clean negative indexing
isCancelled flag hacks	`AbortController`	Actually cancels the network request
`document.execCommand('copy')`	`navigator.clipboard.writeText()`	Async, no DOM gymnastics
JS-based parent styling	`CSS :has()`	Pure CSS, eliminates JS entirely
`Promise.race()`	`Promise.any()`	Ignores failures, picks first success
`moment.js` / regex	`Intl.NumberFormat` / `Intl.DateTimeFormat`	Native, locale-aware, zero dependencies

📚 Want to Go Deeper?

If you want to master modern JavaScript and web development from scratch to production, check out:

👉 Modern Web Course — jsden.com/courses/modern-web

You'll go beyond tips and actually build things the right way with modern APIs, patterns, and real-world projects.

🎯 Final Thoughts

Modern JavaScript is powerful. You don't need a library for everything.

👉 Stop installing unnecessary packages
👉 Start using built-in APIs
👉 Your bundle size will thank you

Part 2 coming soon — covering Object.hasOwn(), .toSorted(), .with(), .findLast(), URLSearchParams, crypto.randomUUID(), and more.

Did I miss a modern API you love? Drop it in the comments 👇

Building a RAG Chatbot with React/Angular, Node.js, pgvector, and OpenAI

Nagendra Namburi — Wed, 01 Apr 2026 18:22:52 +0000

Most chatbots are lying to your users.

Not maliciously — but when a user asks "why does useEffect run twice in React?" and the bot confidently gives a generic answer that has nothing to do with your course content, that’s a failure.

👉 The bot doesn’t know your product. It just sounds like it does.

So I built a RAG (Retrieval-Augmented Generation) chatbot that answers using real data instead of guessing.

👉 Full Details: https://jsden.com/projects/rag-chatbot

The Problem

Basic chatbot:

User → LLM → Response

Issues:

Hallucinations
Generic answers
No product awareness

The Fix: RAG

New flow:

User → Retrieve → Context → LLM → Response

Instead of guessing, the model answers using your data.

Tech Stack

Frontend: React / Angular
Backend: Node.js (Express)
DB: PostgreSQL + pgvector
Embeddings: OpenAI
LLM: GPT-4

How It Works

1. Chunking

function chunkText(text, size = 500) {
  const chunks = [];
  for (let i = 0; i < text.length; i += size) {
    chunks.push(text.slice(i, i + size));
  }
  return chunks;
}

2. Embeddings

const embedding = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: chunk
});

3. Retrieval

SELECT content
FROM documents
ORDER BY embedding <-> $1
LIMIT 5;

4. Prompt

const prompt = `
Use the context below:

${chunks.join('\n\n')}

Question: ${question}
`;

Challenges

Chunk size tuning
Retrieval accuracy
Hallucination control
Prompt design

Result

Before	After
Guessing	Grounded answers
Generic	Context-aware
Demo	Production

Final Thought

AI is not about calling APIs.

👉 It’s about connecting intelligence with your data.

That’s what RAG does.

👉 Full breakdown + working chatbot:

https://jsden.com/projects/rag-chatbot

Why React State Management Changed - setState to Redux to React Query

Nagendra Namburi — Wed, 18 Mar 2026 23:05:49 +0000

TL;DR — React state evolved from setState → Redux → hooks → Zustand → React Query. The lesson: use the right tool for the right type of state.

👉 The biggest mistake developers made for years: treating server state like client state.

Introduction

Every React developer eventually hits the same frustration:

"My state is getting out of control. Components need data three levels up. API calls are scattered everywhere. Nothing stays in sync."

Over the years, the React community developed several solutions to address this problem. Some worked well. Some created new ones.

Here is the honest timeline:

this.setState — class components (2013)
        ↓
Redux — centralized global store (2015)
        ↓
Context API — stable, built-in (2018)
        ↓
useState / useReducer — hooks era (2019)
        ↓
Zustand / Jotai — lightweight global state (2019-2021)
        ↓
React Query / SWR — server state (2020) ✅

In this blog, we'll walk through each stage — not just what each solution is, but why it exists and what problem it was solving.

One Important Clarification

Redux was not created to replace Context API.

Redux came in 2015 — three years before Context API was stable. Developers used Redux because Context was experimental and unreliable at the time.

Redux filled a real gap. Once hooks and stable Context arrived, lighter alternatives became viable. That is the real story.

1️⃣ this.setState — The Beginning (2013)

React launched with class components and this.setState as the only way to manage state.

Example

class Counter extends React.Component {
  state = { count: 0 };

  increment = () => {
    this.setState({ count: this.state.count + 1 });
  };

  render() {
    return (
      <div>
        <p>{this.state.count}</p>
        <button onClick={this.increment}>Increment</button>
      </div>
    );
  }
}

Evaluation

this.setState worked well for:

isolated component state
UI toggles (open/close, show/hide)
simple form inputs

The Problem — Prop Drilling

As apps grew, state needed to be shared across components.

<App user={user}>
  <Dashboard user={user}>
    <Header user={user}>
      <Avatar user={user} />
    </Header>
  </Dashboard>
</App>

Every intermediate component had to pass props it didn't even use. Developers needed a better solution.

2️⃣ Redux — Centralized Global Store (2015)

Redux was created by Dan Abramov and Andrew Clark in 2015. The idea was simple:

A centralized store for application state. State flows in one direction. Every update is predictable.

Core Concept

Action → Reducer → Store → Component

Example

// Action
const increment = () => ({ type: 'INCREMENT' });

// Reducer
function counterReducer(state = { count: 0 }, action) {
  switch (action.type) {
    case 'INCREMENT':
      return { count: state.count + 1 };
    default:
      return state;
  }
}

// Component
function Counter() {
  const count = useSelector(state => state.count);
  const dispatch = useDispatch();

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => dispatch(increment())}>+</button>
    </div>
  );
}

Middleware for Async — redux-thunk

const fetchUser = (id) => async (dispatch) => {
  dispatch({ type: 'FETCH_USER_LOADING' });
  try {
    const user = await api.getUser(id);
    dispatch({ type: 'FETCH_USER_SUCCESS', payload: user });
  } catch (error) {
    dispatch({ type: 'FETCH_USER_FAILED' });
  }
};

Evaluation

Redux solved:

prop drilling
predictable state updates
time-travel debugging
shared state across the entire app

The Problem — Boilerplate Hell

// Just to fetch one user you needed ALL of this:
const FETCH_USER_LOADING = 'FETCH_USER_LOADING';
const FETCH_USER_SUCCESS = 'FETCH_USER_SUCCESS';
const FETCH_USER_FAILED  = 'FETCH_USER_FAILED';

const fetchUserLoading = () => ({ type: FETCH_USER_LOADING });
const fetchUserSuccess = (user) => ({ type: FETCH_USER_SUCCESS, payload: user });
const fetchUserFailed  = () => ({ type: FETCH_USER_FAILED });

function userReducer(state = {}, action) {
  switch (action.type) {
    case FETCH_USER_LOADING: return { ...state, loading: true };
    case FETCH_USER_SUCCESS: return { ...state, loading: false, user: action.payload };
    case FETCH_USER_FAILED:  return { ...state, loading: false, error: true };
    default: return state;
  }
}
// + middleware + connect + mapStateToProps + mapDispatchToProps

Just to fetch one API endpoint. Developers wanted something simpler.

Note: Modern Redux is no longer boilerplate-heavy thanks to Redux Toolkit (RTK), which simplifies reducers, actions, and async logic significantly. However, many teams still prefer Zustand for its simplicity.

3️⃣ Context API — Built-in Solution (2018)

React 16.3 made the Context API stable. It allowed sharing state across the component tree — no external library needed.

Example

// Create context
const UserContext = createContext(null);

// Provide at the top level
function App() {
  const [user, setUser] = useState(null);
  return (
    <UserContext.Provider value={{ user, setUser }}>
      <Dashboard />
    </UserContext.Provider>
  );
}

// Consume anywhere in the tree
function Avatar() {
  const { user } = useContext(UserContext);
  return <img src={user.avatar} alt={user.name} />;
}

Evaluation

Context API works well for:

authentication state
theme (dark/light mode)
language / locale
simple global config

The Problem — Re-render Performance

Context triggers re-renders for all consumers by default when the value reference changes.

// If ANY value in UserContext changes,
// EVERY component using it re-renders
const { user, theme, language } = useContext(UserContext);

However, this can be optimized using:

context splitting
memoization (React.memo, useMemo)
selectors (with libraries like use-context-selector)

For small apps this is fine. For large apps with frequent updates — it causes serious performance problems.

4️⃣ useState / useReducer — Hooks Era (React 16.8 — 2019)

React 16.8 introduced hooks. This was the biggest shift in React's history.

useState replaced this.setState for functional components. useReducer gave Redux-like patterns without Redux.

useState

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>{count}</p>
      <button onClick={() => setCount(count + 1)}>+</button>
    </div>
  );
}

useReducer — for complex local state

const initialState = { count: 0 };

function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { count: state.count + 1 };
    case 'decrement': return { count: state.count - 1 };
    case 'reset':     return initialState;
    default: return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      <p>{state.count}</p>
      <button onClick={() => dispatch({ type: 'increment' })}>+</button>
      <button onClick={() => dispatch({ type: 'decrement' })}>-</button>
      <button onClick={() => dispatch({ type: 'reset' })}>Reset</button>
    </div>
  );
}

Evaluation

Hooks were a massive improvement:

no more class components
cleaner, simpler code
logic reuse via custom hooks
useReducer for complex state without Redux

But hooks alone didn't fully solve global state or server state. Developers still needed something more.

5️⃣ Zustand / Jotai — Lightweight Global State (2019-2021)

After hooks, a new generation of state libraries emerged. Zustand became one of the most popular choices for lightweight global state — minimal API, no boilerplate, no providers, smart re-renders.

Example

import { create } from 'zustand';

// Create store — no Provider needed!
const useUserStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  clearUser: () => set({ user: null }),
}));

// Use in any component directly
function Avatar() {
  const user = useUserStore(state => state.user);
  return <img src={user.avatar} alt={user.name} />;
}

function LoginButton() {
  const setUser = useUserStore(state => state.setUser);
  return <button onClick={() => setUser(newUser)}>Login</button>;
}

Why Zustand Beats Context for Global State

// Context — re-renders ALL consumers when anything changes
const { user, theme, language } = useContext(AppContext);

// Zustand — only re-renders when YOUR specific slice changes
const user  = useUserStore(state => state.user);
const theme = useThemeStore(state => state.theme);

Evaluation

Zustand solved:

minimal API — easy to learn and use
avoids boilerplate — no actions, reducers, or providers needed
fine-grained re-renders — only re-renders what actually changed

Trade-offs

less structure compared to Redux — no enforced patterns
can become messy in very large apps without discipline

But neither Redux nor Zustand handled server state well. That was still a manual, painful process.

The Biggest Shift in React Thinking

The biggest evolution was not a library — it was a mindset shift.

For years, developers treated all state the same way. Everything went into Redux. Everything was managed manually. That was the real source of complexity.

The breakthrough came when the community finally named the distinction:

Client State vs Server State

Client State

State that lives on the client and is owned by the UI:

UI interactions (open/close, active tab)
form inputs
toggles and local preferences

Server State

State that lives on the server and is only borrowed by the client:

API data
cached responses
remote sync and background updates

Why This Matters

// ❌ Old thinking — everything in Redux
dispatch(fetchUser())       // server state in Redux
dispatch(toggleSidebar())   // client state in Redux

// ✅ New thinking — right tool for right state
const { data } = useQuery(...)     // server state → React Query
const [open, setOpen] = useState() // client state → useState

Treating them the same caused years of unnecessary complexity. Separating them solved it.

6️⃣ React Query / SWR — Server State (2020)

React Query was built specifically for server state.

Example — Fetching Data

import { useQuery } from '@tanstack/react-query';

function UserProfile({ id }) {
  const { data, isLoading, error } = useQuery({
    queryKey: ['user', id],
    queryFn: () => api.getUser(id),
  });

  if (isLoading) return <Spinner />;
  if (error)     return <ErrorMessage />;

  return <div>{data.name}</div>;
}

Example — Updating Data

import { useMutation, useQueryClient } from '@tanstack/react-query';

function UpdateUser() {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: (user) => api.updateUser(user),
    onSuccess: () => {
      queryClient.invalidateQueries(['user']);
    },
  });

  return (
    <button onClick={() => mutation.mutate({ name: 'John' })}>
      Update
    </button>
  );
}

Before vs After React Query

// ❌ Before React Query — manual everything
function UserProfile({ id }) {
  const [user, setUser]       = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError]     = useState(null);

  useEffect(() => {
    setLoading(true);
    api.getUser(id)
      .then(data => { setUser(data); setLoading(false); })
      .catch(err  => { setError(err); setLoading(false); });
  }, [id]);

  if (loading) return <Spinner />;
  if (error)   return <ErrorMessage />;
  return <div>{user.name}</div>;
}

// ✅ After React Query — clean and powerful
function UserProfile({ id }) {
  const { data, isLoading, error } = useQuery({
    queryKey: ['user', id],
    queryFn: () => api.getUser(id),
  });

  if (isLoading) return <Spinner />;
  if (error)     return <ErrorMessage />;
  return <div>{data.name}</div>;
}

React Query handles most server-state concerns automatically

loading and error states
caching and cache invalidation
background refetching
deduplication of requests
pagination and infinite scroll
optimistic updates
synchronization across components

The Modern Mental Model

After this entire evolution, here is the simple answer:

What kind of state is it?
          ↓
Server state (API data)?
  → React Query / SWR

Global UI state (auth, theme, cart)?
  → Zustand / Redux Toolkit / Context (depending on scale)

Complex local state?
  → useReducer

Simple local state?
  → useState

Simple shared state, small app?
  → Context API

Final Comparison

Solution	Year	Best for	Problem
this.setState	2013	Local, isolated	Prop drilling
Redux	2015	Large app global state	Boilerplate hell
Context API	2018	Simple shared state	Re-render performance
useState / useReducer	2019	Local state, hooks era	Not for global/server state
Zustand	2019	Global UI state	Less structure in large apps
React Query	2020	Server / API state	Requires understanding cache & invalidation

Most teams didn't have a state management problem.

They had a state categorization problem.

Conclusion

React state management did not evolve because the previous solutions were bad. Each one was the right answer for its time.

this.setState made sense in 2013 when React was brand new. Redux made sense in 2015 when Context was not yet a stable, practical solution and hooks didn't exist. Hooks made sense when class components became too verbose. Zustand and React Query made sense once developers realized UI state and server state are fundamentally different problems.

The key insight from this entire journey:

Not all state is the same. Stop managing server state like UI state.

Today the recommended approach is:

React Query for anything that comes from an API
Zustand for global UI state
useState / useReducer for everything local
Context API for simple shared config like theme or language

The complexity didn't disappear — we just got better at understanding what kind of problem we were actually solving.

What state management solution are you using in your current project? Are you still on Redux or have you moved to React Query + Zustand? Drop a comment below! 👇

The Evolution of React Reusability Patterns - From Composition to Custom Hooks

Nagendra Namburi — Tue, 17 Mar 2026 03:42:11 +0000

TL;DR — React reusability evolved through four patterns: Composition → HOC → Render Props → Custom Hooks. Each pattern solved the problems of the previous one. Today, Custom Hooks for logic and Composition for UI is the recommended approach.

Introduction

Every React developer eventually hits the same problem:

I wrote this logic in one component… now I need it in five more.

Over the years, the React community developed several patterns to solve this problem. Some worked well. Some created new problems.
The journey of React reusability went through four major patterns:

Component Composition
        ↓
Higher Order Components (HOC)
        ↓
Render Props
        ↓
Custom Hooks ✅

In this blog, we will walk through all four patterns — not just what they are, but why they exist and when to use each one.
By the end, you will have a clear mental model for choosing the right pattern in any situation.

1️⃣ Component Composition — UI Reuse

React's original philosophy is:

Composition over inheritance

Instead of creating large monolithic components, React encourages building small reusable components that can be combined together.

Example

function Card({ children }) {
  return <div className="card">{children}</div>;
}

Usage

<Card>
  <UserList />
</Card>

<Card>
  <ProductList />
</Card>

<Card>
  <h2>Any content I want</h2>
  <Button>Click me</Button>
</Card>

Evaluation

Composition works very well for:

reusable UI
layout flexibility
simple component structure

However, it does not address logic reuse.

For example

data fetching
authentication checks
analytics tracking

When multiple components needed the same logic, developers needed another solution.

2️⃣ Higher Order Components — Logic Reuse via Wrapping

Higher Order Components were introduced to reuse behavior across components.
A HOC is a function that takes a component and returns a new enhanced component.

Example

function withAuth(Component) {
  return function WrappedComponent(props) {
    const user = useAuth();

    if (!user) return <Login />;
    return <Component {...props} />;
  };
}

Usage

const ProtectedDashboard = withAuth(Dashboard);
const ProtectedProfile = withAuth(Profile);
const ProtectedSettings = withAuth(Settings);

Evaluation

HOCs allowed developers to reuse logic such as:

authentication
analytics
permissions
logging

But they introduced new problems.

Wrapper Hell

withAuth(
  withTheme(
    withTracking(
      withPermissions(MyComponent)
    )
  )
)

Other issues included:

difficult debugging — anonymous components in React DevTools
prop collisions — two HOCs passing a prop with the same name
complex component trees — hard to trace where props come from

Developers wanted a more flexible solution.

3️⃣ Render Props — Logic Reuse via Functions

Render Props was introduced to solve the wrapper hell problem of HOCs.

Instead of wrapping a component, a Render Prop passes a function as a prop. The component calls that function with data, and the parent decides what to render.

Example

function MouseTracker({ render }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  const handleMouseMove = (e) => {
    setPosition({ x: e.clientX, y: e.clientY });
  };

  return (
    <div onMouseMove={handleMouseMove}>
      {render(position)}
    </div>
  );
}

Usage

<MouseTracker
  render={({ x, y }) => (
    <h1>Mouse is at {x}, {y}</h1>
  )}
/>

<MouseTracker
  render={({ x, y }) => (
    <Circle cx={x} cy={y} />
  )}
/>

Evaluation

Render Props solved wrapper hell by giving consumers full control over rendering.
Benefits included:

no component wrapping
no prop collisions
flexible UI rendering

However, deeply nested Render Props created a new problem — Callback Hell

<MouseTracker
  render={({ x, y }) => (
    <AuthTracker
      render={({ user }) => (
        <ThemeTracker
          render={({ theme }) => (
            <Dashboard x={x} y={y} user={user} theme={theme} />
          )}
        />
      )}
    />
  )}
/>

Other issues included

hard to read
messy JSX structure
performance concerns due to inline functions re-creating on every render

Developers needed a cleaner solution that lived outside JSX entirely.

4️⃣ Custom Hooks — Logic Reuse the React Way

Custom Hooks were introduced in React 16.8 with the Hooks API.
They allow developers to extract stateful logic into a plain JavaScript function — completely separate from any component or JSX.

Any function that starts with use and calls other React hooks is a Custom Hook.

Example

function useMousePosition() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (e) => {
      setPosition({ x: e.clientX, y: e.clientY });
    };
    window.addEventListener("mousemove", handleMouseMove);
    return () => window.removeEventListener("mousemove", handleMouseMove);
  }, []);

  return position;
}

Usage

function App() {
  const { x, y } = useMousePosition();
  return <h1>Mouse is at {x}, {y}</h1>;
}

function Circle() {
  const { x, y } = useMousePosition();
  return <circle cx={x} cy={y} />;
}

Composing Multiple Hooks

function Dashboard() {
  const { x, y } = useMousePosition();
  const user = useAuth();
  const theme = useTheme();
  const { data, loading } = useFetch("/api/data");

  if (loading) return <Spinner />;

  return <div>...</div>;
}

Clean. Flat. Readable. ✅

Evaluation

Custom Hooks solved every problem introduced by the previous patterns:

no wrapper hell
no prop collisions
no messy JSX
easy to test in isolation
easy to compose multiple hooks together
logic lives completely outside the component

When to Use What

Need to reuse UI layout?
  → Use Composition

Need to reuse logic?
  → Use Custom Hooks

Working with an older codebase?
  → You will likely see HOCs and Render Props
  → Understand them, but prefer Custom Hooks for new code

Conclusion

React's reusability story is one of the best examples of a community-driven evolution in frontend development.

Nobody sat down and planned all four patterns upfront. Each one emerged from real frustration developers faced at scale — and each one made React applications a little cleaner and more maintainable than before.

Here is the simple mental model to take away:

💡 Use Composition when you want to reuse UI.

💡 Use Custom Hooks when you want to reuse logic.

HOCs and Render Props served their purpose well. You will still encounter them in older codebases and popular libraries like React Router and React Query. Understanding them makes you a stronger React developer.

But for new code written today — Custom Hooks is the clear winner.

React did not get here overnight. It took years of real-world experience, community feedback, and a willingness to evolve.
And honestly? That is what makes React so powerful.

Which pattern do you still use most in your codebase? Drop a comment below! 👇

Senior UI Developers in the AI Era: What Skills Will Matter Next?

Nagendra Namburi — Thu, 12 Mar 2026 19:56:02 +0000

Artificial Intelligence is rapidly changing how software is built. Many developers are asking the same question: Will AI replace frontend developers?

The reality is different. AI is not replacing UI developers — it is changing the role.

Instead of building interfaces only for APIs and databases, developers are now building interfaces that interact with AI systems.

Here is a simple roadmap for senior UI developers who want to grow in the AI era.

Phase 1 — AI-Augmented Developer (Now)

The first step is learning how to work effectively with AI tools.

Many developers already use tools like GitHub Copilot, Cursor, or Claude to help write and refactor code. These tools improve productivity but also introduce developers to how AI works in software development.

Another important skill is prompt engineering. AI responses depend heavily on how instructions are written. Learning how to provide context, structure outputs, and guide AI responses becomes an important part of development.

Developers should also understand AI UX patterns such as streaming responses, conversational interfaces, and optimistic UI updates.

Phase 2 — AI Interface Specialist (6–12 Months)

At this stage, developers start integrating AI into real applications.

This usually involves using APIs from providers such as OpenAI, Claude, or Gemini.

Frontend developers build features like:

AI chat interfaces
AI search
document summarization
AI assistants

Developers also solve important UI problems such as latency handling, loading states, partial responses, and error recovery.

Phase 3 — AI Product Engineer (12–24 Months)

With more experience, developers begin building complete AI-powered applications.

Many modern AI products use a technique called Retrieval Augmented Generation (RAG), where user questions are combined with data from a knowledge base before sending it to an AI model.

Examples of products at this stage include AI knowledge assistants, AI support chatbots, developer copilots, and intelligent search systems.

Frontend engineers play a key role in designing interfaces that make these systems usable and understandable.

Phase 4 — Career Paths

After gaining experience with AI systems, developers can move in several directions.

One option is becoming an AI Frontend Architect, focusing on scalable AI design systems and interaction patterns.

Another path is becoming a Full-Stack AI Engineer, working on backend AI systems, RAG pipelines, and AI infrastructure.

Some developers may move into AI Product Leadership, focusing on strategy, product direction, and building AI-driven platforms.

Final Thoughts

AI is not the end of frontend development. Instead, it is creating a new generation of applications.

The developers who succeed in the AI era will combine strong UI engineering skills with AI knowledge and product thinking.

For senior UI developers, this shift is not a threat — it is an opportunity to build the next generation of intelligent software.

DEV Community: Nagendra Namburi

🚫 Stop Writing Old JavaScript — ✅ Start Using Modern Built-in APIs (Part 1)

🚀 The Problem (Real Talk)

🎯 What You'll Learn

🧩 Modern APIs You Should Already Be Using

1. Deep Copy Objects (Without Breaking Data)

❌ Old way

⚠️ Why this is dangerous

✅ Modern way

🧠 Real-world use case

2. Group Data Without Reduce Hell

❌ Old way

✅ Modern way

🧠 Real-world use cases

3. Access Last Element

❌ Old way

✅ Modern way

🧠 Real-world use cases

4. Cancel API Calls

❌ Old way — no real cancellation

✅ Modern way

🧠 Real-world use case — Search input

5. Copy to Clipboard

❌ Old way

✅ Modern way

🧠 Real-world use case

6. Style Parent Elements (CSS :has())

❌ Old way — required JavaScript

✅ Modern way — pure CSS

🧠 Real-world use cases

7. First Successful Promise

❌ Old way — Promise.race() rejects on first failure

✅ Modern way

🧠 Real-world use cases

📊 Promise method cheat sheet

8. Format Currency (and Numbers, Dates, Relative Time)

❌ Old way — fragile string building

✅ Modern way

🧠 Real-world use cases

🔁 Quick Reference Table

📚 Want to Go Deeper?

🎯 Final Thoughts

Building a RAG Chatbot with React/Angular, Node.js, pgvector, and OpenAI

The Problem

The Fix: RAG

Tech Stack

How It Works

1. Chunking

2. Embeddings

3. Retrieval

4. Prompt

Challenges

Result

Final Thought

Why React State Management Changed - setState to Redux to React Query

Introduction

One Important Clarification

1️⃣ this.setState — The Beginning (2013)

Example

Evaluation

The Problem — Prop Drilling

2️⃣ Redux — Centralized Global Store (2015)

Core Concept

Example

Middleware for Async — redux-thunk

Evaluation

The Problem — Boilerplate Hell

3️⃣ Context API — Built-in Solution (2018)

Example

Evaluation

The Problem — Re-render Performance

4️⃣ useState / useReducer — Hooks Era (React 16.8 — 2019)

useState

useReducer — for complex local state

Evaluation

5️⃣ Zustand / Jotai — Lightweight Global State (2019-2021)

Example

Why Zustand Beats Context for Global State

Evaluation

Trade-offs

6. Style Parent Elements (CSS `:has()`)

❌ Old way — `Promise.race()` rejects on first failure