كيف أبني بنية Frontend قابلة للتوسع

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

بهذا تبقى البنية مرتبطة بسلوك المنتج الحقيقي. نظام مشفى وشاشة لإدارة قضية ومساحة تحليل نص بالذكاء الاصطناعي قد تستخدم React كلها، لكنها لا تحمل المسؤوليات نفسها ولا يجب تنظيمها بالطريقة نفسها.

تحتفظ كل ميزة بالمكونات والـHooks والتحقق والأنواع والاستعلامات والتعديلات والحالة الخاصة بمسارها. هذا يقلل عدد الملفات غير المرتبطة التي يحتاج المطور إلى قراءتها قبل أي تعديل ويجعل مراجعة Pull Request أوضح.

لا أنقل الكود إلى مساحة مشتركة لمجرد أنه استُخدم مرتين. أبقي السلوك قريباً من الميزة أولاً، ثم أستخرجه عندما يثبت الاستخدام المتكرر أن العقد المشترك مستقر فعلاً.

لا يجب أن تعتمد الشاشات مباشرة على استجابات باكند غير موحدة. أستخدم API client مشتركاً وأنواعاً واضحة للطلبات والاستجابات ودوال لتوحيد البيانات والأخطاء، وبذلك تحصل الواجهة على حد ثابت حتى لو تغير Endpoint أو اختلف شكل البيانات بين خدمتين.

هذه الحدود تحسن التواصل مع فريق الباكند أيضاً؛ يصبح النقاش حول عقد محدد: حقول مطلوبة وقيم nullable وبيانات Pagination وأخطاء تحقق ونتيجة كل Mutation.

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

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

حتى البنية النظيفة تفشل إذا تجاهل الإصدار التجاوب والوصول والأداء والأجهزة الحقيقية. لذلك أجعل هذه المراجعات ضمن تعريف اكتمال الميزة قبل وصولها إلى الإنتاج.

الهدف ليس بنية مثالية لا تتغير، بل نظام تكون تكلفة التغيير فيه مفهومة والملكية واضحة ويستطيع المطور التالي إكماله من دون إعادة البناء من الصفر.