واجهات برمجة تطبيقات المكونات غير الرأسية
تعلم كيفية تصميم مكونات بدون واجهة مستخدم تعرض السلوك دون تحديد واجهة المستخدم، وفصل المنطق عن العرض، ودمجه مع أنماط المكونات المركبة لتحقيق أقصى قدر من المرونة.
مع تطور تطبيقات React ، تبدأ الفرق عادةً باستخراج مكونات واجهة المستخدم القابلة لإعادة الاستخدام، مثل القوائم المنسدلة، والنوافذ المنبثقة، وتلميحات الأدوات، وعلامات التبويب، والقوائم القابلة للطي. في البداية، يبدو هذا تقدماً: سلوك مركزي، وأخطاء أقل، وتفاعلات متسقة. لكن مع مرور الوقت، تظهر بعض المشاكل.
يعمل عنصر قائمة منسدلة بشكل جيد على شاشة واحدة، لكن على شاشة أخرى يتطلب التصميم نمط زر مختلف. يريد فريق المنتج رسومًا متحركة مخصصة. يحتاج قسم التسويق إلى بنية تخطيط مختلفة. تتطلب تحسينات إمكانية الوصول تغيير ترتيب الترميز. فجأة، يصبح العنصر "القابل لإعادة الاستخدام" جامدًا. يبدأ المطورون بإضافة خصائص مثلvariant="compact" أوrenderCustomItem تتكاثر الفروع الشرطية. تتسرب تعديلات التنسيق إلى المكون. ينهار التجريد تحت وطأة احتياجات العرض المتضاربة.
تكمن المشكلة الأساسية في بنية المكون: فهو يربط بين المنطق وواجهة المستخدم. يرتبط سلوك المكون (التنقل باستخدام لوحة المفاتيح، وحالة الفتح/الإغلاق، وإدارة التركيز، وسمات ARIA) ارتباطًا وثيقًا بالترميز والتصميم. أي تغيير في طريقة العرض قد يُعطّل منطق التفاعل. وتصبح إعادة الاستخدام مقيدة بالقرارات البصرية الأصلية.
في React 19، حيث يتم العرض بشكل متزامن وتُعدّ التركيبة إحدى نقاط القوة الأساسية في التصميم، يُمكننا حلّ هذه المشكلة بطريقة مختلفة. فبدلاً من بناء مكونات واجهة مستخدم تحتوي على منطق، نقوم بناء مكونات منطقية تُعرّض الحالة والسلوك. وتُصبح واجهة المستخدم مُستهلكةً لهذا المنطق. هذا هو نمط المكونات غير الرأسية.
المشكلة التي نتناولها في هذا الدرس ليست كيفية بناء قائمة منسدلة، بل كيفية تصميم منطق تفاعلي قابل لإعادة الاستخدام يدعم العديد من التطبيقات المرئية دون تكرار أو جمود.
واجهات برمجة تطبيقات سلوكية قابلة لإعادة الاستخدام مع تصميم واجهة مستخدم مرن
يُظهر المكون غير المُوجّه سلوك التطبيق، وليس ترميزه. في المكون التقليدي، نُعيد JSX الذي يتضمن البنية، وعناصر التنسيق، ومعالجات التفاعل. أما في المكون غير المُوجّه، فنُعيد الحالة وروابط الأحداث. ويُقرر المُستدعي كيفية عرضها. هذا الفصل يُنشئ طبقتين:
طبقة السلوك: تمتلك الحالة، وتفاعلات لوحة المفاتيح، وإدارة التركيز، ودلالات إمكانية الوصول، والمنطق المتحكم فيه أو غير المتحكم فيه.
طبقة العرض: تتحكم في التخطيط والأنماط والرسوم المتحركة والبنية المرئية.
لا يقوم المكون غير المُصمم بواجهة رسومية (headless component) بعرض DOM مباشرةً. بدلاً من ذلك، يوفر واجهة برمجة API)، غالبًا من خلال الخطافات أو المكونات المركبة، التي يستخدمها المستخدمون لإضافة سلوكيات إلى ترميزهم الخاص. أما المفهوم المعماري الثاني فهو بنية المكون المركب. فبدلاً من تمرير عشرات الخصائص، نقوم بتجميع الأجزاء ذات الصلة ضمن سياق مشترك. على سبيل المثال:
<Dropdown><Dropdown.Trigger><Dropdown.Menu><Dropdown.Item>
داخلياً، تتشارك هذه الأجزاء الحالة من خلال السياق. خارجياً، يتحكم المستخدم في التخطيط والتصميم. يتيح هذا النمط أقصى قدر من المرونة.
يمكن للهياكل البصرية المختلفة إعادة استخدام نفس السلوك.
تظل أنظمة التصميم مستقلة.
تبقى منطق التفاعل مركزية وقابلة للاختبار.
يمكن تطبيق إمكانية الوصول في طبقة السلوك.
في مصطلحات React 19، يتوافق هذا مع مبدأ التصميم الذي يركز على التركيب أولاً. يبقى العرض تصريحياً، بينما يتم تنسيق الحالة ضمن حدود محددة. هذا التحول الفكري مهم. نحن لا نبني مكونات واجهة المستخدم، بل نبني واجهات برمجة تطبيقات سلوكية يمكن لواجهة المستخدم استخدامها.
مثال: يتم مشاركة سلوك قائمة منسدلة بدون واجهة مستخدم، ويمكن استبدال واجهة المستخدم.
والآن سنثبت صحة النموذج الذهني من خلال بناء قائمة قائمة منسدلة بدون واجهة مستخدم حيث:
تكشف قائمة منسدلة عن منطق وروابط إمكانية الوصول ولكنها لا تحدد واجهة المستخدم.
يتم تنفيذ العرض التقديمي في مكونات منفصلة باستخدام API غير الرأسية.
نستخدم بنية مكونة مركبة (
Dropdown،Dropdown.Trigger،Dropdown.Menu،Dropdown.Item) مدعوم بالسياق. ...