Closures في JavaScript: كيف تتحول من مصدر ارتباك إلى سلاح سري في الكود؟

تخيل أنك تعمل على تطبيق Node.js لمعالجة البيانات المالية، والسيرفر بدأ يعلق فجأة بعد ساعة من التشغيل. بعد Debugging مكثف، تكتشف أن دالة داخل loop تنشئ Closure جديدة في كل تكرار، وكل منها تحتفظ بمرجع لكائن كبير في الذاكرة. النتيجة؟ Memory Leak صامت يلتهم الـ RAM حتى يتوقف التطبيق. هذه ليست سيناريو افتراضياً، بل مشكلة حقيقية واجهتها في مشروع حقيقي لشركة FinTech، وكانت Closures هي الجاني والبطلة في نفس الوقت.

الـ Closures في JavaScript هي من تلك المفاهيم التي تبدو بسيطة في البداية، لكن عندما تبدأ في استخدامها في مشاريع معقدة، تكتشف أنها أشبه بسكين سويسري: مفيدة جداً، لكنها قد تؤلمك إذا لم تعرف كيف تمسكها. في هذا المقال، لن نتحدث عن تعريف Closure التقليدي الذي تجده في كل مرجع، بل سنغوص في التفاصيل الدقيقة التي لا يشرحها أحد: كيف تتفاعل مع الـ Event Loop؟ متى تصبح خطراً على الأداء؟ وكيف تستخدمها بشكل ذكي في الـ Async Code دون أن تخلق كابوساً في الـ Debugging؟

ما الذي يحدث حقاً عندما تنشأ Closure؟

عندما تكتب دالة داخل دالة في JavaScript، فإن الـ Inner Function تحتفظ بمرجع لكل المتغيرات التي كانت في نطاق الـ Outer Function عند لحظة إنشائها، حتى لو انتهت حياة الـ Outer Function. هذا ليس سحراً، بل هو نتيجة مباشرة لكيفية عمل الـ Lexical Scoping و الـ Memory Management في محرك JavaScript. دعنا نكسر هذا إلى أجزاء مفهومة.

عندما ينفذ محرك JavaScript دالة، فإنه ينشئ ما يسمى بـ Execution Context. هذا الـ Context يحتوي على شيئين رئيسيين: الـ Variable Environment (حيث تُخزن المتغيرات) و الـ Outer Environment Reference (مرجع للنطاق الخارجي). عندما تنتهي الدالة، يفترض أن يتم مسح الـ Execution Context من الذاكرة، لكن إذا كان هناك Inner Function ما زالت تحتفظ بمرجع لهذا الـ Context، فلن يتم مسحه. هذه هي الـ Closure: Inner Function + الـ Environment الذي تحتفظ به.

// مثال بسيط لكن عميق
function createCounter() {
 let count = 0; // متغير في نطاق createCounter
 return function() {
 count++; // Inner Function تحتفظ بمرجع لـ count
 return count;
 };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2

// ماذا يحدث خلف الكواليس؟
// 1. createCounter تنشئ Execution Context جديد
// 2. count تُخزن في الـ Variable Environment لهذا الـ Context
// 3. Inner Function تحتفظ بمرجع لهذا الـ Environment
// 4. عندما تنتهي createCounter، الـ Context لا يُمسح لأن Inner Function ما زالت تحتفظ به
// 5. عند استدعاء counter، يتم الوصول لـ count عبر الـ Closure