22 ديسمبر 2025·8 دقيقة
كيف أعاد React تشكيل هندسة الواجهة الأمامية عبر المكونات
شاع React نمط الواجهة القائم على المكونات، العرض التصريحي، ومشاهد مدفوعة بالحالة—مما حوّل الفرق من كود متمحور حول الصفحات إلى أنظمة وأنماط قابلة لإعادة الاستخدام.
شاع React نمط الواجهة القائم على المكونات، العرض التصريحي، ومشاهد مدفوعة بالحالة—مما حوّل الفرق من كود متمحور حول الصفحات إلى أنظمة وأنماط قابلة لإعادة الاستخدام.
لم تقدم React مكتبة جديدة فقط—بل غيّرت أيضًا معنى ما يقصده الفريق حين يتحدث عن "هندسة الواجهة الأمامية". عمليًا، هندسة الواجهة الأمامية هي مجموعة القرارات التي تحافظ على قابلية فهم قاعدة كود الواجهة على نطاق واسع: كيف تقسم الواجهة إلى أجزاء، كيف تنتقل البيانات بينها، أين تعيش الحالة، كيف تتعامل مع الآثار الجانبية (مثل جلب البيانات)، وكيف تحافظ على قابلية الاختبار والتناسق عبر الفريق.
تفكير المكونات هو التعامل مع كل قطعة من الواجهة كوحدة صغيرة قابلة لإعادة الاستخدام تملك طريقة العرض الخاصة بها ويمكن تركيبها مع وحدات أخرى لبناء صفحات كاملة.
قبل انتشار React، كان كثير من المشاريع منظَّمًا حول الصفحات والتلاعب بالـ DOM: "ابحث عن هذا العنصر، غيّر نصه، بدّل هذا الكلاس." دفعت React الفرق نحو افتراض مختلف:
غيّرت هذه الأفكار العمل اليومي. أصبحت مراجعات الكود تسأل "أين تنتمي هذه الحالة؟" بدلًا من "أي محدد استخدمته؟" وبدأ المصممون والمهندسون يتوافقون على مفردات مكونات مشتركة، ثمّ نشأت مكتبات من لبنات UI دون إعادة كتابة الصفحات كاملة.
حتى إن انتقل فريق لاحقًا إلى إطار آخر، تبقى عادات كثيرة متأثرة بـ React: بنية قائمة على المكونات، العرض التصريحي، تدفق بيانات متوقع، وتفضيل مكونات نظام التصميم القابلة لإعادة الاستخدام بدل كود صفحة لمرة واحدة. جعلت React هذه الأنماط تبدو مألوفة—وهذا أثر في منظومة الواجهة الأمامية الأوسع.
قبل React، بنى العديد من الفرق الواجهات حول الصفحات، لا حول وحدات واجهة قابلة لإعادة الاستخدام. كان الإعداد الشائع قوالب تُعرض من الخادم (PHP، Rails، Django، JSP، إلخ) تنتج HTML، مع القليل من jQuery فوقها للتفاعلية.
كنت تعرض صفحة، ثم "تنشّط"ها بسكربتات: منقحات تواريخ، نوافذ منبثقة، مُتحققات للنماذج، دوارات—لكل منها توقعاته من الـ markup ونقاط ربط الأحداث.
غالبًا كان الكود يبدو هكذا: جد عقدة DOM، أرفق معالجًا، غيّر DOM، وتأمَّل ألا ينهار شيء آخر. ومع نمو الواجهة، صار "مصدر الحقيقة" بصمت هو الـ DOM نفسه.
نادرًا ما عاش سلوك الواجهة في مكان واحد. كان موزعًا بين:
قد يُبنى ويدار عنصر واحد—مثل ملخص سلة الشراء—جزئيًا على الخادم، ويُحدَّث جزئيًا عبر AJAX، ويُتحكَّم به جزئيًا بمكوّن إضافي.
هذا النهج نجح في التحسينات الصغيرة، لكنه أنتج مشاكل متكررة:
حاولت أطر مثل Backbone وAngularJS وEmber إضفاء بنية عبر النماذج والعروض والتوجيه—غالبًا تحسّن كبير. لكن العديد من الفرق بقت تمزج أنماطًا، تاركة فراغًا لطريقة أبسط لبناء واجهات قابلة للتكرار.
أهم تحول لـ React سهل القول ومذهل القوة عمليًا: الواجهة هي دالة للحالة. بدل اعتبار الـ DOM "مصدر الحقيقة" ومزامنته يدويًا، تعامل مع بياناتك كمصدر الحقيقة ودع الواجهة تكون النتيجة.
الحالة هي فقط البيانات التي تعتمد عليها شاشتك الآن: هل القائمة مفتوحة، ماذا كُتب في حقل، أي عناصر في القائمة، أي فلتر مُحدد.
عندما تتغير الحالة، لا تبحث في الصفحة لتحدّث عدة عقد DOM. تحدّث الحالة، وتُعاد عملية العرض لتعكسها.
كود الـ DOM التقليدي كثيرًا ما ينتهي بمنطق تحديث مبعثر:
مع نموذج React، تصبح تلك "التحديثات" شروطًا في ناتج العرض. تتحول الشاشة إلى وصف قابل للقراءة لما يجب أن يكون مرئيًا لحالة معينة. هذا العائد المعماري: شكل البيانات وبنية الواجهة تتوافق، مما يجعل الشاشات أسهل للفهم والاختبار والتطوير.
function ShoppingList() {
const [items, setItems] = useState([]);
const [text, setText] = useState("");
const add = () => setItems([...items, text.trim()]).then(() => setText(""));
return (
<section>
<form onSubmit={(e) => { e.preventDefault(); add(); }}>
<input value={text} onChange={(e) => setText(e.target.value)} />
<button disabled={!text.trim()}>Add</button>
</form>
{items.length === 0 ? <p>No items yet.</p> : (
<ul>{items.map((x, i) => <li key={i}>{x}</li>)}</ul>
)}
</section>
);
}
لاحظ كيف رسالة الفراغ، حالة تعطيل الزر، ومحتويات القائمة كلها مُستنتجة من items وtext. هذه هي الفائدة المعمارية: شكل البيانات وبنية الواجهة متوافقة، مما يجعل الشاشات أسهل للفهم والاختبار والتطوير.
جعلت React "المكوّن" وحدة العمل الافتراضية للواجهة: قطعة صغيرة قابلة لإعادة الاستخدام تجمع الـ markup والسلوك ونقاط تنسيق الأنماط وراء واجهة واضحة.
بدل تشتت قوالب HTML ومعالجات الأحداث ومحددات CSS عبر ملفات متفرقة، يبقي المكوّن الأجزاء المتغيرة قريبة من بعضها. هذا لا يعني أن كل شيء يجب أن يعيش في ملف واحد—لكن يعني أن الكود منظّم حول ما يراه المستخدم ويفعله، لا حول واجهة برمجة الـ DOM.
عادةً يتضمّن مكوّن عمليًا:
التحول المهم هو أنك تتوقف عن التفكير بـ "حدّث هذا div" وتبدأ التفكير بـ "اعرض الزر في حالته المعطلة".
عندما يكشف المكوّن مجموعة صغيرة من props (مدخلات) والأحداث/ردود النداء (مخرجات)، يصبح تغييره داخليًا أسهل دون كسر بقية التطبيق. يمكن للفرق امتلاك مكونات أو مجلدات محددة (مثل "واجهة الدفع") وتحسينها بثقة.
يقلّل التغليف أيضًا الاقتران العرضي: أقل محددات عالمية، أقل آثار جانبية عبر الملفات، أقل مفاجآت "لماذا توقّف هذا معالج النقر عن العمل؟".
بمجرد أن تصبح المكونات وحدات البناء الأساسية، بدأ الكود يعكس المنتج:
يجعل هذا المطالعات المتعلقة بالواجهة أسهل: يمكن للمصممين ومديري المنتجات والمهندسين التحدث عن نفس "الأشياء".
دفع تفكير المكونات العديد من قواعد الكود نحو تنظيم قائم على الميزة أو المجال (مثال: /checkout/components/CheckoutForm) ومكتبات UI مشتركة (غالبًا /ui/Button). هذا الهيكل يتوسع أفضل من مجلدات تعتمد على الصفحات فقط عندما تنمو الميزات، ويهيئ الطريق لأنظمة التصميم لاحقًا.
يوصف أسلوب عرض React غالبًا بأنه تصريحي، بمعنى: تصف كيف يجب أن تبدو الواجهة في حالة معينة، وReact تعرف كيف تجعل المتصفح يطابق ذلك.
في نهج DOM الأقدم، كتب عادةً تعليمات خطوة بخطوة:
مع العرض التصريحي، تعبّر بدلًا عن النتيجة:
إذا كان المستخدم مسجّلًا أظهر اسمه. وإن لم يكن، أظهر زر "تسجيل الدخول".
هذا التغيير مهم لأنه يقلل مقدار "إدارة واجهة المستخدم" التي تحتاج إليها. لا تتعقب باستمرار أي عناصر موجودة وما يحتاج للتحديث—تركّز على الحالات التي يمكن أن يكون فيها تطبيقك.
JSX هو في الأساس طريقة مريحة لكتابة بنية الواجهة قريبة من المنطق الذي يتحكم بها. بدل فصل "ملفات القوالب" عن "ملفات المنطق" والتنقل بينهما، يمكنك إبقاء القطع المرتبطة معًا: البنية المشابهة للـ markup، الشروط، قرارات التنسيق الصغيرة، ومعالجات الأحداث.
هذا التلازم سبب كبير لسبب شعور نموذج React بأنه عملي. المكوّن ليس مجرد جزء HTML أو حزمة جافاسكريبت—إنه وحدة سلوك واجهة.
قلق شائع أن JSX يمزج HTML وJavaScript، ويبدو كخطوة للخلف. لكن JSX ليس HTML حقًا—إنه تركيب ينتج استدعاءات جافاسكريبت. والأهم أن React لا تمزج التقنيات بقدر ما تجمع الأشياء التي تتغير معًا.
عندما يكون المنطق وبنية الواجهة مرتبطين بشدة (مثال: "أظهر رسالة خطأ فقط عندما يفشل التحقق"), إبقاؤهما في مكان واحد يمكن أن يكون أوضح من نشر القواعد عبر ملفات منفصلة.
جعل JSX React قابلة للوصول، لكن المفهوم الأعمق يمتد إلى ما هو أبعد من JSX. يمكنك كتابة React بدون JSX، وأطر أخرى أيضًا تستخدم العرض التصريحي بصيغ قوالب مختلفة.
التأثير الدائم هو العقلية: تعامل مع الواجهة كدالة للحالة ودع الإطار يتكفل بآليات مزامنة الشاشة.
قبل React، كان مصدر شائع للأخطاء بسيطًا: تغيّرت البيانات لكن الواجهة لم تُحدَّث. كان المطورون يجلبون بيانات جديدة، ثم يجدون عقد DOM الصحيحة يدويًا، يحدّثون النصوص، يبدِّلون الكلاسات، يضيفون/يزيلون عناصر، ويحافظون على كل ذلك عبر حواف الحالات. مع الوقت، غالبًا كان منطق "التحديث" أكثر تعقيدًا من الواجهة نفسها.
تحول سير العمل الكبير في React أنك لا تُعطي المتصفح تعليمات كيفية تغيير الصفحة. تصف كيف يجب أن تبدو الواجهة لحالة معينة، وReact تعرف كيف تحدّث الـ DOM الحقيقي ليتطابق.
المصالحة هي عملية React لمقارنة ما عرضته في المرة السابقة بما تعرضه الآن، ثم تطبيق أدنى مجموعة من التغييرات على DOM المتصفح.
الجزء المهم ليس أن React تستخدم "DOM افتراضي" كخدعة أداء، بل أنها تمنحك نموذجًا متوقعًا:
تلك القابلية للتوقع تحسّن سير عمل المطور: تحديثات أقل يدوية للـ DOM، حالات أقل غير متناسقة، وتحديثات واجهة تتبع نفس القواعد في كل التطبيق.
عند عرض قوائم، تحتاج React طريقة ثابتة لمطابقة "العناصر القديمة" مع "العناصر الجديدة" أثناء المصالحة. هذا ما تفعله key.
{todos.map(todo => (
<TodoItem key={todo.id} todo={todo} />
))}
استخدم مفاتيح مستقرة وفريدة (مثل ID). تجنّب فهارس المصفوفة عندما يمكن إعادة ترتيب أو إدراج أو حذف العناصر—إلا فقد تعيد React استخدام مثيل مكوّن خاطئ، مما يقود لسلوك واجهة مفاجئ (مثل إدخالات تحتفظ بقيمة خاطئة).
أحد أكبر التحولات المعمارية في React هو أن البيانات تتدفّق في اتجاه واحد: من المكوّنات الأبوية إلى الأبناء. بدل السماح لأي جزء من الواجهة بـ"الوصول" إلى أجزاء أخرى وتغيير الحالة المشتركة، تشجّع React على اعتبار التحديثات كأحداث صريحة تصعد للأعلى، بينما تنتقل البيانات الناتجة للأسفل.
الوالد يملك الحالة، ويمرّرها للطفل كـ props. يمكن للطفل طلب تغيير عن طريق استدعاء callback.
function Parent() {
const [count, setCount] = React.useState(0);
return (
<Counter
value={count}
onIncrement={() => setCount(c => c + 1)}
/>
);
}
function Counter({ value, onIncrement }) {
return (
<button onClick={onIncrement}>
Clicks: {value}
</button>
);
}
لاحظ ما لا يحدث: الـ Counter لا يغيّر count مباشرة. يستقبل value (البيانات) وonIncrement (طريقة لطلب التغيير). هذا الانفصال هو جوهر النموذج الذهني.
يجعل هذا النمط الحدود واضحة: "من يملك هذه البيانات؟" تُجاب غالبًا بـ "أقرب أب مشترك." عندما يتغير شيء بشكل غير متوقع، تتبعه إلى المكان الذي تعيش فيه الحالة—ليس عبر شبكة من التعديلات المخفية.
يساعد هذا التمييز الفرق على تقرير أين يذهب المنطق ويمنع الاقتران العرضي.
المكونات التي تعتمد على props أسهل في إعادة الاستخدام لأنها لا تعتمد على متغيرات عالمية أو استعلامات DOM. كما أنها أبسط للاختبار: يمكنك عرضها بprops محددة وتأكيد الناتج، بينما يُختبر سلوك الحالة في المكان الذي تُدار فيه الحالة.
دفعت React الفرق بعيدًا عن "شجرات الكلاسات" نحو تجميع الشاشات من قطع صغيرة ومركزة. بدل تمديد Button أساسي إلى عشر نسخ، عادةً ما تُركّب السلوك والمظهر بدمج مكونات.
نمط شائع هو بناء مكوّنات تخطيط لا تعرف شيئًا عن البيانات التي ستحتويها:
PageShell للرأس/الشريط الجانبي/التذييلStack / Grid للتباعد والمحاذاةCard لتأطير متسقتقبل هذه المكونات children حتى تقرر الصفحة ما الموضوع داخله، لا التخطيط. سترى أيضًا أغلفة خفيفة مثل RequireAuth أو ErrorBoundary التي تضيف قلقًا حول ما تلتف به دون تغيير داخلياته.
عندما تحتاج سيطرة أكثر من "فقط children"، كثيرًا ما يستخدم الفرق نهجًا شبيهاً بالمنافذ عبر props:
Modal بعناصر title, footer, وchildrenTable مع renderRow أو emptyStateهذا يبقي المكونات مرنة دون تفجير واجهات برمجة التطبيقات.
تبدأ أشجار الوراثة العميقة بنوايا حسنة ("سنُعيد استخدام الكلاس الأساسي"), لكنها تصبح صعبة الإدارة لأن:
جعلت hooks التركيب أكثر عملية. hook مخصص مثل useDebouncedValue أو usePermissions يسمح لعدة مكونات مشاركة المنطق دون مشاركة الواجهة. اقتران ذلك مع بدائيات UI مشتركة (أزرار، مدخلات، طباعات) ومكونات ميزة (CheckoutSummary, InviteUserForm) يمنحك إعادة استخدام تبقى مفهومة مع نمو التطبيق.
جعلت React البدء بحالة مكوّن محلية طبيعيًا: قيمة حقل، قائمة منبثقة مفتوحة، مروحة تحميل. هذا يعمل جيدًا—حتى يتوسع التطبيق وتحتاج أجزاء متعددة من الواجهة إلى التزامن.
مع توسع الميزات، تحتاج الحالة في كثير من الأحيان أن تُقرأ أو تُعدَّل من مكونات ليست في علاقة أب/ابن مباشرة. "مرّر props" يتحول إلى سلاسل طويلة من props عبر مكونات لا تهتم فعليًا بالبيانات. هذا يجعل إعادة الهيكلة أخطر، ويزيد الحشو، ويمكن أن يؤدي إلى أخطاء حيث يبدو مكانان مختلفان أنهما يمثلان نفس الحالة.
1) رفع الحالة
انقل الحالة إلى أقرب أب مشترك ومرّرها كـ props. هذا غالبًا الحل الأبسط ويجعل التبعيات صريحة، لكنه قد ينشئ "مكونات إله" إن أسرفت في استخدامه.
2) Context للهموم العابرة
React Context مفيد عندما يحتاج العديد من المكونات لنفس القيمة (الثيم، اللغة، المستخدم الحالي). يقلل ذلك حفر الـ props، لكن إن خزّنت بيانات متغيرة كثيرًا في الـ Context، قد يصبح تتبع التحديثات والأداء أصعب.
3) متاجر خارجية
مع نمو تطبيقات React، استجاب النظام البيئي بمكتبات مثل Redux وأنماط متاجر مشابهة. تُركّز هذه على مركزية تحديثات الحالة، غالبًا مع قواعد حول الأكشنات والـ selectors، ما يمكن أن يحسن التوقعية على نطاق واسع.
فضّل الحالة المحلية بشكل افتراضي، ارفع الحالة عندما يحتاج الأشقاء للتنسيق، استخدم Context للهموم العابرة، وفكّر في متجر خارجي عندما تعتمد مكونات بعيدة كثيرة على نفس البيانات وتحتاج قواعد أوضح للتحديث. الاختيار "الصحيح" يعتمد أقل على الصيحات وأكثر على تعقيد التطبيق وحجم الفريق وتكرار التغيرات.
لم تُدخل React فقط طريقة جديدة لكتابة الواجهة—بل دفعت الفرق نحو سير عمل قائم على المكونات حيث يُطوَّر الكود والتصميم والسلوك كوحدات صغيرة قابلة للاختبار. هذا التحول أثر على كيفية بناء مشاريع الواجهة، التحقق منها، توثيقها، وشحنها.
عندما تتكون الواجهة من مكونات، يصبح طبيعيًا العمل "من الحواف إلى الداخل": ابنِ زرًا، ثم نموذجًا، ثم صفحة. بدأت الفرق تعامل المكونات كمنتجات بواجهات واضحة (props)، حالات متوقعة (تحميل، فراغ، خطأ)، وقواعد أنماط قابلة لإعادة الاستخدام.
تغيير عملي: يمكن للمصممين والمطورين التوافق حول جرد مكونات مشترك، مراجعة السلوك معزولًا، وتقليل المفاجآت على مستوى الصفحة.
ساعدت شعبية React في توحيد سلسلة أدوات حديثة تعتبرها فرق عديدة الآن بمثابة البحرية:
حتى إن لم تختَر نفس الأدوات، يبقى التوقع: تطبيق React يجب أن يحتوي دروعًا تكتشف انحدارات الواجهة مبكرًا.
كامتداد جديد لتلك العقلية، بعض الفرق تستخدم منصات مساعدة مثل Koder.ai لتوليد هياكل React (وباك إند حولها) من سير عمل تخطيطي عبر دردشة—مفيد عند الرغبة في التحقق من بنية المكونات وملكيتها وحدود الميزات سريعًا قبل قضاء أسابيع في تركيب يدوي.
روّجت فرق React أيضًا لفكرة مستكشف المكونات: بيئة مخصصة تعرض المكونات في حالات مختلفة، تضيف ملاحظات، وتشارك مصدرًا واحدًا للحقيقة لاستخدامها.
هذا التفكير "بأسلوب Storybook" (دون الالتزام بأي منتج محدد) يغيّر التعاون: يمكن مراجعة سلوك المكوّن قبل ربطه في صفحة، ويمكن التحقق من حالات الحافة عمدًا بدل الاعتماد على الظهور في اختبار يدوي.
إذا كنت تبني مكتبة قابلة لإعادة الاستخدام، فذلك يندمج طبيعيًا مع نهج نظام التصميم—انظر /blog/design-systems-basics.
تدفع أدوات قائمة على المكونات إلى طلبات سحب أصغر، مراجعات مرئية أوضح، وإعادة هيكلة أكثر أمانًا. مع الوقت، تُسرّع الفرق إطلاق تغييرات واجهة لأنهم يتعاملون مع قطع محددة النطاق بدل التنقل عبر كود صفحة متشابك.
نظام التصميم عمليًا هو شيئان معًا: مكتبة مكونات واجهة قابلة لإعادة الاستخدام (أزرار، نماذج، نوافذ حوار، تنقّل) والإرشادات التي تشرح كيف ومتى تستخدمها (التباعد، الطباعة، اللهجة، قواعد الوصول، أنماط التفاعل).
جعلت React هذا النهج طبيعيًا لأن "المكوّن" هو بالفعل وحدة الواجهة الأساسية. بدل تكرار الـ markup بين الصفحات، يمكن للفرق نشر <Button />, <TextField />, أو <Dialog /> مرة وإعادة استخدامها في كل مكان—مع السماح بالتخصيص المسيطر عبر props.
المكونات في React معزولة: يمكنها تجميع البنية والسلوك والتنسيق خلف واجهة ثابتة. هذا يسهل بناء مكتبة مكونات تكون:
إن بدأت من الصفر، تساعدك قائمة فحص بسيطة على منع "كومة مكونات" من التحول لفوضى غير متناسقة: /blog/component-library-checklist.
نظام التصميم ليس مجرد اتساق بصري—إنه اتساق سلوكي. عندما تحجز النافذة دائمًا التركيز بشكل صحيح، أو يدعم القوائم المنسدلة دائمًا التنقل بلوحة المفاتيح، يصبح الوصول الافتراضي بدل أن يكون فكرة لاحقة.
يسهّل الثيمينغ أيضًا: يمكنك مركزية الرموز (ألوان، تباعد، طباعة) ودع المكونات تستهلكها، حتى لا تتطلب تغييرات العلامة التجارية لمس كل شاشة.
للفرق التي تقوّم إن كانت تستحق الاستثمار في مكونات مشتركة، غالبًا ما يرتبط القرار بالحجم وتكاليف الصيانة؛ بعض المؤسسات تربط هذا بالتخطيط المنصَّة مثل /pricing.
لم تغيّر React فقط طريقة بناء الواجهات—بل غيرت كيف نقيم الجودة. بمجرد أن يصبح تطبيقك مكوّنات بمدخلات واضحة (props) ومخرجات (واجهة render)، يصبح الاختبار والأداء قرارات معمارية، لا إصلاحات في اللحظة الأخيرة.
تسمح حدود المكونات بالاختبار على مستويين مفيدين:
ينجح هذا أفضل عندما تكون المكونات ذات ملكية واضحة: مكان واحد يملك الحالة، والأبناء يعرضون البيانات ويصدرون الأحداث.
تبدو تطبيقات React سريعة لأن الفرق تخطط للأداء ضمن البنية:
قاعدة مفيدة: حبِّذ تحسين الأجزاء المكلفة—القوائم الكبيرة، الحسابات المعقدة، والمناطق التي تعاد عرضها كثيرًا—بدل مطاردة مكاسب صغيرة.
مع الوقت، قد ينزلق الفريق إلى أفخاخ شائعة: إفراط تقسيم المكونات (قطع صغيرة كثيرة بلا هدف واضح)، حفر props (تمرير بيانات عبر طبقات كثيرة)، وحدود غامضة حيث لا يعلم أحد أي مكوّن "يملك" جزءًا من الحالة.
عندما تتحرك بسرعة (خاصة مع كود مولد تلقائيًا أو مهيكل)، تظهر نفس المزالق بسرعة أكبر: تتكاثر المكونات وتُطمس ملكية الحالة. سواء كنت تبرمج يدويًا أو تستخدم أداة مثل Koder.ai لتوليد تطبيق React وباك إند (غالبًا Go مع PostgreSQL)، نفس الدرع: اجعل ملكية الحالة صريحة، واجعل واجهات مكونات صغيرة، وأعد الهيكلة نحو حدود ميزة واضحة.
ستستمر Server Components، الأطر الفوقية (meta-frameworks)، وأدوات أفضل في تطوير كيفية تسليم تطبيقات React. الدرس الدائم لا يتغير: صمِّم حول الحالة، والملكية، وقطع الواجهة المركبة، ثم دع الاختبار والأداء يتبعا طبيعيًا.
للقرارات الهيكلية الأعمق، انظر /blog/state-management-react.
React أعادت صياغة هندسة الواجهة الأمامية حول بعض قرارات الجوهرية:
التأثير العملي هو تقليل أعمال تعديل الـ DOM اليدوية وحدود أوضح للفرق والأدوات.
تفكير المكونات يعني التعامل مع كل قطعة واجهة كمكوّن صغير قابل لإعادة الاستخدام يملك طريقة عرضه ويمكن تركيبه في شاشات أكبر. عمليًا، المكوّن يجمع بين:
هذا يحوّل العمل من "حدّث علامة DOM هذه" إلى "عرض هذا المكوّن للحالة المعينة".
في الكود المعتمد على DOM، غالبًا ما يصبح الـ DOM هو مصدر الحقيقة، فتجد نفسك تحافظ يدويًا على عناصر متعددة متزامنة. في React، تحدث الحالة وتُعاد عملية العرض بناءً على هذه الحالة، فتظل شروط مثل مؤشرات التحميل، أزرار معطلة، وحالات الفراغ متناسقة بشكل طبيعي.
اختبار عملي: إذا تكتب كثيرًا "ابحث عن عنصر وغيّر الكلاس" فأنت تقاوم النموذج؛ وإن خرجت الواجهة عن الحالة المتوقعة فعادةً يكون السبب مشكلة في ملكية الحالة.
قبل React، كانت muchos التطبيقات مركزة على الصفحات: قوالب تُولَّد على الخادم مع jQuery والإضافات. كان السلوك مبعثرًا بين عروض الخادم، سمات HTML، ومهيئات JavaScript.
المشكلات الشائعة:
React دفعت الفرق نحو مكونات قابلة لإعادة الاستخدام وتحديثات متوقعة.
الترتيب التصريحي يعني وصف كيف يجب أن تبدو الواجهة لحالة معينة، لا وصف خطوات تعديل الـ DOM سطرًا بسطر.
بدلاً من:
تعبر عن الشروط داخل ناتج العرض (مثال: "إذا كان المستخدم مسجَّلًا أظهر اسمه وإلا أظهر زر تسجيل الدخول")، وتتكفل React بتحديث الـ DOM الحقيقي.
JSX سهّل إقران بنية الواجهة بالمنطق الذي يتحكم بها (الشروط، المعالجات). هذا يقلل التقسيم بين ملفات القوالب والمنطق.
JSX ليس HTML؛ إنه تركيب يُترجم إلى استدعاءات جافاسكريبت. الفائدة الأساسية تنظيمية: تجميع الأشياء التي تتغير معًا (الواجهة + السلوك) داخل مكوّن واحد يميل لأن يكون أسهل للصيانة.
المصالحة هي عملية React لمقارنة الناتج السابق مع الناتج الجديد وتطبيق أصغر مجموعة من التغييرات على DOM.
الخلاصة العملية: تكتب منطق العرض كما لو أنك تعيد بناء الواجهة من الصفر، وReact تتكفل بتحديث DOM تدريجيًا.
في القوائم، استخدم مفاتيح key مستقرة وفريدة (مثل ID). تجنّب استخدام فهارس المصفوفة إن كانت العناصر قابلة لإعادة الترتيب أو الإضافة/الحذف، لأن ذلك قد يجعل React تعيد استخدام مثيلات مكونات خاطئة (مثلاً إدخالات تحتفظ بقيم خاطئة).
تدفق البيانات أحادي الاتجاه يعني أن البيانات تنتقل من المكوّنات الأبوية إلى الأبناء عبر props، بينما يطلب الأبناء التغيير عبر ردود نداء (callbacks).
هذا يوضّح الحدود:
غالبًا يصبح تصحيح الأخطاء عبارة عن "أين تعيش الحالة؟" بدل تتبع تعديلات مخفية عبر أجزاء متفرقة من الكود.
التركيب يعني تجميع السلوك عبر دمج مكونات بدلًا من وراثة هرمية عميقة.
أنماط شائعة:
تدرج عملي لإدارة الحالة مع نمو التطبيق:
اختر بناءً على تعقيد التطبيق وحجم الفريق واحتياجات التغير، لا على الصيحات.
children (PageShell، Stack، Grid)RequireAuth أو ErrorBoundaryfooter, emptyState, renderRow) عندما لا تكفي childrenهذا يبقي الواجهة مرنة دون شجرات وراثة عميقة وتداعيات التغير في الكلاس الأساسي.