أسئلة مقابلة مطور Frontend من المبتدئ إلى الخبير

الدالة لا تحفظ قيمة i وإنما تحفظ مرجعاً إلى المتغير نفسه، وهذا هو الإغلاق Closure، وvar نطاقها الدالة كلها فهناك متغير واحد، والدوال تعمل بعد انتهاء الحلقة لأن setTimeout يضعها في طابور المهام. ومع let تنشئ اللغة ربطاً جديداً لكل دورة، فكل دالة تغلق على نسختها. ونفس الفكرة تسبب أشهر أخطاء أطر العمل: دالة داخل مكون تغلق على قيمة حالة قديمة Stale Closure، فتقرأ عداداً أو نص بحث من رسم سابق.

قيمة this في الدالة العادية تحددها طريقة الاستدعاء: obj.method() تعطي obj، أما const f = obj.method; f() فتعطي undefined في الوضع الصارم Strict Mode، وجسم الكلاس دائماً صارم. وعندما تمرر this.save إلى addEventListener فأنت تمرر الدالة وحدها. والدالة السهمية لا تملك this خاصاً بها وإنما تأخذه من المكان الذي عرفت فيه، لذلك تحل المشكلة كحقل في الكلاس، مع ملاحظة أن كل نسخة تحصل على دالة جديدة، وأن removeEventListener يحتاج نفس المرجع.

TypeScript يفحص الكود وقت الترجمة فقط، ثم تحذف الأنواع ويبقى JavaScript، فعندما تكتب const user = await res.json() as User فأنت تعد المترجم بشيء لا يتحقق منه أحد، وإذا غير ال Backend اسم حقل فسوف يمر الكود ويفشل لاحقاً بعيداً عن السبب. لذلك أعامل كل ما يأتي من الخارج (ال API، وlocalStorage، ورسائل postMessage) على أنه unknown، وأتحقق منه عند الحدود بمكتبة مثل Zod أو بدوال حماية Type Guards، وأستنتج النوع من ال Schema نفسه حتى لا يكون هناك تعريفان يختلفان.

بعد كل مهمة (سكربت، أو حدث، أو مؤقت) يفرغ المتصفح طابور المهام الصغرى كله، بما فيه الصغرى التي تضيفها الصغرى نفسها، قبل أن ينتقل إلى المهمة التالية أو إلى رسم الإطار. لذلك سلسلة then لا نهائية تجمد الصفحة تماماً مثل حلقة while، لأن المتصفح لا يصل أبداً إلى الرسم. وawait هو then على ما بعده، فالسطر بعد await مهمة صغرى. ومؤقت بصفر لا يعني الآن، وإنما بعد انتهاء المهمة الحالية وكل الصغرى، وقد يتأخر أكثر إذا كان الخيط مشغولاً أو كانت الصفحة في الخلفية.

المتصفح ينفذ معالج النقرة في نفس الخيط الذي ينفذ JavaScript الصفحة، فإذا كانت هناك مهمة واحدة تأخذ ثانية (تحليل JSON كبير، أو بناء جدول من آلاف الصفوف، أو Hydration لصفحة كبيرة) فالنقرة تنتظر في الطابور حتى تنتهي، وهذا يظهر في مقياس INP كتأخير إدخال Input Delay. وأي مهمة أطول من 50 ملي ثانية تعتبر مهمة طويلة، وأجدها في تبويب Performance في DevTools. والحل تقسيم العمل إلى قطع مع إعطاء المتصفح فرصة بينها (scheduler.yield() أو setTimeout)، أو نقله إلى Web Worker إذا لم يحتج إلى ال DOM، أو تقليله أصلاً.

المتصفح يرسم بمعدل الشاشة (60 إطاراً في الثانية تعني 16.7 ملي ثانية للإطار، وأسرع في الشاشات الحديثة)، وrequestAnimationFrame يستدعي دالتك قبل الرسم التالي مباشرة، فيكون التحديث متزامناً مع الإطار، ويتوقف تلقائياً في التبويب المخفي فيوفر البطارية. أما setTimeout(16) فلا يعرف متى يرسم المتصفح، فيأتي أحياناً مرتين في إطار وأحياناً لا يأتي. وفي أغلب الحالات الأفضل ألا تحرك بالكود أصلاً، وإنما بـ CSS Transitions على transform وopacity التي ينفذها ال Compositor دون الخيط الرئيسي.

المتصفح يحلل HTML إلى DOM وCSS إلى CSSOM، ويجمعهما في شجرة العرض، ثم يحسب المواقع والأحجام Layout، ثم يرسم Paint، ثم يركب الطبقات Composite. وCSS يحجب الرسم لأن المتصفح لا يرسم صفحة دون أنماطها، وسكربت عادي في head يحجب التحليل حتى يحمل وينفذ، لذلك نستخدم defer أو type="module". والخط الذي لم يحمل بعد قد يخفي النص (FOIT)، والحل font-display: swap مع تحميل مسبق للخط العربي لأن حجمه أكبر غالباً. وأهم ما يؤثر على LCP: سرعة وصول HTML، وأولوية تحميل الصورة الكبيرة أو الخط.

المتصفح يؤجل حساب التخطيط إلى ما قبل الرسم، ولكن إذا قرأت قيمة تعتمد عليه مثل offsetHeight أو getBoundingClientRect() بعد أن كتبت تغييراً، يضطر لحسابه فوراً. وفي حلقة تقرأ وتكتب لكل عنصر يحدث الحساب ألف مرة بدلاً من مرة، وهذا Layout Thrashing. والحل أن أقرأ كل القيم أولاً ثم أكتب كل التغييرات، أو أؤجل الكتابة إلى requestAnimationFrame. وأكتشفه في تبويب Performance حيث يظهر Layout بلون بنفسجي متكرر مع تحذير Forced reflow.

هذه إزاحة التخطيط التي يقيسها CLS، والهدف 0.1 أو أقل. وأسبابها: صور وفيديو دون width وheight أو aspect-ratio، ومحتوى يحقن فوق المحتوى الموجود (لافتة الكوكيز وإعلان)، وخط يحمل متأخراً بمقاسات مختلفة عن البديل، ومكونات تحمل بياناتها ثم تتمدد. والحلول: حجز المساحة مسبقاً، ووضع المحتوى المتأخر في مكان محجوز أو فوق المحتوى بـ position، وضبط مقاسات الخط البديل بـ size-adjust. والإزاحة خلال 500 ملي ثانية بعد تفاعل المستخدم لا تحسب لأنها متوقعة.

أفتح Elements في DevTools وأرى القاعدة مشطوبة ومن الذي غلبها. والترتيب: الأصل (أنماط المتصفح ثم المؤلف) والطبقة ثم الخصوصية ثم ترتيب الظهور، والخصوصية تحسب كثلاثة أرقام (ID، ثم Class وخاصية وPseudo-class، ثم العنصر). ورفع الخصوصية لتغلب قاعدة أخرى يبدأ حرباً لا تنتهي، والحل الأفضل تنظيم الأنماط: @layer لترتيب الطبقات (Reset ثم مكتبة ثم مكونات ثم استثناءات) بحيث تغلب الطبقة المتأخرة مهما كانت خصوصية الأولى، ومحددات بخصوصية منخفضة ومتساوية، و:where() عندما أريد خصوصية صفر.

Flexbox يوزع العناصر على محور واحد ويترك المحتوى يحدد الأحجام، فهو مناسب للمكونات (أزرار، وشريط أدوات، وبطاقة)، وGrid يعرف الصفوف والأعمدة من الحاوي فتصطف العناصر في البعدين، فهو مناسب للتخطيط وللبطاقات التي يجب أن تتساوى. وgrid-template-columns: repeat(auto-fill, minmax(240px, 1fr)) يعطي شبكة متجاوبة دون أي Media Query. والاثنان يحترمان اتجاه الصفحة تلقائياً، فـ justify-content: flex-start تبدأ من اليمين في صفحة RTL، وهذا سبب آخر لتجنب float وleft.

هذا سبب، والسبب الأشهر أن النافذة داخل أب أنشأ سياق تكديس Stacking Context جديداً (بـ transform أو opacity أقل من 1 أو filter أو position: fixed أو z-index على عنصر موضوع)، فقيمة 9999 تقارن فقط مع إخوتها داخل هذا السياق، والأب نفسه خلف العنصر الآخر. والحل ليس رقماً أكبر، وإنما نقل النافذة إلى نهاية body عبر Portal، أو استخدام عنصر <dialog> مع showModal() الذي يضع النافذة في الطبقة العليا Top Layer فوق كل شيء، ويعطي معها إدارة التركيز وزر Escape.

أضع dir وlang على html، وأكتب بالخصائص المنطقية: margin-inline-start بدلاً من margin-left، وpadding-inline، وinset-inline-end، وtext-align: start، وborder-start-start-radius، فتنقلب كلها تلقائياً مع الاتجاه. ويبقى ما يجب قلبه يدوياً: الأيقونات التي لها اتجاه (سهم التالي والرجوع) بـ :dir(rtl) أو transform: scaleX(-1)، أما الأيقونات التي لا اتجاه لها (البحث، والإعدادات، وعلامة التشغيل في بعض الأنظمة) فلا تقلب. وtransform وtranslateX لا تنقلب تلقائياً، وهذا يكسر القوائم المنزلقة.

خوارزمية Unicode Bidi تحدد اتجاه كل حرف، والأرقام وعلامات الترقيم محايدة تأخذ اتجاه ما حولها، فرقم بعد كلمة إنجليزية في جملة عربية قد يلتصق بالكلمة الإنجليزية ويظهر في المكان الخطأ. والحل لكل نص يأتي من المستخدم أو من البيانات هو العزل: عنصر <bdi> أو dir="auto" الذي يحدد الاتجاه من أول حرف قوي، أو في النصوص الخالصة علامات العزل في Unicode مثل FSI وPDI. ونفس المشكلة في حقول الإدخال: حقل البريد والرابط ورقم الهاتف يكون dir="ltr" حتى في الصفحة العربية.

البحث العربي يحتاج تطبيعاً على الجهتين، في النص المحفوظ وفي الاستعلام: توحيد أشكال الألف (أ إ آ إلى ا)، والتاء المربوطة والهاء في نهاية الكلمة، والياء والألف المقصورة، وحذف التشكيل والتطويل (ـ)، مع حفظ النص الأصلي للعرض. ولا أفعل ذلك في الواجهة وحدها، لأن البحث الحقيقي في ال Backend أو محرك البحث. وفي الواجهة نفسها أنتبه لعد الأحرف: "مرحباً".length يعد التنوين حرفاً، والرمز التعبيري قد يأخذ وحدتين، فحد «280 حرفاً» يحتاج Intl.Segmenter ليعد ما يراه المستخدم.

عنصر <button> يعطي مجاناً: الوصول بزر Tab، والتفعيل بـ Enter والمسافة، والدور الصحيح لقارئ الشاشة، وحالة disabled، والإرسال داخل النماذج. وdiv مع role="button" يعطي الدور فقط، وعليك أن تضيف tabindex="0" ومعالج لوحة المفاتيح بنفسك، وسوف تنسى شيئاً. والقاعدة الأولى في ARIA أن العنصر الأصلي أفضل من أي ARIA. وأختبر بنفسي: أترك الفأرة وأتنقل في الصفحة بلوحة المفاتيح، ثم أشغل قارئ شاشة مثل NVDA أو VoiceOver.

الاسم «حذف» وحده لا يكفي في جدول فيه خمسون زر حذف، فمستخدم قارئ الشاشة يتنقل بين الأزرار ويسمع «حذف، حذف، حذف»، لذلك الاسم يجب أن يحدد الصف: «حذف فاتورة 1042»، إما بـ aria-label كاملة أو بـ aria-labelledby يشير إلى خلية الرقم. وللحقول <label for> مرتبطة، وليس placeholder لأنه يختفي عند الكتابة، والأخطاء مربوطة بالحقل بـ aria-describedby. وتسمية الأيقونة باللغة الصحيحة تحتاج lang صحيحاً على الصفحة حتى يقرأها القارئ بالصوت العربي.

عند الفتح ينتقل التركيز إلى النافذة (أول عنصر تفاعلي أو عنوانها)، ويبقى محصوراً داخلها فلا يخرج Tab إلى الصفحة خلفها، والصفحة خلفها تصبح غير متاحة بـ inert، وEscape يغلقها. وعند الإغلاق يعود التركيز إلى الزر الذي فتحها، وإلا وجد مستخدم لوحة المفاتيح نفسه في أعلى الصفحة. وعنصر <dialog> مع showModal() يفعل أغلب هذا تلقائياً اليوم. وفي تطبيقات الصفحة الواحدة SPA نفس المشكلة عند تغيير الصفحة: التركيز يجب أن ينتقل إلى عنوان الصفحة الجديدة ويعلن تغييرها.

بيانات ال API ليست حالتنا، وإنما نسخة من حالة السيرفر قد تكون قديمة، وتحتاج: كاشاً بمفتاح، وإعادة الجلب عند العودة للتبويب، وإلغاء الطلبات القديمة، وحالات التحميل والخطأ، ومنع الطلب المكرر من عدة مكونات، والإبطال بعد التعديل. وكتابة هذا يدوياً في مخزن عام تعيد اختراع مكتبة مثل TanStack Query أو SWR. لذلك أفصل: حالة السيرفر في مكتبة كاش، وحالة الواجهة (القائمة مفتوحة، والتبويب المختار) محلية في المكون أو في الرابط URL، والمخزن العام يبقى صغيراً لما هو عام فعلاً مثل المستخدم الحالي.

عندما تحفظ items وtotal معاً فقد صنعت مصدرين للحقيقة، وكل تعديل على items يجب أن يتذكر تحديث total، ويوماً ما ينساه أحد. والحساب عند العرض صحيح دائماً، وإذا كان مكلفاً فعلاً أحفظ نتيجته Memoization مرتبطة بمدخلاته وليس في الحالة. ونفس القاعدة مع نسخ ال Props إلى حالة محلية في المكون: نسخة لا تتحدث عندما يتغير ال Prop، وهو خطأ شائع جداً.

الحقل المتحكم به يحفظ قيمته في حالة المكون، فكل حرف يحدث الحالة ويعيد رسم المكون الذي يملكها، وإذا كانت الحالة في أعلى النموذج فكل الحقول ترسم مع كل حرف. والحلول: حقول حرة يقرؤها النموذج عند الإرسال (FormData، وهذا ما تفعله مكتبات مثل React Hook Form)، أو نقل الحالة إلى أقرب مكون يحتاجها، أو التحقق عند مغادرة الحقل بدلاً من كل حرف. والتحقق في الواجهة للراحة فقط، فال Backend يتحقق من كل شيء مرة أخرى.

الإطار يقارن الرسم الجديد بالقديم ويطابق العناصر بالمفتاح، فإذا كان المفتاح رقم الموقع وحذفت العنصر الأول، فالعنصر الذي كان ثانياً يأخذ مفتاح الأول ويرث حالته الداخلية: نص مكتوب في حقل، أو مربع محدد، أو تركيز. وهذا خطأ صامت يظهر للمستخدم كبيانات في الصف الخطأ. والمفتاح الصحيح معرف ثابت من البيانات. والمفتاح أيضاً أداة: تغييره عمداً يجبر الإطار على إنشاء المكون من جديد وتصفير حالته، مثل نموذج تعديل عند الانتقال من مستخدم لآخر.

التأثير لمزامنة المكون مع نظام خارجي (اشتراك، أو مؤقت، أو مكتبة خرائط)، أما حساب قيمة من الحالة أو الاستجابة لنقرة فمكانه أثناء الرسم أو في معالج الحدث. والحلقة تحدث عندما يغير التأثير قيمة هو يعتمد عليها، أو عندما يعتمد على كائن أو دالة تنشأ من جديد مع كل رسم فتختلف مرجعياً كل مرة. وكل تأثير يشترك في شيء يحتاج دالة تنظيف، وإلا تراكمت الاشتراكات، وجلب البيانات في التأثير يحتاج إلغاء الطلب القديم، وإلا وصلت النتيجة القديمة بعد الجديدة (التمرين العملي الثالث).

أقيس أولاً بأداة Profiler الخاصة بالإطار لأرى أي مكون يرسم ولماذا وكم يأخذ، لأن إعادة الرسم الرخيصة ليست مشكلة. والأسباب الشائعة: حالة موضوعة أعلى من اللازم فتعيد رسم شجرة كبيرة، وسياق Context يتغير قيمته مع كل رسم فيعيد رسم كل مستهلكيه، وقائمة طويلة ترسم كل عناصرها. والحلول بالترتيب: نقل الحالة إلى الأسفل، وتقسيم السياق، والقوائم الافتراضية Virtualization للقوائم الطويلة، ثم memo في المكان الذي أثبت القياس أنه يفيد، مع ملاحظة أن memo لا يفيد إذا كانت ال Props كائنات جديدة في كل رسم.

بحسب موقع web.dev: LCP زمن ظهور أكبر عنصر في الشاشة الأولى والجيد 2.5 ثانية أو أقل، وINP أطول زمن من التفاعل إلى الرسم التالي خلال زيارة الصفحة والجيد 200 ملي ثانية أو أقل، وCLS مجموع الإزاحات غير المتوقعة والجيد 0.1 أو أقل، والقياس عند النسبة المئوية 75 من زيارات المستخدمين الحقيقيين على الجوال والحاسب كل على حدة. والمهم أن أرقام Lighthouse على جهازي قياس مختبر، أما الحكم فبيانات المستخدمين الحقيقيين RUM، وجهاز المستخدم المتوسط عندنا هاتف متوسط وليس حاسباً حديثاً.

أختار الصيغة (AVIF أو WebP مع بديل)، وأرسل حجماً يناسب الشاشة بـ srcset وsizes حتى لا يحمل الهاتف صورة بعرض 3000 بكسل، وأكتب width وheight لحجز المساحة. وloading="lazy" للصور تحت الشاشة الأولى فقط، أما صورة LCP في أعلى الصفحة فالتحميل الكسول يؤخرها، والصحيح أن أعطيها fetchpriority="high". وأقدمها من CDN بكاش طويل واسم فيه الهاش.

أبدأ بأداة تحليل الحزمة لأرى ما بداخلها، وغالباً أجد مكتبة كاملة استوردت لأجل دالة واحدة (مكتبة تواريخ بكل لغاتها، أو مكتبة أيقونات كاملة)، أو نفس المكتبة بإصدارين. ثم أقسم الكود حسب الصفحة بالاستيراد الديناميكي import() حتى لا تحمل صفحة الدخول كود لوحة التحكم، وأؤجل ما لا يلزم للتفاعل الأول (المحرر، والخرائط، والرسوم البيانية). ولاحظ أن الحجم المضغوط على الشبكة ليس هو التكلفة كلها: 2 ميجابايت غير مضغوطة يجب أن يحللها الهاتف وينفذها، وهذا وقت معالج على الخيط الرئيسي.

السيناريو الشائع: صفحة HTML قديمة في الكاش تطلب app.3f9a.js الذي حذف من السيرفر بعد النشر، أو صفحة مفتوحة منذ ساعات تحمل جزءاً ديناميكياً Chunk لم يعد موجوداً. والحل: HTML بكاش قصير أو no-cache، والملفات الثابتة بأسماء فيها الهاش وكاش طويل، وإبقاء ملفات الإصدار السابق فترة بعد النشر، ومعالجة فشل تحميل الجزء الديناميكي بإعادة تحميل الصفحة مرة واحدة. ومع Service Worker انتبه أكثر، لأنه قد يقدم النسخة القديمة لأيام.

الإطار يهرب النص في المحتوى والسمات العادية، ولكنه لا يحميك في: HTML الخام (dangerouslySetInnerHTML وv-html وinnerHTML)، وروابط href تبدأ بـ javascript: من بيانات المستخدم، وeval ومشتقاته، وقوالب الخادم التي تحقن بيانات داخل <script>، والمكتبات الخارجية التي تعدل ال DOM. وعندما أحتاج HTML من المستخدم (محرر نصوص) أنظفه بمكتبة مثل DOMPurify، وأضيف CSP كطبقة ثانية تمنع تنفيذ السكربتات الغريبة حتى لو نجح الحقن.

قائمة النطاقات المسموحة يتجاوزها المهاجم غالباً إذا كان فيها CDN عام، لذلك الأفضل سياسة مبنية على Nonce أو Hash مع strict-dynamic، وتمنع unsafe-inline وunsafe-eval. وللتطبيق القائم أبدأ بـ Content-Security-Policy-Report-Only مع جمع التقارير لأسابيع، فأرى ما سينكسر (سكربتات داخلية، ومعالجات onclick في HTML، وأدوات التحليل) وأصلحه، ثم أفعل السياسة. وأضيف frame-ancestors لمنع تضمين الصفحة في إطار Clickjacking، وobject-src 'none' وbase-uri.

المتصفح يمنع سكربت موقع من قراءة رد موقع آخر إلا إذا سمح السيرفر بترويسات CORS، وهذا يحمي المستخدم وليس السيرفر، لأن curl أو أي سيرفر يرسل الطلب ويقرأ الرد دون أي قيد. وطلب DELETE أو JSON يمر بطلب تمهيدي Preflight بـ OPTIONS، أما النموذج البسيط فيصل للسيرفر دون أي سؤال، لذلك CORS ليس حماية من CSRF. والخطأ الخطير هو أن يعكس السيرفر أي Origin يأتيه مع Access-Control-Allow-Credentials: true، فيستطيع أي موقع قراءة بيانات المستخدم المسجل.

الكوكيز ترسل مع كل طلب للسيرفر، فهي للجلسة فقط وحجمها صغير. وlocalStorage متزامن يحجب الخيط الرئيسي، ويحفظ نصوصاً فقط، ويقرأه أي سكربت في الصفحة، لذلك للتفضيلات الصغيرة غير الحساسة. وIndexedDB غير متزامن، ويحفظ كائنات وملفات بأحجام كبيرة، ويعمل من Web Worker، فهو للتطبيقات التي تعمل دون اتصال. وكل التخزين قد يمسح: المستخدم يمسح البيانات، والمتصفح يمسح عند امتلاء المساحة، وSafari يمسح بيانات المواقع التي لم يزرها المستخدم مدة، لذلك لا يكون المتصفح المكان الوحيد لبيانات مهمة.

Service Worker يعترض الطلبات ويقدم الملفات من الكاش (الواجهة)، والبيانات في IndexedDB، والتعديلات التي تحدث دون اتصال تحفظ في طابور محلي يرسل عند عودة الاتصال، مع مفتاح Idempotency لكل تعديل حتى لا يتكرر. والصعب ليس العرض وإنما التعارض: المستخدم عدل نفس السجل من جهازين، فمن يفوز؟ هنا أحتاج رقم إصدار لكل سجل والسيرفر يرفض التعديل المبني على إصدار قديم، وواجهة تعرض التعارض. وهذا موضوع التمرين الثالث في مقال أسئلة الجوال.

أختبر ما يراه المستخدم ويفعله: أبحث عن العناصر بدورها واسمها (getByRole('button', { name: 'حفظ' })) وليس بأسماء ال Classes، وأضغط وأكتب كما يفعل المستخدم، وأتحقق من النتيجة الظاهرة. وهذا يجعل الاختبار يصمد أمام إعادة الهيكلة، ويختبر سهولة الوصول كأثر جانبي، لأن الزر الذي لا يجده الاختبار بدوره لا يجده قارئ الشاشة أيضاً. ولا أختبر الحالة الداخلية أو عدد مرات الرسم، وأحاكي الشبكة على مستوى الطلب (Mock Service Worker مثلاً) وليس دوال الجلب.

الانتظار الثابت waitForTimeout(2000) هو أول سبب، والصحيح انتظار حالة (ظهور عنصر، أو انتهاء طلب) وهذا ما تفعله أدوات مثل Playwright تلقائياً مع ال Locators. ثم البيانات المشتركة بين الاختبارات (اختبار يحذف ما يحتاجه آخر)، والاعتماد على الترتيب، والحركات Animations، والخطوط والمنطقة الزمنية واللغة المختلفة في CI، والخدمات الخارجية الحقيقية. وأحفظ التتبع Trace والفيديو عند الفشل لأرى ما حدث بدلاً من التخمين، وأجعل كل اختبار ينشئ بياناته.

اختبار لقطات الشاشة Visual Regression يقارن الصفحة بلقطة معتمدة ويفشل عند الفرق، وأشغله على الاتجاهين وعدة عروض شاشة، مع تثبيت ما يتغير بطبيعته (التواريخ، والبيانات العشوائية، والحركات، والخطوط المحملة) حتى لا يصبح الاختبار ضجيجاً. وهو مكلف في الصيانة، لذلك أضعه على المكونات الأساسية في نظام التصميم وعلى صفحات قليلة مهمة، وليس على كل شيء. ومع الواجهة العربية أختبر نصوصاً طويلة حقيقية، لأن العربية قد تكون أطول أو أقصر من الإنجليزية وتكسر الأزرار.

تبدأ من نقطة الدخول وتبني شجرة الاستيراد، وتحول ما لا يفهمه المتصفح (TypeScript وJSX وأحدث صيغ اللغة إذا لزم)، وتحذف الكود غير المستخدم Tree Shaking، وتقسم الناتج إلى أجزاء، وتصغره، وتضيف الهاش إلى أسماء الملفات، وتنتج Source Maps. وفي وضع التطوير تعمل أدوات مثل Vite بطريقة مختلفة: تقدم الملفات كوحدات ES Modules مباشرة دون تجميع، وتستخدم esbuild للتحويل السريع، ثم تجمع للإنتاج. ومعرفة هذا تفسر أخطاء مثل «يعمل في التطوير ويفشل في الإنتاج».

أثبت الإصدارات بملف القفل Lockfile وأستخدم npm ci في CI، وأفحص الثغرات المعروفة SCA مع فهم أن أغلب التنبيهات في حزم التطوير لا تصل للمتصفح، وأحدث بانتظام بأداة مثل Renovate بدفعات صغيرة. وأخاف أكثر من الحزم الضارة: اسم قريب من حزمة مشهورة Typosquatting، وسكربتات postinstall التي تعمل على جهاز المطور وفي CI بكل صلاحياتها، وحساب صيانة مخترق ينشر إصداراً خبيثاً. وقبل إضافة حزمة أسأل: هل أحتاجها فعلاً، ومن يصونها، وكم حزمة تجلب معها؟

أختار لكل صفحة وليس للتطبيق كله: التوليد المسبق SSG للمحتوى الذي يتغير قليلاً (المدونة، والتوثيق) لأنه HTML جاهز من CDN، والعرض على السيرفر SSR للصفحات العامة التي تتغير لكل طلب أو مستخدم ويهمها أول عرض ومحركات البحث، والعرض في المتصفح CSR للوحات التحكم خلف تسجيل الدخول حيث لا يهم محرك البحث. وSSR ليس مجانياً: سيرفر يجب تشغيله وتوسيعه، وزمن أول بايت يعتمد على أبطأ طلب بيانات، وال Hydration تكلف وقتاً على الهاتف، لذلك ظهرت أساليب مثل التحديث التدريجي ISR وال Streaming ومكونات السيرفر.

الإطار يتوقع أن يطابق أول رسم في المتصفح HTML الذي أرسله السيرفر، فيربط الأحداث به بدلاً من بنائه، وأي اختلاف يجعله يرمي جزءاً ويعيد رسمه أو يترك الصفحة غير متسقة. والأسباب الشائعة: التاريخ والوقت (السيرفر في UTC والمتصفح في الرياض، وهذا يكثر عندنا)، والقيم العشوائية والمعرفات المولدة، والقراءة من window أو localStorage أثناء الرسم، وتنسيق الأرقام بلغة مختلفة (toLocaleString بين بيئتين)، وHTML غير صالح يصلحه المتصفح مثل div داخل p. والحل أن يكون أول رسم حتمياً، والقيم الخاصة بالمتصفح تعرض بعد التحميل.

الرموز قرارات التصميم بأسماء ثابتة، وأفضلها بطبقتين: رموز أولية (blue-600) ورموز بمعنى (color-action-primary)، والمكونات تستخدم ذات المعنى فقط، فيصبح الوضع الليلي أو علامة تجارية ثانية تغييراً في طبقة الربط لا في كل مكون. وتصدر من مصدر واحد إلى CSS Custom Properties وإلى تطبيقات الجوال، فيبقى اللون نفسه في المنصات كلها. ومع العربية أضيف رموزاً للطباعة خاصة بها: حجم الخط العربي غالباً يحتاج أكبر قليلاً، وارتفاع السطر أكبر للحروف والتشكيل.

مكون مشترك واجهته عقد مثل أي API: أقل عدد من الخيارات بأسماء معنى (variant="danger" وليس color="red")، ويقبل كل سمات العنصر الأصلي ويمررها، ويدعم ref، ويظهر كرابط عندما يحتاج التنقل (Polymorphic أو asChild) دون أن يصبح div. وسهولة الوصول مبنية فيه (التركيز الظاهر، وحالة التحميل مع aria-busy، والأيقونة دون نص تحتاج اسماً إلزامياً). ولكل تغيير كاسر إصدار رئيسي ودليل ترحيل، لأن عشرين فريقاً لن يحدثوا في نفس اليوم. وكل خيار يطلبه فريق واحد أسأل عنه: هل هو نمط عام أم استثناء يبقى عند الفريق؟

أكرر عملية واحدة (فتح صفحة وإغلاقها عشر مرات) ثم آخذ لقطة Heap Snapshot قبل وبعد وأقارن، وأبحث عن الكائنات التي يزيد عددها مع كل تكرار، وخاصة عناصر DOM المنفصلة Detached التي حذفت من الصفحة وما زال كود يحتفظ بها. والأسباب الشائعة: مستمع حدث على window لم يزل عند إزالة المكون، ومؤقت setInterval لم يوقف، واشتراك في مخزن أو WebSocket دون تنظيف، وكاش في متغير عام يكبر دون حد. وأتأكد من الإصلاح بنفس التجربة.

أرتب حسب الوقت وأفتح الطلب البطيء وأقرأ التوقيت: إذا كان الوقت في انتظار أول بايت TTFB فالسيرفر بطيء، وإذا كان في التنزيل فالحجم كبير، وإذا كان في الطابور Queueing فالمتصفح ينتظر اتصالاً متاحاً. وأنظر إلى الشلال كاملاً: طلبات متتابعة كل واحد ينتظر الذي قبله (الصفحة تجلب المستخدم ثم إعداداته ثم بياناته) هي غالباً المشكلة الأكبر، والحل جلبها بالتوازي أو في طلب واحد. وأفعل تقليل سرعة الشبكة والمعالج لأرى ما يراه مستخدم بهاتف متوسط.

أفتحه بلوحة المفاتيح وحدها وبقارئ الشاشة، لأن الكود المولد كثيراً ما يصنع أزراراً من div ويهمل التسميات، ثم بالعربية واتجاه RTL ونص طويل، ثم بحالات الشبكة: تحميل بطيء وخطأ واستجابة فارغة وطلبات متداخلة. وأبحث عن innerHTML مع بيانات المستخدم، وعن تأثيرات دون تنظيف، وعن مكتبات أضافتها الأداة لشيء بسيط. والقاعدة أنني لا أدمج ما لا أستطيع شرح كل سطر فيه.

والمخرج في Node.js وفي Chromium (شغلنا نفس الملف في الاثنين عبر Playwright) كان متطابقاً:

1 start
6 async body
10 end
3 then A
5 microtask
7 after await
4 then B
2 timeout 0
8 timeout 2
9 then inside timeout

في المخرج أعلاه لاحظ التالي:

• السكربت نفسه مهمة واحدة، فكل الكود المتزامن ينفذ أولاً: السطر 1، ثم جسم الدالة غير المتزامنة حتى أول await (السطر 6، وهذا ما يفوته كثيرون لأنهم يظنون أن الدالة async كلها تؤجل)، ثم السطر 10.
• بعد انتهاء المهمة تفرغ المهام الصغرى بترتيب دخولها: then A ثم microtask ثم ما بعد await (السطر 7)، ثم then B لأنها لم تدخل الطابور إلا بعد أن نفذت then A.
• بعد ذلك فقط تأتي المؤقتات كمهام منفصلة، وبعد المؤقت الأول (السطر 2) لا توجد مهام صغرى، وبعد المؤقت الثاني (السطر 8) تنفذ المهمة الصغرى التي أضافها (السطر 9) قبل أي مهمة أخرى.

والمرشح الخبير يضيف من نفسه: لو كانت سلسلة then لا تنتهي لما وصلنا إلى السطر 2 أبداً ولتجمدت الصفحة، وفي Node.js يأتي process.nextTick قبل وعود Promise، وترتيب setTimeout مع setImmediate في Node.js ليس مضموناً عندما يستدعيان من الكود الرئيسي. والمرجع في ذلك شرح MDN لحلقة الأحداث.

معالج النقرة يعمل على نفس الخيط الرئيسي الذي ينفذ work(1000)، والمتصفح لا يقطع مهمة JavaScript في منتصفها، فالنقرة التي حدثت بعد 100 ملي ثانية بقيت في الطابور حتى انتهت المهمة، أي 900 ملي ثانية تقريباً، والمستخدم يرى زراً ميتاً. وهذا وحده يجعل INP للصفحة سيئاً، لأن الحد الجيد 200 ملي ثانية بحسب web.dev.

وفي النسخة الثانية نفس العمل (100 قطعة في كل منها 10 ملي ثانية)، ولكن بين القطع يعطي الكود المتصفح فرصة بـ scheduler.yield()، فتدخل النقرة بين قطعتين وتنتظر 13 ملي ثانية فقط، ولا توجد مهمة أطول من 50 ملي ثانية. والفرق بين scheduler.yield() وsetTimeout أن الأول يعيد الكود إلى مقدمة الطابور بعد أن يأخذ المتصفح فرصته، فلا تسبقه مهام أخرى من الصفحة، كما تشرح مدونة Chrome للمطورين، والكود يرجع إلى setTimeout في المتصفحات التي لا تدعمه.

وفي النسخة الثالثة انتقل العمل إلى Web Worker يعمل على خيط آخر، فالخيط الرئيسي حر تماماً (1 ملي ثانية). وما لا تستطيعه هناك هو الوصول إلى ال DOM، فالعامل يحسب ويرسل النتيجة بـ postMessage والخيط الرئيسي يرسمها، ونقل بيانات كبيرة بين الخيطين له تكلفة نسخ أيضاً. والمرشح الخبير يسأل قبل كل ذلك: هل يجب أن يحدث هذا العمل في المتصفح أصلاً، أم يرسله السيرفر جاهزاً؟

الطلبات أرسلت بالترتيب a ثم ab ثم abc، ولكنها عادت بترتيب مختلف: abc بعد 40 ملي ثانية من إرساله، ثم a بعد 300، ثم ab بعد 280 من إرساله أي في النهاية، والنسخة الأولى ترسم كل رد يصل، فآخر رد وصل هو الذي بقي على الشاشة وهو ليس آخر ما كتبه المستخدم. وهذه حالة سباق Race Condition في الواجهة، لا تظهر على جهاز المطور حيث كل الردود سريعة ومتساوية.

والنسخة الثانية تلغي الطلب السابق بـ AbortController قبل أن ترسل الجديد، فلا يرسم إلا رد آخر طلب، ويتوقف أيضاً تنزيل ما لم يعد مطلوباً. وطريقة أخرى صحيحة أن تحفظ رقماً لكل طلب وتتجاهل أي رد ليس للرقم الأخير، وهذا ما تفعله مكتبات جلب البيانات تلقائياً بمفتاح الاستعلام.

والتأخير Debounce يقلل عدد الطلبات ولكنه لا يحل المشكلة، لأن المستخدم قد يتوقف 300 ملي ثانية بين حرفين فيرسل طلبين، ويعود الأول بعد الثاني. وفي React نفس الخطأ يحدث داخل useEffect الذي يجلب البيانات دون دالة تنظيف تلغي الطلب، وهذا ما يجعل التمرين صالحاً لكل أطر العمل.