callback, setTimeout আর callback hell — “কাজ শেষ হলে আমাকে ডাকুন”

১ · Callback কী — “কাজ শেষ হলে আমাকে ডাকুন”

পর্ব ১৩ আর ১৬-এ আপনি callback দেখেছেন: একটি function, যা আরেকটি function-কে argument হিসেবে দেওয়া হয়, যাতে সে নিজের সুবিধামতো সময়ে সেটিকে ডাকে। [3, 1, 2].sort((a, b) => a - b)-এ তুলনার function একটি callback; prices.map((p) => p * 1.15)-এ ভ্যাট যোগের function-ও তাই। যে function অন্য function নেয়, সেটি একটি higher-order function.

কিন্তু এই পর্বের callback একটু আলাদা জাতের। পর্ব ৩১-এ দেখেছেন, JavaScript-এর মূল কোড চলে একটিমাত্র thread-এ (single-threaded): একসাথে একটিই কাজ। তাহলে একটি ফাইল পড়তে ২ সেকেন্ড লাগলে কি পুরো পাতা ২ সেকেন্ড জমে থাকবে? না। JavaScript কাজটি ব্রাউজার বা Node.js-এর হাতে তুলে দেয় (Web API বা Node-এর libuv), সাথে দেয় একটি function — “শেষ হলে এটি ডাকবেন।” তারপর নিজে পরের লাইনে চলে যায়। কাজ শেষ হলে callback-টি task queue-তে লাইনে দাঁড়ায়, আর call stack খালি হলে event loop তাকে চালায়। এই “এখন শুরু, পরে শেষ” ধরনের কোডকে বলে asynchronous (async) কোড।

Sync callback বনাম async callback

একই শব্দ “callback”, কিন্তু দুটি সম্পূর্ণ ভিন্ন সময়-আচরণ। পার্থক্যটি মাথায় পরিষ্কার না থাকলে async কোডের প্রায় সব বাগ বোঝা কঠিন হয়:

console.log("১. শুরু");
[10, 20].forEach((x) => console.log("২. sync callback", x));
setTimeout(() => console.log("৪. async callback"), 0);
console.log("৩. শেষ লাইন");
// প্রত্যাশিত আউটপুট: ১, ২ (10), ২ (20), ৩, তারপর ৪

forEach-এর callback দুটি চলে forEach ফেরত আসার আগেই। কিন্তু setTimeout(…, 0)-এর callback ০ ms delay সত্ত্বেও চলে সবার শেষে — কারণ সেটি task queue-তে যায়, আর event loop তাকে নেয় শুধু তখন, যখন বর্তমান script পুরো শেষ। পর্ব ৩১-এর মূল নিয়মটিই এখানে কাজ করছে: চলমান কোড কখনো মাঝপথে থামিয়ে callback চালানো হয় না (run-to-completion).

Async callback কোথা থেকে আসে — তিনটি উৎস

২ · setTimeout আর clearTimeout — delay মানে “অন্তত এতক্ষণ”

setTimeout একটি function আর একটি সময় (millisecond-এ) নেয়: “অন্তত এত ms পরে এই function-টি চালাবেন।” এটি নিজে কোনো অপেক্ষা করে না — timer-টি রেজিস্টার করে সাথে সাথে ফেরত আসে, আর আপনার কোড পরের লাইনে চলে যায়।

// ১) সাধারণ ব্যবহার
const id = setTimeout(() => console.log("চা তৈরি!"), 3000);

// ২) callback-এ argument পাঠানো — delay-এর পরের সব argument callback পায়
setTimeout((name, n) => console.log(`${name}, আপনার টোকেন ${n}`), 500, "রহিম", 42);

// ৩) মত বদলালে থামানো — callback আর কখনো চলবে না
clearTimeout(id);

// ৪) কখনো এভাবে নয়: string দিলে eval-এর মতো চলে (নিরাপত্তা ঝুঁকি, ধীর)
// setTimeout("console.log('hi')", 100);

Delay একটি ন্যূনতম সময়, প্রতিশ্রুতি নয়

setTimeout(fn, 1000) মানে “১০০০ ms-এর আগে নয়।” ঠিক ১০০০ ms-এ চলবে, এমন কোনো নিশ্চয়তা নেই। কারণগুলো:

• Main thread ব্যস্ত থাকলে অপেক্ষা। সময় পূর্ণ হলে callback শুধু task queue-তে ঢোকে। তখন যদি একটি ভারী লুপ ৩ সেকেন্ড ধরে চলে (long task), callback সেই ৩ সেকেন্ড লাইনে দাঁড়িয়ে থাকবে।
• ০ মানে “যত তাড়াতাড়ি সম্ভব, কিন্তু এখন নয়।” setTimeout(fn, 0) বর্তমান কোড আর সব microtask শেষ হওয়ার পরে চলে।
• Nested timer-এ ৪ ms (timer clamping). HTML মানদণ্ড অনুযায়ী timer-এর ভেতর থেকে timer, এভাবে ৫ স্তরের বেশি গভীরে গেলে ব্রাউজার delay অন্তত ৪ ms করে দেয়।
• পেছনের ট্যাবে আরও ধীর। ট্যাবটি চোখের আড়ালে থাকলে ব্যাটারি বাঁচাতে ব্রাউজার timer ধীর করে দেয় — সাধারণত সেকেন্ডে একবারের বেশি নয়, দীর্ঘক্ষণ লুকানো থাকলে আরও কম।
• সর্বোচ্চ সীমা। Delay রাখা হয় 32-bit signed integer-এ, তাই সর্বোচ্চ 2147483647 ms (প্রায় ২৪.৮ দিন)। এর বেশি দিলে overflow হয়ে timer প্রায় সাথে সাথে চলে যায় (Node.js একটি TimeoutOverflowWarning দিয়ে delay ১ করে দেয়)।

Timer id — ব্রাউজারে সংখ্যা, Node.js-এ object

setTimeout একটি timer id ফেরত দেয় — এটি দিয়েই পরে clearTimeout(id) করে timer বাতিল করা হয়। ব্রাউজারে id একটি ধনাত্মক পূর্ণসংখ্যা (যেমন 7). Node.js-এ এটি একটি Timeout object, যার কিছু বাড়তি method আছে: timeout.unref() বললে এই timer একা process-কে বাঁচিয়ে রাখবে না, refresh() বললে গোনা আবার শুরু থেকে হবে। তাই timer id-কে কখনো “সংখ্যা” ধরে নিয়ে হিসাব করবেন না — শুধু রেখে দিন আর clear-এ ফেরত দিন।

৩ · setInterval, drift আর recursive setTimeout

setInterval একই callback নির্দিষ্ট সময় পরপর বারবার চালায়, যতক্ষণ না clearInterval(id) দিয়ে থামানো হয়। ঘড়ি, countdown, প্রতি ৩০ সেকেন্ডে নতুন বার্তা আছে কি না দেখা — শুনতে সহজ। কিন্তু দুটি জিনিস প্রায়ই ভুল বোঝা হয়।

প্রথমত, setInterval আপনার কাজ শেষ হওয়ার অপেক্ষা করে না। সে একটি নির্দিষ্ট ছন্দ ধরে রাখার চেষ্টা করে — ০, ১০০, ২০০, ৩০০ ms… কিন্তু callback-এর কাজে যদি interval-এর চেয়ে বেশি সময় লাগে? তখন পরের tick-এর সময় পেরিয়ে যায়, আর কাজ শেষ হতেই প্রায় সাথে সাথে আবার শুরু হয় — মাঝে কোনো বিরতি নেই। Main thread একটানা ব্যস্ত থাকে, ক্লিক আর পাতা আঁকার সুযোগ পায় না। সমাধান হলো recursive setTimeout: কাজ শেষ হলে তবেই পরের timer বসানো। এতে প্রতিটি কাজের পরে অন্তত নির্দিষ্ট বিরতি নিশ্চিত থাকে। ধাপে ধাপে দেখুন। “পরে” চাপুন।

1const work = () => busy(150);  // ১৫০ ms-এর কাজ2setInterval(work, 100);34function loop() {5  work();6  setTimeout(loop, 100);   // কাজের পরে7}8setTimeout(loop, 100);

দ্বিতীয়ত, tick গুনে সময় মাপা যায় না। প্রতিটি tick সামান্য দেরিতে আসে, আর দেরি জমতে থাকে — একে বলে timer drift. পেছনের ট্যাবে timer ধীর হলে দেরি অনেক বড় হয়। তাই OTP countdown-এর মতো জিনিসে “৬০ বার tick গুনলে ৬০ সেকেন্ড” ভাবা ভুল। নির্ভরযোগ্য উপায়: শুরুতে শেষ সময়টি লিখে রাখুন (const end = Date.now() + 60_000), আর প্রতি tick-এ Math.ceil((end - Date.now()) / 1000) হিসাব করে বাকি সেকেন্ড দেখান। Tick দেরিতে এলেও দেখানো সময় ঠিক থাকে।

চালিয়ে দেখুন — OTP countdown আর দ্রুত ডেলিভারি

নিচের কোডে দুটি বাস্তব উদাহরণ। প্রথমটি OTP-র মেয়াদ গোনে (পাতায় সময় বাঁচাতে ৬০ সেকেন্ডের বদলে ৩ tick, প্রতিটি ১০০ ms) আর শেষে নিজেকে থামায়। দ্বিতীয়টি একটি ডেলিভারির তিনটি ধাপ পরপর চালায় — প্রতিটি ধাপ আগেরটি শেষ হলে তবেই শুরু, তাই callback-এর ভেতরে callback. প্রথম ধাপের delay ইচ্ছা করে ৪৫০ ms রাখা হয়েছে, যাতে countdown শেষ হওয়ার পরে ডেলিভারি শুরু হয় আর আউটপুট পড়তে সহজ হয়।

// ১) OTP countdown — setInterval চলে, শেষে clearInterval
let left = 3;
const otpTimer = setInterval(() => {
  if (left > 0) return console.log(`OTP-এর মেয়াদ বাকি: ${left--}`);
  clearInterval(otpTimer);                    // না থামালে চিরকাল চলবে
  console.log("মেয়াদ শেষ — আবার কোড চান");
}, 100);

// ২) দ্রুত ডেলিভারি — ধাপগুলো পরপর, তাই callback-এর ভেতরে callback
function step(label, ms, next) {
  setTimeout(() => { console.log(label); next(); }, ms);
}
step("📦 অর্ডার প্যাক হলো", 450, () => {
  step("🚚 গাড়িতে উঠল", 100, () => {
    step("🏠 দরজায় পৌঁছাল", 100, () => {
      console.log("ডেলিভারি সম্পূর্ণ");
    });
  });
});
console.log("sync কোড শেষ — timer-গুলো এখনো অপেক্ষায়");

N বার পরে থামা, আর recursive সংস্করণ

“ঠিক ৫ বার মনে করিয়ে দিন” — এমন কাজে একটি counter রেখে শর্ত পূর্ণ হলে clearInterval করুন, যেমন উপরের OTP-তে। Recursive setTimeout-এ থামানো আরও সহজ: শর্ত পূর্ণ হলে পরের timer আর বসাবেন না।

function poll(tries = 0) {
  checkPayment((err, paid) => {               // ধরা যাক bKash পেমেন্টের অবস্থা দেখে
    if (paid) return console.log("পেমেন্ট পাওয়া গেছে");
    if (tries >= 4) return console.log("সময় শেষ — পরে আবার দেখুন");
    setTimeout(() => poll(tries + 1), 2000);  // উত্তর আসার পরেই পরের চেষ্টা
  });
}

এখানে একটি সূক্ষ্ম সুবিধা আছে: নেটওয়ার্কের উত্তর আসতে ৫ সেকেন্ড লাগলেও কখনো দুটি অনুরোধ একসাথে চলবে না, কারণ পরের অনুরোধ বসে আগেরটির উত্তর আসার পরে। setInterval(check, 2000) দিলে ধীর নেটওয়ার্কে একসাথে কয়েকটি অনুরোধ ঝুলে থাকত, আর উত্তরগুলো এলোমেলো ক্রমে ফিরতে পারত।

৪ · Timer আর this, আর event — callback-এর আরেক রূপ

Timer-এ হারানো this

পর্ব ২৪-এ দেখেছেন, সাধারণ function-এর this ঠিক হয় ডাকার ধরন দেখে। setTimeout(cart.report, 1000) লিখলে timer-এর হাতে যায় শুধু function-টি, cart নয়। এক সেকেন্ড পরে timer সেটিকে ডাকে cart. ছাড়াই — ব্রাউজারে this হয় global object, Node.js-এ একটি Timeout object. একে বলে হারানো this.

class Countdown {
  constructor(sec) { this.sec = sec; }
  startBroken() { setInterval(this.tick, 1000); }        // ❌ this হারায়
  start()       { this.id = setInterval(() => this.tick(), 1000); }  // ✅ arrow
  tick() {
    console.log(this.sec--);
    if (this.sec < 0) clearInterval(this.id);
  }
}
// startBroken: tick-এর ভেতরে this.sec → undefined, তারপর NaN …

Event — বারবার ডাকা callback

Timer একবার বা নির্দিষ্ট ছন্দে ডাকে। Event-এর callback ডাকা হয় “যখনই ঘটনাটি ঘটবে” — হয়তো কখনোই না, হয়তো সেকেন্ডে দশবার। ব্রাউজারে এর রূপ event listener:

const btn = document.querySelector("#resend");
function onResend() { console.log("নতুন OTP পাঠানো হলো"); }
btn.addEventListener("click", onResend);       // প্রতিটি ক্লিকে একবার
btn.removeEventListener("click", onResend);    // থামাতে একই function reference লাগে

Event-এর bubbling, delegation আর custom event পর্ব ৩৮-এ বিস্তারিত। Node.js-এ একই নকশার নাম EventEmitter: একটি object, যাতে on(নাম, fn) দিয়ে listener লাগানো যায় আর emit(নাম, ডেটা) দিয়ে ঘটনা ঘোষণা করা যায়। Node-এর stream, HTTP server, process — প্রায় সবকিছু EventEmitter. একটি গুরুত্বপূর্ণ তথ্য, যা অনেকে জানেন না: emit নিজে synchronous — সে listener-গুলোকে রেজিস্টারের ক্রমে, সাথে সাথে, একই call stack-এ ডাকে। Event “পরে” আসে শুধু তখন, যখন emit-কে কোনো async উৎস (ফাইল, নেটওয়ার্ক, timer) পরে ডাকে। পরের অংশের Node কোডে এটি নিজের চোখে দেখবেন।

৫ · Node.js-এর error-first callback — ভুল আগে, ফল পরে

Timer কখনো ব্যর্থ হয় না — সময় হলে চলেই। কিন্তু ফাইল পড়া ব্যর্থ হতে পারে: ফাইল নেই, অনুমতি নেই, ডিস্ক ভরা। Async কাজে ব্যর্থতা কীভাবে জানানো হবে? throw কাজ করে না — ভুলটি ঘটে অনেক পরে, যখন কলকারী function আর তার try/catch অনেক আগেই শেষ। তাই Node.js একটি রীতি দাঁড় করায়, যার নাম error-first callback:

• Callback-এর প্রথম parameter সবসময় ভুল (err). সফল হলে সেখানে null (বা undefined).
• সফল হলে ফল আসে দ্বিতীয় (প্রয়োজনে তৃতীয়…) parameter-এ।
• Callback একবারই ডাকা হয় — হয় ভুল দিয়ে, নয় ফল দিয়ে, দুটো একসাথে নয়।
• যে callback নেয়, সেই function-এর শেষ parameter হলো callback.

ভুল প্রথমে কেন? কারণ তাহলে ভুলটি উপেক্ষা করা কঠিন — callback লিখতে বসলেই প্রথম নামটি err, আর চোখের সামনে থাকে। ফলের সংখ্যা কাজভেদে বদলাতে পারে (কোনো কাজ শুধু “হয়েছে” জানায়, কোনোটি দুটি মান দেয়), কিন্তু ভুলের জায়গা সব API-তে একই থাকে — তাই util.promisify-এর মতো সাধারণ যন্ত্র যেকোনো callback API-কে একইভাবে বুঝতে পারে (অংশ ৮)। এর ইতিহাস ভাবনার প্রশ্ন ২-এ।

নিচের কোডটি Node.js 20-এ চলে। এটি প্রথমে একটি config ফাইল লেখে, তারপর error-first callback দিয়ে পড়ে; তারপর ইচ্ছা করে একটি অনুপস্থিত ফাইল পড়ে ভুলের পথ দেখায়। সাথে একটি EventEmitter — দেখুন কোন আউটপুট কখন আসে।

const fs = require("node:fs");
const EventEmitter = require("node:events");
fs.writeFileSync("config.json", '{ "shop": "দ্রুত ডেলিভারি", "vat": 15 }');

function loadConfig(file, cb) {                 // error-first callback
  fs.readFile(file, "utf8", (err, text) => {
    if (err) return cb(err);                    // ভুল হলে আগেই ফেরত
    let cfg;
    try { cfg = JSON.parse(text); } catch (e) { return cb(e); }
    cb(null, cfg);                              // সফল: প্রথম ঘরে null
  });
}
loadConfig("config.json", (err, cfg) => {
  if (err) return console.log("ভুল:", err.message);
  console.log("config:", cfg.shop, cfg.vat);
  loadConfig("missing.json", (err2) => console.log("ভুল:", err2.code));
});

const order = new EventEmitter();
order.on("placed", (id) => console.log("SMS গেল, অর্ডার", id));
order.once("placed", (id) => console.log("প্রথম অর্ডারে উপহার:", id));
order.emit("placed", 101);
order.emit("placed", 102);
console.log("emit শেষ — readFile-এর callback এখনো আসেনি");

৬ · Zalgo আর inversion of control — callback-এর বিশ্বাসের সংকট

Zalgo — কখনো sync, কখনো async

একটি দামের API ভাবুন, যা cache-এ দাম থাকলে সাথে সাথে callback ডাকে, না থাকলে সার্ভার থেকে এনে পরে ডাকে। শুনতে কার্যকর — cache hit-এ অপেক্ষা কেন? কিন্তু এতে callback কখনো sync, কখনো async হয়ে যায়, আর কলকারীর কোডের ক্রম নির্ভর করে cache-এ কী আছে তার ওপর। Node.js-এর তৎকালীন প্রধান Isaac Schlueter এই সমস্যার নাম দেন Zalgo — একটি ইন্টারনেট মিম থেকে নেওয়া, যেখানে “Zalgo” মানে বিশৃঙ্খলার দানব। ধাপে ধাপে দেখুন:

1function getPrice(item, cb) {2  if (cache.has(item)) return cb(cache.get(item));3  // ✅ queueMicrotask(() => cb(cache.get(item)))4  fetchPrice(item, cb);           // async5}6console.log("A");7getPrice(item, (p) => { spinner.stop(); console.log("B", p); });8spinner.start();9console.log("C");

queueMicrotask একটি function-কে microtask queue-তে পাঠায় — বর্তমান কোড শেষ হলেই, কোনো timer বা I/O-র আগে চলে (পর্ব ৩১)। Node.js-এর পুরোনো সমতুল্য process.nextTick, যা আরও আগে, Promise-এর microtask-গুলোরও আগে চলে। পর্ব ৩৩-এ দেখবেন, Promise-এর then callback মানদণ্ড অনুযায়ী সবসময় async — Zalgo-কে ভাষার স্তরেই নিষিদ্ধ করা হয়েছে।

Inversion of control — নিজের কোডের নিয়ন্ত্রণ অন্যের হাতে

আপনি যখন একটি third-party লাইব্রেরিকে callback দেন, তখন একটি গুরুত্বপূর্ণ জিনিস তুলে দেন: আপনার কোডের বাকি অংশ কখন, কতবার, কোন argument দিয়ে চলবে — সেই সিদ্ধান্ত। একে বলে inversion of control. সাধারণত আপনি function ডাকেন; এখানে অন্যের কোড আপনার function ডাকে। লাইব্রেরি ভালো হলে সমস্যা নেই। কিন্তু ধরুন একটি পেমেন্ট SDK:

• দুবার ডাকে — একটি retry বাগে onSuccess দুবার; আপনার কোড দুটি অর্ডার তৈরি করে, গ্রাহকের কাছে দুটি SMS যায়।
• কখনো ডাকে না — নেটওয়ার্ক বিচ্ছিন্ন হলে SDK চুপচাপ থেমে যায়; আপনার “অপেক্ষা করুন” লেখা চিরকাল থাকে।
• খুব তাড়াতাড়ি ডাকে — Zalgo-র মতো, আপনার প্রস্তুতি শেষ হওয়ার আগেই।
• ভুল argument দেয় — err আর data দুটোই দেয়, বা কোনোটিই না; বা আপনার callback-এর ভুল নিজে চুপচাপ গিলে ফেলে।

Callback দিয়ে এর প্রতিরক্ষা নিজেকেই লিখতে হয়। পর্ব ২২-এর once মনে আছে? সেটিকে একটি timeout-সহ রক্ষাকবচ বানানো যায়:

function guarded(cb, ms = 10_000) {
  let called = false;                                 // closure-এ রাখা পাহারাদার
  const timer = setTimeout(() => finish(new Error("সময় শেষ — উত্তর আসেনি")), ms);
  function finish(err, data) {
    if (called) return;                               // দ্বিতীয় কল উপেক্ষা
    called = true;
    clearTimeout(timer);
    queueMicrotask(() => cb(err, data));              // সবসময় async — Zalgo নয়
  }
  return finish;
}
paymentSdk.charge(500, guarded((err, receipt) => { /* একবারই, নিশ্চিতভাবে */ }));

৭ · Callback hell — পিরামিডের অভিশাপ

এবার একটি পুরো অনলাইন অর্ডার ভাবুন। পাঁচটি ধাপ, প্রতিটি async, আর প্রতিটি আগের ধাপের ফলের ওপর নির্ভরশীল: ব্যবহারকারী আনা → তার cart আনা → স্টক আছে কি না দেখা → অর্ডার জমা দেওয়া → SMS পাঠানো। Callback দিয়ে “আগেরটি শেষ হলে পরেরটি” বলার একমাত্র উপায় হলো পরেরটিকে আগেরটির callback-এর ভেতরে লেখা। ফল:

getUser(userId, (err, user) => {
  if (err) return fail(err);
  getCart(user.id, (err, cart) => {
    if (err) return fail(err);
    checkStock(cart.items, (err, ok) => {
      if (err) return fail(err);
      placeOrder(user, cart, (err, order) => {
        if (err) return fail(err);
        sendSms(user.phone, `অর্ডার ${order.id} নিশ্চিত`, (err) => {
          if (err) console.log("SMS যায়নি, তবে অর্ডার হয়েছে");
          showDone(order);
        });
      });
    });
  });
});

কোড ডানদিকে সরতে সরতে একটি পাশ-ফেরা পিরামিডের আকার নেয় — এর নাম callback hell, বা “pyramid of doom”. শুধু দেখতে খারাপ নয়; এর আসল সমস্যাগুলো গভীরে। একটি ভুলের যাত্রা ধাপে ধাপে দেখুন — ধরা যাক তৃতীয় ধাপে স্টক নেই।

1getUser(id, (err, user) => {2  if (err) return fail(err);3  getCart(user.id, (err, cart) => {4    if (err) return fail(err);5    checkStock(cart.items, (err, ok) => {6      if (err) return fail(err);   // ← এখানে7      placeOrder(user, cart, (err, order) => {8        if (err) return fail(err);9        sendSms(user.phone, …, (err) => {…});10      });11    });12  });13});  // চারপাশে try/catch দিলে?

Callback hell-এর সমস্যাগুলো তাহলে এক জায়গায়:

• পড়া কঠিন: কাজের ক্রম ওপর থেকে নিচে, কিন্তু চোখকে বারবার ডানে-বামে যেতে হয়; শেষের }); }); }); কোনটি কার, বোঝা মুশকিল।
• ভুল সামলানো ছড়ানো: প্রতিটি স্তরে আলাদা if (err); একটি ভুলে গেলে নিঃশব্দ বাগ। try/catch কাজ করে না।
• নিয়ন্ত্রণ কঠিন: “তিনবার retry”, “৫ সেকেন্ডে উত্তর না এলে বাতিল”, “এই দুটি একসাথে চালানো” — প্রতিটির জন্য হাতে লেখা জটিল কোড।
• বিশ্বাস: প্রতিটি স্তরে inversion of control — পাঁচটি লাইব্রেরির যেকোনোটি callback দুবার ডাকলে পুরো শিকল এলোমেলো।

পিরামিড সমতল করা — named function, early return, ছোট module

Promise ছাড়াও callback hell অনেকটা কমানো যায়। callbackhell.com সাইটটির মূল পরামর্শও এগুলোই: nested anonymous function-কে নাম দিয়ে বাইরে আনুন, প্রথমেই ভুল সামলে return করুন (early return), আর সম্পর্কিত function-গুলোকে আলাদা ছোট module-এ রাখুন।

function startOrder(userId) { getUser(userId, onUser); }

function onUser(err, user) {
  if (err) return fail(err);
  getCart(user.id, (err, cart) => onCart(err, user, cart));
}
function onCart(err, user, cart) {
  if (err) return fail(err);
  checkStock(cart.items, (err) => onStock(err, user, cart));
}
function onStock(err, user, cart) {
  if (err) return fail(err);
  placeOrder(user, cart, (err, order) => onOrder(err, user, order));
}
// onOrder → sendSms → showDone, একই ধাঁচে

৮ · একসাথে অনেক কাজ — parallel counter, promisify আর টেস্টে timer

পিরামিডের কাজগুলো একটির ওপর আরেকটি নির্ভরশীল, তাই পরপর (series) চালাতে হয়। কিন্তু একটি dashboard খোলার সময় তিনটি জিনিস লাগে — ব্যবহারকারীর তথ্য, cart আর আজকের অফার — যারা একে অপরের ওপর নির্ভর করে না। এদের পরপর চালালে মোট সময় = তিনটির যোগফল; একসাথে (parallel) চালালে মোট সময় = সবচেয়ে ধীরটির সময়। সমস্যা হলো: তিনটি callback যেকোনো ক্রমে ফিরতে পারে, তাহলে “সবগুলো শেষ” বুঝব কীভাবে? উত্তর: একটি counter.

function parallel(tasks, final) {
  const results = [];
  let done = 0, finished = false;
  tasks.forEach((task, i) => {
    task((err, data) => {
      if (finished) return;                      // final একবারই
      if (err) { finished = true; return final(err); }
      results[i] = data;                         // ক্রম বজায় — index দিয়ে
      if (++done === tasks.length) { finished = true; final(null, results); }
    });
  });
}
const fakeRequest = (name, ms, cb) => setTimeout(() => cb(null, `${name}: ঠিক আছে`), ms);
parallel([
  (cb) => fakeRequest("user", 300, cb),
  (cb) => fakeRequest("cart", 100, cb),
  (cb) => fakeRequest("offer", 200, cb),
], (err, all) => console.log(err ? "ব্যর্থ" : all));
// প্রত্যাশিত আউটপুট (৩০০ ms পরে):
// [ 'user: ঠিক আছে', 'cart: ঠিক আছে', 'offer: ঠিক আছে' ]

1tasks.forEach((task, i) => task((err, data) => {2  if (finished) return;3  if (err) { finished = true; return final(err); }4  results[i] = data;5  if (++done === tasks.length) {6    finished = true; final(null, results);7  }8}));

২০১০ সালে Caolan McMahon-এর লেখা npm প্যাকেজ async এই ধরনের সহায়ক (async.series, async.parallel, async.waterfall, সীমিত সংখ্যায় একসাথে চালানোর async.parallelLimit) জনপ্রিয় করে, আর Promise আসার আগের যুগে Node.js কোডবেসের প্রায় অপরিহার্য অংশ হয়ে ওঠে। পুরোনো প্রজেক্টে আজও এটি দেখবেন।

util.promisify — callback থেকে Promise-এ সেতু

আজকের নতুন কোড callback-এ লেখা হয় না, কিন্তু callback-ভিত্তিক পুরোনো API সর্বত্র। Node.js 8 (২০১৭) একটি সেতু যোগ করে: util.promisify. এটি যেকোনো error-first callback function নিয়ে একটি Promise-ফেরত-দেওয়া সংস্করণ বানায় — error-first রীতি সব জায়গায় একই বলেই এটি সম্ভব।

const { promisify } = require("node:util");
const fs = require("node:fs");

const readFileP = promisify(fs.readFile);     // (file, enc) => Promise
readFileP("config.json", "utf8")
  .then((text) => console.log(JSON.parse(text).shop))
  .catch((err) => console.log("ভুল:", err.code));

// আজ সরাসরি Promise API-ও আছে:
// require("node:fs/promises").readFile(...)
// require("node:timers/promises").setTimeout(500)  — অপেক্ষার Promise

Promise কীভাবে কাজ করে, then-এর শিকল পিরামিডকে কীভাবে সোজা লাইন বানায়, আর একটি .catch কীভাবে সব স্তরের ভুল এক জায়গায় ধরে — সেটাই পর্ব ৩৩. আর async/await (পর্ব ৩৪) সেই কোডকে প্রায় সাধারণ sync কোডের মতো দেখায়। Debounce আর throttle — timer দিয়ে বানানো আরও দুটি দরকারি নকশা — পর্ব ৩৬-এ।

টেস্টে timer — অপেক্ষা না করে সময় এগিয়ে দেওয়া

OTP-র ৬০ সেকেন্ডের মেয়াদ টেস্ট করতে কি প্রতিবার ৬০ সেকেন্ড অপেক্ষা করবেন? না। টেস্টিং টুলগুলো fake timers দেয়: আসল setTimeout-এর জায়গায় একটি নকল ঘড়ি, যা আপনি নিজে এগিয়ে দেন। Vitest-এ vi.useFakeTimers() চালু করে vi.advanceTimersByTime(60_000) বললে ৬০ সেকেন্ডের সব timer সাথে সাথে চলে যায়; Jest-এ একই কাজ jest.useFakeTimers(), আর Sinon-এর @sinonjs/fake-timers লাইব্রেরি এদের অনেকের ভিত্তি। টেস্ট দ্রুত হয়, আর ফল নিশ্চিত — আসল ঘড়ির এলোমেলো দেরি থাকে না। বিস্তারিত পর্ব ৪৮-এ।

৯ · AI-এর যুগে — AI-এর লেখা callback আর timer যাচাই করা

AI মডেল শিখেছে ইন্টারনেটের কোটি লাইন কোড থেকে, যার বিশাল অংশ ২০১০-এর দশকের callback-ভিত্তিক Node.js আর jQuery. তাই callback বা timer-এর কাজ চাইলে চারটি ভুল বারবার দেখা যায়।

১. গভীর পিরামিড। “ফাইল পড়ো, প্রসেস করো, ডেটাবেসে রাখো, ইমেইল পাঠাও” বললে অনেক সময় চার-পাঁচ স্তরের nested callback আসে। ২. ভুলে যাওয়া clearInterval. একটি countdown বা polling শুরু হয়, কিন্তু থামানোর পথ নেই — বা component সরে যাওয়ার সময় পরিষ্কার করা হয় না; ফল memory leak আর ভূতুড়ে আপডেট। ৩. উপেক্ষিত err. (err, data) => { use(data) } — প্রথম parameter লেখা আছে, কিন্তু কখনো পরীক্ষা হয় না। ৪. Callback আর Promise মেশানো। একই function কখনো callback নেয়, কখনো Promise ফেরত দেয়; বা একটি async function-এর ভেতরে callback-এর ভেতরে return লিখে ধরে নেওয়া হয় যে বাইরের function সেটি ফেরত দেবে। এতে ভুল দুবার সামলানো হয়, বা একবারও না।

// ❌ AI-এর একটি সাধারণ ভুল: callback-এর return বাইরের function-এর return নয়
async function getShopName() {
  fs.readFile("config.json", "utf8", (err, text) => {
    return JSON.parse(text).shop;     // এই return যায় callback থেকে, কোথাও না
  });
}                                     // getShopName() → Promise<undefined>
// ✅ ঠিক: const text = await fs.promises.readFile("config.json", "utf8");

AI-এর লেখা callback বা timer হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি error-first callback-এর প্রথম লাইনে if (err) return … আছে, আর ভুলটি কোথাও পৌঁছায় (লগ, ব্যবহারকারীকে বার্তা, বা কলকারীর callback)
• প্রতিটি setInterval/setTimeout-এর id রাখা হয়েছে, আর থামার শর্ত ও cleanup (component সরানো, পাতা ছাড়া) নিশ্চিত
• দীর্ঘ বা নেটওয়ার্ক কাজে setInterval-এর বদলে recursive setTimeout; countdown tick গুনে নয়, শেষ সময় থেকে হিসাব করে
• Timer-এ method পাঠানো হলে this ঠিক আছে (arrow বা bind)
• কোনো callback কখনো sync কখনো async নয় (Zalgo); third-party callback দুবার বা কখনো না এলে কী হবে, ভাবা হয়েছে
• Callback আর Promise একই function-এ মেশানো হয়নি; callback-এর ভেতরের return থেকে বাইরের ফল আশা করা হয়নি
• তিন স্তরের বেশি nesting থাকলে named function বা Promise/async-await দিয়ে লেখার প্রস্তাব দেওয়া হয়েছে