بناء برمجيات المؤسسات بـReact وTypeScript

تطبيق React الذي يُطلق MVP لديك ليس تطبيق React الذي يصمد بعد ثلاث سنوات من العمل على ميزات المؤسسات. الأنماط التي تُوصلك إلى الإطلاق — أنواع غير رسمية، حالة مُرتجَلة، مكوّنات مُكرَّرة — تُراكم تكلفة بهدوء. هذا ما تعلّمناه من المساهمة في صيانة أنظمة React مؤسسية عبر ارتباطات العملاء.

شكل المشكلة

تتشارك الواجهات المؤسسية سمات لا تتشاركها التطبيقات الاستهلاكية. فِرَق كثيرة تشحن في نفس قاعدة الكود. الميزات تعيش لسنوات. المستخدمون يشملون موظفين داخليين يعتمدون عليها يومياً وعملاء خارجيين يُصعّدون عند الانكسار. الامتثال وإمكانية الوصول ومتطلبات التدقيق ليست اختيارية. تكلفة الانحدار ليست تقييماً سيّئاً — بل حادثة.

هذا يُغيّر المشكلة الهندسية. أنت لا تُحسّن لسرعة الميزة الأولى؛ أنت تُحسّن للسرعة الدائمة للميزة المئة. الأنماط التي تشتري لك تلك المتانة ليست تلك التي تظهر في دروس الإطار.

TypeScript صارم، صارم فعلاً

تقريباً كل قاعدة كود React مؤسسية تدّعي استخدام TypeScript. أقلّ بكثير تستخدمه بصرامة. الفرق كبير.

قاعدة كود "TypeScript متساهلة" بها any مرشوش في استجابات API، حقول اختيارية تُعامَل كمطلوبة، ومكوّنات خصائصها مكتوبة كـRecord<string, unknown>. المُجمّع راكب فقط. عمليات إعادة الهيكلة تكسر أشياء كان على المُجمّع التقاطها. يُخمّن المهندسون الأنواع وينسخون فحوصات دفاعية تحسّباً.

قاعدة كود "TypeScript صارمة" بها strict: true في tsconfig، noUncheckedIndexedAccess مُفعَّل، فحص switch شامل، واستجابات API مُتحقَّق منها عند الحدّ (بـZod أو ما يماثله). المُجمّع طبقة اختبار حقيقية. عمليات إعادة الهيكلة تصبح آمنة. يستطيع المهندسون الجدد الاعتماد على الأنواع لتعلّم النظام.

التكلفة صغيرة مقدّماً والمردود سنوات. إذا كنت تبدأ قاعدة كود مؤسسية جديدة في 2026، لا يوجد سبب مدافع عنه لشحنها بـTypeScript مُرخّى.

طريقة واحدة لجلب البيانات

أكثر مصادر الخلل شيوعاً في تطبيقات React الكبيرة هو جلب البيانات بخمس طرق مختلفة عبر قاعدة الكود. بعض الصفحات يستخدم useEffect + fetch. بعضها يستخدم React Query. بعضها يستخدم هوكاً مخصصاً كتبه أحدهم قبل ثلاث سنوات. بعضها يُغيّر الحالة العامة مباشرة.

اختر نمطاً واحداً — نوصي عادةً بـReact Query (TanStack Query) أو RTK Query — واجعله الطريقة الوحيدة لجلب البيانات في التطبيق. اكتب الاتفاقيات: كيف تُبنى مفاتيح الذاكرة المؤقتة، كيف تُلغي الطفرات الاستعلامات، كيف تنتشر الأخطاء، كيف تُعرض حالات التحميل. النقطة ليست أنّ النمط صحيح بشكل فريد؛ بل أنّ التوحيد يُزيل فئة من الأخطاء.

نظام مكوّنات حقيقي يملكه فريق حقيقي

كل قاعدة كود مؤسسية تنمو في النهاية لتصنع مجلّد "components" ممتلئاً بقطع نصف مشتركة ونصف مكرّرة. النسخة الصادقة من هذا هي تسميته نظام مكوّنات، إعطاؤه ملكية، ومعاملته كمنتج بمستخدمين داخليين.

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

ميزانيات أداء مُنفَّذة في CI

انحدارات الأداء لا تحدث في قفزات كبيرة. تحدث ميزة واحدة في كل مرة. كل اعتمادية جديدة "بضع كيلوبايت فقط". كل صورة جديدة "مطلوبة للتصميم". كل صفحة جديدة "جيّدة". بعد ستة أشهر، التطبيق ضعف الثقل ولا أحد يستطيع التفسير.

العلاج هو ميزانيات أداء تُفشل البناء. حدّد عتبات لحجم الحزمة وLargest Contentful Paint وTime to Interactive. شغّل Lighthouse (أو المكافئ) على كل طلب دمج ضدّ الصفحات الحرجة. أفشل البناء عندما تُعبر العتبات.

الجزء الصعب ليس الأدوات — بل انضباط معاملة انحدارات الأداء كأخطاء. أول مرة تُفشل فيها PR لتجاوز 30 كيلوبايت، سيشتكي أحدهم. الإصلاح إمّا إزالة اعتمادية أو رفع الميزانية لسبب موثَّق. كلاهما جيّد. ما ليس جيّداً هو السماح للانحدار بالهبوط.

هرم اختبارات يطابق المخاطر

الفِرَق المؤسسية تفرط في اختبار مكوّناتها وتُقلّل من اختبار سير عملها. خمسون ألف اختبار snapshot لا تلتقط شيئاً مفيداً وتُبطئ كل تغيير. ثلاثة اختبارات شاملة لرحلات مستخدم حرجة تلتقط أخطاء حقيقية وتمنح الفريق الثقة للشحن.

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

المسارات كحدود

قواعد الكود المؤسسية تميل للنمو إلى حساء مكوّنات كبير. العلاج هو معاملة المسارات كحدود معمارية حقيقية. كل مسار يمتلك جلب بياناته، حالته، ومكوّناته. المشاركة عبر المسارات تحدث عبر مجموعة صغيرة من الواجهات الصريحة — متاجر مشتركة، مكوّنات مشتركة، أنواع مشتركة — لا عبر اقتران ضمني.

هجرة تدريجية، أبداً عمليات إعادة كتابة

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

ما يجب أن تكتبه

قواعد الكود المؤسسية تستفيد بشكل هائل من وثيقة قصيرة حقيقية تقول: كيف نجلب البيانات، كيف ندير الحالة، أين تذهب المكوّنات الجديدة، كيف نتعامل مع الأخطاء، كيف نختبر، ما هي ميزانيات أدائنا. ليس "دليل أسلوب" بمئات القواعد — قائمة قرارات، نصف صفحة. يقرأها كل مهندس جديد في أسبوعه الأول. تُحدَّث عندما تتغيّر القرارات فعلاً.

هذه الوثيقة هي أرخص قطعة أعلى رافعة يمكنك إنتاجها. تكلّف بعد ظهر. توفّر شهوراً من العمل غير المتّسق.

React المؤسسي ليس حقاً عن React. إنه عن الممارسات حوله — الأنواع، البيانات، المكوّنات، الأداء، الاختبار، الحدود، التوثيق — التي تسمح لقاعدة الكود بمواصلة النمو دون التوقّف. الفِرَق التي تنجح تُعامل هذه الممارسات كاستثمارات. التي تُعاني تعاملها كأعباء. كلتاهما تختار؛ أحد هذه الخيارات يتقدّم في العمر أفضل.