Forem: SAURAV KUMAR

🧠 How Do Closures Work in JavaScript?

SAURAV KUMAR — Wed, 05 Nov 2025 06:03:24 +0000

Explained in Simple Words (with Code Examples & Interview Tips)

When I first started learning JavaScript, the word closure sounded scary.

Later I realised closures are just functions that remember things — nothing magical, only useful.

This article explains closures in plain English, with small code examples and a short interview-friendly answer you can use. Let’s keep it simple and practical.

🧩 What Is a Closure?

A closure is when a function remembers and uses variables from its outer (parent) function — even after the outer function has finished running.

Think of it like a backpack 🎒: when a function is created, it carries its surrounding variables inside that backpack. Even if the parent function returns, the inner function still has access to those items in the backpack.

💡 Very Simple Example

function outerFunction() {
  let count = 0;

  function innerFunction() {
    count++;
    console.log("Count is:", count);
  }

  return innerFunction;
}

const counter = outerFunction();

counter(); // Count is: 1
counter(); // Count is: 2
counter(); // Count is: 3

Why this shows a closure:

innerFunction keeps access to count even after outerFunction has finished. That remembered access is a closure.

🧠 Step-by-step: What’s Happening?

Call outerFunction() → it creates a local variable count = 0.
Define innerFunction() inside outerFunction().
Return innerFunction from outerFunction.
Even though outerFunction finishes, innerFunction still remembers count.
Each call to counter() updates the same count stored in the closure.

🔐 Practical Use: Private Data (Counter Module)

Closures help you hide data (make it private) and expose only controlled methods.

function createCounter() {
  let count = 0; // private

  return {
    increment() {
      count++;
      console.log("Count:", count);
    },
    decrement() {
      count--;
      console.log("Count:", count);
    },
    getCount() {
      return count;
    }
  };
}

const counter = createCounter();
counter.increment(); // Count: 1
counter.increment(); // Count: 2
console.log(counter.getCount()); // 2
// direct access like counter.count → undefined

Benefit: count cannot be changed except via the provided methods. This pattern avoids global variables and accidental mutations.

⏰ Closures with Async Code

Closures work perfectly with timers, promises, and callbacks.

function greetUser(name) {
  setTimeout(function () {
    console.log("Hello, " + name);
  }, 1000);
}

greetUser("Saurav"); // After 1s: Hello, Saurav

Even after greetUser returns, the timeout callback remembers name because of the closure.

⚙️ Function Factories (Another Useful Pattern)

Closures can produce customised functions.

function multiplyBy(factor) {
  return function (number) {
    return number * factor;
  };
}

const double = multiplyBy(2);
const triple = multiplyBy(3);

console.log(double(5)); // 10
console.log(triple(5)); // 15

Each returned function remembers its own factor. This is simple and powerful.

⚠️ Common Beginner Mistakes

Shared loop variable problem: Using var in loops with closures can be confusing. Prefer let or create new scopes.
Memory concerns: Closures keep references to outer variables; avoid holding large data unnecessarily.
Confusing scopes: Same variable names in inner and outer scopes shadow each other — be clear about where a variable is defined.

🚀 Where You See Closures in Real Code

React hooks (useState, useEffect) use closures under the hood.
Event handlers that access outer variables.
Module and factory patterns for encapsulation.
Currying and functional utilities.

🧠 Key Takeaway

A closure is simply an inner function that remembers variables from its outer scope.

Use closures to keep data private, remember state, and write modular code.

🎯 Bonus: How to Explain Closures in an Interview (with Example)

When an interviewer asks “What is a closure?” or “Explain closures in JavaScript”, keep your answer short and then show a tiny example.

Short answer (30–45 seconds)

A closure is when a function remembers the variables from its outer scope even after that outer function has finished executing. In other words, the inner function carries its lexical environment with it. Closures enable data privacy and stateful functions in JavaScript.

Follow-up: Quick example to show on the whiteboard or in code

function makeGreeter(name) {
  return function greet() {
    console.log("Hello, " + name);
  };
}

const greetSaurav = makeGreeter("Saurav");
greetSaurav(); // Hello, Saurav

Explain while you show it:

makeGreeter creates a local name.
It returns greet, which uses name.
Even after makeGreeter returns, greet still remembers name — that’s a closure.

Common interview follow-ups & how to answer them

Q: Why is closure useful? A: For stateful functions and data privacy without globals. It helps implement modules, factories, and callbacks.
Q: Any pitfalls? A: If not careful, closures can unintentionally keep large objects alive, causing memory to be retained. Also, loop-variable capture mistakes can confuse results — use let to avoid it.
Q: Can you show a bug caused by closures? A: Yes — older code using var in loops with async callbacks captures the same variable. Show the fixed version using let or an IIFE.

Mini whiteboard challenge (simple coding task)

Task: Write a function makeCounter() that returns an object with increment and get methods. get returns the current count.

Solution to write quickly:

function makeCounter() {
  let count = 0;
  return {
    increment() { count++; },
    get() { return count; }
  };
}

const c = makeCounter();
c.increment();
console.log(c.get()); // 1

Why this is a good interview answer:

Short, correct, and shows you understand closures and data privacy.
You can extend it (add decrement, validation) if asked.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

Why Doesn’t My API Call Wait? — Understanding Promises & Async/Await in JavaScript

SAURAV KUMAR — Mon, 20 Oct 2025 05:16:48 +0000

Imagine you’re building a small weather app 🌤️.

You click a “Get Weather” button, and your JavaScript calls a weather API like this:

const data = fetch("https://api.weatherapi.com/data");
console.log(data);

You expect it to print the weather data.

Instead, it shows this 👇

Promise { <pending> }

No temperature. No city name. Just... pending.

You try adding more logs, maybe even a delay — but the result doesn’t change.

Why?

Because JavaScript is asynchronous — it doesn’t stop and wait for slow tasks (like APIs, timers, or file reads).

While your fetch request is still in progress, JS moves to the next line.

To handle this properly, JavaScript gives us Promises — a way to represent “something that will finish later.”

And once you understand Promises, you’ll learn Async/Await, which makes asynchronous code look clean and readable — like synchronous code.

🧠 What Is a Promise?

A Promise is just a JavaScript object that represents the eventual result of an asynchronous operation.

It can be in one of three states:

Pending → still waiting
Fulfilled → operation succeeded
Rejected → operation failed

Let’s see an example 👇

const weatherData = new Promise((resolve, reject) => {
  const success = true;
  if (success) {
    resolve("☀️ Weather data fetched successfully!");
  } else {
    reject("❌ Failed to fetch weather data!");
  }
});

weatherData
  .then((message) => console.log(message))
  .catch((error) => console.error(error));

Step-by-step:

We create a Promise that either resolves (success) or rejects (error).
.then() handles success.
.catch() handles failure.

This way, your app doesn’t freeze while waiting — it continues other work and handles the result later.

⚙️ The Problem with `.then()` Chains

As your app grows, chaining .then() becomes hard to read.

fetchUser()
  .then((user) => fetchWeather(user.city))
  .then((weather) => fetchForecast(weather.id))
  .catch((error) => console.error(error));

This can quickly look messy — especially with multiple dependencies.

That’s where Async/Await comes in.

✨ Async/Await — Making Async Code Look Simple

async/await is just a cleaner way to work with Promises.

It helps you write asynchronous code that looks synchronous.

async function getWeather() {
  try {
    const response = await fetch("https://api.chucknorris.io/jokes/random");
    const data = await response.json();
    console.log("☀️ Weather:", data.value);
  } catch (error) {
    console.error("❌ Error fetching data:", error);
  }
}

getWeather();

Step-by-step:

Add the async keyword before the function.
Use await to pause until the Promise resolves.
Wrap code in try...catch for error handling.

🌦️ Mini Project: Weather Fetch App

Let’s build a beginner-friendly Weather App that uses async/await and proper error handling.

<body>
  <h1>🌦️ Weather App</h1>
  <input type="text" id="city" placeholder="Enter city name" />
  <button id="btn">Get Weather</button>
  <p id="result">Enter a city and click the button 👆</p>

  <script>
    const cityInput = document.getElementById("city");
    const btn = document.getElementById("btn");
    const result = document.getElementById("result");

    async function getWeather() {
      const city = cityInput.value.trim();
      if (!city) {
        result.innerText = "⚠️ Please enter a city name!";
        return;
      }

      try {
        result.innerText = "⏳ Loading...";
        const res = await fetch(`https://api.weatherapi.com/v1/current.json?key=YOUR_API_KEY&q=${city}`);
        if (!res.ok) throw new Error("City not found or API issue.");
        const data = await res.json();
        result.innerText = `🌤️ ${data.location.name}: ${data.current.temp_c}°C`;
      } catch (err) {
        result.innerText = "❌ Could not fetch weather data.";
        console.error(err);
      }
    }

    btn.addEventListener("click", getWeather);
  </script>
</body>

✅ What’s happening:

When you click the button, it calls getWeather().
The function waits (await) for the API to respond.
If something fails (no internet or bad city name), it’s handled gracefully with catch.

⚠️ Common Mistakes Beginners Make

Forgetting to use await:

const data = fetch(url).json(); // ❌ Doesn't wait for the response

Mixing .then() and await:

const data = await fetch(url).then(res => res.json()); // ❌ Avoid mixing

No error handling: Always use try...catch to avoid unhandled rejections.
Using await outside an async function: Only works inside functions marked with async.

🧩 Real-World Example in React

Here’s how you’d use the same concept inside a React component 👇

import { useEffect, useState } from "react";

export default function WeatherApp() {
  const [weather, setWeather] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchWeather() {
      try {
        const res = await fetch("https://api.weatherapi.com/v1/current.json?key=API_KEY&q=Delhi");
        const data = await res.json();
        setWeather(data.current.temp_c);
      } catch (err) {
        setError("Failed to fetch weather.");
      }
    }

    fetchWeather();
  }, []);

  if (error) return <p>{error}</p>;
  if (!weather) return <p>Loading...</p>;
  return <p>🌤️ Current Temperature: {weather}°C</p>;
}

🎯 Bonus: How to Explain in an Interview

Q: What is a Promise?

A: A Promise represents a value that will be available in the future — success or failure.

Q: How is async/await different from Promises?

A: Async/Await is syntactic sugar over Promises — it makes async code cleaner and easier to read.

Q: How do you handle errors in async code?

A: Using try...catch blocks or the .catch() method.

Q: What happens if you forget await?

A: You get a Promise object instead of the resolved value.

🧠 Key Takeaways

✅ Promises represent future results of async operations.

✅ Async/Await makes Promises easier to use.

✅ Always handle errors using try...catch.

✅ Use async/await for cleaner, more readable code.

✅ Async doesn’t block — it helps your app stay responsive.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

var, let, and const in JavaScript — Differences Explained for Beginners

SAURAV KUMAR — Wed, 15 Oct 2025 18:02:09 +0000

If you are learning JavaScript, one of the first questions you will meet is: when should I use var, let, or const?

They all declare variables, but they behave differently — and those differences can cause bugs if you don’t know the rules.

In this post I’ll explain the differences in very simple words, show short code examples you can run, and give clear rules you can use right away. No heavy jargon — just practical advice for students and early React learners.

🔎 Why this matters

Choosing the right keyword makes your code safer and easier to reason about:

Avoid accidental bugs caused by redeclaration or wrong scope.
Make your intent clear to other developers (and future you).
Reduce runtime errors caused by Temporal Dead Zone (TDZ) or accidental globals.

Knowing a few small rules will help you write cleaner code from day one.

✋ Quick summary (the short rule)

const — use for values that should not be reassigned. Prefer by default.
let — use when you need to change the variable later. Block-scoped.
var — older behaviour, function-scoped, allows redeclaration. Avoid in modern code.

Now let’s see why, with simple examples.

🔬 1) Scope: where the variable lives

`var` — function scope (or global)

function testVar() {
  if (true) {
    var x = 10;
  }
  console.log(x); // 10 — visible outside the if-block
}
testVar();

var ignores block boundaries (like if, for) and belongs to the function scope.

`let` / `const` — block scope

function testLetConst() {
  if (true) {
    let a = 5;
    const b = 6;
  }
  console.log(a); // ReferenceError
  console.log(b); // ReferenceError
}
testLetConst();

let and const are limited to the block { ... } where they are declared.

Rule: prefer block-scoped let/const to avoid accidental leaks outside blocks.

🔁 2) Redeclaration: can you declare the same name twice?

var v = 1;
var v = 2; // allowed — overwrites v

let l = 1;
// let l = 2; // SyntaxError: Identifier 'l' has already been declared

const c = 1;
// const c = 2; // SyntaxError

var allows redeclaration (can cause accidental overwrites).
let and const do not allow redeclaration in the same scope.

Rule: avoid var redeclaration problems by using const / let.

🔄 3) Reassignment: can you change the value?

let x = 1;
x = 2; // OK

const y = 3;
y = 4; // TypeError: Assignment to constant variable.

let allows reassignment.
const does not allow reassigning the variable binding.

Important nuance: const protects the binding, not the value itself for objects.

const obj = { name: "saurav" };
obj.name = "saurav kumar"; // allowed — object content changed
obj = {}; // TypeError — cannot reassign the const binding

Rule: use const for variables that should not be reassigned; for objects you can still mutate properties if needed.

⏳ 4) Temporal Dead Zone (TDZ) — `let` / `const` safety

console.log(z); // ReferenceError
let z = 10;

let/const are hoisted but not initialized until their line runs — the period before initialization is the TDZ. Accessing them early throws an error. var is hoisted and initialized with undefined, so it gives undefined instead.

Rule: TDZ prevents accidental use before initialization — a safety feature.

🔍 5) Global object behavior

In browsers:

var a = 1;
console.log(window.a); // 1

let b = 2;
console.log(window.b); // undefined

Declaring with var at top-level creates a property on the global object (window in browsers). let and const do not. This helps avoid accidental global pollution.

Rule: avoid making globals — use modules and const/let.

✅ When to use what (practical guide)

Start with const: default to const for every variable. It communicates intent: this value should not be reassigned.
Use let when you need to update the variable (loops, counters, changing state).
Avoid var in modern JavaScript. Only use it if you must support very old code or environments.

Example — typical modern code style:

const maxUsers = 10;
let current = 0;

function addUser() {
  if (current < maxUsers) {
    current += 1;
  }
}

⚠️ Common beginner mistakes

Using var for everything → leads to accidental scope leaks and redeclaration bugs.
Expecting const objects to be immutable → const prevents reassigning the variable, but object properties can change.
Accessing let/const before declaration → TDZ errors — put declarations before use.
Relying on global var variables — hard to debug and easy to conflict.

🎯 Small project example (React friendly)

Imagine a small counter component in React:

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0); // use const for state variable reference
  const step = 1; // step does not change — const

  function increment() {
    setCount((c) => c + step); // we update state with setCount
  }

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

Notes:

const [count, setCount] is standard — the binding is constant, state changes through setCount.
Use let for temporary loop counters if needed.

🎯 Interview prep — short & sharp

30s answer:

var is function-scoped and allows redeclaration. let and const are block-scoped; let can be reassigned, const cannot. Prefer const by default and let where reassignment is required. Avoid var in new code.

Show quick examples (these are great on a whiteboard):

// var
var a = 1;
var a = 2; // allowed

// let
let b = 1;
// let b = 2; // not allowed

// const
const c = 1;
// c = 2; // TypeError

Common follow-ups & answers:

Q: Can you mutate a const object? A: Yes — the object contents can change, but you can't reassign the variable.
Q: Why prefer const by default? A: It makes intent clear and prevents accidental reassignments.

Mini whiteboard challenge: Convert a small var-based snippet into const/let style and explain scope differences.

🧠 Key takeaways

Prefer const for values that won't reassign.
Use let for variables that will change.
Avoid var — it has confusing scope and redeclaration rules.
Remember TDZ for let/const.
const prevents reassigning bindings, but object properties can still change.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

What is Hoisting in JavaScript? Explained for Beginners

SAURAV KUMAR — Tue, 14 Oct 2025 20:54:20 +0000

Imagine a teacher who quickly checks the attendance list before class starts. The teacher notes who is present, then the class begins. JavaScript does something similar: before it runs your code it makes a short pass to note declarations. This behaviour is called hoisting.

Hoisting explains many surprises beginners see — like why var sometimes gives undefined, or why calling a function works even if the function appears later in the file. In this post we will explain hoisting in simple words, show clear code examples, and give short tips you can use right away.

🔎 Why hoisting matters

When JavaScript runs a script it does two small steps for each scope (global or function):

Creation step — it looks for declarations and prepares memory.
Execution step — it runs the code line by line.

Hoisting happens because of that first step. If you know these two steps, many confusing behaviours become easy to understand.

✋ Easy intuition (no hard words)

During the creation step, var names are set up and given the value undefined.
let and const names are known but not ready to use until the code reaches them — this waiting period is called the Temporal Dead Zone (TDZ).
Function declarations are ready in creation step with their full body, so you can call them even before the line where they are written.

🧪 Short examples (see it clearly)

1) `var` example — gives `undefined`

console.log(a); // undefined
var a = 5;
console.log(a); // 5

What happened: JavaScript set up a at the start (with value undefined), then later the assignment a = 5 happened.

2) `let` / `const` — not ready before their line

console.log(b); // ReferenceError
let b = 10;

What happened: b is known to the engine, but it is not usable until the line let b = 10 runs. Accessing it early gives an error.

3) Function declaration — can be called early

greet(); // works: "Hello!"

function greet() {
  console.log("Hello!");
}

What happened: The whole greet function is set up during the creation step, so it is ready to call even before the code reaches its line.

4) Function expression — not hoisted the same way

sayHi(); // TypeError: sayHi is not a function
var sayHi = function() {
  console.log("Hi");
};

What happened: sayHi was set up as undefined at creation. The function value is only assigned later. So calling it too early causes an error.

🔍 Simple step-by-step of what engine does

Creation step: JavaScript finds declarations.
- var → create name, set to undefined.
- let/const → reserve name, do not set a value yet (TDZ).
- Function declarations → create name and set function value.
Execution step: JavaScript runs the code line by line, doing assignments and calls.

This model is enough to reason about most hoisting cases.

⚠️ Common beginner mistakes (and quick fixes)

Thinking hoisting moves code. It does not rewrite your source — it just prepares memory first. Fix: Read code top to bottom, initialise variables where you use them.
Using var everywhere. var can cause undefined surprises. Fix: Use const by default, let when you must reassign.
Expecting function expressions to be callable early. Only function declarations are available before execution reaches them. Fix: Use function declarations when you need that behaviour, otherwise keep functions close to where they are used.

🚀 Practical rules you can start using

Prefer const for values that do not change, let for values you will change. Avoid var.
Initialise variables near where you use them — it is clearer for readers and for you.
If you need a helper that should be available anywhere in the scope, a function declaration is OK. Otherwise use function expressions for clearer order.

🎯 Bonus: How to explain hoisting in an interview (short and clear)

30-second answer:

Hoisting is the JS engine’s creation step that runs before code execution. var is hoisted and set to undefined. let and const are known but not usable until their line (TDZ). Function declarations are hoisted with their body.

Show quickly: paste this in the interview:

console.log(x); // undefined
var x = 1;

console.log(y); // ReferenceError
let y = 2;

foo(); // works
function foo() { console.log('hi') }

bar(); // TypeError
var bar = function() { console.log('ho') }

Common follow-ups: TDZ meaning, leading practice (const/let), and difference between function declarations and expressions.

🧠 Key takeaways

Hoisting = creation step + execution step.
var → hoisted and initialised as undefined.
let / const → hoisted but not initialised (TDZ) until the line runs.
Function declarations → hoisted with the function body.
Prefer const/let and keep declarations clear and close to use.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer building web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.
I explore using AI tools to speed up development and I share beginner-friendly tutorials and practical tips.

🔗 Connect with me:

GitHub

If this helped you, please share with a friend learning JavaScript.
Until next time, keep coding and keep learning 🚀

⏱️ Debounce vs Throttle — How to Choose & Build One Mini Project

SAURAV KUMAR — Mon, 13 Oct 2025 12:16:27 +0000

You know the problem: the search box fires too many requests, or scrolling and resize make the UI janky. Two tools fix this: debounce and throttle. The trick is not memorising code — it’s knowing when to use which.

This article gives you:

a short decision checklist to pick the right tool,
a single beginner-friendly mini-project that uses both (so you see the difference),
plain-JS + React code you can copy, and
a short interview prep section.

Let’s be practical and keep things small.

✅ Quick decision checklist — when to use which

Use this checklist first. If you can answer “yes” to a line, follow that rule.

Does the user expect the final value after they stop interacting? → debounce. (search box, autosave, type-to-filter where final query matters)
Do you need regular updates while the user is interacting, capped at a frequency? → throttle. (scroll position updates, resize/layout recalculation, performance telemetry)
Do you need the last event after a burst and regular updates during the burst? → consider throttle + trailing or a combined approach.
Are you protecting server/API costs (many users typing)? → debounce for inputs.
Is the event happening continuously (scroll/resize) and you want a steady stream of updates? → throttle.

Simple rule:

final-value ⇒ debounce
steady-rate ⇒ throttle

Recommended starting delays:

UI inputs (debounce): 250–500ms
scroll/resize (throttle): 100–300ms

🔁 Mini project: PhotoSearch (one app, both tools)

Build a small app with:

a search box that queries (debounced), and
an infinite scroll that loads more photos while the user scrolls (throttled).

This shows both problems in one place — and teaches decision-making by doing.

Plain JavaScript: core helpers

debounce.js

export function debounce(fn, delay = 300) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

throttle.js

export function throttle(fn, wait = 200) {
  let last = 0;
  return function (...args) {
    const now = Date.now();
    if (now - last >= wait) {
      last = now;
      fn.apply(this, args);
    }
  };
}

PhotoSearch: simple layout (HTML)

<!-- index.html -->
<input id="search" placeholder="Search photos..." />
<div id="gallery" class="gallery"></div>
<script type="module" src="app.js"></script>

styles.css can be a simple grid — use CSS grid with grid-template-columns: repeat(auto-fill, minmax(180px,1fr));.

PhotoSearch: app logic (plain JS)

// app.js
import { debounce } from './debounce.js';
import { throttle } from './throttle.js';

let page = 1;
let query = '';

async function fetchPhotos(q = '', pageNo = 1) {
  // replace with a real API or mock
  console.log('fetching', q, pageNo);
  // example: return fetch(`/api/photos?q=${q}&page=${pageNo}`)
}

const gallery = document.getElementById('gallery');
const input = document.getElementById('search');

const debouncedSearch = debounce((value) => {
  query = value;
  page = 1;
  fetchPhotos(query, page);
  gallery.innerHTML = ''; // reset gallery
}, 400);

input.addEventListener('input', (e) => debouncedSearch(e.target.value));

const handleScroll = throttle(() => {
  if (window.innerHeight + window.scrollY >= document.body.offsetHeight - 200) {
    page++;
    fetchPhotos(query, page);
  }
}, 250);

window.addEventListener('scroll', handleScroll);

// initial load
fetchPhotos();

Why this shows the difference:

Typing triggers many input events; debounce collapses them into one final fetch.
Scrolling fires many events; throttle ensures we load more photos at most once per interval.

⚛️ React: same idea but modular

useDebounce hook

// useDebounce.js
import { useEffect, useState } from 'react';

export default function useDebounce(value, delay = 300) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const t = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(t);
  }, [value, delay]);

  return debounced;
}

useThrottleRef for scroll

// useThrottleRef.js
import { useEffect, useRef } from 'react';

export default function useThrottleRef(callback, wait = 200) {
  const lastRef = useRef(0);
  const cbRef = useRef(callback);
  cbRef.current = callback;

  useEffect(() => {
    function handler() {
      const now = Date.now();
      if (now - lastRef.current >= wait) {
        lastRef.current = now;
        cbRef.current();
      }
    }
    window.addEventListener('scroll', handler);
    return () => window.removeEventListener('scroll', handler);
  }, [wait]);
}

PhotoSearch component (sketch)

import React, { useState, useEffect } from 'react';
import useDebounce from './useDebounce';
import useThrottleRef from './useThrottleRef';

function PhotoSearch() {
  const [q, setQ] = useState('');
  const debouncedQ = useDebounce(q, 400);
  const [page, setPage] = useState(1);

  useEffect(() => {
    // call API with debouncedQ
    // reset page if debouncedQ changed
    setPage(1);
    // fetchPhotos(debouncedQ, 1)
  }, [debouncedQ]);

  useThrottleRef(() => {
    if (window.innerHeight + window.scrollY >= document.body.offsetHeight - 200) {
      setPage((p) => p + 1);
      // fetchPhotos(debouncedQ, page + 1)
    }
  }, 250);

  return (
    <>
      <input value={q} onChange={(e) => setQ(e.target.value)} placeholder="Search photos..." />
      <div className="gallery">{/* map photos */}</div>
    </>
  );
}

⚠️ Common beginner mistakes — focused checklist

Don’t debounce when you need immediate feedback (e.g., toggles).
Don’t throttle when you need the final value (e.g., final form submit) — or add a trailing call.
Don’t recreate handlers every render — use hooks or memoised helpers.
Always remove event listeners in cleanup (React useEffect return).
Test wait on real devices — 100ms ≠ 100ms on mobile.

🎯 Interview-friendly explanation (short & demo)

30s answer:

Debounce waits for a pause and runs the last event — good for inputs. Throttle runs at most once per interval — good for continuous events like scroll/resize.

Show: paste both helpers side-by-side and explain setTimeout/clearTimeout vs Date.now() timestamp checks.

Follow-ups to expect: leading vs trailing behavior, combining throttle+trailing, SSR concerns, handler identity in React.

Mini challenge: Implement throttle(fn, wait, { leading, trailing }) and explain the timeline.

🧠 Key takeaways (one-liner checklist)

final-value → debounce (search, autosave).
steady updates → throttle (scroll, resize, telemetry).
combined needs → consider throttle with trailing or a hybrid.
test wait on real devices (100–300ms typical).
in React, use hooks and useRef to keep handlers stable.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

🚦 What is Throttling in JavaScript?

SAURAV KUMAR — Sun, 12 Oct 2025 21:08:34 +0000

You build a small React dashboard and notice the browser lags when you resize the window or scroll fast. The charts stutter, buttons freeze, and users get annoyed. I hit this exact problem once — charts were re-rendering on every tiny resize event and users with slower machines felt like they were dragging through molasses.

The fix was small but effective: throttling. We limited how often the expensive work ran, and the app felt smooth again. In this post, I’ll explain why throttling matters, how it works, and how to use it in React — in plain English.

🧩 Why throttling matters (the “why” before the “how”)

Think of throttling like a traffic cop at a busy crosswalk. Without the cop, everyone rushes across and causes chaos. With the cop, one person crosses every few seconds — orderly and predictable.

In web apps, events like scroll, resize, mousemove, and input can fire dozens or hundreds of times per second. If your handler does heavy work (re-render, compute layout, call API), running it on every event will:

slow down the browser (CPU spikes),
cause many unnecessary network calls, and
make the UI feel janky.

Throttling gives you control: run the handler at most once every N milliseconds. That reduces work and keeps the UI responsive.

🧠 Throttle vs Debounce — quick friendly analogy

Throttle: A guard lets one person through every N seconds. Even if 100 people wait, one goes through on schedule. Good for: scroll, resize, periodic analytics.
Debounce: A timer waits for silence, then lets the last person through. If people keep coming, it keeps waiting. Good for: search-as-you-type where you want to wait until typing stops.

Both are useful — pick based on the problem.

🛠️ Simple throttle implementation (plain JS)

Let’s build a small, easy-to-read throttle function.

// throttle.js
function throttle(fn, wait = 200) {
  let lastCall = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastCall >= wait) {
      lastCall = now;
      fn.apply(this, args);
    }
  };
}

export default throttle;

🔍 Why this works (step-by-step)

lastCall stores when fn last ran.
On each event, we check current time (now).
If now - lastCall >= wait, we run fn and update lastCall.
Otherwise, we ignore this event.

This is a leading-edge throttle — it runs immediately, then blocks until wait ms pass.

📈 React use case: Throttle window resize

Imagine you want to update a chart layout on window resize. Resizing fires continuously as a user drags the corner — we only need to update at most once every 200ms.

// useWindowSizeThrottled.jsx
import { useEffect, useState } from "react";
import throttle from "./throttle";

export default function useWindowSizeThrottled(wait = 200) {
  const isClient = typeof window !== "undefined";
  const [size, setSize] = useState({
    width: isClient ? window.innerWidth : 0,
    height: isClient ? window.innerHeight : 0,
  });

  useEffect(() => {
    const handleResize = throttle(() => {
      setSize({ width: window.innerWidth, height: window.innerHeight });
    }, wait);

    window.addEventListener("resize", handleResize);
    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, [wait]);

  return size;
}

✅ Step-by-step breakdown

useState keeps the current window size.
Inside useEffect, we create a throttled handleResize using our throttle helper.
We add handleResize to the resize event.
On cleanup, we remove the listener to avoid leaks.

This prevents setSize from being called dozens of times per second, reducing re-renders and CPU usage.

⚙️ Improve the throttle for React (useRef approach)

If your component re-renders often, recreating the throttle could cause surprising behavior. useRef keeps stable state without causing re-renders:

import { useEffect, useRef, useState } from "react";

function useWindowSizeThrottledRef(wait = 200) {
  const isClient = typeof window !== "undefined";
  const [size, setSize] = useState({
    width: isClient ? window.innerWidth : 0,
    height: isClient ? window.innerHeight : 0,
  });
  const lastCallRef = useRef(0);

  useEffect(() => {
    function handler() {
      const now = Date.now();
      if (now - lastCallRef.current >= wait) {
        lastCallRef.current = now;
        setSize({ width: window.innerWidth, height: window.innerHeight });
      }
    }

    window.addEventListener("resize", handler);
    return () => window.removeEventListener("resize", handler);
  }, [wait]);

  return size;
}

✨ Why `useRef` helps

lastCallRef persists across renders without triggering re-renders.
The handler’s internal state remains stable across the component lifecycle.

⚠️ Common mistakes and misconceptions

Confusing throttle with debounce — pick based on need.
Not cleaning up listeners — always remove event listeners in cleanup.
Recreating throttle on every render — leads to losing internal state; use useRef or useCallback.
Throttling API calls blindly — if users expect instant feedback (search), debouncing may be better.
Assuming throttle makes things ‘real-time’ — throttle limits frequency but can delay responsiveness if wait is large.

🧾 Real-world use cases

Throttling scroll handlers for sticky headers or analytics.
Throttling resize events for layout recalculation.
Limiting telemetry or analytics to avoid server-side throttling.
Rate-limiting cursor-movement handlers in web games.
Controlling UI updates from frequent streams or websockets.

🎯 Bonus: How to Explain Throttling in an Interview

When an interviewer asks, “What is throttling?” keep it short and show a quick example.

🗣️ Short answer (30s)

Throttling limits how often a function can run — at most once per given interval — which prevents expensive handlers from running too frequently and improves UI performance.

💻 Quick example to show

Sketch or paste the simple throttle(fn, wait) code and explain lastCall + Date.now() logic.

🔁 Common follow-ups & answers

Q: How is throttle different from debounce? A: Throttle enforces a steady pace; debounce waits for silence.
Q: Leading vs trailing throttle? A: Leading runs immediately then waits; trailing runs at the end of the burst. You can implement options for both.
Q: Edge cases? A: Time drift, handler identity across renders, and missing final call after a burst — be prepared to discuss solutions.

🧩 Mini whiteboard challenge

Design throttle(fn, wait, options) where options may include leading and trailing. Sketch a timeline showing when fn runs during a burst of events.

🧠 Key takeaways

Throttle = run at most once every N ms — great for periodic limits.
Debounce = run after events stop — great for waiting until user is done typing.
In React, keep handlers stable (useRef, useCallback) and always remove listeners.
Choose wait by testing on real devices — 100–300ms is a common range for UI work.
Keep user expectations in mind — throttling reduces CPU/network but may delay responsiveness.

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips

GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

🧠 How to Optimize Search in JavaScript with Debouncing

SAURAV KUMAR — Sat, 11 Oct 2025 16:32:49 +0000

When I was working on a search feature for one of my projects, everything seemed fine at first — until users started typing really fast.

The app suddenly became slow, the search results lagged, and the whole UI felt heavy.

Turns out, every single keystroke was triggering a new search call to the API.

Imagine typing “JavaScript” — that’s 10 letters, which means 10 API requests sent in just a few seconds!

That’s a problem.

Let’s understand why — and how to fix it with something called debouncing.

🧩 Why This Happens (and Why It’s Bad)

When we type in a search bar, the app tries to fetch results as we type.

That sounds smooth, right?

But without control, it’s like calling your friend 10 times in 3 seconds just to say one sentence. 😅

Here’s what happens without optimization:

⚙️ Your browser slows down due to too many re-renders.
💸 Your server receives multiple requests, increasing API usage and cost.
😩 Your users think the app is lagging or frozen.

So, how do we make the app smarter?

That’s where debouncing comes in.

⚙️ What Is Debouncing?

Think of debouncing like a short waiting timer ⏱️.

It means — “Wait until the user stops typing for a moment before doing the actual work.”

In simple words:

If the user is still typing, don’t run the search yet.

Only when they pause for a few milliseconds — then perform the search.

This tiny delay helps you:
✅ Avoid unnecessary API calls

✅ Keep the UI fast and smooth

✅ Reduce server costs

💻 Let’s See It in Action

Here’s a simple debounce function in JavaScript:

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer); // clear old timer
    timer = setTimeout(() => {
      fn.apply(this, args); // run after delay
    }, delay);
  };
}

🔍 Step-by-Step Explanation

Let’s break it down like we’re explaining to a friend 👇

fn → This is the function we want to delay (like fetching search results).
delay → How long to wait before running the function.
setTimeout() → Starts a timer for that delay.
clearTimeout() → Cancels the previous timer if the user types again.
Once the user stops typing, the function finally runs.

In short — it’s like saying:

“Hold on... wait until I stop typing before you start searching.”

🧠 Real Example: Search Bar Without Lag

Here’s how you can use the debounce function:

<input type="text" id="search" placeholder="Search something..." />

<script>
  function fetchResults(query) {
    console.log("Fetching results for:", query);
    // Replace this with your actual API call
  }

  const debouncedSearch = debounce(fetchResults, 300);

  const input = document.getElementById("search");
  input.addEventListener("input", (e) => {
    debouncedSearch(e.target.value);
  });
</script>

Now, if a user types “hello”, instead of 5 API calls,

the app waits until the user stops typing — then makes just one call.

This simple trick makes your app faster, smoother, and more efficient. ⚡

⚛️ Bonus: Using Debouncing in React

If you’re using React, you can create a custom hook for it.

import { useEffect, useState } from "react";

function useDebounce(value, delay = 300) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebouncedValue(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

export default useDebounce;

How to Use It in a Component

import React, { useState, useEffect } from "react";
import useDebounce from "./useDebounce";

function SearchBar() {
  const [query, setQuery] = useState("");
  const debouncedQuery = useDebounce(query, 300);

  useEffect(() => {
    if (debouncedQuery) {
      console.log("Searching for:", debouncedQuery);
      // Replace this with your API call
    }
  }, [debouncedQuery]);

  return (
    <input
      type="text"
      value={query}
      onChange={(e) => setQuery(e.target.value)}
      placeholder="Search..."
    />
  );
}

export default SearchBar;

This React example does the same thing —

it waits 300ms after the user stops typing before triggering the search.

🚀 Why Debouncing Matters

Using debouncing might look like a small change,

but it has a huge impact on performance.

✅ Fewer API calls → Saves cost and bandwidth

✅ Smoother UI → Feels responsive

✅ Happier users → No lag, no delay

⚠️ Common Mistakes to Avoid

❌ Setting too long a delay — Makes search feel slow

✅ Keep it between 300–500ms

❌ Forgetting clearTimeout() — You’ll still get multiple calls

✅ Always clear the previous timer

❌ Not testing edge cases — Try typing fast, deleting text, or pasting text

🎯 Bonus: How to Explain Debouncing in an Interview

When an interviewer asks,

“What is Debouncing in JavaScript?” — here’s how to answer clearly.

🗣️ Short Answer (30–45 seconds)

Debouncing is a technique that controls how often a function is executed.

It waits for a short delay and only runs the function if no other event happens during that time.

It helps avoid unnecessary API calls and keeps the app fast and responsive.

💻 Quick Example to Show

function debounce(fn, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

function search(query) {
  console.log("Searching for:", query);
}

const optimizedSearch = debounce(search, 300);
optimizedSearch("JavaScript");

💬 Common Follow-up Questions

Q: Why is debouncing useful?

A: It prevents too many function calls and improves performance.

Q: How is it different from throttling?

A:

Debouncing → Runs after the user stops typing.
Throttling → Runs at regular intervals while typing.

Q: Where is it used in real life?

A: In search boxes, scroll events, resizing windows, and API calls.

🧩 Mini Whiteboard Challenge

Task: Write a debounce function that delays execution by 500ms.

Solution:

function debounce(fn, delay = 500) {
  let timeout;
  return (...args) => {
    clearTimeout(timeout);
    timeout = setTimeout(() => fn(...args), delay);
  };
}

function logMessage() {
  console.log("Clicked!");
}

const debouncedClick = debounce(logMessage, 500);

✅ Why this works:

Short and clear
Shows understanding of timers
Easy to explain in an interview

🧠 Key Takeaway

Debouncing isn’t a framework feature — it’s a simple logic that makes your apps smarter.

It teaches you how to think like a performance-minded developer —

to run code only when it’s needed.

So next time your app feels slow, remember:

maybe you just need a little debounce magic. ✨

👋 About Me

Hi, I'm Saurav Kumar — a Software Engineer passionate about building modern web and mobile apps using JavaScript, TypeScript, React, Next.js, and React Native.

I’m exploring how AI tools can speed up development,

and I share beginner-friendly tutorials to help others grow faster.

🔗 Connect with me:

LinkedIn — I share short developer insights and learning tips
GitHub — Explore my open-source projects and experiments

If you found this helpful, share it with a friend learning JavaScript — it might help them too.

Until next time, keep coding and keep learning 🚀

# 🧩 Next.js 16 Simplified: Understanding the `.next/dev` Folder

SAURAV KUMAR — Thu, 09 Oct 2025 21:18:50 +0000

🏁 TL;DR

Next.js 16 brings a small but powerful improvement — it separates development and build files inside a new folder .next/dev. This means you can safely run next dev and next build together without breaking your local server.

In this blog, we’ll cover the problem, what changed, a hands-on demo, and a quick recap — all in simple terms.

⚠️ The Problem (Explained Simply)

Before Next.js 16, both next dev and next build wrote data inside the same .next folder.

This caused a problem — when you built your app (next build) while the dev server was running, the build would overwrite files that your server was using. That often crashed the app or broke your local environment.

💥 Old Folder Structure

.next/
├── cache/
├── server/
├── static/
└── build-manifest.json

When next build ran, it modified some of these files — and your next dev session would suddenly break. Not fun!

🔧 What Changed in Next.js 16

Next.js 16 introduces a clean fix: .next/dev folder.

Now, development and build artifacts are stored separately.

✅ New Folder Structure

.next/
├── cache/
├── dev/
│   ├── build-manifest.json
│   ├── cache/
│   ├── package.json
│   └── react-loadable-manifest.json
├── server/
├── static/
└── trace/

🚀 What This Means for You

next dev files live inside .next/dev
next build creates production files in .next
Both can now run together safely

This update ensures your dev server doesn’t crash even when a build runs in the background.

🧪 Hands-On Demo (Try It Yourself)

Follow these steps to see it in action 👇

Step 1: Check your Next.js version

npx next -v

If it’s below 16, update it:

npm install next@latest

Step 2: Start the development server

npx next dev

This starts the local server on http://localhost:3000.

Step 3: Run a production build in parallel

Open another terminal window (same project folder) and run:

npx next build

Earlier, this would crash your server — but now it runs smoothly.

Step 4: Inspect the `.next` folder

ls -la .next

You’ll now see a dev directory inside .next. That’s where your development files live.

Output example:

.next/
├── cache/
├── dev/
│   ├── build-manifest.json
│   ├── cache/
│   ├── package.json
│   └── react-loadable-manifest.json
├── server/
├── static/
└── trace/

✅ Result: Your app runs smoothly, no crashes, no interruptions.

🧰 Troubleshooting & Caveats

Here’s what to check if something doesn’t work right:

❌ No .next/dev folder? → Upgrade to Next.js 16 or later.
⚠️ Dev server crashes? → Ensure no script is deleting .next while you’re running both commands.
🧾 Custom distDir? → If you use a custom directory, the same behavior applies — .next/dev will be created there.

📘 TL;DR Recap + Next Steps

Task	Before (Old Behavior)	Now (Next.js 16)
`next dev` + `next build`	Crashed often	Works perfectly
Folder structure	Mixed files	Separated (`.next/dev`)
Developer experience	Frustrating	Smooth & stable

✅ What You Should Do Next:

Update your project to Next.js 16+
Try running next dev and next build together
Observe the .next/dev folder structure

You’ll instantly feel how much more reliable your workflow becomes.

💬 FAQs

Q: Do I need to enable .next/dev manually?
A: No, it’s automatic from Next.js 16 onward.

Q: Will this affect my production build?
A: Nope. This only impacts local development — production builds remain the same.

Q: Can I use this with a custom dist directory?
A: Yes, .next/dev will appear inside your custom directory.

🙌 Share Your Experience

Did you try this feature yet?
Share your thoughts in the comments — or tell us how it improved your workflow.
If this helped, give it a 👍 on Hashnode and share it with your dev circle. 🚀

🔗 Connect with Me

If you enjoyed this article and want to connect, feel free to reach out on LinkedIn:

LinkedIn: Saurav02022

Let’s discuss web development, share ideas, and grow together 🚀

How I Automated Daily GitHub Contributions Using GitHub Actions ⚡

SAURAV KUMAR — Wed, 08 Oct 2025 11:22:05 +0000

🎯 The Challenge

As a developer working on a long-term project, I faced a common problem: my GitHub contribution graph wasn't reflecting my actual work. Despite coding daily and pushing commits, my profile showed gaps because:

Commits were on feature branches – GitHub only counts contributions on the default branch or merged PRs
Wrong email configuration – My commits used a work email not linked to my GitHub account
Time zone confusion – Struggled with UTC vs IST conversions

💡 The Solution: GitHub Actions

I decided to create an automated workflow that:

Updates my README.md daily with a timestamp
Commits and pushes automatically
Runs at 8:30 AM IST every day
Can be triggered manually for testing

🛠️ Implementation Journey

Phase 1: Email Configuration Issue

Problem: Commits weren't showing up on my profile.

# Wrong config (work email)
git config user.email "work.email@company.com"

# Correct config (GitHub email)
git config user.email "your-github-email@gmail.com"

Solution: Set the correct email for the project:

bash git config user.email "sk729584@gmail.com" git config user.name "Saurav02022"

Phase 2: Branch Strategy Mistake

Problem: I initially merged the feature branch to main without asking – a workflow violation!

Lesson Learned: Always respect branching strategies and ask before merging to protected branches.

Solution:

`bash

Revert the unauthorized merge

git reset --hard
git push --force origin main

Return to feature branch

git checkout feature/day-02
`

Phase 3: GitHub Action Creation

Created .github/workflows/daily-readme-update.yml:

`yaml
name: Daily README Update

on:
# Scheduled trigger - runs daily at 8:30 AM IST
schedule:
- cron: '30 2 * * *' # 3:00 AM UTC = 8:30 AM IST

# Manual trigger
workflow_dispatch:

jobs:
update-readme:
runs-on: ubuntu-latest

steps:
  - name: Checkout repository
    uses: actions/checkout@v4
    with:
      token: ${{ secrets.GITHUB_TOKEN }}

  - name: Set up Git configuration
    run: |
      git config --local user.email "sk729584@gmail.com"
      git config --local user.name "Saurav02022"

  - name: Update README with current date and time
    run: |
      CURRENT_DATETIME=$(TZ='Asia/Kolkata' date '+%Y-%m-%d %H:%M:%S IST')

      if grep -q "<!-- AUTO-UPDATE-START -->" README.md; then
        sed -i "/<!-- AUTO-UPDATE-START -->/,/<!-- AUTO-UPDATE-END -->/c\\
      <!-- AUTO-UPDATE-START -->\\
      **Last Updated:** $CURRENT_DATETIME\\
      \\
      *This section is automatically updated daily at 8:30 AM IST by GitHub Actions.*\\
      <!-- AUTO-UPDATE-END -->" README.md
      else
        echo "" >> README.md
        echo "---" >> README.md
        echo "<!-- AUTO-UPDATE-START -->" >> README.md
        echo "**Last Updated:** $CURRENT_DATETIME" >> README.md
        echo "*This section is automatically updated daily at 8:30 AM IST by GitHub Actions.*" >> README.md
        echo "<!-- AUTO-UPDATE-END -->" >> README.md
      fi

  - name: Check for changes
    id: check_changes
    run: |
      if git diff --quiet; then
        echo "changes=false" >> $GITHUB_OUTPUT
      else
        echo "changes=true" >> $GITHUB_OUTPUT
      fi

  - name: Commit and push changes
    if: steps.check_changes.outputs.changes == 'true'
    run: |
      git add README.md
      git commit -m "chore: Auto-update README with current timestamp"
      git push

Phase 4: Time Zone Confusion

Initial Mistake: Set cron to '0 9 * * *' thinking it was IST.
Reality: Cron uses UTC!
9:00 AM UTC = 2:30 PM IST ❌

Correct Calculation:

Target: 8:30 AM IST
IST = UTC + 5:30
8:30 AM IST - 5:30 = 3:00 AM UTC
✅ Cron: '30 2 * * *' (minute 30, hour 2 UTC)

🚀 Setup Steps

1. Enable Workflow Permissions

Repository → Settings → Actions → General → Workflow permissions
✅ Select “Read and write permissions”
✅ Check “Allow GitHub Actions to create and approve pull requests”

2. Add Auto-Update Section to README

`markdown

Last Updated: 2025-10-06 00:12:34 IST

This section is automatically updated daily at 8:30 AM IST by GitHub Actions.

3. Test with Manual Trigger

Go to Actions tab → Daily README Update → Run workflow

✅ Results

Daily contributions: Automatic green squares every day at 8:30 AM IST
Zero maintenance: Completely automated
Professional profile: Shows consistent activity
Learning experience: Deep dive into GitHub Actions, cron, and time zones

🎯 Key Takeaways

Email matters: GitHub links commits via email addresses

Branch strategy: Only default branch commits count as contributions

UTC vs Local Time: Always convert to UTC for cron schedules

Test first: Use workflow_dispatch for manual testing

GITHUB_TOKEN: Automatically provided, no manual secrets needed

Git etiquette: Never merge without permission!

📊 Impact

Before: Sporadic contributions, gaps in activity
After: Consistent daily contributions, professional profile
Bonus: Learned GitHub Actions automation

🔗 Resources

💬 Your Turn

Have you automated your GitHub contributions?
What challenges did you face? Drop your thoughts in the comments below! 👇

Tags: #GitHubActions #DevOps #Automation #GitHub #WebDev #Tutorial #Productivity

🔗 Connect with Me

GitHub: github.com/Saurav02022
LinkedIn: linkedin.com/in/saurav02022

💬 What automation challenges have you solved?
Share your experiences in the comments below!

Forem: SAURAV KUMAR

🧠 How Do Closures Work in JavaScript?

🧩 What Is a Closure?

💡 Very Simple Example

🧠 Step-by-step: What’s Happening?

🔐 Practical Use: Private Data (Counter Module)

⏰ Closures with Async Code

⚙️ Function Factories (Another Useful Pattern)

⚠️ Common Beginner Mistakes

🚀 Where You See Closures in Real Code

🧠 Key Takeaway

🎯 Bonus: How to Explain Closures in an Interview (with Example)

Short answer (30–45 seconds)

Follow-up: Quick example to show on the whiteboard or in code

Common interview follow-ups & how to answer them

Mini whiteboard challenge (simple coding task)

👋 About Me

Why Doesn’t My API Call Wait? — Understanding Promises & Async/Await in JavaScript

🧠 What Is a Promise?

Step-by-step:

⚙️ The Problem with .then() Chains

✨ Async/Await — Making Async Code Look Simple

Step-by-step:

🌦️ Mini Project: Weather Fetch App

⚠️ Common Mistakes Beginners Make

🧩 Real-World Example in React

🎯 Bonus: How to Explain in an Interview

🧠 Key Takeaways

👋 About Me

var, let, and const in JavaScript — Differences Explained for Beginners

🔎 Why this matters

✋ Quick summary (the short rule)

🔬 1) Scope: where the variable lives

var — function scope (or global)

let / const — block scope

🔁 2) Redeclaration: can you declare the same name twice?

🔄 3) Reassignment: can you change the value?

⏳ 4) Temporal Dead Zone (TDZ) — let / const safety

🔍 5) Global object behavior

✅ When to use what (practical guide)

⚠️ Common beginner mistakes

🎯 Small project example (React friendly)

🎯 Interview prep — short & sharp

🧠 Key takeaways

👋 About Me

What is Hoisting in JavaScript? Explained for Beginners

🔎 Why hoisting matters

✋ Easy intuition (no hard words)

🧪 Short examples (see it clearly)

1) var example — gives undefined

2) let / const — not ready before their line

3) Function declaration — can be called early

4) Function expression — not hoisted the same way

🔍 Simple step-by-step of what engine does

⚠️ Common beginner mistakes (and quick fixes)

🚀 Practical rules you can start using

🎯 Bonus: How to explain hoisting in an interview (short and clear)

🧠 Key takeaways

⏱️ Debounce vs Throttle — How to Choose & Build One Mini Project

✅ Quick decision checklist — when to use which

🔁 Mini project: PhotoSearch (one app, both tools)

Plain JavaScript: core helpers

PhotoSearch: simple layout (HTML)

PhotoSearch: app logic (plain JS)

⚛️ React: same idea but modular

useDebounce hook

useThrottleRef for scroll

PhotoSearch component (sketch)

⚠️ Common beginner mistakes — focused checklist

🎯 Interview-friendly explanation (short & demo)

🧠 Key takeaways (one-liner checklist)

👋 About Me

🚦 What is Throttling in JavaScript?

🧩 Why throttling matters (the “why” before the “how”)

🧠 Throttle vs Debounce — quick friendly analogy

🛠️ Simple throttle implementation (plain JS)

🔍 Why this works (step-by-step)

📈 React use case: Throttle window resize

✅ Step-by-step breakdown

⚙️ Improve the throttle for React (useRef approach)

⚙️ The Problem with `.then()` Chains

`var` — function scope (or global)

`let` / `const` — block scope

⏳ 4) Temporal Dead Zone (TDZ) — `let` / `const` safety

1) `var` example — gives `undefined`

2) `let` / `const` — not ready before their line

✨ Why `useRef` helps

Step 4: Inspect the `.next` folder