كان للإصدار الأول من ShipmentCard في Northwind ستة props. وبعد عام صار له ثلاثة وعشرون: title، subtitle، status، statusTone، showMenu، menuItems، footerText، footerAction، footerActionVariant، hideBorder، compact، imageUrl، imagePosition، وهكذا. كل بطاقة مختلفة قليلًا لدى أحد الفرق صارت prop إضافيًا. وتحوّل كود المكوّن إلى أدغال من الشروط، وصارت صفحة التوثيق تسرد props لا يستطيع أحد أن يحفظها. هذا هو انفجار الـ props (prop explosion)، وكل نظام تصميم يقابله.
المكوّن المُعَدّ بالإعدادات (configured) يستقبل البيانات ويقرّر التخطيط بنفسه. أما المكوّن المركّب (composed) فيقدّم قطعًا، والمستخدم يرتّبها.
\nهذه بطاقة الشحنة نفسها، مركّبة:
\n<Card>\n <Card.Header>\n <Card.Title>Shipment NW-4471</Card.Title>\n <Badge tone=\"info\">In transit</Badge>\n <ShipmentMenu shipmentId=\"NW-4471\" />\n </Card.Header>\n <Card.Body>Rotterdam to Hamburg · 2 pallets</Card.Body>\n <Card.Footer>\n <Button size=\"sm\">Track</Button>\n <Button size=\"sm\" variant=\"primary\">Assign driver</Button>\n </Card.Footer>\n</Card>لم تحتج البطاقة قط إلى prop باسم footerSecondaryAction، لأن Card.Footer هو slot يقبل أي إجراءات. والقائمة مكوّن خاص بالفريق، موضوع حيث تسمح الترويسة. ومع ذلك ما زال النظام يملك المسافات والحدود والطباعة والسلوك المتجاوب لكل قطعة. تحصل الفرق على مرونة في ما يوضع وأين، ويحتفظ النظام بالسيطرة على شكل كل قطعة.
القطع الثابتة مثل Card لا تحتاج إلا إلى التخطيط. أما التفاعلية مثل Tabs فتحتاج إلى حالة مشتركة: التبويب المحدّد، وأيّ لوحة تُعرض. والطريقة المتينة لمشاركتها هي الـ context:
\nimport { createContext, use, useId, useState } from 'react';\n\nconst TabsContext = createContext<{\n selected: string;\n select: (value: string) => void;\n baseId: string;\n} | null>(null);\n\nfunction useTabs() {\n const ctx = use(TabsContext);\n if (!ctx) throw new Error('Tabs.* must be used inside <Tabs>');\n return ctx;\n}\n\nexport function Tabs({ defaultValue, children }: { defaultValue: string; children: React.ReactNode }) {\n const [selected, select] = useState(defaultValue);\n const baseId = useId();\n return <TabsContext value={{ selected, select, baseId }}>{children}</TabsContext>;\n}\n\nTabs.Trigger = function Trigger({ value, children }: { value: string; children: React.ReactNode }) {\n const { selected, select, baseId } = useTabs();\n return (\n <button\n type=\"button\"\n role=\"tab\"\n id={`${baseId}-tab-${value}`}\n aria-selected={selected === value}\n aria-controls={`${baseId}-panel-${value}`}\n onClick={() => select(value)}\n >\n {children}\n </button>\n );\n};\n// Tabs.List (role=\"tablist\") and Tabs.Panel (role=\"tabpanel\") follow the same idea.يقرأ الـ trigger الحالة المشتركة أينما كان في الشجرة: داخل tooltip، أو div للتخطيط، أو مكوّن كتبه الفريق. في React 19 تعرض الـ context مباشرة كـ provider (<TabsContext value={…}>) وتقرؤه بـ use. أدوار ARIA مأخوذة من نمط التبويبات في WAI-ARIA، وستتعرّف عليه جيدًا في الدرس التالي؛ أما التعامل مع لوحة المفاتيح فمحذوف هنا لإبقاء المثال قصيرًا.
الـ composition ليست مجانية. يكتب المستخدمون markup أكثر، ويمكنهم ترتيب القطع بطرق لم تقصدها، مثل تذييلين أو عنوان داخل المتن. تتعامل Northwind مع هذا بثلاث طرق. كل قطعة مقيّدة: Card.Footer يرتّب الإجراءات، ولا شيء آخر يبدو صحيحًا فيه. والترتيبات الشائعة تُطلَق كوصفات موثّقة تنسخها الفرق. وبعض التركيبات الشائعة جدًا تصبح مغلّفات صغيرة مُعدّة بالـ props ومبنية من القطع المركّبة، مثل ShipmentSummaryCard بأربعة props، فتبقى حالة الـ 80% قصيرة، وتبقى حالة الـ 20% ممكنة.
نادرًا ما تحظى ببداية جديدة. كان ShipmentCard مستخدمًا في 60 شاشة حين أعدنا تصميمه. لم نحذفه؛ بل أعدنا بناءه فوق القطع الجديدة، فصارت الـ props الثلاثة والعشرون تعرض Card.Header وCard.Body وCard.Footer داخليًا. استمرّت كل شاشة موجودة في العمل وحصلت على الأنماط الجديدة مجانًا. ثم علّمنا ShipmentCard كـ deprecated، ووثّقنا المقابل المركّب لكل تركيبة props شائعة، ونقلنا الشاشات فريقًا بعد فريق. بناء الـ API القديم من القطع الجديدة هو ما جعل الانتقال مملًّا، وهذا أعلى مديح يمكن أن يناله انتقال.
ليس كل مكوّن يجب أن يكون مركّبًا. الـ Badge الخاص بالحالة له tone وتسمية؛ والـ Avatar له صورة واسم وحجم. تنويعاتهما قليلة ومغلقة، فتصفهما الـ props وصفًا كاملًا، ولن تضيف الـ composition إلا تعقيدًا شكليًا.
قاعدة عملية من مراجعات الـ API في Northwind: حين تبدأ الـ props بوصف التخطيط (imagePosition، footerAlign) أو بنية المحتوى (menuItems، footerText)، فالمكوّن يريد slots أو قطعًا. وحين تصف الـ props المظهر أو الحالة (tone، size، disabled)، فالإعدادات لا بأس بها.
في التمرين تحكم على اقتراح API لـ Dialog بهذه القواعد. وبعدها تتأكّد أن كل قطعة من هذه القطع تعمل مع لوحة المفاتيح وقارئ الشاشة (screen reader)، افتراضيًا.
\n","toc":[{"id":"sec-1","text":"الإعدادات مقابل الـ composition","level":2},{"id":"sec-2","text":"مشاركة الحالة بين القطع","level":2},{"id":"sec-3","text":"للـ composition تكاليفها أيضًا","level":2},{"id":"sec-4","text":"الانتقال بعيدًا عن مكوّن مُعَدّ بالإعدادات","level":2},{"id":"sec-5","text":"متى تكون الإعدادات هي الصواب","level":2}],"takeaways":["حين تضيف كل حالة استخدام جديدة prop جديدًا، فالمكوّن يُعَدّ من الخارج وسيظلّ يكبر؛ أما الـ composition (التركيب) فتسمح للمستخدمين بترتيب القطع بأنفسهم.","المكوّنات المركّبة مثلCard.Header وTabs.Trigger تتشارك الحالة عبر الـ context، لا عبر فحص الأبناء (children).","يظلّ النظام مالكًا لشكل كل قطعة وسلوكها، فتضيف الـ composition مرونة دون التخلّي عن الاتّساق.","المكوّنات الصغيرة المغلقة مثل Badge أو Avatar لا بأس أن تُعَدّ بالـ props؛ والجأ إلى الـ composition حين تبدأ الـ props بوصف التخطيط أو المحتوى."],"further":[{"title":"Passing data deeply with context (React)","url":"https://react.dev/learn/passing-data-deeply-with-context"},{"title":"use (React API reference)","url":"https://react.dev/reference/react/use"},{"title":"Tabs pattern (WAI-ARIA Authoring Practices)","url":"https://www.w3.org/WAI/ARIA/apg/patterns/tabs/"}],"quiz":[{"q":"طلب أحد الفرق prop باسم footerSecondaryActionIcon على ShipmentCard. علامَ يدلّ هذا الطلب على الأرجح؟
كيف يجب أن يعرف Tabs.Trigger أيّ تبويب هو المحدّد؟
Tabs.","why":"صحيح. الـ context يعمل مهما كان عمق تداخل الـ trigger، وأيًّا كان الترتيب الذي يستخدمه المستخدم."},{"text":"بأن يمرّ Tabs على أبنائه عبر React.Children.map ويحقن الـ props.","why":"هذا ينكسر بمجرّد أن يُغلَّف الـ trigger بعنصر آخر، مثل tooltip أو div للتخطيط."},{"text":"بأن يقرأ كل trigger متغيّرًا عامًا (global).","why":"مجموعتا تبويبات في صفحة واحدة ستتنازعان على المتغيّر نفسه."},{"text":"بأن يمرّر المستخدم selected لكل trigger يدويًا.","why":"ممكن، لكنه يلقي إدارة حالة المكوّن نفسه على كل فريق."}],"answer":0},{"q":"أيّ مكوّن هو الأنسب ليبقى مكوّنًا بسيطًا يُعَدّ بالـ props؟
","options":[{"text":"Dialog فيه ترويسة ومتن وتذييل ولوحة جانبية اختيارية.","why":"محتواه وتخطيطه يتفاوتان كثيرًا بين الاستخدامات، وهذا بالضبط حيث تساعد الـ composition."},{"text":"جدول بيانات بخلايا مخصّصة وأشرطة أدوات وإجراءات للصفوف.","why":"الجداول تتفاوت تفاوتًا هائلًا؛ والجداول المبنية على الإعدادات وحدها تصبح أطول قوائم props في أي نظام."},{"text":"Badge لعرض الحالة بـtone وتسمية قصيرة.","why":"صحيح. تنويعاته قليلة ويمكن عدّها، فبضعة props تصفه وصفًا كاملًا."}],"answer":2}],"exercise":{"kind":"choice","multiple":false,"options":["props","children-only","compound","per-team"],"correct":["compound"],"title":"اختر الـ API الخاص بالـ Dialog","prompt":"تحتاج Northwind إلى Dialog. الاستخدامات المعروفة حتى الآن: تأكيد حذف (عنوان وجملة وزرّان)، ونموذج إسناد سائق فيه قائمة قابلة للبحث، ومعاينة مسار فيها خريطة ولوحة جانبية، ونموذج اشتراك في النشرة البريدية للتسويق. وصلت أربعة اقتراحات للـ API. اختر الاقتراح الذي توافق عليه.
\n// A\n<Dialog title=\"Delete route?\" body=\"…\" confirmLabel=\"Delete\" confirmVariant=\"danger\"\n cancelLabel=\"Cancel\" showSidePanel={false} onConfirm={…} />\n\n// B\n<Dialog open={open} onOpenChange={setOpen}>{anything}</Dialog>\n\n// C\n<Dialog open={open} onOpenChange={setOpen}>\n <Dialog.Header><Dialog.Title>Delete route?</Dialog.Title></Dialog.Header>\n <Dialog.Body>…</Dialog.Body>\n <Dialog.Footer>\n <Button onClick={close}>Cancel</Button>\n <Button variant=\"danger\" onClick={remove}>Delete</Button>\n </Dialog.Footer>\n</Dialog>\n\n// D\n// No shared Dialog: each team builds its own on top of the native <dialog> element.الاقتراح C يعتمد الـ composition: النظام يملك الطبقة المعتمة وإدارة التركيز والمسافات والعنوان الذي يسمّي النافذة، بينما ترتّب الفرق محتوى الترويسة والمتن والتذييل بحرية. أما A فيناسب تأكيد الحذف ويتحوّل إلى انفجار props من حالة الاستخدام الثانية. وB مرن لكنه يتخلّى عن البنية، فيحلّ كل فريق مسائل العناوين والمسافات والتذييلات بطريقته. وD يرمي عمل النظام في إمكانية الوصول بالكامل. ويمكن لاحقًا بناء مكوّن صغير مُعَدّ بالـ props باسم ConfirmDialog فوق C للحالة الأكثر شيوعًا.
showSidePanel."},"children-only":{"text":"B: Dialog يعرض أيّ أبناء يستقبلهم.","why":"مرن إلى أقصى حدّ، لكن النظام لم يعد يملك العناوين والمسافات والتذييلات، فتتباعد النوافذ من جديد."},"compound":{"text":"C: Dialog مركّب من قطع Header وTitle وBody وFooter.","why":"صحيح. يغطّي الاستخدامات الأربعة كلها بينما يحتفظ النظام بالسيطرة على البنية والأنماط وإمكانية الوصول."},"per-team":{"text":"D: لا مكوّن مشترك؛ تستخدم الفرق عنصر <dialog> الأصلي مباشرة.","why":"العنصر الأصلي أساس جيد لـ Dialog الخاص بالنظام، لكن ترك كل فريق ينسّقه ويسمّيه بنفسه يعيد إنتاج التناقض الذي وُجد النظام لإزالته."}}},"words":612,"readMinutes":4}