اليوم شاهدت هذا الفيديو، و الحقيقة أنه جميل جدا و يوضح الفكرة بصورة نظرية مع ربطها بأكواد الجافاسكريبت التي نكتبها كل يوم و ماذا يحدث لها خلف الكواليس.
شكرا حسام على النقل و أنا بدوري أنصح كذلك بمشاهدته،
تحت هذه التغريدة سألخص محتوى الفيديو
ما هو ال event loop و كيف يعمل؟
👇🏻
شكرا حسام على النقل و أنا بدوري أنصح كذلك بمشاهدته،
تحت هذه التغريدة سألخص محتوى الفيديو
ما هو ال event loop و كيف يعمل؟
👇🏻
في البداية.. المعروف عن الجافاسكريبت أنها
single-threaded / non-blocking
و بالرغم من كثرة اعتمادها على ال callbacks و ال async code الذي يوحي بتوزيع الأكواد على أكثر من thread (نظريا) إلا أن كل ذلك يعمل في واقع الأمر في thread واحد فقط (عمليا)
single-threaded / non-blocking
و بالرغم من كثرة اعتمادها على ال callbacks و ال async code الذي يوحي بتوزيع الأكواد على أكثر من thread (نظريا) إلا أن كل ذلك يعمل في واقع الأمر في thread واحد فقط (عمليا)
المقصود بكونها non-blocking أنها تسمح لك بتنفيذ أشياء أخرى في الجافاسكريبت في الوقت الذي تنتظر فيه اكتمال عمليات أخرى تجري خلف الكواليس مثل القراءة من ملف أو التواصل مع api، بالعربي.. لما نسوي api request نقدر اننا نسوي أشياء أخرى بنفس الوقت اذا خلينا كود ال request يكون async
ألا يوحي ذلك أن الجافاسكريبت multithreaded؟ ألا يتناقض ذلك مع كونها single-threaded؟
الجواب: كونها non-blocking لا يعني أنها يجب بالضرورة أن تكون multithreaded و هذا الذي يحاول المقطع شرحه.. كيف تعمل الجافاسكريبت خلف الكواليس كلغة singlethreaded - non blocking
الجواب: كونها non-blocking لا يعني أنها يجب بالضرورة أن تكون multithreaded و هذا الذي يحاول المقطع شرحه.. كيف تعمل الجافاسكريبت خلف الكواليس كلغة singlethreaded - non blocking
لتوضيح ذلك فإن أول مفهوم يقوم المقدم بشرحه هو ال stack، و الذي يمكن اعتباره المكان الذي يتم في تتبع الدوال و ترتيب استدعائها و كأنها مهام موجودة في ال memory و بمجرد اكتمال استدعاء الدالة(return) يتم إزالة الدالة من ال stack
لاحظ المهام الموجودة في الصورة الأولى و من ثم كيف ترتبت
لاحظ المهام الموجودة في الصورة الأولى و من ثم كيف ترتبت
و بناءً على ذلك، في حال حدوث خطأ، فمن الممكن إظهار ال stack trace للمبرمج بنفس الترتيب الذي كانت عليه في ال stack لمساعدته في تتبع منبع المشكلة و حل الخطأ
و كذلك فإن امتلاء ال stack بعدد كبير جدا من الدوال و الذي عادة ما يكون بسبب infinite method calls سينتج مشكلة عدم قدرة ال stack على احتمال العدد الموجود و إصدار المشكلة الموضحة أو هي المشكلة المعروفة ب (stack overflow)
النقطة الأخرى التي تحتاج لفهمها هي ال blocking code و كيف أن ال synchronous code سيعطل أي مهمة أخرى و سيوقف الجافاسكريبت ككل إلى حين اكتمال استدعاء هذه ال synchronous function و حينها ستتمكن الجافاسكريبت من مواصلة العمل على المهام الأخرى
و بالتالي فإن الحل لهذه المشكلة هو ال asynchronous callback
ايش اللي بيصير؟
ايش اللي بيصير؟
لو أخذنا هذا الكود كمثال و الذي يستخدم ال setTimeOut مع callback function (و بالتالي فإن ال callback function تمثل async code)
حينها ستترتب الدوال في ال stack حسب ترتيب استدعائها كما ذكر سابقا. و لكن تنفيذ ال callback سيتم جدولته عن طريق نقله إلى ال webapi، ما هو ال webapi؟
حينها ستترتب الدوال في ال stack حسب ترتيب استدعائها كما ذكر سابقا. و لكن تنفيذ ال callback سيتم جدولته عن طريق نقله إلى ال webapi، ما هو ال webapi؟
ال webapi هو أحد الأجزاء التي يوفرها المتصفح، يمكنك اعتباره (نظريا) على أنه خط زماني آخر لجدولة ال async code، حيث يتم الانتظار حتى اكتمال وقت ال timer وقتها سيصبح ال async callback جاهزا للتنفيذ، كيف يتنفذ؟ يروح لل stack؟
لا ☝️..
لا ☝️..
لماذا لا يتم نقله لل stack مباشرة؟ لأن في ذلك تعدي على ترتيب الأكواد التي تتنفذ حاليا في ال stack مما سيعيق هذا الترتيب، لذا لا بد من وجود طريقة أكثر تنظيما لدخوله لل stack، و هذا يتم عن طريق نقله إلى ال task queue. طيب ايش هو ال task queue؟
بإمكانك اعتبار ال stack queue على أنه الطابور المخصص لكل ال async code التي حان وقت استدعائها (إما بسبب اكتمال ال timer أو وصول ال response في حال ال api request الخ..) و هي المرحلة الانتقالية لهذه الأكواد لدخول ال stack، طيب كيف حتدخل ال stack؟ هنا يأتي أخيرا دور ال event loop
وظيفة ال event loop بسيطة جدا، مراقبة ال stack و التأكد من خلوه تماما من أي أكواد أو دوال، و في حال تحقق هذا الشرط يقوم باستخراج الأكواد من ال task queue و نقلها لل stack حتى يتم تنفيذها أخيرا. و من ثم إزالتها من ال stack بعد اكتمال هذا الاستدعاء
و الحقيقة أن هذا ال task queue هو مقسم إلى جزئين:
الأول render queue: و هو المسؤول عن عمل ال re-rendering للصفحة للمستخدم عن طريق مهمة مخصص لذلك يتم تنفيذها حوالي كل 600ms لتعكس آخر التغييرات على الصفحة للمستخدم و بالتالي يكون الموقع reactive،
الثاني..
الأول render queue: و هو المسؤول عن عمل ال re-rendering للصفحة للمستخدم عن طريق مهمة مخصص لذلك يتم تنفيذها حوالي كل 600ms لتعكس آخر التغييرات على الصفحة للمستخدم و بالتالي يكون الموقع reactive،
الثاني..
الثاني هو ال callback queue و هو المخصص بال async code الذي حان وقته كما تم الشرح سابقا.
السؤال المهم: ماذا لو تعاملت مع كل ال api requests لديك على أنها synchronous؟
الجواب: سيتم وضعها في ال stack مباشرة و بالتالي لن يكون بمقدور ال event loop إرسال المهام الخاصة بال re-render
السؤال المهم: ماذا لو تعاملت مع كل ال api requests لديك على أنها synchronous؟
الجواب: سيتم وضعها في ال stack مباشرة و بالتالي لن يكون بمقدور ال event loop إرسال المهام الخاصة بال re-render
و بالتالي فإن الموقع ككل سيظهر متوقفا للمستخدم و لن يكون بمقدور المستخدم التفاعل معه حتى اكتمال استدعاء الكود في ال stack ثم خلو ال stack تماما حينها سيقوم ال event loop بإرسال مهمة ال re-render إلى ال stack لإعادة الحياة إلى صفحة الموقع. 😄
أخيرا.. السبب خلف جمالية المقطع و سلاسة تقديمه، هو الوقت الكبير الذي قضاه صاحبه في فهم المفهوم بالتفاصيل و من ثم ترتيب التسلسل الخاص بشرحه،
تجهيز الشرح النظري، ربط الشرح النظري بالعملي، برمجة أداة لشرحه!
25 دقيقة متعوب عليها و تستحق المشاهدة
تجهيز الشرح النظري، ربط الشرح النظري بالعملي، برمجة أداة لشرحه!
25 دقيقة متعوب عليها و تستحق المشاهدة
جاري تحميل الاقتراحات...