المدونة

ست بطاقات على لوحة التحكم، ست مؤشرات تحميل، ولا تظهر معاً — تظهر واحدة تلو الأخرى كالدومينو، لأن كل بطاقة بدأت التحميل فقط بعد انتهاء التي فوقها. هذا هو الشلال، والوقت الإجمالي للانتظار ليس أبطأ طلب بل مجموع الكل. use() وSuspense يقطعان هذه السلسلة — لكن المثير للاهتمام هو الآلية الداخلية: ماذا يرمي المكوّن المُعلَّق فعلاً، وكيف يصل HTML الذي يصل بترتيب خاطئ إلى مكانه الصحيح.

كتبتُ في مقال التفاعلات الدقيقة أن transform وopacity تتحرّكان على خيط التركيب (compositor)، فحتى الصفحة الثقيلة لا ينبغي أن تُعطّل حركة الزر. هذا لا يزال صحيحًا – مع تحفّظ واحد سكت عنه ذلك المقال: إذا كان الخيط الرئيسي محجوزًا بمهمّة JS طويلة، فقد لا تحصل الحركة أبدًا على فرصة للبدء، لأنّ معالج النقرة نفسه ينتظر في الطابور. INP هو مقياس يقيس بالضبط هذه الفجوة – وscheduler.yield() إحدى الوسائل القليلة لسدّها فعليًّا.

قائمة من ألف تعليق تُعرَض ببطء، فتلجأ إلى react-window – وفي مقابل تمرير سلس تخسر Ctrl+F، وطباعة الصفحة، وجزءًا من تنقّل قارئ الشاشة، لأن العناصر خارج النافذة المرئية تتوقف عن الوجود فعليًا في DOM. تحلّ content-visibility المشكلة نفسها بطريقة مختلفة: تبقى العناصر في DOM، ويكتفي المتصفح بتجاهل العمل المكلف من تخطيط وطلاء لها، إلى أن تقترب من المنطقة المرئية – والمفاجئ أنها قادرة على كشفها مؤقتًا حين تبحث فيها عن نص.

في مقال إتاحة الوصول، كانت النافذة المنبثقة بخاصية display:none، التي بقيت مع ذلك موجودة في شجرة إتاحة الوصول، مثالًا على خطأ نتج عن بناء نافذة منبثقة من الصفر باستخدام عناصر div. السؤال الحقيقي هو: لماذا كان يجب بناؤها من الصفر أصلًا؟ أفحص ما يقدّمه عنصر ‎<dialog> الأصيل وسمة popover مجّانًا – الطبقة العليا، وفخّ التركيز، والإغلاق الخفيف (light dismiss) – وأين يختلف هذان الآليتان بما يكفي لجعل الخلط بينهما طريقًا مباشرًا لواجهة غير قابلة للوصول.

زرّ «إعجاب» يستجيب فورًا، القلب يمتلئ، العدّاد يرتفع – قبل أن يجيب الخادم أصلًا. هذا ليس وهم السرعة من مقال التفاعلات الدقيقة، بل شيء أبعد من ذلك: تُظهر الواجهة حالة لم توجد بعد، وتفترض أنها ستوجد قريبًا. أفحص كيف تُبنى هذه التقنية بأمان – مع تراجع حقيقي عن الكذبة حين لا يتحقّق الافتراض، ولماذا يُعدّ setState اليدوي مع catch نسخة أسوأ ممّا يقدّمه useOptimistic.

تبدو „use server” وكأنها سكّر نحوي (syntactic sugar) فوق طلب fetch إلى مسار API – ولهذا بالضبط تتعامل معظم التطبيقات معها كأنها استدعاء دالة عادي. هذا خطأ له عواقب ملموسة: كلّ دالة موسومة بـ„use server” تصبح نقطة نهاية عامة على الشبكة، والنموذج المبني على هذه الآلية يعمل حتى قبل أن تتاح فرصة لجافاسكريبت أن تُحمَّل. أفحص ما يجري فعليًا خلف هذا التوجيه، وأين تكمن الفخاخ التي لا تظهر في التوثيق من النظرة الأولى.