DEV Community: Shanthi's Dev Diary

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.

Exploring the Exciting New Features in React 18

Shanthi's Dev Diary — Tue, 04 Jun 2024 12:54:18 +0000

React 18 is a significant update for one of the most popular JavaScript libraries used for building user interfaces. This version introduces several exciting new features and improvements that aim to enhance performance, improve the developer experience, and enable new use cases. In this post, we’ll explore some of the standout features of React 18 and what they mean for developers.

Concurrent Rendering

One of the most anticipated features in React 18 is Concurrent Rendering. This new rendering mechanism allows React to prepare multiple versions of the UI at the same time. This can improve the user experience by making the UI more responsive and fluid, especially in applications with complex, interactive interfaces.

Concurrent Rendering enables React to interrupt and pause work, then continue later. This means your app can stay responsive even during heavy rendering tasks. For example, if a user interaction is more urgent, React can prioritize rendering that over less critical tasks.

import { useState, useTransition } from 'react';

function App() {
  const [isPending, startTransition] = useTransition();
  const [input, setInput] = useState('');
  const [list, setList] = useState([]);

  const handleChange = (e) => {
    setInput(e.target.value);
    startTransition(() => {
      const newList = Array(5000).fill(e.target.value);
      setList(newList);
    });
  };

  return (
    <div>
      <input type="text" value={input} onChange={handleChange} />
      {isPending ? 'Loading...' : list.map((item, index) => <div key={index}>{item}</div>)}
    </div>
  );
}

Automatic Batching

React 18 introduces Automatic Batching, which optimizes the way updates are processed. Previously, React batched state updates that occurred within event handlers. However, updates that happened outside of event handlers, like those in setTimeouts or native event listeners, weren’t batched.

With React 18, all updates are automatically batched, regardless of where they originate. This leads to fewer renders and better performance:

// Before React 18
setTimeout(() => {
  setCount(count + 1);
  setFlag(flag + 1);
  // Two separate renders
}, 1000);

// With React 18
setTimeout(() => {
  setCount(count + 1);
  setFlag(flag + 1);
  // Only one render
}, 1000);

New Suspense Features

React’s Suspense feature, which was introduced earlier, has received significant updates in React 18. Suspense allows components to “wait” for something before they render. This is particularly useful for handling asynchronous data fetching.

In React 18, Suspense works seamlessly with Concurrent Rendering to make data fetching more efficient and the UI more resilient. For example, you can now use Suspense to control loading states more granularly, ensuring that your application remains responsive and visually consistent:

import React, { Suspense } from 'react';

const MyComponent = React.lazy(() => import('./MyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <MyComponent />
    </Suspense>
  );
}

Transitions

Transitions in React 18 allow developers to distinguish between urgent and non-urgent updates. This is particularly useful for distinguishing between interactions that need immediate feedback (like typing in a text box) and those that can be deferred (like loading a new page).

The new useTransition hook lets you mark updates as transitions, allowing React to keep the UI responsive during non-urgent updates:

import { useTransition } from 'react';

const [isPending, startTransition] = useTransition();

startTransition(() => {
  setState(newState);
});

startTransition API
The startTransition API complements the useTransition hook by allowing developers to mark updates as transitions. This helps React prioritize urgent updates over non-urgent ones, ensuring a smooth user experience.

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

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

  const handleClick = () => {
    startTransition(() => {
      setCount(c => c + 1);
    });
  };

  return (
    <div>
      <button onClick={handleClick}>Increment</button>
      <p>{count}</p>
    </div>
  );
}

Improved Server-Side Rendering

React 18 brings significant improvements to Server-Side Rendering (SSR) with the introduction of a new API called react-dom/server. This API allows for more efficient streaming of HTML, which can improve the performance of server-rendered React applications.

The new streaming SSR architecture lets the server send content to the client as soon as it’s ready, rather than waiting for the entire component tree to be rendered. This can lead to faster load times and a better user experience.

import { renderToPipeableStream } from 'react-dom/server';
import express from 'express';
import App from './App';

const app = express();

app.get('/', (req, res) => {
  const stream = renderToPipeableStream(<App />, {
    onShellReady() {
      res.setHeader('Content-type', 'text/html');
      stream.pipe(res);
    },
  });
});

app.listen(3000, () => {
  console.log('Server is running on port 3000');
});

Server Components

Another major addition to React 18 is Server Components. Server Components enable developers to build apps that leverage both the server and the client for rendering, resulting in faster load times and reduced bundle sizes.

Server Components allow parts of the UI to be rendered on the server and sent to the client as HTML. This can significantly reduce the amount of JavaScript that needs to be loaded and executed on the client, leading to faster initial renders and improved performance.

// MyComponent.server.js
export default function MyComponent() {
  return <div>This is a server component</div>;
}

// App.client.js
import React, { Suspense } from 'react';
import MyComponent from './MyComponent.server';

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <MyComponent />
    </Suspense>
  );
}

export default App;

javascript
Conclusion
React 18 is packed with features that enhance performance, improve the developer experience, and open up new possibilities for building modern web applications. Concurrent Rendering, Automatic Batching, enhanced Suspense, Transitions, improved SSR, and Server Components are just a few of the exciting additions.

As developers, these new tools and improvements allow us to build more responsive, efficient, and user-friendly applications. With React 18, the future of web development looks brighter than ever.

Stay tuned to Shanthi's Dev Diary series for more in-depth tutorials and insights into the latest in web development!

Frontend Challenge June Edition - Take me to the beach

Shanthi's Dev Diary — Thu, 30 May 2024 20:43:44 +0000

This is a submission for [Frontend Challenge v24.04.17]((https://dev.to/challenges/frontend-2024-05-29), Glam Up My Markup: Beaches

What I Built

Take me to the beach!

Welcome to our collection of the world's top beaches. Experience it all with two breathtaking views: the tranquil night scene and the vibrant morning ambiance. Plus, immerse yourself further with a gallery of stunning beach snapshots.

The application isbuilt in a responsive way.

Demo

Journey

Process:
Envisioning Enhancement: Upon reviewing the HTML markup and objectives, I visualized ways to amplify its appeal and interactivity, ensuring seamless user experience.

Strategic Blueprinting: I sketched a roadmap, delineating stages for each improvement, ranging from style infusion with CSS to functionality infusion via JavaScript.

Artful Execution: With a blend of precision and creativity, I executed enhancements incrementally, prioritizing user engagement and accessibility.

Meticulous Refinement: At each juncture, I meticulously refined the design and functionality, leveraging feedback loops and rigorous testing for refinement.

Comprehensive Documentation: Finally, I encapsulated the journey in comprehensive documentation, elucidating the rationale behind each tweak and the cumulative impact on user delight.

Learning:
Advanced Layout Techniques: I honed skills in CSS Grids and Flexbox to sculpt responsive layouts, ensuring harmonious display across diverse screen dimensions.

Eloquent Event Handling: Through JavaScript, I mastered the orchestration of DOM events, seamlessly choreographing interactive elements like toggling night mode and modal unveilings.

Artistry of Animation: Experimenting with the parallax effect unveiled a realm where CSS and JavaScript seamlessly converge to imbue interfaces with dynamism and allure.

Proud Moments:
Innovative Solutions: Crafting inventive avenues for features such as night mode, modal pop-ups, and the parallax effect fostered a sense of accomplishment.

User-Centric Design: Fusing aesthetics with accessibility, I endeavored to fashion an interface that beckons users with visual charm and navigational ease.

Next Steps:
Unceasing Growth: Fuelled by an insatiable appetite for learning, I aspire to delve deeper into advanced CSS techniques, explore emerging JavaScript frameworks, and delve into UX/UI design principles.

Feedback Integration: I eagerly anticipate assimilating feedback, thereby fortifying future endeavors with insights garnered from real-world usage.

Exquisite Craftsmanship: With each project, I aim to refine my craft, infusing it with finesse and flair, to craft digital experiences that captivate and inspire.

Embracing the dynamism of web development, I relish the journey of continuous improvement and innovation, as I strive to craft interfaces that dazzle and delight users.

Mastering React Hooks: Best Practices for Efficient and Maintainable Code

Shanthi's Dev Diary — Thu, 30 May 2024 17:44:53 +0000

Introduction

In the ever-evolving landscape of React development, React Hooks have emerged as a powerful tool for managing state and side effects in functional components. With their introduction, developers have gained a more intuitive and concise way to write React code. However, as with any new feature, understanding and following best practices is essential for writing efficient and maintainable code. In this blog post, we'll dive deep into React Hooks and explore best practices to help you master them.

1. Embrace Functional Components
Functional components are lightweight and easier to read. Here's a simple example demonstrating the transition from a class component to a functional component using Hooks.

Class Component:

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

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

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

Functional Component with Hooks:

import React, { useState } from 'react';

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

  const increment = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
};

2. Use Hooks Sparingly and Strategically
Avoid overcomplicating components with too many Hooks. Keep components focused and cohesive.

Bad Example:

const Component = () => {
  const [state1, setState1] = useState(0);
  const [state2, setState2] = useState('');
  const [state3, setState3] = useState(false);
  const [state4, setState4] = useState([]);
  // Too many state variables can make the component hard to manage

  // logic...
};

Good Example:


const Component = () => {
  const [count, setCount] = useState(0);
  const [text, setText] = useState('');

  // logic...
};

3. Follow the Rules of Hooks
Always call Hooks at the top level and never inside loops, conditions, or nested functions.

Wrong Way:


const MyComponent = () => {
  if (someCondition) {
    const [state, setState] = useState(0); // This will break the Rules of Hooks
  }
  // logic...
};

Right Way:


const MyComponent = () => {
  const [state, setState] = useState(0);

  if (someCondition) {
    // use state
  }
  // logic...
};

4. Keep Hooks Simple and Readable
Break down complex logic into smaller, composable Hooks.

Complex Hook:


const useComplexLogic = () => {
  const [state1, setState1] = useState(0);
  const [state2, setState2] = useState('');

  useEffect(() => {
    // some complex logic
  }, [state1, state2]);
};

Simplified with Custom Hooks:


const useState1 = () => {
  const [state1, setState1] = useState(0);
  useEffect(() => {
    // logic for state1
  }, [state1]);
  return [state1, setState1];
};

const useState2 = () => {
  const [state2, setState2] = useState('');
  useEffect(() => {
    // logic for state2
  }, [state2]);
  return [state2, setState2];
};

const useComplexLogic = () => {
  const [state1, setState1] = useState1();
  const [state2, setState2] = useState2();
};

5. Separate Concerns with Custom Hooks
Encapsulate reusable logic in custom Hooks.

Custom Hook Example:

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(url)
      .then(response => response.json())
      .then(data => {
        setData(data);
        setLoading(false);
      });
  }, [url]);

  return { data, loading };
};

const MyComponent = () => {
  const { data, loading } = useFetch('https://api.example.com/data');

  if (loading) return <p>Loading...</p>;

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

6. Optimize Performance
Use useMemo and useCallback to optimize performance and avoid unnecessary re-renders.

Using useMemo and useCallback:

const MyComponent = ({ items }) => {
  const [count, setCount] = useState(0);

  const expensiveCalculation = useMemo(() => {
    return items.reduce((acc, item) => acc + item.value, 0);
  }, [items]);

  const increment = useCallback(() => {
    setCount(count + 1);
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <p>Sum: {expensiveCalculation}</p>
      <button onClick={increment}>Increment</button>
    </div>
  );
};

7. Leverage useEffect Wisely
Manage side effects properly with useEffect.

Data Fetching with Cleanup:

const MyComponent = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    let isMounted = true;

    fetch('https://api.example.com/data')
      .then(response => response.json())
      .then(data => {
        if (isMounted) setData(data);
      });

    return () => {
      isMounted = false; // Cleanup
    };
  }, []);

  return <div>{data ? data : 'Loading...'}</div>;
};

Conclusion

React Hooks have revolutionized the way we write React components, offering a more elegant and functional approach to state management and side effects. By following best practices and leveraging the full potential of Hooks, you can write cleaner, more maintainable code and unlock new levels of productivity in your React development journey. Embrace the power of Hooks, but remember to use them wisely and responsibly to reap their full benefits. Happy hooking!

DEV Community: Shanthi's Dev Diary

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

4. ES Modules

A Simple Web Component Example

Why Web Components Matter

1. Framework Independence

2. Perfect for Design Systems

3. Long-Term Stability

Fun Facts About Web Components

🧠 Fun Fact #1

🧠 Fun Fact #2

🧠 Fun Fact #3

🧠 Fun Fact #4

Why Aren’t Web Components More Popular?

Final Thoughts

Understanding the Component in React 19

🤔 The Problem with Conditional Rendering

🆕 Enter <Activity> in React 19

✨ Basic Usage

What happens here?

🧠 How <Activity> Thinks

🔥 Real-World Use Cases

1️⃣ Tabbed Interfaces

2️⃣ Modals & Drawers

3️⃣ Background UI

⚠️ Things to Keep in Mind

🧩 <Activity> vs Suspense

🧠 Mental Model

🚀 Why This Matters

🏁 Final Thoughts

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

The Reality of Large-Scale React Applications

Why React Context and Hooks Struggle in Micro-Frontends

React Context Stops at Bundle Boundaries

Prop Drilling Becomes Impossible

Global State Becomes Too Global

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

What Are Remote Contexts?

Cross-Bundle Messaging in React Architectures

Why Remote Contexts Work Well with React

Example: Distributed React Dashboards

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

Migrating from Redux and Traditional State Management

When Should You Use Remote Contexts?

Final Thoughts: React Architecture Must Evolve with Scale

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

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

The Old (Painful) Way 😬

What it breaks:

Meet structuredClone() 🧠✨

What Makes structuredClone So Cool?

It supports:

Example: Deep Clone That Actually Works

Circular References? Bring It On 💪

Map & Set — Finally Respected 🫶

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

structuredClone vs Spread Operator 🥊

Performance: Should I Worry?

Where You’ll Actually Use This

Browser & Runtime Support 🌍

Final Thoughts 💭

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

🧍‍♂️ What Is a Shallow Copy?

Example

Why?

🧠 What Is a Deep Copy?

Example

🛠 Copying Methods

🔹 Shallow Copy Methods

🔹 Deep Copy Methods

🎯 When Should You Use Which?

✔️ Use Shallow Copy when:

✔️ Use Deep Copy when:

🧘 TL;DR Table

🏁 Summary

🆕 Enter `<Activity>` in React 19

🧠 How `<Activity>` Thinks

🧩 `<Activity>` vs `Suspense`

Meet `structuredClone()` 🧠✨

What Makes `structuredClone` So Cool?

`structuredClone` vs Spread Operator 🥊

✔ When You SHOULD Use `React.memo`

❌ When NOT to Use `React.memo`

5. Leverage JSDoc in `.js` Files

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