DEV Community: Shanthi's Dev Diary

React 19.3: The Release That Makes React Feel More Native

Shanthi's Dev Diary — Mon, 14 Sep 2026 17:57:00 +0000

React 19.3: The Release That Makes React Feel More Native

React 19.3 is here.

And while this isn't one of those releases where you need to rewrite your entire application, there are a few changes that are genuinely interesting for anyone building modern React applications.

The biggest ones are View Transitions and Fragment Refs, both of which were experimental APIs before becoming stable in React 19.3.

What I find interesting about this release is that React is moving further into an area that frontend developers care about a lot:

How an application feels, not just how it works.

Let's look at the changes that matter.

1. View Transitions are now stable

This is probably the feature that will get the most attention.

React 19.3 introduces the stable <ViewTransition> component, which allows React applications to animate UI changes using the browser's View Transition API.

For example:

import { ViewTransition } from 'react';

function Product({ product }) {
  return (
    <ViewTransition>
      <ProductCard product={product} />
    </ViewTransition>
  );
}

The interesting part isn't simply that React can now animate components.

It's when React decides to animate them.

React understands different kinds of transitions:

enter — something is added
exit — something is removed
update — existing content or styling changes
share — something moves from one place to another

This means animations can become part of the UI transition model instead of being manually wired into every state change.

2. View Transitions work with React Transitions

Here's where this becomes more interesting.

A View Transition is triggered when an update is marked as a React Transition.

For example:

import {
  ViewTransition,
  useState,
  startTransition
} from 'react';

function Component() {
  const [showItem, setShowItem] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShowItem(prev => !prev);
          });
        }}
      >
        {showItem ? 'Hide' : 'Show'}
      </button>

      {showItem && (
        <ViewTransition>
          <Video />
        </ViewTransition>
      )}
    </>
  );
}

React can now connect the state transition with the visual transition.

Updates inside startTransition, Suspense reveals, and updates caused by useDeferredValue can trigger View Transitions.

That distinction is important.

Not every state update should be animated.

An urgent interaction should usually happen immediately.

A non-urgent transition can be animated.

3. `addTransitionType()` gives meaning to a transition

Here's another feature I think developers will find useful.

Imagine a carousel.

When the user clicks Next, you want the slide to move from right to left.

When they click Previous, you want it to move in the opposite direction.

Both actions might update the same piece of state:

setCurrentSlide(...)

So how does the animation know why the state changed?

React 19.3 introduces:

addTransitionType()

For example:

startTransition(() => {
  addTransitionType('next');
  setCurrentSlide(current => current + 1);
});

And:

startTransition(() => {
  addTransitionType('previous');
  setCurrentSlide(current => current - 1);
});

You can then configure different animations based on the transition type.

This is a nice shift in thinking.

Instead of saying:

"Animate this component."

you can say:

"This UI changed because the user went to the next slide."

That additional context gives the animation system more control.

4. Suspense + View Transitions

This is probably my favorite part of the release.

Consider a component that suspends while data is loading.

Normally you might have:

<Suspense fallback={<Loading />}>
  <ProductDetails />
</Suspense>

React 19.3 allows you to wrap the Suspense boundary with ViewTransition.

<ViewTransition>
  <Suspense fallback={<Loading />}>
    <ProductDetails />
  </Suspense>
</ViewTransition>

When the suspended content becomes available, React can animate the transition from the fallback to the actual content.

But there is an important UX lesson here.

Don't animate everything.

React's documentation recommends that fallbacks appear immediately, while the transition from fallback to final content can be animated. Already-loaded content should ideally appear immediately.

That is a subtle but important distinction.

Animations should make the application feel faster, not make it feel slower.

5. Images and fonts can participate in transitions

View Transitions aren't limited to React components.

React 19.3 also allows images and fonts to participate in Suspense-based loading sequences.

For example:

<ViewTransition>
  <Suspense fallback={<Fallback />}>
    <img src={imageSrc} />

    <style href={fontSrc} precedence="default">
      {`@font-face {
        font-family: 'Fancy';
        src: url(${fontSrc}) format('truetype');
      }`}
    </style>
  </Suspense>
</ViewTransition>

This can help avoid the typical experience where an image or font suddenly appears whenever the browser happens to finish loading it.

Instead, multiple resources can participate in a coordinated loading experience.

For product pages, profile cards, media-heavy interfaces, and dashboards, this could become particularly useful.

6. Fragment Refs are finally stable

The second major feature is Fragment Refs.

We've all encountered this problem.

A component renders multiple elements:

<>
  <Heading />
  <Heading />
  <Heading />
</>

You want a ref to the group.

But there isn't a single DOM element you can attach the ref to.

You could add:

<div>
  ...
</div>

But now you've changed the DOM structure just to support behavior.

That can affect CSS, layout, accessibility, or existing component behavior.

Fragment Refs solve this problem.

React 19.3 allows a ref to be passed directly to a Fragment.

const fragmentRef = useRef(null);

return (
  <Fragment ref={fragmentRef}>
    <Heading />
    <Heading />
    <Heading />
  </Fragment>
);

The ref gives you a FragmentInstance.

7. What can you do with FragmentInstance?

This isn't just a ref that exists for the sake of having a ref.

The FragmentInstance provides several useful operations.

You can:

Add and remove event listeners
Dispatch events
Manage focus
Observe elements
Measure client rectangles
Scroll elements into view
Access the root node
Compare document positions

One particularly interesting use case is an InView component.

Imagine:

<InView onChange={setIsVisible}>
  <Card />
  <Card />
</InView>

The InView component can observe its children without requiring them to have a common DOM wrapper or expose their own refs.

That can make reusable UI components considerably cleaner.

8. A new `browser` API for server rendering

React 19.3 also introduces a browser API in react-dom.

Server rendering creates an interesting problem.

Some components simply don't make sense on the server.

For example:

const timeZone =
  new Intl.DateTimeFormat()
    .resolvedOptions()
    .timeZone;

The user's timezone is a browser concern.

Previously, developers often handled this with:

const [mounted, setMounted] = useState(false);

useEffect(() => {
  setMounted(true);
}, []);

or:

if (typeof window !== 'undefined') {
  ...
}

React 19.3 provides a more direct mechanism:

import { use } from 'react';
import { browser } from 'react-dom';

function TimeZone() {
  use(browser());

  const timeZone =
    new Intl.DateTimeFormat()
      .resolvedOptions()
      .timeZone;

  return <p>{timeZone}</p>;
}

During server rendering, use(browser()) suspends and allows the nearest Suspense fallback to be rendered. On the client, it doesn't suspend.

This is particularly interesting for applications that mix server-rendered and browser-specific experiences.

9. Trusted Types support

Security is another area where React 19.3 gets an important improvement.

React now integrates with the browser's Trusted Types API.

Trusted Types helps protect applications against DOM-based XSS by requiring certain DOM injection APIs to receive trusted objects rather than arbitrary strings.

Previously, React could coerce Trusted Types objects into strings.

React 19.3 now passes these values through without that coercion, allowing browser Trusted Types policies to work correctly.

For applications with strong Content Security Policy requirements, this is a meaningful improvement.

10. Server Components get a small but useful improvement

React 19.3 also makes it possible for Server Components to render Context directly.

Previously, you might create a separate provider component:

export function UserProvider({
  currentUser,
  children
}) {
  return (
    <UserContext value={currentUser}>
      {children}
    </UserContext>
  );
}

Then:

<UserProvider currentUser={currentUser}>
  {children}
</UserProvider>

With React 19.3, a Server Component can render the Context directly:

<UserContext value={currentUser}>
  {children}
</UserContext>

This removes a wrapper whose only purpose was forwarding a value into Context.

It's a relatively small change, but one that can simplify Server Component code.

11. There are also some important fixes

React 19.3 isn't only about new APIs.

The release includes changes to how transitions are rendered, so a slow Transition doesn't hold up unrelated transitions.

There are also fixes around:

useDeferredValue
Context propagation through Suspense
useSyncExternalStore
useEffectEvent
Fast Refresh
Activity
Hydration
Mobile Safari View Transition crashes
Server Components
Form state
DOM behavior

So upgrading isn't just about getting shiny new APIs. There are also stability and correctness improvements underneath.

What actually matters for a React developer?

If I had to narrow React 19.3 down to four things, I'd pick:

1. View Transitions

This can fundamentally improve how navigation and state changes feel.

2. Fragment Refs

A much cleaner way to interact with groups of DOM elements without introducing unnecessary wrappers.

3. `browser()`

A more React-native way of dealing with components that should only render meaningfully in the browser.

4. Trusted Types

An important security improvement for applications with strong CSP and XSS protection requirements.

Should you upgrade immediately?

Not necessarily.

If you're maintaining a production application, I'd first check:

React version compatibility
Next.js/framework compatibility
Third-party libraries
Testing setup
SSR/hydration behavior
Any libraries that depend on React internals

But if you're starting a new application or experimenting with modern React patterns, React 19.3 is worth exploring.

Especially if your application has rich transitions, Suspense-heavy loading experiences, or complex DOM interactions.

The bigger picture

What I find interesting about React 19.3 isn't any single API.

It's the direction.

React has historically focused heavily on rendering UI based on state.

Now we're seeing more attention on the transition between states:

State A
   ↓
Transition
   ↓
State B

How does the UI move?

How does loading feel?

How does content appear?

How do we interact with groups of DOM nodes without destroying the component structure?

How do server-rendered and browser-only experiences coexist?

Those are increasingly important questions for frontend engineering.

Because a technically correct application isn't necessarily a good application.

The best frontend experiences are the ones where users barely notice the transitions between states.

And React 19.3 takes another step in that direction.

If REST APIs Keep Asking, Webhooks Simply Call

Shanthi's Dev Diary — Thu, 06 Aug 2026 15:27:33 +0000

REST API vs Webhook: Stop Asking "Are We There Yet?" 🚗💨

If you've been building applications for a while, you've probably worked with REST APIs.

And at some point, you've probably written something like this:

setInterval(() => {
  checkStatus();
}, 5000);

Congratulations. 🎉

You've successfully taught your application to behave like a kid on a road trip:

"Are we there yet?"
"No."
"Are we there yet?"
"No."
"How about now?"

That's basically polling. 😄

And this is exactly where Webhooks enter the picture.

Let's understand REST APIs vs Webhooks without making it feel like we're reading an RFC document.

🍕 Let's Start With Pizza

Imagine you've ordered a pizza.

You have two ways to know whether it's ready.

REST API Approach

You call the restaurant every 2 minutes.

👩‍💻 You: "Is my pizza ready?"

🍕 Restaurant: "No."

Two minutes later...

👩‍💻 You: "Now?"

🍕 Restaurant: "Still no."

Two minutes later...

👩‍💻 You: "Now?"

🍕 Restaurant: "Please stop calling us."

Finally...

👩‍💻 You: "Now?"

🍕 Restaurant: "YES!"

This is essentially polling an API.

Your application keeps asking the server whether something has changed.

Webhook Approach

Now imagine a slightly smarter restaurant.

You order the pizza and continue watching Netflix.

When the pizza is ready:

🔔 Ding Dong!

The restaurant notifies you.

You didn't ask.

You didn't poll.

You didn't write a setInterval().

You just got notified when something happened.

That's a Webhook.

So, What Exactly Is a REST API?

REST stands for Representational State Transfer.

Which sounds complicated enough to impress someone at a meeting.

But the idea is simple.

A client sends a request.

The server sends a response.

Client
   │
   │  GET /orders/123
   ▼
Server
   │
   │  200 OK
   ▼
{
  "status": "Shipped"
}

The important part is:

The client starts the conversation.

The server isn't randomly calling your frontend at 2 AM saying:

"HEY! ORDER 123 JUST SHIPPED!"

It waits until you ask.

Common REST Methods

Method	Meaning
`GET`	Give me something
`POST`	Create something
`PUT`	Replace something
`PATCH`	Change something
`DELETE`	This relationship isn't working

Okay... technically DELETE removes a resource. 😄

Example REST Request

GET /api/users/101

Response:

{
  "id": 101,
  "name": "Alex",
  "role": "Developer"
}

Simple.

Predictable.

Reliable.

REST APIs are perfect when you know when you need the data.

What Is a Webhook?

A Webhook flips the communication model.

Instead of:

"Hey server, anything new?"

The server says:

"I'll tell you when something happens."

Your application exposes an endpoint:

POST /webhooks/payment

Then another service calls it when an event occurs.

For example:

{
  "event": "payment.completed",
  "orderId": 1234,
  "amount": 250
}

Your application didn't ask for this.

The payment provider sent it because something happened.

That's why Webhooks are often described as:

Event-driven HTTP callbacks.

Or, if you prefer:

"Call me when something interesting happens."

REST API vs Webhook Communication

REST API

Client                      Server

   │                           │
   │──── Anything new? ───────►│
   │◄────── Nope ──────────────│
   │                           │
   │──── Anything new? ───────►│
   │◄────── Still nope ────────│
   │                           │
   │──── Anything new? ───────►│
   │◄────── YES! ──────────────│

Webhook

Application                 Provider

     │                          │
     │                          │
     │       *event occurs*     │
     │                          │
     │◄──── HEY! UPDATE! ───────│
     │                          │
     │────── 200 OK ───────────►│

Much quieter.

Your servers will thank you.

Your cloud bill might too. 😄

Polling vs Push

Let's say you're waiting for a payment to complete.

Polling

GET /payment/status

Pending

Five seconds later:

GET /payment/status

Pending

Again:

GET /payment/status

Pending

Again:

GET /payment/status

Pending

Again:

GET /payment/status

Success

Your server:

"You could've just waited for me to tell you." 😑

Webhook

Payment succeeds.

The payment provider immediately sends:

{
  "event": "payment.success",
  "paymentId": "pay_123"
}

Your application processes it.

Done.

No unnecessary requests.

No polling.

No server harassment.

Real-World Example: GitHub 💻

Imagine building CI/CD without Webhooks.

Your CI server would constantly ask:

Hey GitHub, new commit?

No.

New commit?

No.

New commit?

No.

New commit?

YES!

Instead, when someone pushes code, GitHub sends a Webhook.

{
  "event": "push",
  "repository": "awesome-project",
  "branch": "main"
}

Your pipeline wakes up and starts working.

Meanwhile, the developer who pushed on Friday evening suddenly remembers:

"Maybe I shouldn't have deployed that."

Too late. 🚀

Real-World Example: Payments 💳

Payment systems are one of the best examples of why Webhooks matter.

Your application might initiate a payment using a REST API.

POST /payments

The payment provider responds:

{
  "paymentId": "12345",
  "status": "processing"
}

But the final payment result may happen seconds—or minutes—later.

Instead of repeatedly checking:

GET /payments/12345

GET /payments/12345

GET /payments/12345

The provider sends:

{
  "event": "payment.completed",
  "paymentId": "12345"
}

REST started the process.

Webhook told us how it ended.

A beautiful relationship. ❤️

Unlike some microservices.

Real-World Example: WhatsApp Business 💬

Messaging systems are another perfect example.

Your application sends a message using an API.

POST /messages

The message may go through multiple states:

Sent
  ↓
Delivered
  ↓
Read

You don't want to keep asking:

Is it delivered?

Is it delivered?

Is it delivered?

Did they read it?

Did they read it?

WHY HAVEN'T THEY READ IT?!

At this point, we're no longer debugging.

We're emotionally invested. 😂

Instead, Webhooks notify your application whenever the status changes.

{
  "status": "delivered"
}

Later:

{
  "status": "read"
}

Your application updates accordingly.

REST APIs Are Great At...

REST APIs are ideal when your application needs to actively perform an operation.

For example:

Fetch users
Search products
Create orders
Update profiles
Delete records
Generate reports

Think:

"I need something right now."

Use an API.

Webhooks Are Great At...

Webhooks are ideal when your application needs to react when something happens.

For example:

Payment completed
Order shipped
Message delivered
Email opened
User registered
GitHub push received
Build completed

Think:

"Tell me when something happens."

Use a Webhook.

REST API vs Webhook

Feature	REST API	Webhook
Communication	Request → Response	Event → Notification
Initiated By	Client	Provider
Updates	Polling	Push
Real-Time	Not necessarily	Usually
HTTP Methods	GET, POST, PUT, PATCH, DELETE	Mostly POST
Best For	CRUD & commands	Event notifications
Network Requests	Potentially many	Usually only when needed
Endpoint	Provider exposes API	Consumer exposes endpoint
Developer Mood	🙂	😎

Okay, that last row may not be scientifically verified.

Why Not Use Webhooks for Everything?

At this point, Webhooks might sound magical.

So why not replace APIs completely?

Because imagine asking:

"Webhook, give me all products under ₹1,000."

Webhook:

"That's... not my job."

Webhooks notify you about events.

They aren't designed for arbitrary data retrieval.

Similarly, REST APIs don't magically notify you when something changes unless you ask.

They solve different problems.

The Best Architecture? Use Both 🤝

Most modern integrations use REST APIs and Webhooks together.

For example:

                 USER
                   │
                   │
                   ▼
            REST API Request
             Create Order
                   │
                   ▼
              Application
                   │
                   ▼
            Payment Provider
                   │
                   │
            Payment Completed
                   │
                   ▼
                WEBHOOK
                   │
                   ▼
           Update Database
                   │
                   ▼
           Notify Customer

REST API:

"Please do this."

Webhook:

"Hey! That thing you asked for? It's done."

But Webhooks Come With Responsibilities ⚠️

Webhooks are great, but don't blindly trust incoming requests.

Anyone who discovers your endpoint could potentially send requests to it.

POST /webhook

{
  "payment": "success"
}

Your application:

"Cool! Free money!"

🚨 Absolutely not.

Always verify incoming Webhooks.

Common protections include:

HTTPS
HMAC signatures
Secret tokens
Timestamp validation
Replay protection
Idempotency
Retry handling

Don't Forget Idempotency

Webhook providers may retry events.

That means you might receive:

payment.completed

twice.

If your code blindly processes both:

Webhook #1 → Ship Product

Webhook #2 → Ship Product Again

Customer:

"Wow, amazing service!"

Finance team:

"We need to talk."

Your Webhook handlers should therefore be idempotent.

Processing the same event multiple times should produce the same result as processing it once.

What Happens If Your Webhook Fails?

Suppose the provider sends:

POST /webhook

But your server responds:

500 Internal Server Error

Most Webhook providers implement retry mechanisms.

Something like:

Attempt 1 → Failed

Wait...

Attempt 2 → Failed

Wait longer...

Attempt 3 → Success 🎉

This is commonly implemented using exponential backoff.

So when designing Webhooks, always think about:

Retries
Duplicate events
Event ordering
Failed processing
Logging and monitoring

Because distributed systems have one universal rule:

If something can fail, eventually it will.

Usually in production.

Usually on Friday.

Quick Decision Guide

Ask yourself one question.

Do I need to request something?

YES
 │
 ▼
REST API

Examples:

Get Products
Create Order
Update User
Delete Record

Do I need to know when something happens?

YES
 │
 ▼
WEBHOOK

Examples:

Payment Completed
Order Shipped
Message Delivered
Build Finished

Need both?

Welcome to modern software development. 😄

Final Takeaway

The easiest way to remember the difference is:

REST API

"Hey, do you have an update?"

Webhook

"I'll call you when I have an update."

REST APIs are request-driven.

Webhooks are event-driven.

And in most real-world systems, they work best together.

So the next time you find yourself writing:

setInterval(checkStatus, 5000);

Pause for a second.

Take a deep breath.

And ask:

"Could this have been a Webhook?" 😄

If you enjoyed this article, drop a ❤️, share it with another developer, and let me know:

What's the funniest polling implementation you've seen in production? 😄

Happy Coding! 🚀

Why Firestore Keeps Throwing “Missing Index” Errors — And How to Fix It Like an Engineer

Shanthi's Dev Diary — Wed, 29 Apr 2026 18:52:35 +0000

If you’ve worked with Firestore long enough, you’ve definitely seen this:

“The query requires an index. You can create it here…”

At first, it feels harmless. You click the link, create the index, and move on.

But as your application grows, this turns into:

Random API failures
Broken production queries
Confusing deployment issues
A growing list of manually created indexes

I’ve been there. Let’s break down why this happens—and how to fix it properly.

The Root Cause

Firestore is not a relational database.

Unlike SQL databases that dynamically plan queries, Firestore depends entirely on pre-built indexes.

It automatically indexes single fields, but the moment you write queries like:

db.collection('orders')
  .where('status', '==', 'completed')
  .where('createdAt', '>=', someDate)
  .orderBy('createdAt', 'desc')

Firestore needs a composite index

If it doesn’t exist → your query fails.

How Firestore Thinks

Instead of executing queries dynamically, Firestore does:

“Do I already have an index that exactly matches this query?”

Yes → return results fast
No → throw error

That’s it. No fallback. No query optimization.

The Beginner Workflow (And Why It Breaks)

Most developers follow this flow:

Run query
Get error
Click “Create Index”
Retry

This works… until:

You deploy to staging or production
A teammate runs the same query
CI/CD pipelines execute code

Now the index doesn’t exist there → failure

The Real Problem in Production

Manual index creation leads to:

Environment inconsistencies
Deployment risks
Hard-to-debug runtime errors
Lack of visibility into required indexes

Indexes become tribal knowledge, not code.

The Engineering Fix

1. Version-Control Your Indexes

Export your indexes:

firebase firestore:indexes > firestore.indexes.json

Now you have something like:

{
  "indexes": [
    {
      "collectionGroup": "orders",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "status", "order": "ASCENDING" },
        { "fieldPath": "createdAt", "order": "DESCENDING" }
      ]
    }
  ]
}

This file should live in your repo.

2. Deploy Indexes via CI/CD

firebase deploy --only firestore:indexes

Now your indexes are:

Repeatable
Shareable
Environment-safe

3. Design Queries Before Writing Them

Instead of reacting to errors, think upfront:

What filters will this API support?
What sorting is required?
Will pagination be used?

Design indexes alongside your API.

Avoid Index Explosion

This is where things get messy.

Bad Pattern

.where('status', '==', status)
.where('type', '==', type)
.where('region', '==', region)
.orderBy('createdAt')

This creates combinatorial index explosion.

Better Approach: Denormalization

Instead of multiple filters:

.where('status_type', '==', `${status}_${type}`)

Or simplify queries:

.where('status', '==', status)
.orderBy('createdAt')

Fewer combinations = fewer indexes

Advanced Tricks

Use `in` Queries

.where('status', 'in', ['open', 'pending'])

Reduces multiple queries and index combinations.

Avoid Multiple Range Filters

This won’t work:

.where('createdAt', '>', x)
.where('price', '<', y)

Firestore limitation — redesign your schema.

Use Composite Fields

Instead of:

.where('firstName', '==', 'John')
.where('lastName', '==', 'Doe')

Store:

fullName: "John_Doe"

Backend Best Practice (Node.js)

Always log index errors clearly:

try {
  const snapshot = await query.get();
} catch (err) {
  if (err.code === 9) {
    console.error('Missing Firestore index:', err.message);
  }
  throw err;
}

Frontend (React) Gotcha

Don’t let UI generate random query combinations.

Instead:

Define fixed query patterns
Map UI filters → backend-controlled queries

Your backend should control index complexity, not the UI.

The Mindset Shift

Stop thinking:

“Firestore will figure it out.”

Start thinking:

“Every query must already be indexed.”

Final Thoughts

Firestore is incredibly fast—but only if you respect its rules.

If you:

Treat indexes as code
Design queries upfront
Reduce combinations

You’ll avoid 90% of these errors.

If you’re currently struggling with index errors, don’t just fix them—systematize them.

That’s the difference between a working app and a scalable one.

Web Components: The Most Underrated Feature of the Modern Web

Shanthi's Dev Diary — Sun, 15 Mar 2026 18:57:34 +0000

A few days ago, one of my colleagues casually asked me:

“Do you know Web Components?”

My immediate answer was:

“Yes, of course.”

But a few seconds later I paused and thought:

Wait… what exactly are Web Components?

I had heard about them in tech talks, maybe read about them somewhere, but I couldn’t confidently say:

I had used them in a project
I fully understood how they worked
I knew when to use them

That moment made me curious.

So I started digging deeper… and realized something surprising:

Web Components might be one of the most underrated features of the modern web.

What Are Web Components?

Web Components are a set of native browser APIs that allow developers to create custom, reusable HTML elements.

Instead of relying on framework-specific components like in React, Angular, or Vue, Web Components let you define your own HTML tags.

Example:

<user-card name="Shanthi"></user-card>

Once defined, the browser itself understands this component.

That means the same component can work in:

React apps
Angular apps
Vue apps
Plain HTML pages

Write once, use anywhere.

The 4 Building Blocks of Web Components

Web Components are built on four main browser standards.

1. Custom Elements

Custom Elements allow you to create your own HTML tags.

Example:

class UserCard extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<p>Hello ${this.getAttribute("name")}</p>`;
  }
}

customElements.define("user-card", UserCard);

Now the browser recognizes:

<user-card name="Shanthi"></user-card>

2. Shadow DOM

Shadow DOM provides encapsulation.

This means:

Styles inside the component stay inside the component
External CSS cannot break it

Example:

const shadow = this.attachShadow({ mode: "open" });

shadow.innerHTML = `
  <style>
    p { color: blue; }
  </style>
  <p>Hello from Shadow DOM</p>
`;

Think of it like giving your component its own private DOM and CSS space.

3. HTML Templates

Templates allow you to define reusable HTML structures.

<template id="cardTemplate">
  <div class="card">
    <h3></h3>
  </div>
</template>

JavaScript can clone this template whenever needed.

4. ES Modules

Web Components are usually distributed using JavaScript modules.

import "./user-card.js";

This keeps components modular and reusable across applications.

A Simple Web Component Example

Let’s build a small component.

class HelloWorld extends HTMLElement {
  connectedCallback() {
    const name = this.getAttribute("name") || "Developer";

    this.innerHTML = `
      <style>
        div {
          padding: 10px;
          border: 1px solid #ddd;
          border-radius: 6px;
        }
      </style>
      <div>Hello ${name} 👋</div>
    `;
  }
}

customElements.define("hello-world", HelloWorld);

Usage:

<hello-world name="Shanthi"></hello-world>

Output:

Hello Shanthi 👋

Why Web Components Matter

1. Framework Independence

A single Web Component can work in:

React
Angular
Vue

This is especially useful for organizations managing multiple frontend stacks.

2. Perfect for Design Systems

Web Components are great for building design system libraries.

Example components:

<company-button>
<company-modal>
<company-card>

These can be reused across multiple applications without rewriting them for each framework.

3. Long-Term Stability

Frameworks evolve quickly.

But Web Components are browser standards, meaning they will keep working regardless of which framework becomes popular next.

Fun Facts About Web Components

🧠 Fun Fact #1

Many developers use Web Components without realizing it.

For example, the <video> and <audio> elements behave like complex components built into the browser.

🧠 Fun Fact #2

Google was one of the early promoters of Web Components and created the Polymer library to help developers adopt them.

🧠 Fun Fact #3

Salesforce built their UI framework called Lightning Web Components using this concept.

🧠 Fun Fact #4

Many modern microfrontend architectures use Web Components as a way to integrate applications built with different frameworks.

Why Aren’t Web Components More Popular?

This was the question I kept asking myself.

A few possible reasons:

Framework ecosystems became dominant
Earlier browser support was inconsistent
Developers are more comfortable using framework-specific solutions

But things are changing.

Modern browsers now fully support Web Components, and more teams are exploring them for design systems and cross-framework libraries.

Final Thoughts

It’s funny how a simple question from a colleague made me revisit a concept I had only heard about in passing.

Sometimes, technologies exist in the background for years before we truly notice their potential.

Web Components might not be the most talked-about topic in frontend development, but they offer something powerful:

Reusable UI components that work across frameworks.

And that makes them one of the most underrated features of the modern web.

💡 Now I’m curious

Have you used Web Components in production?

Or are they still one of those technologies you’ve heard about but never explored deeply?

Understanding the Component in React 19

Shanthi's Dev Diary — Wed, 21 Jan 2026 09:09:30 +0000

React 19 continues to push the boundaries of UI performance and control. One of the quieter—but powerful—additions is the <Activity> component.

At first glance, it looks like another conditional rendering helper. But under the hood, <Activity> solves a long-standing problem in React apps:

hiding UI without destroying its state or effects.

Let’s break it down.

🤔 The Problem with Conditional Rendering

In React today, hiding UI usually means unmounting it:

{isVisible && <ChatWindow />}

When isVisible becomes false:

The component unmounts
State is lost
Effects are cleaned up
Timers, subscriptions, and caches reset

This is often not what we want.

🆕 Enter `<Activity>` in React 19

The <Activity> component allows you to:

Hide UI
Keep it mounted
Preserve state, effects, and subscriptions

Think of it as pausing visibility, not lifecycle.

✨ Basic Usage

import { Activity } from "react";

<Activity visible={isVisible}>
  <ChatWindow />
</Activity>

What happens here?

When visible={false}:
- The UI is hidden
- The component stays mounted
When visible={true}:
- The UI reappears instantly
- State is preserved

🧠 How `<Activity>` Thinks

Behavior	Conditional Rendering	`<Activity>`
Component mounted	❌ No	✅ Yes
State preserved	❌ No	✅ Yes
Effects retained	❌ No	✅ Yes
UI visible	Conditional	Controlled

🔥 Real-World Use Cases

1️⃣ Tabbed Interfaces

Switch tabs without losing form input or scroll position.

<Activity visible={activeTab === "profile"}>
  <ProfileForm />
</Activity>

2️⃣ Modals & Drawers

Avoid re-initializing data every time a modal opens.

<Activity visible={isOpen}>
  <SettingsModal />
</Activity>

3️⃣ Background UI

Keep background widgets alive but invisible.

<Activity visible={false}>
  <LiveSyncService />
</Activity>

⚠️ Things to Keep in Mind

<Activity> does not stop effects
Background logic continues running
Use carefully with:
- Polling
- Intervals
- Heavy subscriptions

If you want effects to pause, you must handle that explicitly.

🧩 `<Activity>` vs `Suspense`

Feature	Suspense	Activity
Handles async loading	✅	❌
Controls visibility	❌	✅
Preserves state	⚠️ Partial	✅
Lifecycle remains	❌	✅

They solve different problems and work well together.

🧠 Mental Model

Suspense delays rendering.

Activity hides rendering.

🚀 Why This Matters

<Activity> enables:

Faster UI transitions
Better UX
Fewer unnecessary remounts
More control over component lifecycles

It’s a small API with big architectural implications.

🏁 Final Thoughts

React 19’s <Activity> component is a step toward intentional UI lifecycles—where visibility and existence are no longer the same thing.

If you’ve ever wished for:

“Hide this component, but don’t reset it”

<Activity> is your answer.

💬 Have thoughts or use cases in mind?

Drop them in the comments—let’s discuss React 19 together.

Rethinking React Architecture at Scale: From Hooks to Remote Contexts With Code base

Shanthi's Dev Diary — Tue, 06 Jan 2026 19:34:09 +0000

React hooks, the Context API, and Suspense have completely changed how we build modern React applications. For small to medium-sized apps, these tools work exceptionally well.

But once React applications scale into micro-frontend architectures—with multiple teams, independent deployments, and runtime-loaded bundles—many familiar patterns start to break down.

This post explores why React state management becomes difficult at scale and introduces remote contexts, an architectural approach for sharing state across distributed React applications.

The Reality of Large-Scale React Applications

Modern React systems often consist of:

Multiple micro-frontends
Independent build and deployment pipelines
Runtime-loaded bundles (Module Federation, dynamic imports)
Teams owning isolated business domains

At this point, your frontend is no longer a single application—it’s a distributed system.

And distributed systems demand different architectural thinking.

Why React Context and Hooks Struggle in Micro-Frontends

React Context Stops at Bundle Boundaries

React Context only works within a single React tree.

When providers and consumers live in different bundles, context simply doesn’t cross that boundary.

Prop Drilling Becomes Impossible

When applications are compiled and deployed independently, passing props across boundaries is no longer viable.

Global State Becomes Too Global

To compensate, teams often introduce:

Large Redux stores
Shared event buses
Singleton services

These approaches work, but they introduce new problems:

Tight coupling between teams
Hard-to-debug state flows
Performance bottlenecks
Fear-driven deployments

The Real Problem Isn’t State—It’s Communication

At scale, the challenge isn’t how to store state.

It’s how applications communicate.

Most React state management tools assume:

The same team owns both the state and its consumers.

In micro-frontend architectures:

Ownership is distributed
Consumers are unknown at build time
Load order is unpredictable

This requires a shift—from shared state to shared contracts.

What Are Remote Contexts?

A remote context extends the idea of React Context beyond a single bundle.

Key characteristics:

Lives outside a single React tree
Uses a publish/subscribe model
Supports late subscribers
Preserves the React hook-based developer experience

To a React developer, it still feels like useContext.

Architecturally, it behaves like distributed state management.

Cross-Bundle Messaging in React Architectures

Remote contexts rely on a lightweight messaging layer to communicate across micro-frontends.

This layer can be implemented using:

Module Federation shared modules
BroadcastChannel
postMessage
Custom event transports

The transport mechanism can change.

The architectural pattern stays the same.

Why Remote Contexts Work Well with React

React already provides a solution for consuming external state safely:

useSyncExternalStore.

Remote contexts use this API to:

Remain concurrent-safe
Avoid tearing
Ensure predictable re-renders

React stays local.

State communication becomes distributed.

Example: Distributed React Dashboards

Consider a dashboard where:

One team owns authentication
Another team owns analytics widgets
A third team manages feature flags

Each micro-frontend:

Deploys independently
Publishes updates to remote contexts
Consumes only the data it needs

No shared Redux store.

No direct imports.

No hidden dependencies.

Real-World Challenges (and Why They’re Solvable)

Distributed state introduces real concerns:

Race conditions → solved with snapshot replay
Type safety → enforced through shared TypeScript contracts
Versioning → handled with schema evolution
Debugging → improved through observable context flow

These problems already exist in large systems.

Remote contexts make them explicit and manageable.

Migrating from Redux and Traditional State Management

Remote contexts are not a replacement for local state or Redux.

A practical migration strategy looks like this:

Keep local state local
Expose only cross-application state as remote contexts
Gradually reduce reliance on shared global stores

This allows teams to adopt the pattern incrementally—without rewrites.

When Should You Use Remote Contexts?

Good fit when:

You have multiple micro-frontends
Teams deploy independently
State must be shared across bundles
Global stores cause performance or coordination issues

Not needed when:

Building small or single-team applications
Managing purely local UI state

Architecture should match scale—not trends.

Final Thoughts: React Architecture Must Evolve with Scale

React itself scales well.

What doesn’t scale is applying single-app state management patterns to distributed frontend systems.

Remote contexts allow teams to:

Move independently
Share state intentionally
Preserve the React developer experience

As frontend systems grow, architecture—not libraries—becomes the differentiator.

Working code : https://github.com/shanthipalani/monorepo-react-microfrontend/tree/remote-context-performant

structuredClone() — The Deep Copy Hero JavaScript Deserved 🦸‍♀️

Shanthi's Dev Diary — Wed, 31 Dec 2025 14:29:31 +0000

Let’s be honest.

Every JavaScript developer has broken production at least once because of copying objects the wrong way.

You thought you cloned it.

JavaScript smiled.

Then changed the original too.

Enter structuredClone() — the native deep-cloning superhero that finally says:

“Relax. I got this.”

The Problem: “Why did my original object change?! 😭”

Classic situation:

const user = {
  name: "Shanthi",
  skills: ["JavaScript", "React"]
};

const copy = user;
copy.skills.push("TypeScript");

console.log(user.skills);
// ["JavaScript", "React", "TypeScript"] 😱

You didn’t mean to update the original…

JavaScript just assumed you were feeling adventurous.

The Old (Painful) Way 😬

We all tried this at some point:

JSON.parse(JSON.stringify(obj))

It looks clever.

It feels clever.

But it betrays you silently.

What it breaks:

❌ Date becomes a string
❌ Map, Set vanish into thin air
❌ undefined, NaN, Infinity disappear
❌ Circular references? App crash 💥

Basically, it copies your data and forgets its personality.

Meet `structuredClone()` 🧠✨

JavaScript finally said:

“Okay fine, here’s a proper deep clone.”

const cloned = structuredClone(original);

That’s it.

No imports.

No libraries.

No emotional damage.

What Makes `structuredClone` So Cool?

✅ It actually understands JavaScript data.

It supports:

Objects & Arrays
Date
Map, Set
RegExp
BigInt
TypedArrays
Circular references (YES 🔥)

Basically, real-world data. Not just JSON-shaped dreams.

Example: Deep Clone That Actually Works

const user = {
  name: "Shanthi",
  meta: {
    joined: new Date(),
  },
};

const clone = structuredClone(user);

clone.meta.joined.setFullYear(2030);

console.log(user.meta.joined.getFullYear());
// Still 2024 😌

No side effects.

No surprises.

No apology messages to your team.

Circular References? Bring It On 💪

const obj = {};
obj.self = obj;

const cloned = structuredClone(obj);

console.log(cloned.self === cloned); // true

Old methods would:

❌ Cry
❌ Throw errors
❌ Give up on life

structuredClone just nods politely and continues.

Map & Set — Finally Respected 🫶

const data = {
  map: new Map([["a", 1]]),
  set: new Set([1, 2, 3]),
};

const clone = structuredClone(data);

clone.map.set("b", 2);

console.log(data.map.has("b")); // false 🎉

Your original data remains unbothered.

What It Won’t Clone (And That’s Fair)

Some things simply refuse to be cloned:

❌ Functions (they have commitment issues)
❌ DOM nodes (use cloneNode)
❌ Symbols
❌ WeakMap, WeakSet

Try cloning these and JavaScript will politely throw a DataCloneError instead of silently ruining your data.

Honestly? We appreciate the honesty.

`structuredClone` vs Spread Operator 🥊

const original = { a: { b: 1 } };

const shallow = { ...original };
const deep = structuredClone(original);

shallow.a.b = 2;

console.log(original.a.b); // 2 ❌
deep.a.b = 3;
console.log(original.a.b); // still 2 ✅

Spread operator:

“I’ll copy the top layer and hope for the best.”

structuredClone:

“I’ll copy everything. Thoroughly.”

Performance: Should I Worry?

Faster than JSON.parse(JSON.stringify())
Optimized by modern JS engines
Safe for state cloning and message passing

⚠️ Just don’t clone massive objects in tight loops unless you enjoy performance reviews.

Where You’ll Actually Use This

React state updates (immutability without headaches)
Redux / Zustand / any state manager
Web Workers
Undo / redo features
Caching snapshots
“Why did this mutate?” bug prevention

Browser & Runtime Support 🌍

Good news:

Modern browsers ✅
Node.js 17+ ✅
Deno, Bun ✅

No polyfills. No drama.

Final Thoughts 💭

structuredClone() is:

✅ Native
✅ Safe
✅ Deep
✅ Honest about errors

If you’re still using JSON.parse(JSON.stringify()), it’s okay.

We all grow. 😄

Modern JavaScript has given us a proper deep clone.

Let’s actually use it.

💬 Have you been betrayed by shallow copies before?

Share your cloning horror stories in the comments!

Shallow Copy vs Deep Copy in JavaScript — Quick and Clear explanation

Shanthi's Dev Diary — Tue, 09 Dec 2025 21:11:07 +0000

Copying objects in JavaScript looks easy… until the original object changes when you didn’t touch it.

Congratulations — you’ve encountered shallow copy chaos.

Let’s fix that in the simplest, funniest, most precise way possible.

🧍‍♂️ What Is a Shallow Copy?

A shallow copy only copies the top-level values.

Nested objects? Arrays?

JavaScript just hands you the same reference like a lazy coworker.

Example

const user = {
  name: "Shanthi",
  address: { city: "Chennai" }
};

const copy = { ...user };
copy.address.city = "Coimbatore";

console.log(user.address.city); 
// "Coimbatore" — betrayal detected 💔

Why?

Because only the top-level value (name) was cloned.

The nested object (address) was shared, so modifying it changes the original.

🧠 What Is a Deep Copy?

A deep copy clones every level of the object.

No shared references
No accidental mutations
No “WHY DID THIS CHANGE??” debugging nightmares

Example

const user = {
  name: "Shanthi",
  address: { city: "Chennai" }
};

const deep = structuredClone(user);
deep.address.city = "Coimbatore";

console.log(user.address.city);
// "Chennai" — original untouched ✨

🛠 Copying Methods

🔹 Shallow Copy Methods

{ ...obj }
Object.assign({}, obj)
array.slice()
Array.from()

⚠️ Note: All shallow copy methods copy nested objects by reference, not by value.

🔹 Deep Copy Methods

structuredClone(obj) ← Best + modern
Custom recursive deep clone
JSON.parse(JSON.stringify(obj)) ⚠️ Breaks for:
- Date
- Functions
- undefined
- RegExp
- Circular references

🎯 When Should You Use Which?

✔️ Use Shallow Copy when:

Only top-level values change
The object is simple
You just need a quick non-nested clone

✔️ Use Deep Copy when:

Your data is nested
You need immutability (React, Redux, etc.)
You want predictable, safe updates

🧘 TL;DR Table

Feature	Shallow Copy	Deep Copy
Copies nested values	❌	✅
Safe for complex data	❌	✅
Surprise bugs	High	Low
Best method	Spread / `Object.assign`	`structuredClone()`

🏁 Summary

Shallow and deep copying may sound similar, but they behave completely differently in JavaScript.

A shallow copy only duplicates the first level, leaving nested objects linked and ready to cause sneaky bugs.

A deep copy, however, clones every level, giving you safe, predictable, mutation-free data — especially important in React, Redux, and any place where immutability matters.

When in doubt:

Use shallow copy for simple, flat objects.
Use deep copy for anything nested or important.

Your future debugging sessions will thank you. 🚀

🚀 Client-Side vs Server-Side CORS: Understanding the Real Difference

Shanthi's Dev Diary — Thu, 04 Dec 2025 20:49:34 +0000

If you’ve ever screamed at your monitor because of a mysterious CORS error…

Congratulations — you are officially a web developer. 🎉

CORS is like that strict bouncer outside the club who won’t let you in even though you swear you're on the list.

This blog will finally explain the difference between Client-Side CORS and Server-Side CORS, without making your brain melt like a broken build.

🧐 What Is CORS, Really?

CORS stands for Cross-Origin Resource Sharing — which sounds fancy, but really means:

“Hey browser, can this website talk to that other website? Or is it a stranger danger situation?”

The browser is extremely paranoid.

If domain A calls domain B, the browser goes:

“Hold up. Who sent you? Show me your passport, Aadhar card, PAN card, and two 2x2 photos.”

🤓 Client-Side vs Server-Side CORS: The Plot Twist

People keep saying “client-side CORS” and “server-side CORS,” but here’s the truth:

Only the server decides CORS. The client is just a confused teenager asking for permission.

Still, both sides play a role — so let’s decode them.

🔵 Client-Side CORS (AKA: The Illusion of Control)

Developers be like:

fetch("/api", { mode: "cors" })

And expect the browser to go:

“Yes sir! CORS enabled! You’re a genius!”

But no.

The browser basically says:

“Cute. But I enforce the rules. Sit down.”

Client-side "CORS" is really about how you send the request:

mode: "cors" → “Please let me in!”
mode: "no-cors" → “Fine, I’ll leave. I didn’t want to see the response anyway.”
credentials: "include" → “Here are my cookies, please don’t judge.”

⚠️ But the client CANNOT actually enable CORS.

It’s like trying to unlock a door by telling the door politely.

The server still holds the key.

🟣 Server-Side CORS (The Real Boss Here)

This is where the actual magic happens.

If the server doesn’t approve your origin…

The browser will block you faster than a bad ex.

Servers respond with headers like:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true

Only then does the browser say:

“Okay, fine. I guess you're allowed in.”

Example (Express.js)

app.use(cors({
  origin: "https://myapp.com",
  credentials: true
}));

Example (Next.js API Route)

res.setHeader("Access-Control-Allow-Origin", "https://myapp.com");
res.setHeader("Access-Control-Allow-Credentials", "true");

If you forget even one header?

Boom.

CORS error.

Your day is ruined. Your coffee goes cold. Your teammates hear a scream.

🧪 Simple vs Preflight Requests (AKA: Browser Drama)

The browser sends:

👉 Simple requests

These are chill. The browser is like:

“GET or POST with simple headers? Fine, go ahead.”

👉 Preflight requests

These are drama.

If you use:

PUT, PATCH, DELETE
Custom headers
JSON body

The browser becomes your mom:

“Wait. Before you go, WHERE are you going? Who’s going with you? When will you come back???”

It sends an OPTIONS request first.

If the server doesn’t respond correctly?

Blocked. Again.

🧠 Summary Table for Geniuses Who Scrolled Too Fast

Thing	Client Side	Server Side
Who’s in control?	Lol. Not you.	The real boss.
Can it allow a request?	❌ Nope	✅ Absolutely
Can it trigger preflight?	✅ Yes	⚠️ Must respond properly
Is it real CORS?	❌ No	✅ Yes, 100% legit

Final Thoughts

CORS errors might feel like a personal attack from the universe, but the rule is simple:

Client requests. Server approves. Browser judges.

Just like real life.

If everyone plays their part correctly, CORS becomes easy.

If not… well, enjoy the next 3 hours of debugging. 😅

React.memo vs useMemo

Shanthi's Dev Diary — Sun, 23 Nov 2025 14:33:38 +0000

React.memo vs useMemo — Explained

If you've ever stared at your React component tree wondering "Why are you re-rendering? I didn’t even touch you!" — congratulations, you're officially a React developer.

With React 19 rolling into town like a cool new intern, many devs still ask: “Do React.memo and useMemo still matter?”

Short answer: YES. Long answer: You’re about to read it.

🧠 The Real Difference

Let’s clear the confusion once and for all:

🔹 React.memo — The Component Bodyguard

React.memo wraps a component, preventing it from re-rendering unless its props change.

Think of React.memo as:
A bouncer at the club door checking props IDs.

const Greeting = React.memo(function Greeting({ name }) {
  console.log('Rendered!')
  return <h1>Hello {name}</h1>
})

If name doesn’t change → No re-render.
If name changes → VIP access.

🔹 useMemo — The Expensive Calculator

useMemo memoizes a value, usually something expensive to compute.

Think of useMemo as:
A lazy accountant who refuses to redo work unless absolutely necessary.

const total = useMemo(() => expensiveCalculation(items), [items])

If items doesn’t change → useMemo says: "Bro, I already did this."
If it does → reluctantly recomputes.

🥊 React.memo vs useMemo — Head-to-Head

Feature	React.memo	useMemo
Purpose	Prevent component re-render	Cache expensive calculations
Works on	Components	Values (numbers, objects, arrays, results)
Checks dependencies	Props	Dependency array
Best for	Heavy UI components	Heavy computations
Worst use case	Wrapping everything blindly	Memoizing cheap functions

🧩 When to Use What?

✔ Use React.memo if:

Component is heavy to re-render.
Renders the same UI if props don’t change.
Parent re-renders too often.

Don't use React.memo if the props are always changing anyway (it does nothing then).

✔ Use useMemo if:

You’re running expensive logic inside render.
You pass stable memoized values to child components.
You want to avoid useless recalculations.

Don't use useMemo for:

Cheap calculations.
Every single variable (this is not TypeScript, calm down).

🎨 Diagram Time!

"What they actually do"

React.memo                     useMemo
--------------                --------------
Component? Stop here.         Value? Store here.
Props same? Skip render.      Dependencies same? Skip computing.
Props changed? Render!        Changed? Recompute!

If React.memo were a person → security guard
If useMemo were a person → lazy mathematician

🧪 Real-Life Example (The Comedy Version)

function App({ items }) {
  // useMemo: "Don't make me calculate again!"
  const total = useMemo(() => {
    console.log('Computing total...')
    return items.reduce((a, b) => a + b, 0)
  }, [items])

  return (
    <ExpensiveUI total={total} />
  )
}

// React.memo: "You're not getting in unless your props change!"
const ExpensiveUI = React.memo(function ExpensiveUI({ total }) {
  console.log('Rendering ExpensiveUI')
  return <h1>Total: {total}</h1>
})

In this drama:

useMemo prevents recalculations.
React.memo prevents component re-renders.
Your CPU lives to fight another day.

🚀 So… Are They Still Useful in React 19?

YES.
Even with improved React internals, concurrent features, and better scheduling —
React.memo and useMemo remain performance best friends, especially in large apps.

React 19 doesn’t remove them.
It doesn’t deprecate them.
It doesn’t roast them on stage.

They're still very much alive and helpful — when used wisely.

😂 The Funniest Explanation

React.memo: “Bro, don’t re-render unless something ACTUALLY changed.”

useMemo: “Bro, stop calculating that again. I saved the answer already.”

🧁 Final Thoughts (Sweet & Short)

React.memo = Avoid useless re-renders.
useMemo = Avoid useless re-calculations.
Don’t overuse them.
Don’t underuse them. Use them like salt: Just enough, or everything becomes weird.

Is React.memo Still Useful in React 19? A Practical Guide for 2025

Shanthi's Dev Diary — Sun, 23 Nov 2025 14:18:06 +0000

React 19 introduced several internal improvements, async rendering refinements, and smarter rendering heuristics. Because of this, many developers began asking a familiar question again:

“Do we still need React.memo in React 19?”
Short answer: Yes — but use it deliberately.

Let’s break this down in a simple, practical way.

⭐ What React.memo Does (Quick Refresher)

React.memo is a higher-order component that prevents unnecessary re-renders when the component’s props haven’t changed.

const UserCard = React.memo(function UserCard({ user }) {
  return <div>{user.name}</div>
});

When used correctly, this can reduce wasted renders and improve performance in large lists, dashboards, or heavy UI sections.

⚡ What Changed in React 19?

React 19 brought several rendering optimizations:

✔ Smarter scheduling

React handles background rendering better and avoids blocking work.

✔ More efficient reconciliation

Some internal improvements reduce excessive re-renders that used to happen in older versions.

✔ Fewer unnecessary re-renders by default

React is better at skipping updates when values obviously haven't changed.

BUT:
React still does not do deep prop comparisons.

React still cannot know if a child component is expensive to render.

React still re-renders on parent render unless you prevent it.

Meaning: The fundamental reason for using React.memo still exists.

🎯 So… Is React.memo Still Recommended in 2025?
Absolutely YES — but with intention.

✔ When You SHOULD Use `React.memo`

Use it when:

1️⃣ Components receive stable props

Example:

Large list items (UserRow, ProductCard)
Table rows
Reusable UI blocks with minimal prop changes

2️⃣ The component is expensive

Heavy computation

Large DOM
Complex markup

3️⃣ The component appears in a list

React lists are the biggest beneficiaries of React.memo.

4️⃣ Parent component re-renders frequently

If the parent updates often, memoizing the child prevents ripple renders.

❌ When NOT to Use `React.memo`

Skip it when:

1️⃣ Component is cheap and simple

Small button components, labels, icons, etc.

2️⃣ Props change almost every render

If the component always needs to render, memo brings no benefit.

3️⃣ You’re passing non-memoized objects every time

Example:

<Component data={{ a: 1 }} /> // new object each render → memo useless

You'll need useMemo or stable references for React.memo to work.

4️⃣ Premature optimization

Don’t wrap every component by default — it adds a comparison cost.

📌 What About Server Components (RSC)?

Many developers wondered if React.memo becomes irrelevant because of server-driven rendering.

*No *— because React.memo is for client components.

React Server Components don’t re-render in the browser.
Client Components do, and that’s where React.memo still matters.

✔ Real-World Example (React 19)

Without memo:

Every time the parent renders, all items re-render.


function UserList({ users }) {
  return users.map(u => <UserItem key={u.id} user={u} />);
}

With memo:

Each item re-renders only when its own props change.

const UserItem = React.memo(function UserItem({ user }) {
  return <div>{user.name}</div>;
});

In large lists:
Before React 19 → critical
After React 19 → still critical

🚀 Final Verdict

React.memo is STILL useful in React 19 — very much so.

React’s new optimizations don't eliminate the need to prevent unnecessary re-renders. They simply make React faster by default. But:

React doesn’t magically skip renders.
React doesn’t compare deep props.
React doesn’t know your component’s render cost.

So you still need React.memo when you want to explicitly optimize.

📝 Conclusion

React 19 improves rendering, but it doesn’t replace what React.memo offers. React.memo remains a powerful performance optimization tool — especially for lists, expensive components, and frequently re-rendered UIs. Use it intentionally, not everywhere, and it will continue to provide real performance wins in modern React applications.

Read about React.memo vs useMemo in this blog

🛠️ Migrating from JavaScript to TypeScript: Strategies and Gotchas

Shanthi's Dev Diary — Thu, 31 Jul 2025 06:42:45 +0000

If you're thinking about migrating your JavaScript codebase to TypeScript, you're not alone — and you're definitely on the right track. TypeScript offers type safety, better tooling, and a more confident developer experience. But a migration isn't just a simple "rename-all-the-files" process. It's a journey — and like any journey, it’s smoother with a map. 🗺️

In this post, I'll walk you through a practical migration strategy and highlight some common gotchas to avoid.

✅ Why Migrate to TypeScript?

🔍 Catch errors before they happen (at compile time)

✨ Enjoy better IntelliSense and code navigation

🛡️ Refactor with confidence

📚 Your types are your documentation

Let’s make your codebase future-proof.

🔄 Migration Strategies

1. Start with the TypeScript Compiler

Install TypeScript and initialize the project:

npm install --save-dev typescript
npx tsc --init

This creates a tsconfig.json file — the heart of your TS setup.

2. Enable JavaScript Compatibility

You can type-check your existing .js files without converting them yet:

// tsconfig.json
{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true,
    "outDir": "dist"
  },
  "include": ["src"]
}

3. Rename Files Gradually

Start renaming .js → .ts (or .jsx → .tsx) one file at a time.

Start with:

Utility functions
Isolated modules
Non-UI logic

Avoid renaming everything at once — it’s easier to debug issues incrementally.

4. Add Type Annotations Where Needed

Start small. Focus on:

Function arguments and return types
Object shapes using interfaces or type aliases
Constants and enums

type User = { name: string };

function greet(user: User): string {
  return `Hello, ${user.name}`;
}

5. Leverage JSDoc in `.js` Files

Want TS support without converting a file yet? Add JSDoc:

/**
 * @param {string} name
 * @returns {string}
 */
function greet(name) {
  return `Hello, ${name}`;
}

This is a great way to introduce typing without renaming.

6. Use `any` and `@ts-ignore` Sparingly

Yes, they can unblock you. But track them down and clean them up later.

// @ts-ignore
someLegacyCode();

7. Tighten the Compiler Gradually

Once you're confident, turn on stricter settings in tsconfig.json:

"strict": true,
"noImplicitAny": true,
"strictNullChecks": true

Enable them one at a time to avoid overwhelming yourself.

⚠️ Gotchas to Watch For

🧩 Dynamic Code Is Hard to Type
Things like eval, Object.assign, or deeply dynamic object keys are hard to infer. Consider refactoring those.

📦 Missing Types for Libraries
Use DefinitelyTyped when needed:

npm install --save-dev @types/lodash

If no types exist, you can write your own *.d.ts file.

🔀 Implicit any Types
You’ll hit this a lot if noImplicitAny is enabled:

function log(message) {
  console.log(message);
}
//       ~~~~~~~~ Error: Implicit any

⚛️ JSX Requires .tsx
Using React? Any file that includes JSX must use the .tsx extension.

Also, don’t forget to type your props:

type ButtonProps = {
  label: string;
};

function Button({ label }: ButtonProps) {
  return <button>{label}</button>;
}

🧪 Update Your Build + Test Tools
Make sure:

Webpack or Vite is configured to handle .ts files
Babel has @babel/preset-typescript
Jest uses ts-jest or babel-jest

🧭 Your Migration Roadmap

Phase	What to Do
🧪 Enable Type Checking	Use `allowJs` + `checkJs`
🔀 Rename Incrementally	Convert `.js` → `.ts` in small batches
✍️ Add Types Slowly	Start with functions, constants, object shapes
⚙️ Configure Tools	Update build/test tooling
🧼 Clean Up	Remove `any`, `@ts-ignore`, etc.

✨ Final Thoughts

Migrating to TypeScript doesn’t have to be overwhelming. It’s not an all-or-nothing decision. Use a gradual, iterative approach — and before you know it, you'll have a fully typed, safer, and more enjoyable codebase.

Your future self (and your team) will thank you. 🙌

Thanks for reading! Have you tried migrating a JS project to TypeScript? Share your story or tips in the comments below.

DEV Community: Shanthi's Dev Diary

React 19.3: The Release That Makes React Feel More Native

React 19.3: The Release That Makes React Feel More Native

1. View Transitions are now stable

2. View Transitions work with React Transitions

3. addTransitionType() gives meaning to a transition

4. Suspense + View Transitions

5. Images and fonts can participate in transitions

6. Fragment Refs are finally stable

7. What can you do with FragmentInstance?

8. A new browser API for server rendering

9. Trusted Types support

10. Server Components get a small but useful improvement

11. There are also some important fixes

What actually matters for a React developer?

1. View Transitions

2. Fragment Refs

3. browser()

4. Trusted Types

Should you upgrade immediately?

The bigger picture

If REST APIs Keep Asking, Webhooks Simply Call

REST API vs Webhook: Stop Asking "Are We There Yet?" 🚗💨

🍕 Let's Start With Pizza

REST API Approach

Webhook Approach

So, What Exactly Is a REST API?

Common REST Methods

Example REST Request

What Is a Webhook?

REST API vs Webhook Communication

REST API

Webhook

Polling vs Push

Polling

Webhook

Real-World Example: GitHub 💻

Real-World Example: Payments 💳

Real-World Example: WhatsApp Business 💬

REST APIs Are Great At...

Webhooks Are Great At...

REST API vs Webhook

Why Not Use Webhooks for Everything?

The Best Architecture? Use Both 🤝

But Webhooks Come With Responsibilities ⚠️

Don't Forget Idempotency

What Happens If Your Webhook Fails?

Quick Decision Guide

Do I need to request something?

Do I need to know when something happens?

Need both?

Final Takeaway

REST API

Webhook

Why Firestore Keeps Throwing “Missing Index” Errors — And How to Fix It Like an Engineer

The Root Cause

How Firestore Thinks

The Beginner Workflow (And Why It Breaks)

The Real Problem in Production

The Engineering Fix

1. Version-Control Your Indexes

2. Deploy Indexes via CI/CD

3. Design Queries Before Writing Them

Avoid Index Explosion

Bad Pattern

Better Approach: Denormalization

Advanced Tricks

Use in Queries

Avoid Multiple Range Filters

Use Composite Fields

Backend Best Practice (Node.js)

Frontend (React) Gotcha

The Mindset Shift

Final Thoughts

Web Components: The Most Underrated Feature of the Modern Web

What Are Web Components?

The 4 Building Blocks of Web Components

1. Custom Elements

2. Shadow DOM

3. HTML Templates

3. `addTransitionType()` gives meaning to a transition

8. A new `browser` API for server rendering

3. `browser()`

Use `in` Queries

🆕 Enter `<Activity>` in React 19

🧠 How `<Activity>` Thinks

🧩 `<Activity>` vs `Suspense`

Meet `structuredClone()` 🧠✨

What Makes `structuredClone` So Cool?

`structuredClone` vs Spread Operator 🥊