DEV Community: Jalaj Bankar

React Fiber, react-quill, and Why Component Architecture Is the Whole Point

Jalaj Bankar — Fri, 20 Mar 2026 17:25:49 +0000

A session that goes under the hood of React itself. Most developers use React without ever knowing how it actually schedules and renders work. This changes that.

**
React Fiber** — A Complete Rewrite, Not Just an Update
React Fiber landed in React v16 and it wasn't a new feature — it was a ground-up rewrite of how React does its work internally. The old system had long-standing issues that couldn't be patched. Fiber fixed them properly.
The core idea: every component now has its own Fiber — also called a Unit of Work. What you see rendered on screen is called Finished Work. The Fiber is the behind-the-scenes representation, the Finished Work is what actually made it to the DOM.

The Old Problem — Stack Reconciler
The old reconciler used a Stack data structure. Stacks are synchronous by nature — last in, first out, and you can't stop in the middle. Once React started rendering a tree, it had to finish the whole thing before doing anything else.
Imagine a large component tree rendering and a user starts typing in a search bar. The old React would make them wait. The typing felt laggy because React was busy and couldn't pause. That's the problem Fiber was built to solve.

Fiber Reconciler — Async, Prioritised, Interruptible
Fiber replaced the Stack with its own Fiber data structure — a linked list of units of work that can be paused, resumed, reused, or thrown away entirely.
Here's what that unlocks:
Split work into chunks — every single component gets its own rendering unit. Not the whole tree at once.
Pause rendering — if React sees the user typing or clicking, it can pause low-priority work and handle the interaction first.
Reuse or abort work — if something changes mid-render, React can throw away what it was doing and start fresh with the new state.
Prioritise everything — work isn't equal anymore. React assigns priority levels:
Immediate — clicks, typing. Has to feel instant.
High — animations. Can't afford to drop frames.
Low — data fetching, background updates. Can wait.
If a low-priority fetch is happening and the user clicks something, React pauses the fetch work, handles the click, then comes back to the fetch. The user never feels the lag.

The Two Phases of Fiber
Phase 1 — Render Phase (Async)
This is where React figures out what needs to change. It runs beginWork() and completeWork() on each Fiber unit — building up a picture of the new UI in memory. This phase can be paused, restarted, or thrown away. Nothing has touched the real DOM yet.
Phase 2 — Commit Phase (Synchronous)
Once React has the full picture ready, it commits everything to the DOM in one go using commitWork(). This phase cannot be interrupted — it runs synchronously start to finish. The reason is simple: you can't have a half-updated DOM visible to the user. All or nothing.

react-quill — Rich Text Editing Without Building It Yourself
react-quill is a React wrapper around Quill.js — a powerful, modular text editor engine. Quill.js itself doesn't know React exists. react-quill just bridges the two worlds.
What you get is a fully functional WYSIWYG (What You See Is What You Get) editor — Bold, Italic, Underline, links, headings, lists — all the formatting tools a user would expect in a text editor, ready to drop into a React component.
import ReactQuill from 'react-quill';

Two lines and you have a production-ready rich text editor. Saves days of work.

Component Architecture — The Three Reasons It Matters
Everything in React is a component. But why that structure exists is worth understanding properly:
Reusability — write a once, use it across fifty pages. Change it in one place, it updates everywhere. This is the single biggest time saver in frontend development.
Isolation — components don't bleed into each other. If your breaks, you open SearchBar.js and the problem is right there. You're not hunting through thousands of lines of mixed code.
Composability — components nest inside each other naturally:
<NewsFeed> <Post /> <Post /> <Post /> </NewsFeed>
doesn't need to know how renders. doesn't need to know it lives inside . Each one does its job. Together they build the whole UI. That separation is what makes large apps manageable.

SWR, Webhooks, useState Deep Dive, and a Few Things Worth Cementing

Jalaj Bankar — Fri, 20 Mar 2026 17:22:51 +0000

A session that revisits some fundamentals with fresh eyes and adds a couple of genuinely useful concepts on top. The useState explanation here is the clearest it's been — worth reading carefully.

React SWR — Show Old Data, Fetch New Data, Nobody Waits
SWR stands for Stale-While-Revalidate — a caching strategy that shows you whatever data it already has while quietly fetching fresh data in the background.
Here's what makes it worth knowing:
You give it a key (usually the URL) and a fetcher function (your actual network call). It handles the rest — caching, revalidating, deduplication.
If ten components all need the same data, SWR doesn't make ten requests. It makes one and shares the result across all of them.
It also re-fetches automatically when you re-focus the window — so if a user switches tabs and comes back, they always see fresh data without you writing any logic for it.
const { data, error, isLoading } = useSWR('/api/user', fetcher);
Three things back — your data, any error, and a loading state. Clean, no boilerplate, handles edge cases you'd otherwise forget to write.

Webhooks — Stop Asking, Just Listen
Polling is when your app keeps asking the server every few seconds — "is it done? is it done? is it done?" — like a kid in the back seat. Works, but wasteful.
Webhooks flip that relationship. Instead of you asking, the server tells you when something happens. Once, immediately, no repeated requests.
Real example — user pays via GPay → GPay sends a notification (HTTP POST) directly to your server the moment the payment is confirmed. Your server wasn't sitting there asking. GPay knocked on the door when it had news.
Better for performance, better for real-time accuracy, better for your server's sanity.

useState — The Clearest Explanation Yet
Let's go through this properly because it trips people up more than almost anything else in React.
const [data, setData] = useState(0);
useState(0) — that 0 is the initial value. What data holds on the very first render before anything happens.
data — a read-only snapshot of the current state. You cannot change it directly. Ever. data = 5 does nothing useful in React.
setData — the only door into changing state. It receives new data, tells React "store this as the new value," triggers a re-render, and on that next render data becomes the new stored value.
So the question — "if data already has data, why do we need setData?" — here's the answer:
Because React needs to know something changed. If you mutate data directly, React has no idea and won't re-render. setData is the signal. It's not just storage — it's the trigger that kicks off the whole update cycle.
setData receives → React stores → data updates → component re-renders with new value. That's the full loop every single time.

Why Callbacks Sit Between Hooks and Their Logic
onChange(() => { setCount(count + 1) })
useEffect(() => { setAPI(data) }, [])
The callback function is there to say — "wait for me to run first, then you go." The hook (useEffect, onChange, setTimeout) needs to execute before the inner logic fires. The callback is what creates that waiting relationship. Without it, the setter functions would have nothing to wait for — they'd either run immediately or not at all.

setTimeout — Wait Before You Even Start
This one is worth being precise about. The delay in setTimeout is not "run this, but slowly." It's "don't even begin until this much time has passed."
setTimeout(() => { doSomething(); }, 3000);
Three seconds of silence. Then execution begins. Nothing happens in the meantime — no partial work, no progress. Just waiting. Then go.

Always Use try / catch / finally With Async Code
This is a best practice worth making a habit immediately:
async function fetchData() { try { const res = await fetch(url); const data = await res.json(); setData(data); } catch (err) { console.error("Something went wrong:", err); } finally { setLoading(false); } }
try — the optimistic path. Things go well here.
*catch *— when they don't. Catches any error thrown inside try.
*finally *— runs no matter what. Success or failure, the loader disappears. This is non-negotiable with async functions — if you skip finally and an error gets thrown, setLoading(false) inside try never runs and your spinner spins forever.
Make it a reflex. Async function — try, catch, finally. Every time.

Promises, Batching, AbortController, and How the Web Actually Works

Jalaj Bankar — Fri, 20 Mar 2026 17:20:09 +0000

A session that fills in a lot of gaps. Some advanced Promise patterns, a React performance secret most beginners don't know about, and then a mental model for HTTP and APIs that's worth reading twice.

.then() and .finally() Are Full Functions — Use Them That Way
A common mistake is treating .then() like it can only do one thing. It's a full function — you can declare variables, write logic, run conditions, all of it:
Promise.allSettled([fetchConfig, fetchColor]) .then((results) => { const configResult = results[0].status === 'fulfilled' ? results[0].value : defaultConfig; const colorResult = results[1].status === 'fulfilled' ? results[1].value : '#FFFFFF'; })
Promise.allSettled() waits for all promises to finish — whether they resolved or rejected — and gives you a results array where each item tells you the status and value. No promise getting rejected silently breaks everything else. You handle each one individually.

The Loader and allSettled Are Best Friends
Think about it — a loading spinner should disappear exactly when the data is ready. Not before, not after. Promise.allSettled() + .finally() is the cleanest way to guarantee that:
Promise.allSettled([fetchConfig, fetchColor]) .then((results) => { // handle your data }) .finally(() => { setLoading(false); })
.finally() runs no matter what — success, failure, doesn't matter. The spinner dies exactly when the promises settle. If you don't use .finally(), you risk the spinner spinning forever if an error is thrown and .then() never runs.

JSON.stringify(data, null, 2) — Pretty Printing JSON
JSON.stringify(data.config, null, 2)
The 2 here is the indentation level — it formats the output with two spaces per level so it's actually readable in a console or log. Without it you get one long unreadable line. The null in the middle is the replacer argument — passing null just means "include everything, no filtering."

AbortController — Cancel a Request When You No Longer Need It
Imagine a user opens a page, a fetch starts, then they immediately navigate away. The fetch is still running in the background — and when it finishes, it might try to update state on a component that no longer exists. AbortController stops that:
const controller = new AbortController();
fetch(url, { signal: controller.signal })
.then(res => res.json())
.then(data => setData(data));
// When the user leaves:
controller.abort();
Inside useEffect, you'd call controller.abort() in the cleanup function — the one that runs when the component unmounts. Only update state if the user is still on the page. Clean, safe, no ghost updates.

React's Automatic Batching — One Render, Not Two
In React 18+, when you call multiple state setters one after another inside a .then() block:
setData(result); setLoading(false);
React doesn't re-render twice. It waits until the function finishes, collects all the state updates, and does one single render with everything applied at once. This is called Automatic Batching and it's a silent performance optimisation you get for free.
Why it matters — if setLoading(false) runs in the wrong place, React might render once with new data but loading still true, then render again with loading false. The user sees a half-finished page for a split second — that flicker. Keeping your state updates together inside .then() or .finally() lets React batch them properly and render once cleanly.

useState Always Holds the Initial Value
const [data, setData] = useState(null);
Whatever you pass into useState() is the starting value — what the component holds on its very first render before anything updates it. After that, only setData() changes it. Simple but worth keeping clear in your head especially when debugging why something is null on first render.

How the Web Actually Works — The Full Mental Model
These are the rules. Read them slowly:
API does not travel — the API is just a definition. A menu of what's available.
HTTP request travels — the actual message that goes across the internet.
Frontend never talks directly to DB — the browser has no business touching a database directly.
Backend owns DB communication — the server talks to the database, nobody else.
Middleware enables body parsing — without it, your backend can't read the body of incoming requests.
Methods express intent — the HTTP method tells the server what you want to do, not just where to go.

The HTTP Methods — What Each One Means:
GET — "please send me data"
POST — "please create something new"
PUT — "please replace this entirely"
PATCH — "please update just part of this"
DELETE — "please remove this"

The Restaurant Mental Model — Stick This in Your Head:
Menu = API — defines what can be ordered, doesn't deliver anything itself
Order = HTTP request — the actual message sent
*Waiter *= Internet — carries the message back and forth
*Kitchen *= Backend — receives the order, does the work
*Food *= Response — what comes back
So when someone says "the API sends data" — not quite. The API defines what data can be requested. The HTTP request is what actually goes out and asks for it. The API is the menu. The request is the order. The backend is the kitchen that actually makes the food.

Libraries, Errors, Concepts, and the Full Map of a Software Project

Jalaj Bankar — Fri, 20 Mar 2026 17:10:56 +0000

A wide session today — some React and Node utilities, JavaScript error types worth knowing, a few important concepts, and then something genuinely useful at the end: the full picture of every category of tool a real software project actually needs.

react-window — Don't Render What the User Can't See
npm install react-window
If you're rendering a list of 10,000 items, React doesn't need to put all 10,000 in the DOM at once. react-window handles virtualization — it only renders the items currently visible in the viewport and quietly swaps them out as the user scrolls. Same experience for the user, dramatically less work for the browser.

Non-Null Assertion in TypeScript — The ! Operator
When TypeScript isn't sure if a value might be null or undefined, it'll warn you. If you know it definitely isn't null, you can tell TypeScript to trust you using !:
let text = document.getElementById('text')!;
That ! at the end says "I promise this isn't null, stop worrying." TypeScript backs off. Use it when you're certain — if you're wrong, you'll get a runtime error and TypeScript won't warn you because you told it not to.

The process Object in Node.js
process is a global object Node.js gives you automatically — no import needed. It's your window into the runtime environment:
process.env — access environment variables like process.env.PORT or process.env.API_KEY
process.argv — array of command line arguments passed when running your script
process.exit(0) — clean exit, no errors, everything went fine
process.exit(1) — exit with failure, something went wrong
The exit codes matter in CI/CD pipelines — 0 means success, anything else means the pipeline should stop and flag an error.

React Context — Global Data Without Prop Drilling
Context is React's built-in way to share data across components without manually passing props through every level in between. You've touched on this before — worth restating cleanly: create the context, wrap your tree with a Provider, consume it anywhere below with useContext. The component that needs the data just reaches up and grabs it directly. No middlemen.

JavaScript Error Types — Know What You're Looking At
Every error in JavaScript has a type, and the type tells you immediately what kind of problem you're dealing with:
SyntaxError — your code structure is broken. JavaScript couldn't even parse it. Usually a missing bracket, a typo in a keyword, something that stops the engine before it even runs.
ReferenceError — you're trying to use something that was never defined. Classic sign of a typo in a variable name or using something before it's been declared.
TypeError — you're doing something to a value that that type doesn't support. Calling .map() on a string, calling a variable that's not a function, accessing a property on null.
RangeError — a value is outside acceptable limits. Passing -1 to an array constructor, or hitting maximum call stack size from infinite recursion.
URIError — malformed URI data, usually from misusing decodeURIComponent() or similar functions.
EvalError — related to eval() usage. Rare. You probably won't see this in modern code.
Custom Error — intentionally thrown by a developer when something specific goes wrong that the standard error types don't cover. throw new Error("Payment failed") is a custom error.

Circular References — When Objects Point Back at Themselves
A self-reference is when an object points directly to itself: A → A
A circular reference is when multiple objects reference each other in a loop: A → B → A
This becomes a real problem when you try to JSON.stringify() a circular reference — it throws a TypeError because JSON can't represent infinite loops. It also causes memory leaks in certain situations because the garbage collector can't clean up objects that are still technically referenced by each other.

SSO and gRPC — Two Concepts Worth Knowing
SSO (Single Sign-On) — one login, many apps. You sign in with Google once and you're automatically authenticated across YouTube, Gmail, Google Drive without logging in again. The auth is shared, not repeated.
gRPC — a way for services to communicate with each other using remote function calls instead of REST endpoints. Faster than REST, uses binary instead of JSON, and is strongly typed. Common in microservices where speed between internal services matters.

The Full Map of Tools a Software Project Needs
This is genuinely worth saving. Every serious software project needs tools across all of these categories — and knowing the full map means you're never caught off guard when a new tool gets introduced:

Planning & Tracking — requirements documentation, task management, roadmapping. Knowing what to build before building it.
Version Control — source code management, branching, collaboration. Git lives here.
Development Environment — your editor or IDE, runtime, package manager. The place where code gets written.
Build & Dependency Management — installing packages, building artifacts, running scripts. npm, vite, webpack live here.
Backend & API Layer — your server framework, database access, authentication. Express, Prisma, JWT.
Frontend & UI — rendering framework, state management, UI components. React, Redux, component libraries.
Testing — unit tests, integration tests, end-to-end tests. Each catches a different kind of bug at a different level.
Code Quality — linting, formatting, static analysis. ESLint, Prettier. The stuff that keeps code consistent across a team.
CI/CD — automated tests, deployment pipelines. Every push gets tested and deployed automatically without manual steps.
Deployment & Infrastructure — hosting, containers, cloud services. Where your app actually lives and runs.
Monitoring & Logging — error tracking, performance metrics, logs. How you find out something broke in production before your users tell you.
Security — secrets management, access control, dependency scanning. Making sure nothing sensitive leaks and no vulnerable packages sneak in.
Twelve categories. Most developers start knowing two or three of these well. Knowing all twelve exist — and what problem each one solves — is already ahead of most.

Promises, Data Flow, and the memo + useCallback Combo That Actually Makes React Fast

Jalaj Bankar — Fri, 20 Mar 2026 17:06:30 +0000

A big session with some genuinely advanced React in the second half. The memo and useCallback combination is one of those things that looks complicated but makes complete sense once you understand why it exists.

.then() Can Handle Rejections Too — Not Just .catch()
Most people only use .catch() for errors and .then() for success. But .then() actually accepts two functions — one for success, one for rejection:
promise
.then(successFn) // handles success only .then(successFn, errorFn) // handles both .catch(errorFn) // handles rejection only
Here's the quick reference:
.then(successFn) — success ✅, rejection ❌ skipped .then(successFn, errorFn) — success ✅, rejection ✅ .catch(errorFn) — success ❌ skipped, rejection ✅
And the other thing worth locking in — whatever you return inside a .then() gets passed down to the next .then() or .catch() waiting below it. The chain is just values being handed down one step at a time.

React Data Flow — The Parent is Always in Charge
A few rules that are worth stating clearly because they govern everything in React:
Only one function gets export default — that's your root component.
A prop-name and the variable holding it can be the same name — is perfectly valid.
Re-rendering starts from the Parent — no child re-renders on its own. The parent gives permission, intentionally or not.
Here's the full flow when a child updates state:
Child runs a setter function → Parent's state updates → Parent re-renders → all children re-render by default, whether they needed to or not.
That last part is the problem. A child that didn't receive any new data still re-renders just because it lives inside the parent. In small apps this is fine. In larger ones it becomes a real performance issue.

memo — Telling React "Don't Re-render This Unnecessarily"
memo wraps a component and tells React — "only re-render this if its props actually changed."
import { memo } from 'react'; export const Child1 = memo(({ setToggle }) => { console.log("Child1 Rendered!"); return <button onClick={() => setToggle((t) => !t)}>Toggle</button>; });
Sounds perfect. But there's a catch.

The memo Trap — Functions Are Always "New"
Every time App re-renders, any function defined inside it gets recreated from scratch. It looks the same to you, but React sees it as a brand new function reference. So even with memo, Child1 re-renders — because React thinks setToggle changed.
Same logic, new object. memo checks props with === — and two different function references are never === even if they do the exact same thing.

useCallback — Keeping Function References Stable
useCallback wraps a function and says "keep this exact same reference between renders unless the dependencies change."

import { useState, useCallback, memo } from 'react'; export default function App() { const [toggle, setToggle] = useState(false); const memoizedSetToggle = useCallback(() => { setToggle((t) => !t); }, []); return ( <> <Child1 setToggle={memoizedSetToggle} /> <Child2 toggle={toggle} /> </> ); } const Child1 = memo(({ setToggle }) => { console.log("Child1 only renders ONCE now!"); return <button onClick={setToggle}>Toggle</button>; }); const Child2 = memo(({ toggle }) => { console.log("Child2 renders when toggle changes."); return <p>{toggle ? "ON" : "OFF"}</p>; });

Here's why this works properly now:
Child1 — receives memoizedSetToggle. Since useCallback keeps the same function reference every render, memo correctly sees "props didn't change" and skips the re-render. Renders once, stays there.
Child2 — receives toggle. That value genuinely changes on every click, so Child2 should re-render to show the updated text. And it does.
The mental model is simple — memo skips re-renders when props don't change. useCallback makes sure function props actually don't change between renders. They need each other to work properly. One without the other only solves half the problem.

setTimeout Internals, Anonymous Functions, and the this Keyword — Properly This Time

Jalaj Bankar — Fri, 20 Mar 2026 17:03:28 +0000

One of those sessions where something you thought you understood gets explained at a deeper level and suddenly makes way more sense. The this keyword especially — this is the full picture.

setTimeout Is Just a Function Too

This sounds obvious but it's worth saying clearly. setTimeout is itself a function — one that the browser gives you. Under the hood it looks something like:

function setTimeout(callback, delay) { // browser starts the timer // when delay is done, calls callback() }

The timer doesn't start on its own. You start it the moment you write:

setTimeout(myFunc, 3000);

That line is you saying — "hey browser, start a 3 second countdown, then call myFunc." You own the trigger. The browser owns the clock.
The Only Two Valid Ways to Write an Anonymous Function

There are exactly two ways to define an anonymous function and actually use it:

`const myFunc = function() { ... }

const myFunc2 = () => { ... }`

Both store the function in a variable so you can call it later. Arrow functions are anonymous by nature — they have no name of their own, they just get stored wherever you put them.

This however is invalid:

function() { ... }

A floating anonymous function with no variable to hold it — you've created something you can never call. JavaScript won't even let this through without throwing an error. It needs a home.

this Inside Objects — The Collision Problem

When you're working with this inside an object method, there's one rule that saves a lot of pain: don't nest a regular function inside another regular function and expect this to behave.

Here's why — every time you write the function keyword, JavaScript creates a brand new this context. So when you nest one inside another, the inner one creates its own this and completely shadows the outer one. Two bosses, one conflict.

`const laptop = { brand: "Apple", showBrand: function() { setTimeout(function() { console.log(this.brand); // 'this' is Window, not laptop! }, 1000); } };

laptop.showBrand(); // undefined 😭`

The outer function in showBrand correctly points this at laptop. But the inner function inside setTimeout creates its own this — and since nothing is calling it as a method, this resets to the window object. window.brand doesn't exist. undefined.

Arrow Functions Fix This — Here's Exactly Why

Arrow functions don't bring their own this. They genuinely don't have one. Instead they look outward and say "I'll borrow this from whoever is above me" — this is lexical binding.

`const laptop = { brand: "Apple", showBrand: function() { setTimeout(() => { console.log(this.brand); // Inherits 'this' from showBrand ✅ }, 1000); } };

laptop.showBrand(); // "Apple" 🎉`

The arrow function inside setTimeout has no this of its own so it looks at its parent — showBrand — which does have this pointing correctly at laptop. Problem solved, no collision.

The Full this Mental Model — All Eight Rules in One Place

These are worth locking in properly:

this is just a reference — a pointer to whatever object is currently relevant to that function. Nothing more.

Every regular function gets its own this for free the moment it's created. That's the function keyword's doing.

Arrow functions have no this — they inherit it from the scope they were written in. That's lexical scoping in action.

When you nest a regular function inside a regular function, the inner one shadows the outer this. Two function keywords, two this contexts, collision guaranteed.

When you nest an arrow function inside a regular function, the arrow says "I'm not the boss, I'll follow whoever is above me." It binds to the parent's this at the time it's created.

A regular function called without an object (just myFunc()) — this resets to window in normal mode, or undefined in strict mode.

A regular function called as a method (laptop.showBrand()) — this correctly points to laptop.

This is why inside objects, the outer method should use the function keyword (to establish the correct this context pointing to the object), and any inner functions should be arrow functions (to inherit that same context without creating a new one).

Debugging Renders, Callbacks Everywhere, and JavaScript's Global Scope

Jalaj Bankar — Fri, 20 Mar 2026 16:57:34 +0000

A session that connects a lot of dots — practical debugging instincts, the callback pattern showing up in places you didn't expect, and a cleaner understanding of why map, filter and reduce are called methods and not functions.

When Something Doesn't Render — Where Do You Look?

This is genuinely useful debugging instinct to build early:

Image or text not showing up? — the problem is almost always in the API response. Open your browser console, go to the Network tab, find your request, and look at what actually came back. Nine times out of ten the data structure is different from what you expected — a nested property, a different key name, an empty array.

A service not working — like Google Maps, payment widgets, auth providers? — 90% of the time it's the API key. Either it's wrong, expired, restricted to a different domain, or it's not being read properly. First place to check is your runtime.config or .env file. Make sure the key is actually there, spelled correctly, and being accessed with the right variable name.

Two different problems, two different places to look. Building this reflex early saves hours of frustration.

setTimeout With a Dynamic Delay

You're not locked into hardcoding the seconds inside setTimeout — you can pass the delay as a parameter and control it from outside:

`function myFunc(twoFunc, seconds) { console.log('Hi Jalaj!'); setTimeout(() => { twoFunc(); }, seconds * 1000); }

myFunc(someFunction, 2);`

The delay becomes flexible. Call the same function with 3 and it waits three seconds. Call it with 0 and it fires almost immediately. The function doesn't care — it just uses whatever it was given.

Callbacks Are Everywhere — You've Been Using Them All Along

Once you see the callback pattern you can't unsee it. useEffect, setTimeout, setInterval, reduce, filter, map — they all accept a function while being called. That function is the callback.

And it genuinely doesn't matter whether you name it or not:

Anonymous callback — defined while calling:

greetUser("Alex", () => console.log("Logged in successfully. ✅"));

Named callback — defined beforehand and passed in:

function onSuccess() { console.log("Logged in successfully. ✅"); } greetUser("Alex", onSuccess);

Same result. The parent function doesn't care what your callback's name is — it just calls whatever was handed to it.

The Three Things a Dev Controls With Callbacks

Every time you work with a function that takes a callback, there are exactly three decisions you're making:

1 — The arguments — how many, what type, in what order you pass them. Get this wrong and nothing works.

2 — What's inside the callback — are you writing the logic inline while calling, or did you build the function separately beforehand and just drop it in?

3 — How you call the main function — are you passing an anonymous arrow function right there, or a variable that holds a pre-built function?

These three things cover every variation of the callback pattern you'll ever see. Once you can identify all three in any piece of code, callbacks stop feeling unpredictable.
The Window Object — JavaScript's Outermost Scope

In the browser, the window object is the global scope — the outermost container that everything lives inside. Functions you define at the top level, variables, even built-in things — they all exist on window.

window.setTimeout, window.console, window.alert — these are all just properties on that same object. When you call setTimeout() without any prefix, JavaScript quietly looks it up on window for you.

Why map, filter, reduce Are Methods, Not Functions

This is a subtle but real distinction worth understanding.

A function is a standalone callable — it exists on its own. A method is a function that lives inside an object.

map, filter, and reduce live on Array.prototype — which is itself an object. Every array you create inherits from that prototype, which is why you can call .map() on any array. Since they live inside an object (Array.prototype), they are by definition methods, not standalone functions.

Same applies to object methods — anything sitting inside an object as a function is a method. The distinction matters when you start dealing with this — because methods have an owner, and this points to that owner. Standalone functions don't have one, so this floats up to window.

useEffect, Callbacks, and How They Work Together

Jalaj Bankar — Fri, 20 Mar 2026 16:53:58 +0000

Short session but genuinely important stuff. These two concepts — useEffect and callbacks — are everywhere in React and JavaScript. Understanding them properly changes how you read code.

useEffect — When Does It Actually Run?
Simple and worth stating clearly: useEffect runs after every render of the component it lives in. That's its default behaviour — component renders, effect fires. No magic, no mystery.
You control when it runs using the dependency array:
useEffect(() => { ... }, []); — runs only once, on first render.
useEffect(() => { ... }, [value]); — runs whenever value changes.
useEffect(() => { ... }); — runs after every single render, no restrictions.
That's the whole mental model. Render happens first, then the effect. Always in that order.

Callbacks — A Function That Waits Its Turn
A callback is just a function you hand to another function and say "you decide when to call this."
The flow is always the same: main function runs first → callback runs inside it, wherever it was placed.
function iAmGonnaBeCallback() { console.log("I ran second!"); } function runsInsideMe(callback) { console.log("I ran first!"); callback(); } runsInsideMe(iAmGonnaBeCallback);
You're not calling iAmGonnaBeCallback yourself — you're handing it over and letting runsInsideMe decide where it fires. Could be line 1, could be line 555. You don't control that. The parent does.
Three things worth locking in about callbacks:
The callback must be defined before it's passed in — JavaScript needs to know what it is before handing it over.
You pass the function without parentheses — runsInsideMe(iAmGonnaBeCallback) not runsInsideMe(iAmGonnaBeCallback()). Parentheses would call it immediately, not pass it.
It runs exactly where it's placed inside the parent — not before, not after.

How a Callback Saves Your App Inside useEffect
Here's the flow when useEffect handles an API call — and why the callback pattern matters here:
App opens → component renders → useEffect fires immediately after → if there's no callback structure, it tries to fetch data right away → but what if the component isn't ready yet, or you want more control over timing?
The clean pattern is to define your fetch function outside and pass it in — or define it inside the effect and call it properly:
useEffect(() => { function fetchData() { // API call here } fetchData(); }, []);
The effect runs, then calls your function inside it — exactly like the callback pattern. useEffect is the parent, your fetch function is the callback. It runs where you placed it, when the effect decides. Clean, predictable, no surprises.

&&, Lexical Scope, Closures, and Why Axios Feels Nicer Than fetch

Jalaj Bankar — Fri, 20 Mar 2026 16:49:57 +0000

One of those sessions where the JavaScript fundamentals get a little deeper. These concepts — scope, closures — are the kind of things that separate someone who uses JavaScript from someone who actually understands it.

How && Actually Works in JavaScript

Most people think && just returns true or false. It doesn't — it returns one of the actual values. Here's the full picture:

If any value is falsy, it returns that falsy value and stops right there. Doesn't even look at the rest.

If one is truthy and one is falsy, it returns the falsy one.

If both are falsy, it returns the left side — because that's where it stopped.

If both are truthy, it returns the right side — because it evaluated everything and the last truthy value wins.

This is exactly why you see patterns like {isLoggedIn && <Dashboard />} in React. If isLoggedIn is false, && short-circuits and returns false — nothing renders. If it's true, && moves to the right side and returns — which renders. The whole conditional rendering pattern in React is just && doing its thing.
Lexical Scope — Where You Write It Is What Matters

Lexical scope is the rule that decides which variables a function can "see" and access. In JavaScript, an inner function always has access to its parent function's variables — not because of when it runs, but because of where it was written.

The word lexical literally means "at the time of lexing" — which is the phase where JavaScript reads your code before running it. The Lexer walks through your code, sees where variables are declared, and locks in their scope right there and then.

That's also why it's called Static Scope — it doesn't shift. It doesn't matter where or how you call the function later. The scope was decided the moment you wrote it down. No surprises, no dynamic changes.

Closures — The "Backpack" a Function Carries

A closure is what happens when an inner function holds onto its lexical scope even after its parent function has finished running and disappeared from memory.

Normally when a function finishes executing, its local variables get cleaned up. Gone. But if an inner function was returned or stored somewhere — it takes a backpack with it. That backpack contains every variable from the parent's scope that the inner function needs.

`function makeCounter() { let count = 0; return function() { count++; console.log(count); }; }

const counter = makeCounter(); counter(); // 1 counter(); // 2 counter(); // 3
`
makeCounter() finished running. count should be dead. But the returned function still has its backpack — count lives on inside the closure. Every call to counter() reaches into that backpack and updates the same count.

This is one of the most powerful patterns in JavaScript and it shows up everywhere — event handlers, React hooks, module patterns. Once you see the backpack mental model, closures stop feeling scary.

Why Axios Gets Recommended Over fetch

Both do the same job — make HTTP requests. But axios is noticeably nicer to work with day-to-day for two reasons:

Better default response object — when you console.log an axios response, you get a rich object with config, headers, status, request, and your actual data all neatly organised. With fetch you get something much more bare.

No res.json() step — with fetch you always have to do this:

fetch(url) .then(res => res.json()) .then(data => console.log(data));

With axios it's already parsed for you:

axios.get(url) .then(res => console.log(res.data));

One less step every single time. Small thing, but across a whole project it adds up.

...rest, ...spread, reduce(), and Two JavaScript Tricks That'll Mess With Your Head

Jalaj Bankar — Fri, 20 Mar 2026 16:47:05 +0000

A fun session. Some genuinely useful patterns and two JavaScript behaviours at the end that look like bugs but are actually the language working exactly as designed.

...rest vs ...spread — Same Syntax, Opposite Jobs

These both use ... but they do completely opposite things depending on which side of the assignment they're on. That's why they're easy to mix up.

...rest (Left Hand Side) — gathering things together

When you see ... on the left side of an assignment or in a function parameter, it's collecting whatever's left into an array:

function logAll(first, ...rest) { console.log(first); console.log(rest); }
logAll(1, 2, 3, 4, 5); // first → 1 // rest → [2, 3, 4, 5]
Everything that didn't get its own name gets gathered into rest. That's why these are called variadic functions — they can accept any number of arguments.

...spread (Right Hand Side) — spreading things apart

When ... appears on the right side, it's doing the opposite — unpacking an existing array into individual elements:

let arr = [1, 2, 3, 4, 5]; let arr2 = [...arr, 6, 7, 8, 9, 10]; // [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

You're not copying the array reference — you're spreading out its elements and building a brand new array. This is why spread is so useful for immutable updates in React.

Simple rule to remember: left side gathers, right side scatters.

reduce() — A for Loop With a Memory

reduce() is honestly just a cleaner abstraction of the classic accumulator pattern. Here's the same operation written both ways so you can see exactly what it replaces:

With a for loop:

let arr = [1, 2, 3, 4, 5]; let sum = 0; for (let i = 0; i < arr.length; i++) { sum += arr[i]; } console.log(sum);

With reduce():

let arr = [1, 2, 3, 4, 5]; let sum = (acc, elem) => acc + elem; let result = arr.reduce(sum, 0); console.log(result);

Same result. reduce() just handles the loop and the accumulator internally so you only have to think about the logic.

A few things worth locking in about reduce():

reduce() takes two arguments — a callback function and the initial value of the accumulator. In the example above that's sum and 0.

The initial value (0 here) only kicks in for the very first iteration. After that, the accumulator carries whatever value the previous iteration returned.

And importantly — respect lexical scoping. Call reduce() after your callback function is defined, not before. JavaScript needs to know what sum is before you reference it.

JavaScript Trick #1 — The Accidental Index Selector

This one looks like an array with two arrays inside it but it's actually something completely different:

let arr = [1, 2, 3, 4, 5][0, 3]; console.log(arr); // Output: 4

What's happening here — the second [0, 3] is not a second array. It's bracket notation accessing an index on the first array. And inside it, 0, 3 is the comma operator — which evaluates both expressions left to right and returns the last one. So [0, 3] evaluates to 3, and arr[3] is 4.

So the whole thing reads as: "give me index 3 of this array" — which is 4. Looks like two arrays, behaves like an index accessor. Wild.
JavaScript Trick #2 — Duplicate Keys in Objects

let obj = { a: 1, b: 2, a: 3 }; console.log(obj); // Output: { a: 3, b: 2 }

Objects don't support duplicate keys — just like Sets don't support duplicate values. When JavaScript sees two properties with the same key, the second one overwrites the first. But here's the subtle part — it doesn't just replace the value and move on. It goes back to the first appearance of that key and updates its value there. That's why a stays in its original position in the output but holds the newer value 3.

So the object ends up as { a: 3, b: 2 } — not { b: 2, a: 3 }. Position is preserved, value is overwritten.

Server Rendering, Express Routing, JSX Under the Hood, and this Keyword Finally Making Sense

Jalaj Bankar — Fri, 20 Mar 2026 16:42:49 +0000

A big session. React internals, some Node territory, and one of the most confusing JavaScript concepts that suddenly clicks when explained the right way. Let's get into it.

Two Types of Server-Side Rendering
These sound similar but they're quite different in how they work:
Server-Side Rendering (SSR) — the entire page is rendered on the server on each request and sent as ready HTML to the browser. Fast first load, good for SEO.
React Server Components (RSC) — a newer model where specific components run only on the server, never shipping their JavaScript to the browser at all. Not just rendering on the server — actually living there permanently. Leaner bundles, better performance.

Basic Routing in Express
Express makes routing straightforward — you define a path and what should happen when someone hits it. Learned the basics today, more on this as it gets deeper.

npm run dev vs npm run build
Easy to confuse early on but the difference matters:
npm run dev — spins up a temporary development server in memory. Nothing is written to disk. Fast, hot-reloading, meant for development only.
npm run build — creates permanent, optimised files in a dist/ folder. This is what actually gets deployed to production. Minified, bundled, ready for the real world.

Three Ways to Create an Element — JS, JSX, and Raw React
This is one of those comparisons that makes JSX suddenly feel less magical.
Plain JavaScript:
let H1 = document.createElement('h1'); H1.textContent = "Hello World"; React + JSX: const H1 = ( <h1>Hello World!</h1> );
React without JSX (what JSX actually compiles to):
React.createElement('h1', {className: 'greet'}, "Hello World!"); And what React actually holds in memory after that — a plain JavaScript object: { type: 'h1', props: { className: 'greet', children: "Hello World!" } }
JSX is just syntactic sugar. Under the hood it's always React.createElement producing a plain object. The browser never sees JSX — Babel transforms it before it gets there.

useRef() — Reaching Into the DOM
useRef() gives you a way to directly reference a DOM element from inside your component — without triggering a re-render when it changes. Useful for things like focusing an input, reading scroll position, or integrating with third-party libraries that need a real DOM node.

useContext() — Skipping the Prop Chain
Normally if component 1 has data that component 7 needs, you'd pass props through every component in between. useContext() skips all of that.
Step 1 — Create the context:
const AppContext = createContext();
Step 2 — Wrap your parent and put data on the value prop:
<AppContext.Provider value={text}> <App /> </AppContext.Provider>
Step 3 — Grab it anywhere down the tree:
function Title() { const text = useContext(AppContext); return <h1>{text}</h1>; }
No prop drilling. Component 7 just reaches up and grabs what it needs directly.

Portals — Rendering Outside Your Component Tree
Sometimes you need a component to visually break out of its parent — modals, dropdowns, tooltips. Portals let you render a component into any DOM element, not just its parent:
createPortal(

I am in the document body., document.body)
The component still lives in your React tree logically — events bubble normally — but it physically renders wherever you point it.

Suspense — Waiting for Things to Load
Suspense lets you define a fallback UI while something is loading:
<Suspense fallback={<p>Loading...</p>}> <SlowComponent /> </Suspense>
Pairs really cleanly with lazy() for loading components only when they're actually needed:
const Component = lazy(() => import('./Component')); <Suspense fallback={<p>Loading...</p>}> <Component /> </Suspense>
The component's JavaScript doesn't even download until it's needed. Great for performance on larger apps.

**this** Keyword — It's About Who Called It, Not Where It Lives
This is one of those JavaScript concepts that confuses everyone until it's explained the right way. The rule is simple: this looks for whoever called it.
In a browser function, this points to the window object. In Node.js, it points to the global object.
Inside an object method, this refers to that object — because the object is the one calling it.
Here's where it gets interesting:
const user = { name: "Deep", logName: function() { console.log(this.name); } };
user.logName(); ✅ — outputs "Deep" because user is calling it. this obeys user.
const standAlone = user.logName;
standAlone(); ❌ — outputs undefined because now a plain variable is calling it, not an object. this has no object to obey so it climbs up to window — and window.name is empty.
Same function. Different caller. Completely different result. this doesn't care where the function was defined — it only cares about who invoked it. Once that mental model locks in, this stops being scary.

What Actually Happens When You Type google.com — And All the Terms Behind It

Jalaj Bankar — Fri, 20 Mar 2026 11:54:11 +0000

This one goes deep. Understanding what happens in those few milliseconds between hitting Enter and seeing a webpage is one of those things that makes you look at the internet completely differently. Let's walk through it properly.

The Journey of a Single Request
Step 1 — You type google.com and hit Enter
Simple enough. But what happens next is anything but.
Step 2 — DNS Lookup: Finding the Address
Your browser doesn't understand names — it understands IP addresses. So first it needs to translate google.com into something like 142.250.195.46. It checks in this order:
Local cache → ISP → Root server → gets the Mumbai IP (or wherever you're closest to)
Think of DNS as the internet's phonebook. You give it a name, it gives you a number.
Step 3 — TCP Handshake: Building the Road
Before any data moves, a reliable connection needs to be established. This is the TCP handshake — using SYN and ACK messages back and forth to essentially say "hey, can you hear me?" — "yes, can you hear me?" — "yes, let's go." Think of it as road construction before traffic can flow.
Step 4 — TLS Handshake: Locking the Road
The road exists, but it's not secure yet. The TLS handshake encrypts the connection so nobody in the middle can read what's being sent. Once this is done, HTTP becomes HTTPS — the S literally stands for the TLS layer wrapping the connection.
Step 5 — HTTP Request: The Actual Conversation
Now the browser finally asks for the page. "Give me google.com." The server responds with HTML, CSS, JavaScript — everything needed to render what you see.
Step 6 — Page Rendered

Your browser takes all that data and paints the page. What feels instant is actually all six of these steps happening in milliseconds.

The 2026 Cool Fact — 0-RTT

If you've visited Google recently, Steps 3 and 4 can happen almost simultaneously — this is called 0-RTT (Zero Round-Trip Time). It's a feature in TLS 1.3 that lets your browser skip the full handshake on reconnection and send data immediately. The result? The site feels like it loaded instantly. This is why returning visits always feel faster than first visits.

The Glossary — Security & Protocol Terms
TLS — Transport Layer Security. The current standard for encrypting connections.
SSL — Secure Sockets Layer. The older, now-deprecated version of TLS. You'll still hear people say "SSL certificate" but they almost always mean TLS at this point.
HTTP — Hypertext Transfer Protocol. The language browsers and servers use to talk.
HTTPS — HTTP + TLS. The secure version. Always look for this in your browser bar.
HSTS — HTTP Strict Transport Security. Forces your browser to only use HTTPS for a site — even if you type http:// manually. A site can tell your browser "never connect to me without encryption."

0-RTT — Zero Round-Trip Time. High-speed reconnection feature in TLS 1.3.

The Glossary — Networking & Infrastructure
IP — Internet Protocol. The addressing system of the internet.
IPv4 / IPv6 — Version 4 uses addresses like 192.168.1.1. Version 6 was introduced because we ran out of IPv4 addresses — there are only about 4 billion of them and the internet has way more devices than that now.
TCP — Transmission Control Protocol. Reliable, ordered delivery. The "road builder."
UDP — User Datagram Protocol. Faster but doesn't guarantee delivery — used in HTTP/3, video calls, gaming. Speed matters more than perfection there.
DNS — Domain Name System. Translates google.com into an IP address.

ISP — Internet Service Provider. The company you pay for internet access.

The Glossary —** Advanced Concepts**
MUX (Multiplexing) — Sending multiple signals through one path simultaneously. HTTP/2 and HTTP/3 use this so multiple files load in parallel over a single connection instead of queuing up.
GGC — Google Global Cache. Google literally places their own servers inside ISP buildings around the world so your YouTube video doesn't have to travel halfway across the planet. Fewer hops, faster delivery.
IoT — Internet of Things. Smart devices — cameras, thermostats, fridges — anything connected to the internet that isn't a traditional computer.
TLD — Top-Level Domain. The .com, .org, .in part of a URL.
SYN / ACK — Synchronize / Acknowledgement. The specific messages exchanged during the TCP handshake.

RTT — Round-Trip Time. How long it takes a signal to travel to a server and come back. Lower is better.

Domain Hierarchy — Reading Right to Left
Most people read a domain left to right — but the internet reads it right to left. Here's the full tree:
Root Level — The invisible dot at the very end of every URL (google.com.). All DNS lookups start here.
TLD (Top-Level Domain) — The extension after the last dot. .com, .org, .in. Categorises the site by purpose or region.
SLD (Second-Level Domain) — What most people call "the website name." The google in google.com.
Subdomain (Third Level) — Prefixes that organise sections of a site. The docs in docs.google.com.
Lower Levels — Technically up to 127 levels deep, though more than four is rare in practice. Something like dev.blog.google.com would be a fourth-level domain.

Special Case — ccSLD — Some countries add a category at the second level. So instead of google.com, you get google.co.uk — where .uk is the country, .co is the category, and google is pushed to the third level.

SMTP, POP3, and IMAP — Email Has Three Jobs
Here's something most people don't realise — email uses different protocols for sending vs receiving, and they're completely separate:
SMTP (Simple Mail Transfer Protocol) — only for sending mail. That's its one job. When you hit send, SMTP takes over.
POP3 (Post Office Protocol 3) — for reading mail. Downloads emails to your device and typically removes them from the server. Old school.

IMAP (Internet Message Access Protocol) — also for reading, but smarter. Keeps emails on the server and syncs across all your devices. This is why your phone and laptop show the same inbox.

DHCP — How Your Device Gets an IP Address Automatically
Every device on a network needs an IP address. But you've never manually typed one in (probably). That's DHCP doing its job silently.
When you connect your phone to your router, your phone is the host — and it needs an IP, a subnet mask, a default gateway, and DNS settings to function on the network. DHCP handles all of that automatically through a four-step process called DORA:
Discover — your device shouts "is there a DHCP server here?"
Offer — the router replies "yes, here's an IP you can use"
Request — your device says "great, I'll take that one"
Acknowledge — the router confirms "it's yours"
One network, one default gateway, one IP address assigned cleanly — and just like that your device is on the internet without you having to configure anything.