DEV Community: Anju Karanji

It's over, Repo. I have the high ground!

Anju Karanji — Sat, 14 Mar 2026 21:41:49 +0000

Your boyfriend has messed up. Royally. He knows it. You know it. The neighbor knows it. Everyone and their mother knows it!
The words form in your head -
I. Told. You. So.
And then, this other voice, "Don't be a dick, Anju" seemingly comes out of nowhere!
And then, dang! You swallow the sentence.
Congratulations. You’re basically Mother Teresa.
Just… hotter.

Next scenario: The man cuts you off in traffic. Your hand is already on the horn.
A very specific two-word insult involving his mother... is loading. And again: Don't be a dick, Anju.
Hand moves away, curse dies in your throat. You’re Buddha baby! You are practically levitating.

Or when you’ve crafted the perfect insult.
You know the kind: Elegant. Perfect. A gift from the universe. Frame-worthy! 
And right before you say it... you get a vision of future-you; rocking back and forth at 2:30 a.m., ruminating, feeling guilty. Forever. Until eternity.
The insult is swallowed. The masterpiece lost to history. Did I mention already? Yes. I am Jesus.
The Vatican has been notified.

That voice? That sanctimonious, holier-than-thou voice? 
That's the linter for you!

Fixing legacy lint errors at work. You know how it goes... you fix one error, you write a blog.

For frontend code, ESLint is the dominant choice.
It's the Obi-Wan Kenobi. Strict older brother energy. But secretly caring.

Obi-Wan doesn’t live inside the IDE. He lives away from Luke but in the same desert.

Let's talk: Job Description.

In VS Code, ESLint parses every debounced keystroke and converts javascript into AST. It takes your tiny little
const x = 1
and turns it into AST (Nodes. Relationships. Structure... a complete ancestry report). A whole crime scene - over 1 variable. Iconic! 😏

Before it starts traversing the AST, ESLint's already mapped your codebase into a scope tree (basically tracking which variables live where, and who can access what).

Each rule registers for the only node type it truly cares about. Very committed. And voila! The listener map is ready.

During the walk, the listener map applies the rules and these rules with the help of the scope tree decide whether to call report().

Think of it as:

If a CallExpression appears, wake up only RuleA. Joker walks in, only Batman stands up.

{
  CallExpression: [ruleA],
  Identifier: [ruleC],
  VariableDeclaration: [ruleD]
}

You might already know this part... remember Leetcode? DFS? Visitor pattern? That's the algorithm ESLint uses to walk AST.

(Your little const x = 1 you ask... triggers nothing.)
ESLint walks past it like: Not today baby!

Plugins - the Jedis who do the actual sparring

ESLint itself is more like a sitting member of the jedi council. The Jedis that participate in the clone war, that’s all plugins!

eslint-plugin-react (Anakin), eslint-plugin-unicorn (Mace Windu), etc...

Bienvenido Grogu.

Today, let's write a linter... for the heck of it.
Not the Obi-Wan. He's seen wars. Just a bite-sized 'baby Yoda'.

Our force can catch every rogue console.log left behind in code.  
Here's the thing about Grogu though - he’s not the sharpest tool in the shed.  
Grogu logic goes something like - see a frog → eat the frog.

It visits every node in the AST and calls report() whenever it finds console.log.

Here's the whole traversal - super simple

// The traversal accepts AST and the map only bothers itself with 'CallExpression' node. The only Jedi assigned to that node is 'noConsoleLog'.

walk(ast, {
  CallExpression(node) {
    noConsoleLog(node, report); 
  },
});

function walk(node, visitor) {
  // Base case: if this isn't a real AST node, return early
  if (!node || typeof node !== "object") return;

  // If we have a Jedi registered for this node type, fire it
  if (visitor[node.type]) {
    visitor[node.type](node);
  }

  // Recurse through all it's children just to be sure
  for (const key of Object.keys(node)) {
    walk(node[key], visitor);
  }
}

Grogu only complains. ESLint however is the adult and so takes care of the clean up if urged.
Pass --fix and it gathers all the fixes and applies them at the end.
Calling npm link makes it globally accessible on your machine.
And... that's it. Your very own prickly little conscience is ready to harass your repo.

Word travels fast 'round these parts. And the word is, there's new kids in town.

Biome and Oxlint are written in Rust. On a 1,000-file repo, ESLint might take 40 seconds. Oxlint does it in under 2s flat! Reason being ESLint is JavaScript. So, single-threaded.

These new plugin ecosystems are however still catching up. I tried Biome on a personal project and liked it. It is worth your time. YouTube has solid tutorials if you want to go deeper. I like this one - https://www.youtube.com/watch?v=x5kwmIaPty8&t=48s

Just fyi, ESLint did hold the fort down for 13 years (So that kind of time does help you load up on ammunition)

In a nutshell:

Linters don't cut you off at the bar. They just hold your hair back while you vomit.

Baby linter repo is here.

Grogu is thriving.
I sent the drunk text.
We don't talk about it.
Linter agrees.
Ship the code!👩‍💻

Code-ing in a Tree: Adding Auto-Save to freeCodeCamp

Anju Karanji — Fri, 16 Jan 2026 04:23:59 +0000

freeCodeCamp and Anju, sitting in a tree, code-ing (the e stays. I will die on this hill).
First came ADHD. Then came coffee.
Then—inevitably—a pull request and this blog you are currently reading.  

After they set the start date for my next gig—about two weeks out—I suddenly had time to burn.
I finished the onboarding docs, cooked actual food, paid the bills, watched some Jimmy Kimmel.

Eventually, I decided to do some coding—lest I find myself vacuuming the bathroom ceiling out of sheer boredom.

I poured myself a cup of coffee — still too early for the wine.

Opened VS Code.

I stared out the window.
Stared at my coffee.
Watched more Jimmy Kimmel.

All in the hope that a brilliant app idea would magically appear.

It didn’t.

That’s when I decided to go looking for “help wanted” signs on GitHub repos.

So, I slithered my way back into the freeCodeCamp repo. I am, if nothing else, a creature of familiarity.   

I did a quick “eeny, meeny, miny, mo” and clicked on one. A small flutter followed, and I knew I’d found the one. Thank God—my Dyson was moments away from meeting the popcorn ceiling.

So, to cut a long story short, I present to you: THE ISSUE. (Here’s the original issue for context, if you’re curious-https://github.com/freeCodeCamp/freeCodeCamp/issues/57818)

Cue trumpet music.  

freeCodeCamp doesn't autosave to localStorage. Users have to hit Ctrl+S. But here's the problem — nobody tells them that. So they write beautiful, gorgeous code, navigate away to watch some Netflix, come back, and discover their masterpiece has been sent to the shadow realm. Ctrl+Z can't save you here. Nothing can.

My solution was simple: add autosave—the way LeetCode and GreatFrontend already do.

You can check out the full PR here if you want to see the implementation details.

So, after the usual forking and branching, I went hunting for the component in question. Channeling my inner High Potential’s Morgan Gillory, I found the right components surprisingly quickly.

Turns out 10,000 hours of TV viewing does pay dividends.

All jokes aside, the folder structure was intuitive. The function names were descriptive and the hunt was fairly straightforward.

I remember chatting with a Netflix engineer once. She sized me up and said, "You probably design applications backend-first, don't you?" She was right—I do. But this time? I wanted to start with something the user could see. A little visual reassurance felt like the right move. So I added a simple indicator to the toolbar (ActionRow): a FontAwesome checkmark and a quick line of text. Nothing flashy—just enough to whisper, hey, your work is safe.

You know—I’m a creature of familiarity. My go-to has always been React’s Context API or, more recently, Zustand. Redux was new territory, so I had Claude walk me through the setup - ’lastSavedTime’ was going to be used to calculate the time lapsed since the last save.  

I checked all the boxes on my mental TODO list:  

Persistence to localStorage, wired into debounced onChange, onBlur, onUnmount, and beforeunload.
A timestamp that updates every five seconds and resets cleanly on navigation—no stale “Saved 20m ago” ghosts.
A big beautiful download button. Big enough to spot from Mars.
Respect for the DRY, courtesy of a shared utility function and a custom hook.

Then the tests broke.
Of course they did.

First up: the unit test in completion-modal.test.tsx. I’m blaming Robert Martin and Clean Code for this one—I had refactored the logic into a utility and forgotten to update the test. An easy fix.

Then the e2e tests failed. Two tests in multifile-cert-projects.spec.ts. Running e2e tests locally felt oddly familiar. Playwright isn’t all that different from Cypress, which I’d used before, and that familiarity helped me zero in on the real issue. The fix turned out to be simple—and, honestly, better design.

Auto-save should be silent.

I updated code-storage-epic.js to suppress flash messages for auto-saves. Manual saves still get explicit confirmation; auto-saves just quietly update the timestamp. Less noise, and better UX.  

My PR was officially ready. 
The damage report:  

Days spent: 2
Coffee consumed: A few hundred gallons
Fat-Cat cuddles: Stole a few (unless she pushed my face away with her paw)
Showers taken: 0 (for the environment, obviously!)
Lessons learned: Redux isn't scary. Auto-save should whisper, not be a drama queen.

Now? I wait. And maybe shower.

Update (February 2026):

I waited… For 1.5 months.

One maintainer surfaced briefly, commented that “the implementation is solid,” but wasn't sure if they wanted the feature. They tagged decision-makers for input.

Then? Radio silence.

I nudged politely every few weeks.

Meanwhile, the codebase kept evolving. Merge conflicts spawned and I fixed them once. Then they came back. Again. 985 other people were also committing code while my PR quietly fossilized.

After 1.5 months of limbo - no feedback, no decision - I closed it.

What I learned:

Open source contribution is about timing and luck. Sometimes you do everything right and still get ghosted harder than a Tinder match.

But I don't regret it. I learned Redux and playwright, and I got this blog post out of it. The feature works. The code is solid.

Not every PR merges. But every PR teaches you something - Like maybe shower occasionally.

So I consider that a win.

From CDN to Pixel: A React App's Journey

Anju Karanji — Thu, 08 Jan 2026 22:35:18 +0000

The success of my last blog has cursed me with the burden of EXPECTATIONS. I've accidentally set the bar too high and now have to pretend I'm good at this. To cope with this crushing pressure, I’ve turned to the most emotionally stable things in my life:

Wine
Hallmark Christmas movies where small towns have better WiFi than my house.

[Originally drafted in December. Finally committed in January. Yes - Procrastination is my brand. 😌]

Four movies deep into "Career-oriented big City Girl falls for handsome small town tree farmer who saves her from personal or professional ruin", I remember: oh right - I have a React blog to write.  
And then I thought: God, I wish React were more like the ruggedly handsome Christmas-tree-farm guy with the flannel shirt and the jawline. sigh

Steady. Predictable. Doesn't have a meltdown because someone three counties over changed their order about pie flavors.

Also — and I cannot stress this enough — devastatingly handsome.

React's whole brand is "I’m the stable, predictable framework. I make UI updates easy.”

LIES! ABSOLUTE LIES I SAY!

He will re-render because his cousin’s, ex-girlfriend’s props changed even though he hasn’t spoken to that cousin since Thanksgiving ’09 or - just because you made eye contact.

React whispers sweet nothings like "I'm just a library standing in front of a dev, asking her to love me" and then casually mentions you'll need React Router, React Query, React Hook Form, and 47 other "react-something" packages - not his problem.

So in the spirit of holiday romance — and my heart's desire to understand his backstory, I present to you:

From CDN to Pixel: A React App’s Journey from "npm run build" to "oh look, a button"

The Browser (let's call her... Browser) arrives in town, confident and capable. She's been rendering content since 1995. She's parsed HTML that would make you weep. She's survived the IE6 era. She's seen some stuff.

She can handle anything.

Then she meets React.

And So it Begins...

Browser types www.small-town-love-story.com and hits Enter.
DNS resolves to Netlify's CDN. Geography decides the rest - Dallas browser hits Dallas edge, London hits London. Same IP, different physical server (Anycast routing).

Encrypted connection established.

This is the Hallmark prelude - the editor ultimatum, the rushed flight home, the "I'm only here for the holidays" trope.

CDN edge responds with cached index.html

Browser Meets index.html

She makes her first friend in town. Naturally, she owns the only café that exists in this town.

It's empty right now.
Mostly just a <div id="root"></div> but it's got potential...

"I'm a container." index.html says cheerfully. "Once React gets here, this place is gonna be bustling!"

"We need to save the town Christmas party." she tells Browser. Of course. Duh! The obligatory catastrophe.

React is still en route from the CDN - packed in those JavaScript files, probably bringing his entire component tree as carry-on.

Winter is coming...

React Finally Shows Up

Cue the slow-motion entrance.

Hair blowing in non-existent wind. Flannel shirt unbuttoned just enough.
And the abs.
The glorious abs.

Browser's JavaScript engine parses ~170KB of bundles.
Parse time: ~80-100ms.
Single-threaded.
Blocking.

This is why bundle size matters - not download time (CDNs are fast), but parse time. Every kilobyte is CPU work grinding away on the main thread while nothing else can happen.

He spots that empty <div id="root"></div>.

"I'll take it from here," he announces, rolling up his sleeves.

Browser, who's been busy with DNS resolution, TLS handshakes, HTML parsing, and resource orchestration - of course feels the unmistakable pull toward the ruggedly handsome protagonist with the heart of gold.

Don't roll your eyes people! It is a rom-com! What else did you expect?

The Town Shows Up (Or: How the Christmas Party Actually Gets Saved)

So, now to avert the impending apocalypse, our protagonist React rallies the super-friendly townsfolk.

He's got the vision. The coordination. The jawline.

But it takes the whole town to actually make it happen.

JavaScript Engine shows up first — runs React’s code, schedules tasks, queues microtasks, and keeps the main thread alive.

Rendering Engine does the real construction — creates actual DOM nodes (C++ objects in memory), parses CSS, assembles the render tree by combining DOM + CSSOM.

Layout Engine measures everything — exact sizes, positions, box model math, flexbox negotiations, grid calculations. Nothing is guessed. This is reflow and it's expensive.

Paint rasterizes to pixels. Until this moment, nothing was visible. Just data structures.

Compositor breaks the page into layers, hands them to the GPU — transforms, opacity, z-index. Aims for 60fps.

The OS, our mayor, gives the final blessings — input events, thread scheduling, screen refresh.

Pixels hit the screen.
The title "Once Upon a Holiday" fades in.
Okay, she thinks. Maybe he's not completely useless.
The abs certainly don't hurt.

The First Tiff: React's Re-render Philosophy

It’s been a few days.
The title looks cute in its cursive font.
The town has settled. Our couple has routines.

Then a user clicks a button.
State changes.
React panics.
He re-renders everything.

"The counter went from 0 to 1," Browser says, very calmly. "Why are you calling every component function again?"
"Re-renders are cheap. It's just JavaScript," React shrugs.
"I have to recalculate layout. Repaint pixels. Composite layers." Browser's voice tightens. "You just re-rendered 47 components to change one text node."
"Declarative updates," React says defensively. "Simple. Predictable."
"Simple for you. I'm doing the actual work."
React looks away. She's mad.

This is The Big Fight™.

(Hallmark fights, am I right? 🙄 In production this wouldn’t even log a warning.)

Browser Packs Her Bags

A few days later, Browser is at the train station, suitcase packed.
"I have other apps to render," she tells index.html. "Other frameworks to work with. This was... temporary"
React shows up breathless. Hair still perfect - obviously.

"Wait!"

Browser turns. "What now? Did you bring your 47 npm packages to say goodbye?"

"I've been working on something," React says. "Memoization."
Browser blinks.
"React.memo. useMemo. useCallback." He's talking fast. "I can skip re-renders now. Only update what actually changed. Like you kept telling me to do."
"And there's more!" React continues. "React Compiler. Automatic memoization. I don't even have to think about optimization anymore. It just... happens."

She likes this.

"Sixty frames per second?" she asks.
"Sixty," React promises. "Even under pressure."

Browser sets the suitcase down.
They kiss.

Before you gag — a reminder:
it is a rom-com.

6 Months Later

React didn’t become perfect.
Browser didn’t stop doing all the work.

But now they understand each other.
Snow falls softly over the town.
Fade to black.
(Post-credits scene: someone forgets a dependency array.)

React 19.2: React in its sigma era

Anju Karanji — Wed, 12 Nov 2025 03:46:02 +0000

The lights dim — or maybe that's just dark mode — and somewhere buried inside a million open tabs, I, React 19.2, take a deep breath.

I'm the millennial dev of frameworks: experienced, over-caffeinated, quietly wondering if work-life balance is real, and still feeling guilty about using PTO. The stickers still sell, but the critics? They've been whispering for years about "side effects" and "memoization fatigue."

But I'm back — bolder, wiser, and dare I say, with a little rizz.

I've stopped taking photos of my meals, swapped Red Bull for matcha, and finally learned to set boundaries with useEffect.

My new name? React 19.2. And I've finally embraced my sigma era.

Sure, my new React Compiler (with its Babel plugin) might tack a few seconds onto the Vite build, but that's a small price to pay for the hours you used to spend manually memoizing everything. Isn't it? My compiler now handles optimization automatically — and honestly? I'm stoked about this upgrade.

What's new in my glow-up:

1) `<Activity />` = "It’s giving background character energy." 🎭

Okay, real talk — I used to have a toxic push-pull relationship with my components.
Mount. Unmount. Mount again.
It was giving on-again-off-again couple energy.

One second your <Sidebar /> was here — the next? Gone. Deleted. State obliterated. Then we’d get back together and I’d have to rebuild everything from scratch like nothing ever happened. Exhausting. For both of us.

But I’ve grown. With <Activity />, I’ve learned that not every break needs to be a breakup.

<Activity mode={isShowingSidebar ? "visible" : "hidden"}>
  <Sidebar />
</Activity>

React renders <Sidebar /> in the background at low priority — like NPCs waiting for you to walk by again. State intact, DOM preserved, just off-screen. Not unmounted, just hidden.

It’s giving “we’re on a break but you can still have my Netflix login.”
So very emotionally available 😉

2) useEventEffect = "the Gen-Z stare" (boundaries, no oversharing) 🧘‍♀️

My useEffects -> Every little prop change? Every callback tweak? Boom, dependency drama. I’d drag everyone into my business like, "If I’m re-rendering, we’re all re-rendering."
But then I met useEventEffect.
Cool, detached, emotionally stable — basically the Gen-Z friend who just blinks at your chaos and says, "that’s crazy, lol."

const onConnected = useEventEffect(() => {
  sendMessage("hey");
});

My new friend - useEventEffect taught me that not every update is about me.
Sometimes, the healthiest thing you can do... is just take it easy... 🧘‍♀️

3) cacheSignal = "the friend who cancels plans before you can." 🫠

Okay, let’s be honest — cacheSignal() is... fine.
Basically, it gives you an AbortSignal tied to your cached Server Component fetches. So if React decides mid-render that it doesn't need that cached data anymore, the signal aborts and your fetch bails early.

Real talk: I added it to the list because it's new, not because you'll reach for it. This is the API equivalent of meal-prepping on Sunday and then ordering takeout anyway by Wednesday.

Is it useful? Sure, in some edge case on a high-traffic app with complex streaming SSR.
Will you use it? Probably not. And that's okay. Not all my kids turned out equally awesome. 😉

4) Performance Tracks = "Spotify Wrapped, but for your renders" 📊

Look, debugging React performance used to be like trying to figure out why your situation-ship ghosted you. Was it me? Did I re-render too much? Am I being needy?

You'd stare at flame graphs like they were Instagram stories, wondering if 47ms was "a lot" or if you were just being dramatic.

But now? I'm serving receipts.

Open Chrome DevTools → Performance tab, and I'll literally show you.

⚛️ Scheduler Tracks:

Blocking track: "Yeah, I froze your UI for 500ms. You asked me to!" (It's not me. It's definitely YOU!)
Transition track: "This work? Low priority. Multitasking like Snoop Dogg with his side hustles."
Suspense track: "Still loading that API. I'm being patient, okay!"
Idle track: "Literally doing busywork. It's giving unemployment"

⚛️ Components Track:

The component tree where render time is on full display. Every component gets a colored bar.
Darker = slower = that's your problem child 🤷🏻‍♀️

I'm no longer bottling things up. I'm communicating. I'm vulnerable. I'm showing you the work.

And honestly? It's exhausting being this self-aware. 💅

5) Partial Pre-rendering = "I do meal prep now!" 🍱

Partial Pre-rendering sounds delicious, but the recipe isn’t exactly HelloFresh yet. The core API exists in React 19.2, but real-world setup still depends on your framework and server, so the "how" feels a little fuzzy to me.

PPR in 30 seconds (plain React):

Build (or precompute) time: call prerender(<App/>, { signal }) -> you get a prelude (static shell) and a postponed state. Save postponed somewhere (KV/blob/db) and ship prelude to your CDN.
Request time: load the saved postponed, then resume the render and stream the dynamic parts into the response.

The catch? You're wiring up your own SSR server, managing state storage, configuring everything, and handling hydration. It is a little bit like plumbing I guess.

With Next.js 15, you can just wrap the dynamic bits in <Suspense>, flip experimental.ppr = true in your config, and call it a day. Next does the rest —> less cooking, more eating.

Again, not exactly the brightest of the bunch — unless you’re using a framework to babysit it.

6) Batching Suspense Boundaries for SSR = "group therapy for my loading states" 🤝

I used to have no chill during SSR. I now batch my Suspense boundaries during SSR, meaning I reveal multiple async chunks together instead of one at a time.

<Suspense fallback={<LoadingProfile />}>
  <Profile />
</Suspense>
<Suspense fallback={<LoadingPosts />}>
  <Posts />
</Suspense>

Before: Profile flashes in, Posts follows awkwardly later.
Now: I wait till both are ready, then enter the stage gracefully, in sync.

I’ve grown past my biases. I’m no longer a component-ist okay? All are equal under the law (which, obviously, is just me 😁)

🏅 Honorable Mentions:

eslint-plugin-react-hooks v6: This one understands useEffectEvent, supports flat config by default, and keeps your dependency arrays drama-free.

useId prefix update: Changed from :r: to _r_ to support View Transitions API. If you're doing SSR and using useId() for accessibility (instead of nanoid like a normal person), this matters. Otherwise, carry on. 😁

React 19.2: optimized, hydrated, emotionally regulated. Sigma era achieved. 💅
Now go build something. I'll be here, compiling in the background, quietly judging your useEffect dependencies 😉

React and the City ⚔️ Part 3: Return of the MCP

Anju Karanji — Fri, 24 Oct 2025 07:37:34 +0000

⚡️ Part 3: When Your AI Helps You Integrate... Another AI

FIELD NOTE

Two MCP servers purring on localhost like they own the place.
Claude Desktop conducting the symphony.
Me at 2 AM, wearing yesterday's hoodie, convinced I've achieved enlightenment.
🧘🏽‍♀️ Narrator: She had not.

So there I was, watching two MCP servers hum contentedly, when I realized: My Next.js app still wasn’t part of the conversation.

So I did what any reasonable developer does at 2 AM — opened Claude and typed the most dignified technical query of my career: "Help. Plz. Make thing talk to other thing."

🤝 The Pair-Programming Dance

What followed was the most delightful pair programming session where an AI helped me integrate... another AI. Meta? Absolutely. Effective? You have no idea. Slightly concerning for the future of humanity? We'll cross that bridge when the robots tell us to.

Plot twist: the fancy server.tool() wrapper everyone talks about? Didn't work.
So I rolled up my sleeves and went full grease-monkey with CallToolRequestSchema, ListToolsRequestSchema — the raw MCP APIs.

Suddenly I wasn't writing React; I was rebuilding the Millennium Falcon's hyperdrive while Chewie (Claude) gave me encouraging but technically vague advice.

🧰 First Challenge: Teaching Next.js to Talk MCP

I needed to spawn my MCP server as a child process.

Added a bin entry in package.json so npx component-tree-services could invoke it — basically letting npm drop a symlink in node_modules/.bin/.

  "bin": {
    "component-tree-services": "./build/src/index.js"
  }

Now Next.js could whisper sweet JSON into my MCP server’s socket.

💃 Step by Step: The 5-Line Rule

By this point I was deep in pair-programming with Claude.

Claude: "Okay, first let's import the dependencies—"
Me: "STOP. Just the imports."
Claude: "Here are the four import lines—"
Me: "Perfect. Next five."

And so it went. Slow, methodical, and shockingly peaceful — like meditation, but with TypeScript errors.

When something broke (and oh, things broke), I knew exactly which five lines to blame. No more spelunking through 200 lines of stack traces.

Me: "Wait — I need an API key?"
Claude: "Yes."
Me: "I have to PAY for this?"
Claude: "Yes."
Me: "With MONEY?"

I stared at my $7 oat milk latte. Then at my screen. Then back at the latte.

We proceeded.

Turns out, yes — minimum $5 deposit, around $0.03 per voice command. The 5-line rule wasn't just debugging discipline — it was a reminder that when building with AI, slowness is your ally. Also, apparently so is having a credit card.

🔁 The Loop (Or: Why Claude Needs Multiple Turns)

When I said, “delete the red Welcome button,” Claude couldn’t just … do it in one go.

From Claude’s point of view:
1️⃣ Get the tree (get_tree)
2️⃣ Find the red Welcome button
3️⃣ Call delete_component with the right keys

Problem: Claude can only use one tool per turn. Like a video game character who can only do one action before waiting for your input.

Claude: "I have retrieved the tree."
Me: "Great! Now delete the button."
Claude: "I cannot. It is not my turn."
Me: "...this is like playing chess with a very polite robot."
Claude: "Check."

Solution: build a loop so it can use a tool → see the result → think → use another.

(One small while-loop for code, one giant leap for machine autonomy.)

🔥 The Chokidar + SSE Symphony

At this point:

✅ Voice commands working
✅ Property updates working
❌ UI still clueless

Enter stage left: Chokidar, the watcher, and Server-Sent Events, the messenger.

Chokidar just stares at component-tree.json like a very dedicated stalker. The moment it twitches — it screams in binary.

watcher.on('change', () => callback('update'));

SSE keeps an open line to the browser, ready to whisper: “Hey, something happened.”
React refetches, the UI rerenders, and peace returns to the galaxy.

🎯 The Victory Lap

THE APP WORKS.

“Add a blue Welcome button.” → It appeared.
“Make it pink.” → It blushed.
“Delete the pink button.” → Gone.

I definitely danced. The chair did a little spin.
My cat watched from the couch, radiating judgment.
She's seen me debug before. This changes nothing between us.

All the moving pieces — voice input, MCP servers, Claude's orchestration, real-time updates — finally talking like old friends at a coffee shop.
Me? Trying not to cry into my keyboard. (The keys stick when they get wet. Learned that the hard way.)

🎬 Proof of Life: Here’s the app listening, obeying, and making me question the definition of "control."

🧩 The Stack (a.k.a. How the Magic Actually Works)

Voice Input (Web Speech API)
↓
Next.js API (MCP Client)
↓
Anthropic Claude API
↓
component-tree-services (MCP Server)
↓
component-tree.json
↓
Chokidar (File Watcher)
↓
SSE (Real-time Updates)
↓
React (UI Re-render)

A perfect loop — thoughts to words, words to code, code to UI — stitched together by caffeine and curiosity.

💭 What Just Happened Here?

React Compiler saved my renders.
Claude API saved my sanity.
MCP saved the project.
And the 5-line rule? That saved me.

🚀 Next Up: Deploy Like It’s 2025

Now that everything works — servers hum, Claude orchestrates, components obey — there’s only one thing left: set it free.

In Part 4, I take this caffeine-fueled contraption to Vercel and see if the cloud is ready for an app that talks back.

Stay tuned.
It’s live or nothing. ⚡️
(Or as my laptop calls it: "may the fans be ever in your favor.")

P.S. Repo is live: SayBuild. You’ll need an Anthropic API key, a tolerance for experimental tech, and a cat for moral support. Cat optional but recommended.

UPDATE (Oct 30, 2025):
It's live at saybuild.vercel.app.
Getting it there involved the usual Supabase/Vercel dance—Auth redirects pointing at localhost, environment variables playing hide-and-seek, and ESLint blocking deployment over my types. Not glamorous, but it finally is deployed!
Also switched from Claude Sonnet to Haiku (30x cheaper, still excellent at function calling). Turns out you don't need the Ferrari when the Honda does the job just fine.
Try it out. Break it. Let me know.

React and the City ⚡️: Nevertheless, She Persisted

Anju Karanji — Sat, 18 Oct 2025 02:06:41 +0000

⚡️ Part 2: May the Force Be With You!

FIELD NOTE: Continuing research on Project SayBuild, the voice-driven page builder.
After React Compiler restored my faith in chivalry, I decided to flirt with English literature — language parsing. The results were… how shall I put it? Humbling.

🔬 EXPERIMENT 2: Custom Pattern Matching for Voice Commands

Objective:
Teach the builder to understand speech without using an LLM.
Why skip the obvious solution?
Pride. Pure, unfounded pride.

Hypothesis:
If I can break every command into verbs, nouns, prepositions, and modifiers — then map them to CRUD operations on the component tree — I’ll have unearthed "intelligence" once again.

Estimated time to success: 30 minutes. With beer breaks every 5.

🧠 Day 1 — Confidence Level: 100%

My parser is elegant. My pattern matching is flawless.
I’m basically building natural language understanding from scratch. Future historians will bow before the great Anju.

😵 Day 2 — Confidence Level: 12%

Turns out humans don’t speak in clean patterns.
They mumble. They change their minds mid-sentence. They say things like, "Add a big-ish button in the middle of that... uh... brownish thingy."
Regex cried. I cried. We all cried.

🪦 DAY 3 – 3:00 AM

I surrender.
Deleted half the code. Summoned the LLM like a desperate summoning ritual, ego served on a platter.
It responded immediately.
It understood "Add a big-ish button in the middle of the brownish thingy."
It knew which component "it" referred to.
It handled every edge case I'd spent three days regex-fighting.

Time to implement: 45 minutes.

☠️ Conclusion:
Hubris detected.
Pattern matching is strong with the Dark Side.
LLM partnership initiated.

🧩 THE DIY PARSER PHASE (RIP)
The plan was simple:

Verbs → CRUD operations (add, delete, update, move)
Nouns → UI components (button, text, image)
Prepositions → Spatial relationships (inside, below, next to)
Modifiers → Props (big, blue, centered)

Linguistics 101, right? Just map words to actions.

Suffice to say, it was not Linguistics 101 😒

The way the LLM handled pattern matching, you’d think it was built on that very concept.

But then it hit me — why stop at parsing?
What if the LLM didn’t just understand the commands… what if it orchestrated everything?

🧭 FIELD NOTE: The MCP Awakens

For the past year, everyone’s been talking about MCP servers.
Every conference. Every LinkedIn post. Every "what’s new in AI" panel.
I nodded along politely, secretly wondering, "Is this another blockchain in the making?" 🤨

Then I wandered into an MCP session at the Atlanta Developer Conference.
Dimly lit room. Engineers leaning forward.
The presenter described it simply: lightweight servers that let LLMs talk with structure, schema, and boundaries — clean delegation, clear contracts.

Something clicked.
I walked out of that room knowing exactly what I had to do.
So I did what any reasonable developer would: went home, abandoned my laundry to its fate, and rewired SayBuild overnight.

🧩 Curiosity killed the cat but satisfaction brought it back

The Setup:

2 MCP Servers:
🧠 State Server — reads and writes to the component tree
📊 Data Server — holds component-tree.json + Chokidar watcher

Other players:
1 LLM: the orchestrator — smart enough to delegate
1 Next.js App: the display layer with live updates via SSE

Converted the project to a pnpm workspace with proper package separation. Immediately pushed 123MB of node_modules to GitHub because /node_modules only ignores root — not workspace folders.

Public Service Announcement for monorepo newbies: use node_modules (without '/') in order to ignore it everywhere. 🙇🏽‍♀️

🧭 MCP Architecture

Next up: wiring it all together — two MCP servers, one LLM orchestrator, and a stubborn developer who just wouldn't quit. Stay tuned for Part 3: The Servers Strike Back.

☕ Unsolicited Wisdom from My Ceramic Life Coach

Anju Karanji — Wed, 08 Oct 2025 03:36:23 +0000

My mug said to me I should stop checking LinkedIn and start writing again. I told it to mind its own handle.
The nerve!☕️

So… My coffee mug and I have been in a committed relationship for 8 months now.

We’ve been through all my ups and downs together — the late-night “Maybe I should just become a stripper… look at CardiB already!” spirals, the unfinished Leetcode medium dynamic programming problems, and my designer collection of rejection emails — you know, the 'we were truly impressed' ones sent from do-not-reply — stored in a PriorityQueue minHeap ranked by fake warmth.

And it’s also my most annoying best friend.

Mug: "You could practice Dijkstra’s algorithm."
Me: "Why? I’m not even sure I can find the shortest path to employment."

She huffs a little.

I open Leetcode. Stare at 'Two Sum' like it personally wronged me. Close it. She eyes me critically.

Me: "Remember when I used to do this stuff for fun? Like, actual fun? I’d stay up till 3 a.m. debugging some stupid recursive function just because I enjoyed it. Now I’m supposed to invert a binary tree while maintaining eye contact and ‘showing my thought process.’ Ugh."
Mug: "Suck it up, buttercup. Skeletons have more backbone — and they'd probably nail the system design round."

She laughed at her own joke.

Me: "I hate you."
Mug: "No you don't. I'm literally the only relationship that's working out for you right now."

I used to deploy to AWS. Now, I just stare at the clouds for 30 minutes and hope the universe autosaves my future.

Mug: "You know what your problem is?"
Me: "Oh good, a list. I love lists."
Mug: "Maybe you should follow up?"
Me: "With who? The recruiter who disappeared after asking for my availability, or the one who called me ‘Anjay’?"
Mug: "Both. The living and the dead deserve closure."

I stare into what’s left of my coffee. It stares back — judgmentally, of course.

Me: "You think I’m wasting time, don’t you?"
Mug: "You? The great Anju?" She scoffed at me.
"You’re just running an extended background process called existential dread."
Me: "Ha-ha."
Mug: "Relax. Maybe this isn’t a gap. Maybe it’s a refactor."
Me: "You sound like one of those LinkedIn influencers who post 'Stop scrolling. Start building.' and then sell online courses."
Mug: "Maybe you do need some discipline."

I roll my eyes, but something about it sticks.
A refactor? Huh…
All those old patterns I wrote under pressure (the ones those K-pop demon hunters warned me about) — all the unnecessary dependencies I kept around just to make things compile.
Maybe they’re being rewritten quietly, in the background.

Me: "Okay, okay. I get it. You're very wise for a vessel."
Mug: "I contain your caffeine. I am your life force. Show some respect."

I sigh, open my laptop, and hover over a blank document.

Me: "What now?" I ask.
Mug: "Write."
"Not a résumé. Something real."

So I do.

Mug: "Finally. Was that so hard?"
Me: "Shut up. You're just a cup."
Mug: "A cup that's been carrying you for eight months. You're welcome."

React and the City 💘: The Compiler Saves the Day

Anju Karanji — Sat, 27 Sep 2025 01:57:03 +0000

Welcome to the pilot episode of - React and the City

And yes, it’s another AI chatbot tutorial
(cue the collective groans reverberating across the internet and echoing into the galaxy far, far away🌌).

But this one’s special. Why, you ask? Because you never forget your first. 😉

From Rejection to Experiment

Picture this: after months of interviews, the rejection landed like a guy who talks marriage, then ghosts the second you ask to see his house.

Ouch.

Here’s the upside, though - the take-home assignment planted an idea. The task was to build a “mini” version of their visual page builder: the usual drag-and-drop editor hooked up to an iframe preview. Standard fare.

Except while writing the jest tests, I couldn’t stop thinking about Cypress. You know how Cypress runs tests in a little Broadway show right in front of you? And then it hit me: what if building the page wasn’t about dragging or typing… but talking?

Cue lightbulb moment. 💡
 
I won’t bore you with the standard page-builder setup (like one of those lazy “you look nice” compliments 🙃).
It’s just the usual React component tree managing an iframe preview.
If you’re curious, the repo’s here: SayBuild.
Let’s skip to the fun part: making it listen.

Making the Page Builder Listen

I wanted to build something that would actually listen - a revolutionary concept in more than just tech 😉. Enter the Web Speech API.

At first, everything seemed perfect. Speech recognition was working, my page builder was responding in real time.
I thought: this is the beginning of a beautiful friendship.

Cool, right? Except my laptop started heating up like it was single-handedly handling every therapy session on ChatGPT across the country.

Naturally, I assumed: “Oh no! Speech recognition is melting my CPU.” Alas — she had been such a lovely friend so far!

Turns out… nope. 🙃

The Gaslighting Phase

I was mourning my friendship with speech recognition… only to realize it was React gaslighting me all along.

Debugging this felt like having the talk.
Me: "Why are you re-rendering me constantly?"
React: "I don’t know… I just need space right now."

What was actually frying my laptop?

I opened the React Profiler, and there it was: my renders were spiraling out of control. Functions kept getting recreated, and my poor useEffect hook was spinning like a dog chasing its tail.🌀

 const sendMessageToHost = (message: Message) => {
    if (iframeRef.current?.contentWindow) {
      iframeRef.current.contentWindow.postMessage(
        message,
        "http://localhost:3000"
      );
    }
  };
  useEffect(() => {
    sendMessageToHost({
      type: MESSAGE_TYPES.UPDATE_COMPONENTS,
      components: debouncedComponentTree,
    });
  }, [debouncedComponentTree, sendMessageToHost]);

React and its mind games! Normally, you toss in a useCallback, hope ESLint nags you about missed dependencies, and move on.

But this time I thought: what if I let the new React Compiler do the heavy lifting - give the dude a chance?

React Compiler to the Rescue

I felt like I met Lisaan Al-Ghaib when I turned on the experimental compiler in next.config.js:

// next.config.js
const nextConfig = {
  experimental: {
    reactCompiler: true
  }
};

I deleted all my manual memoization.

The results? Render times dropped from 20.8ms → 2.1ms. No useCallback, no headaches, no babysitting dependencies.

Honestly, React Compiler felt like a knight in shining armor. 🛡️

The compiler looked at my sendMessageToHost function, realized it had no dependencies, and just… memoized it for me.

👉 Read Part 2: ⚡️Nevertheless, She Persisted (In which the builder learns to understand you - and promptly humbles me.)

The Future

Now I have:

A page builder that listens (mind-blowing!).
Laptop no longer stranded in the Sahara without a water bottle.
Daydreams of a future with the React Compiler. 💭

Next I focus on:

Parsing commands like “add a button with text ‘Click Me’”
Handling chaos like “make it blue” when there are five buttons
Mapping natural speech to component props without losing your mind

Basically, we’re past the talking stage — things are getting serious. 😉

"Thank U, Next" by Ariana Grande

Sometimes the best ideas show up when life goes off script.

This one just happens to involve speech recognition, a rejection email, and a little help from the React Compiler.

🎤 To be continued… 💭

Breaking the Rules at Privet Drive: A React Origin Story

Anju Karanji — Tue, 23 Sep 2025 21:09:10 +0000

The frontend developers of number 2013, Privet Drive, were proud to say they kept their code perfectly normal, thank you very much. HTML stayed in its cupboard, CSS in its closet, JavaScript in its corner — and they liked it that way. And here I was, breaking all their sacred rules.

I was small and skinny for my age, and wore my cousin Angular's oversized hand-me-downs. My code looked clunky next to my bigger, successful cousin.

One morning, on May 29th, 2013, a letter arrived — not by owl, but on a stage at JSConf US. It wasn’t sealed in wax, but in curiosity. Inside: JSX.

That day Jordan Walke introduced me to the world; I wore my Sunday best to the conference and the programmers looked skeptical. Some even hostile. “JSX! Mixing HTML and JavaScript? An abomination,” they scoffed. Most of the world still bowed to the Dark Lord jQuery.

Underneath my awkwardness, I had talent. My secret sauce -> always redraw the whole tree.

Not literally - duh, I'm not a barbarian.

To many developers, the DOM felt like a brick wall. I discovered a secret passage — a virtual DOM, hidden in plain sight — where updates could slip through. There, I could diff trees and apply only the changes: same type? patch props; different type? replace the node.

At first, my children were shuffled about like nameless first-years on the train. But then I found the magic of a key. At last, each child was sorted not by seat, but by identity — like a Sorting Hat whispering who they truly were.

Two years had passed by then. 2015 was a big year for me. I started embracing simple, elegant, stateless functional components - little functions that took props and returned JSX, nothing more. Little did I know I was planting the seeds of my own future, but I'm getting ahead of myself.

By then, I was v0.14. One day at lunch, this kid came and sat next to me. "Hey, I'm JavaScript ES6+," he said casually. "That virtual DOM thing you do? Pretty impressive."

Just like that, he became my best friend.

TypeScript soon joined my circle too. The RFC process was my ancient headmaster: patient and wise. Each new spell of syntax or feature was weighed in his study before being released to the wider world.

I also met Netflix and felt this overwhelming feeling of acceptance.

I was still using my stack-based reconciliation back then. Start at the root, render each node, dive into the children — all the way down to the leaves before climbing back up. Recursive, synchronous, relentless. Since I was single-threaded, I froze the entire world until my work was done. It wasn’t elegance; it was brute determination.

At first, I thought this was enough. But as I matured, I began to see the cracks: jank, dropped frames, unresponsive interfaces. My users noticed too — and it hurt. Somewhere deep inside, I felt the stirrings. The first whispers of what would eventually become Fiber.

Cut to 2017. I completely rewrote my react internal engine to use fiber. Each React element had a corresponding fiber node and they are no longer re-created every render.

I learned patience. I could split my work into chunks, pause midway, and resume later — or even abandon tasks I decided weren’t worth finishing.

I began to live in two worlds at once: a current tree, the one you saw on the screen, and a work-in-progress tree, where I quietly shaped the next update. For the first time, I could prioritize my tasks — urgent updates first, background work later. This discipline opened the door to features I’d only dreamed of before: Concurrent Mode, Suspense, even hooks like useDeferredValue.

At last, I had come of age!

Before I knew it, it was 2018. And that's when I meet hooks! One look and I knew I was in love! Suddenly, everywhere I turned, it was useState, useEffect, useContext. They weren’t just utilities, they were a new mental model.

Hooks transformed me. It felt like spring had finally arrived — and yes, roses had never smelled sweeter.

With hooks, I found myself!

My dear developers still loved me, but I could sense their growing frustration. The work of building UIs had become a balancing act: memoize too much and you choke performance, memoize too little and you drown in re-renders. useCallback, useMemo, React.memo — these spells cluttered their minds, stealing energy from the real joy of UI creation.

I knew something had to change. For years, I had prided myself on my runtime capabilities — Fiber, scheduling, concurrency. But I had limits. I swallowed my pride and called in reinforcements.

My brilliant, affluent uncle arrived — the React Compiler. He could see through my components, analyze them at build time, and slip optimizations in automatically. Where I once asked developers to carry the burden of performance, he promised to carry it for them.

Looking back, I realize I may have outgrown my teenage infatuation with Hooks. Yet I haven’t left them behind — not fully. For now, they’re still by my side, shaping how I think and speak. And as I continue to evolve, I can see the React Compiler settling into something deeper as well - not just a distant uncle, but a father, a true part of my family.

Soon it would be time for the next major release.
"Will you write to me over the summer?" one developer asked as they pushed their latest commit.
I smiled. They still didn't realize I was always there, always evolving.
"I'll be around," I promised. "After all, someone has to keep breaking the rules at Privet Drive."

For the first time in my life, I was truly excited to go home — because now I knew where I belonged: in the world of frontend development, making beautiful interfaces feel smooth, alive, and lightning fast.

Design Patterns by Purpose: The Command Pattern in Frontend Life (Part 4)

Anju Karanji — Thu, 11 Sep 2025 14:03:09 +0000

The Command Pattern: Because Undo Shouldn't Be Rocket Science 🚀

The Undo Hell Nightmare

Picture this: You're building a rich text editor. Users type, format, delete, paste images—and then inevitably smash Ctrl+Z expecting everything to magically reverse. Without the Command Pattern, you're staring into the abyss of "Undo Hell": a massive switch statement trying to track every possible action, or worse, attempting to reverse-engineer state changes like some kind of code archaeologist.

Been there? Yeah, we all have.

The Command Pattern saves you from this nightmare. Instead of building an undo system, you build a time machine. Wrap every action in a command object, stack them up, and undo becomes as simple as popping items off a stack. Don't pray for perfect state tracking—queue commands and let them handle their own cleanup.

The Universal Remote Reality Check

Let's start with something relatable. You've built the ultimate universal remote with three magic buttons—it can control anything! Naturally, you test it on your TV, your cat, and your spouse:

TV Remote – Works like a dream. Press TurnOn → TV lights up. Press TurnOff → darkness. Press ChangeChannel → new show appears. Finally, a receiver that actually receives commands! 📺

Cat Remote – Pure chaos. Press CuddleCommand → cat teleports to the opposite corner. Press StopBeggingForFood → cat inhales the entire bowl, then screams like she's been starving for decades. Press BehaveCommand → cat locks eyes with you and slowly pushes your coffee off the table. Classic. 😹

Spouse Remote – Press DoDishesCommand... radio silence. Press ListenToMeCommand... still buffering. Press FixFaucetCommand... you know how this ends. 😂

Here's the beautiful part: same remote structure, completely different results. Each receiver interprets commands in their own way. The remote doesn't care if it's talking to a logical TV, a chaotic cat, or a mysteriously unresponsive spouse—it just fires the command and moves on.

That's Command Pattern in a nutshell: decouple the invoker from the receiver, wrap requests in neat packages, and let each receiver handle them however they see fit.

The Friday Afternoon Panic

Ever had your PM casually drop "Oh, can we add undo functionality?" on a Friday at 4 PM? If your code isn't already using Command Pattern, you're looking at a weekend of architectural surgery on a moving train.

Here's the thing: adding undo to existing code is like trying to install airbags in a car that's already driving. With Command Pattern, undo is baked in from day one.

Command Pattern: The Code Reality

Let's build this step by step, starting with the most cooperative receiver known to humankind: a light bulb. Unlike cats (or spouses), lights have exactly two states and always respond to commands.

// Command Interface - the contract for all commands
interface ICommand {
  execute(): void;
  unexecute(): void; // The magic sauce for undo
}

// Receiver - the thing that actually does work
class Light {
  private isOn = false;

  turnOn() {
    this.isOn = true;
    console.log("Light is ON");
  }

  turnOff() {
    this.isOn = false;
    console.log("Light is OFF");
  }
}

// Commands - actions wrapped in objects
class LightOnCommand implements ICommand {
  constructor(private light: Light) {}

  execute() {
    this.light.turnOn();
  }

  unexecute() {
    this.light.turnOff(); // Knows how to undo itself
  }
}

class LightOffCommand implements ICommand {
  constructor(private light: Light) {}

  execute() {
    this.light.turnOff();
  }

  unexecute() {
    this.light.turnOn(); // Every command is its own time machine
  }
}

// Invoker - your remote control
class RemoteControl {
  private undoStack: ICommand[] = [];
  private redoStack: ICommand[] = [];

  constructor(private on: ICommand, private off: ICommand) {}

  pressOn() {
    this.on.execute();
    this.undoStack.push(this.on);
    this.redoStack = []; // Clear redo when new action happens
  }

  pressOff() {
    this.off.execute();
    this.undoStack.push(this.off);
    this.redoStack = [];
  }

  pressUndo() {
    if (this.undoStack.length > 0) {
      const command = this.undoStack.pop()!;
      command.unexecute(); // Command knows how to undo itself
      this.redoStack.push(command);
    }
  }

  pressRedo() {
    if (this.redoStack.length > 0) {
      const command = this.redoStack.pop()!;
      command.execute();
      this.undoStack.push(command);
    }
  }
}

// Usage - simple and clean
const light = new Light();
const onCommand = new LightOnCommand(light);
const offCommand = new LightOffCommand(light);
const remote = new RemoteControl(onCommand, offCommand);

remote.pressOn();    // Light is ON
remote.pressOff();   // Light is OFF  
remote.pressUndo();  // Light is ON (undid the off command)
remote.pressRedo();  // Light is OFF (redid the off command)

Notice how the remote doesn't know anything about lights—it just executes commands. That's the magic of decoupling.

Frontend Reality: Where You've Seen This Before

Command Pattern isn't some academic exercise—you interact with it daily:

Google Docs undo - Every keystroke is a command
Figma/Canva operations - Drawing, moving, styling—all commands
VS Code - Every edit, format, refactor is wrapped as a command
Photo editors - Crop, filter, adjust—each step is undoable because it's a command
Any app with Ctrl+Z - If it has undo, it probably uses Command Pattern

Anywhere you see "Edit → Undo" in a menu, someone implemented Command Pattern (or should have).

The Reusable Button Problem

Here's where Command Pattern becomes your secret weapon. Imagine a single Undo button you can drop anywhere in your React app—toaster notifications, modals, WYSIWYG editors. Same button, completely different behaviors.

The button doesn't know what it's undoing. Each context provides its own command:

// Command interface
interface UndoCommand {
  execute(): void;
}

// Universal Undo Button - works anywhere
const UndoButton = ({ command }: { command: UndoCommand }) => (
  <button onClick={() => command.execute()}>
    ↶ Undo
  </button>
);

// Different commands for different contexts
const toasterUndo: UndoCommand = {
  execute: () => showDeletedItemAgain(),
};

const modalUndo: UndoCommand = {
  execute: () => reopenModal(),
};

const editorUndo: UndoCommand = {
  execute: () => undoLastTextOperation(),
};

// Same button, different superpowers
function App() {
  return (
    <div>
      <ToastNotification>
        <UndoButton command={toasterUndo} />
      </ToastNotification>

      <Modal>
        <UndoButton command={modalUndo} />
      </Modal>

      <TextEditor>
        <UndoButton command={editorUndo} />
      </TextEditor>
    </div>
  );
}

One button to rule them all. The Command Pattern makes your components truly reusable.

Memory Management: The Harsh Reality

Here's what the tutorials don't tell you: Command Pattern can eat your RAM for breakfast. Every undoable action lives in memory until you clear it. I learned this the hard way when users crashed our app by typing a novel.

Production-ready strategies:

Cap your undo stack (50-100 commands max)
Batch tiny operations (merge keystrokes into word-level commands)
Compress repetitive actions (10 cursor movements → 1 "move right 10" command)
Clear on major operations (file save, page navigation)

class SmartRemoteControl {
  private undoStack: ICommand[] = [];
  private readonly MAX_UNDO_HISTORY = 50;

  execute(command: ICommand) {
    command.execute();
    this.undoStack.push(command);

    // Prevent memory leaks
    if (this.undoStack.length > this.MAX_UNDO_HISTORY) {
      this.undoStack.shift(); // Goodbye, oldest command
    }
  }
}

Advanced Patterns: Level Up Your Game

Macro Commands - Group operations into super-commands:

// "Format Paragraph" = Select All + Bold + Center Align
const formatParagraph = new MacroCommand([
  new SelectAllCommand(),
  new BoldCommand(),
  new AlignCenterCommand()
]);
// One undo reverses all three operations

Command Chaining - Build pipelines that auto-rollback on failure:

// Form submission pipeline
new CommandPipeline()
  .add(new ValidateFormCommand())
  .add(new SaveDraftCommand())
  .add(new SubmitToAPICommand())
  .add(new ShowSuccessCommand())
  .executeWithRollback(); // If any step fails, previous steps auto-undo

When NOT to Use Command Pattern

Don't be that developer who turns everything into a command. Skip it for:

Simple toggles (isDark ? 'dark' : 'light')
One-off actions that will never need undo
Performance-critical paths (command dispatch has overhead)
Basic CRUD where you're just calling a method

If you're creating commands just to call a single method with no undo needs, you're overthinking it. Not every button press needs to be a command.

The Bottom Line

Command Pattern turns chaos into order:

Invokers (buttons, remotes) don't need to know what they control
Commands wrap requests and handle their own undo logic
Receivers do the actual work without knowing who called them
You get undo/redo for free, plus amazing flexibility

It's the programming equivalent of having a universal remote that actually works. Your future self will thank you when requirements change next sprint (and they always do).

What's your Command Pattern war story? Drop it in the comments—we've all been there.

Design Patterns by Purpose: The Strategy Pattern in Frontend Life (Part 3)

Anju Karanji — Fri, 22 Aug 2025 02:46:04 +0000

You've tamed structure (Module) and domesticated creation (Factory). Next up: behavior.

Consider a payment processor that needs different personalities (credit card, PayPal, crypto, bank transfer, gift card). Left alone, it turns into an if/else hydra. The Strategy Pattern trims that chaos: you define a small, stable interface for the operation (say process, validate, or charge) and pass in interchangeable implementations at runtime. Call sites stay consistent; only the strategy changes. Result: fewer branches, cleaner tests, and new variants without touching the core. Swap, don't sprawl.

Cat Behaviors: The Furry Problem

Meet Cat, our base class.
Now the variants: StreetCat, HouseCat, ManekiNeko, HelloKitty (famously… silent).

Hard-coding eat(), meow(), and move() into Cat breaks half the family—some behave differently, some don’t meow at all. Copy-pasting those methods into every subclass? Hairball city.

Enter Strategy: pull -> eat, sound, and move into small, swappable objects with the same interface. Compose each cat with the behaviors it actually needs at runtime. New cat? Meet RoboCat—USB-C-powered, doesn’t eat, outputs a synthetic meow, and yes, it flies. You just plug in eatBehavior: none, soundBehavior: synth, and moveBehavior: thrusters. No base-class surgery, no if/else hairballs—just composition that feels like a firmware upgrade.

A real-world pass: CollapsiblePanel with pluggable behaviors

Time to leave the cat café and touch UI. The panel’s structure stays boring on purpose; the behavior gets swapped in.

You ship a solid CollapsiblePanel, and suddenly it’s everywhere. Marketing wants color + sparkle on click. Settings wants non-clickable panels. The dashboard wants panels sorted by priority. Sound familiar? This is where the Strategy Pattern earns its keep: don’t fork your component or stuff it with if/else. Make it behavior-agnostic and accept tiny “strategies” for clicks, sorting—whatever you need.

Think of it this way: the panel is the car; strategies are the drivers. The car exposes the wheel and pedals; the driver decides how to drive. Your panel exposes markup and state; strategies decide what to do.

You can create small strategy functions for different behaviors:

// Strategy objects
const clickStrategies = {
 colorSparkle: {
   onClick: (id) => addSparkleEffect(id),
   getStyle: (id) => ({ backgroundColor: 'lightblue', transition: 'all 0.3s' })
 },
 disabled: {
   onClick: () => {}, // No-op
   getStyle: () => ({ opacity: 0.6, pointerEvents: 'none' })
 }
};

const sortStrategies = {
  priority: (panels) => [...panels].sort((a, b) => a.priority - b.priority),
  alphabetical: (panels) => [...panels].sort((a, b) => a.title.localeCompare(b.title)),
};


// The panel stays behavior-agnostic
const CollapsiblePanel = ({ id, title, children, clickStrategy = clickStrategies.disabled }) => {
 return (
   <div>
     <div 
       onClick={() => clickStrategy.onClick(id)}
       style={clickStrategy.getStyle(id)}
       className="panel-header"
     >
       {title}
     </div>
     <div className="panel-content">{children}</div>
   </div>
 );
};

// Usage
<CollapsiblePanel 
 id="marketing" 
 title="Campaign Results"
 clickStrategy={clickStrategies.colorSparkle} 
/>

<CollapsiblePanel 
 id="dashboard"
 title="Web Traffic"
 clickStrategy={clickStrategies.disabled} 
/>

Before You If/Else

When you feel an if (type === 'special') coming on, pause. Ask: “Could this be a strategy instead?” If yes, extract a tiny function, pass it in, and keep your component calm. Future-you (and your team) will thank you when requirements change again next sprint.

Gotchas

No default strategy? Give your component a safe fallback (e.g., disabled behavior) so it never crashes when someone forgets to pass one in.

Testing panic? Don’t test every combo :)

Over-strategizing? Not every if deserves a strategy. A quick inline check is fine when there are only one or two cases and they won’t grow - extract them when you actually need the third variation.

When NOT to use Strategy:

Simple toggles (theme.dark ? 'dark' : 'light')
One-off customizations that won't grow
Performance-critical paths (strategy dispatch has overhead)

When Strategy shines:

Multiple implementations of the same interface
Runtime behavior switching
Plugin architectures
Algorithm families that need to be swappable

Final Thoughts

Strategy is the gateway drug to plugin architectures. Mastering this helps you build micro-frontends, extensible design systems, and even frameworks that don't lock you into their opinions. Your components become platforms, not just UI blocks.

Posting in case it helps someone.

Design Patterns by Purpose: The Factory Pattern in Frontend Life (Part 2)

Anju Karanji — Thu, 31 Jul 2025 22:32:22 +0000

🏭 The Factory Pattern – Creating Without Clutter

Before I open a PR, I scan my code like a typical disappointed Asian parent: "Why are there three identical button setups? Who copy-pasted this API client everywhere? And what's with all these validators doing the exact same dance?"

Each one technically works, but asking every file to memorize a 15-step recipe is like teaching the whole family to make rasam from scratch every time — someone’s bound to mess up the masalas.

That’s where the Factory Pattern comes in: it centralizes creation.
Instead of copy-pasting setup code, you just ask by intent — “primary button,” “authenticated client,” “email validator.” The factory knows the house recipe and returns a ready-to-use object.

Best part: when you decide to switch from chat masala to turmeric (or swap an API provider), you update the factory once. Every dish — and every file — automatically gets the upgrade, no family meeting required.

Where the Factory Pattern Quietly Does Its Magic

Think about visual page builders.

// Component Factory for page builder
const ComponentFactory = {
  create: (type, props) => {
    switch(type) {
      case 'hero':
        return new HeroComponent({
          ...props,
          className: 'hero-section',
          defaultHeight: '500px'
        });
      case 'testimonial':
        return new TestimonialComponent({
          ...props,
          showAvatar: true,
          maxLength: 200
        });
      default:
        throw new Error(`Unknown component type: ${type}`);
    }
  }
};

// Usage - clean and simple
const hero = ComponentFactory.create('hero', { title: "'Welcome' });"

It’s flexible, too. These factories are often built using polymorphism, so if your current setup ever starts to feel clunky — or you need something more scalable — you can swap in a different factory without touching the rest of the system.

That kind of design stays clean for years.

Beyond the Basics: Simple, Method, and Abstract

Do you see where I’m going with this?
Imagine you have an Outfit Generator for different kinds of days:

🧰 Simple Factory – kinda simplistic

A Simple Factory is a convenient helper that builds an object based on a parameter — like our Outfit Generator picking “pajamas” or “blouse & skirt.”

⚠️ Note: Purists don’t list this as an official “Gang of Four” pattern because it doesn’t involve inheritance or polymorphism — it’s basically a neat wrapper around new. Still, for small apps it’s practical and keeps creation logic in one spot.

const OutfitFactory = {
  create(type) {
    switch (type) {
      case 'wfh': return 'Mismatched pajama set';
      case 'office': return 'Clean blouse & skirt';
      default: throw new Error('Unknown vibe');
    }
  }
};

🏭 Factory Method – stylists with their own rules

The Factory Method pattern delegates creation to specialized “stylists.”
Each subclass knows how to assemble its look.

class Stylist {
  createOutfit() {
    throw new Error('Override me');
  }
}

class WFHStylist extends Stylist {
  createOutfit() {
    return 'Pajamas + messy bun + cookie crumbs';
  }
}

class OfficeStylist extends Stylist {
  createOutfit() {
    return 'Blouse, skirt, neat hair, hint of perfume';
  }
}

Use this when different environments need their own construction steps but you want one interface: stylist.createOutfit()

🏗️ Abstract Factory – complete lifestyle bundles

The Abstract Factory builds families of related objects, keeping them consistent.
Think of it as a recipe for the whole vibe:

class WFHBundleFactory {
  createClothes() { return 'Comfy PJs'; }
  createHair()    { return 'Messy bun'; }
  createExtras()  { return 'Crumbs on top'; }
}

class OfficeBundleFactory {
  createClothes() { return 'Pressed blouse & skirt'; }
  createHair()    { return 'Freshly washed'; }
  createExtras()  { return 'Light perfume'; }
}

Perfect when you need coordinated sets — outfit, grooming, accessories — all matching the environment.

🧪 Testing & Single Responsibility (Tiny but Mighty)

Factories also shine when it comes to unit testing and Single Responsibility.
By moving setup code into one spot, your classes stay focused on behavior — and tests can inject mocks without wading through construction logic.
(In outfit terms: you test how you wear the clothes, not how the wardrobe picked them.)

A Real-World Moment

Here’s one example from a past project:

I didn’t write the drag-and-drop code myself — but I remember noticing it.

It worked fine in Chrome, but in Firefox, things got a little weird. At the time, most users were on Chrome, so the issues went unnoticed for a while. But when the team finally needed to fix it, they had a choice: scatter browser-specific if-else checks throughout the code… or find a cleaner solution.


// Before Factory - browser checks scattered everywhere
const handleDragStart = (event) => {
  if (navigator.userAgent.includes('Firefox')) {
    event.dataTransfer.effectAllowed = 'move';
    event.dataTransfer.setData('text/plain', '');
  } else if (navigator.userAgent.includes('Chrome')) {
    event.dataTransfer.effectAllowed = 'copyMove';
  }
  // This logic gets duplicated in every drag handler...
};

// After Factory - clean separation
const DragHandlerFactory = {
  create: () => {
    if (navigator.userAgent.includes('Firefox')) {
      return new FirefoxDragHandler();
    }
    if (navigator.userAgent.includes('Chrome')) {
      return new ChromeDragHandler();
    }
    return new DefaultDragHandler();
  }
};

class FirefoxDragHandler {
  handleDragStart(event) {
    event.dataTransfer.effectAllowed = 'move';
    event.dataTransfer.setData('text/plain', '');
  }
}

class ChromeDragHandler {
  handleDragStart(event) {
    event.dataTransfer.effectAllowed = 'copyMove';
  }
}

// Usage - no browser detection needed
const dragHandler = DragHandlerFactory.create();
dragHandler.handleDragStart(event);

The main drag-and-drop code stayed clean. Easy to test. Easy to grow. When Safari needed support later, they just added another handler class — no rewrites, no mess scattered throughout the codebase.

When to Use (and Not Use) Factory Pattern

Factory shines when you have:

Multiple variations of similar objects that need different configurations
Complex setup logic that you don't want scattered everywhere
Objects that need environment-specific behavior (dev vs prod, mobile vs desktop)

// Worth using Factory - multiple complex configurations
const APIClientFactory = {
  create: (environment) => {
    switch(environment) {
      case 'development':
        return new APIClient({
          baseURL: 'http://localhost:3000',
          timeout: 30000,
          debug: true,
          retries: 1
        });
      case 'production':
        return new APIClient({
          baseURL: 'https://api.company.com',
          timeout: 5000,
          headers: { 'X-Environment': 'prod' },
          retries: 3
        });
    }
  }
};

Skip Factory when:

You only have one or two simple variations
The setup is straightforward and unlikely to change
You're just avoiding a few lines of code

// Overkill - simple toggle doesn't need Factory
const theme = isDark ? 'dark' : 'light'; // This is fine

Rule of three: once you’ve set up the same complex object three times, it’s factory time.

Scaling bonus: factories grow sideways, not everywhere.
Need a new API environment? Add a case to the factory — the rest of the codebase stays blissfully unaware.
Compare that to scattered if-else blocks you'd have to hunt down in dozens of files.