من التصميم إلى الكود

من التصميم إلى المكوّن: تغيير العقلية

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

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

flowchart LR
  D["التصميم المعتمَد في الـartifact"] --> T["الـtokens: متغيرات CSS"]
  T --> C["المكوّنات: props + حالات + إتاحة"]
  C --> I["الدمج بواسطة المطوّر"]
  I --> V["التحقق: الحالات، لوحة المفاتيح، التباينات"]

تشريح مكوّن جيد

يوصف المكوّن جيد التصميم بـprops (معاملات الإدخال): للزر مثلاً variant (primary، secondary، ghost) وsize (sm، md، lg) وdisabled. هذه الواجهة ليست تفصيلاً تقنياً: إنها ترجمة قرارات نظام تصميمك إلى كود. ثلاثة أنواع أزرار في التصميم = prop واحدة variant بثلاث قيم في الكود. وإذا وجدت نفسك تطلب نوعاً رابعاً «لهذه الصفحة فقط»، فهذه إشارة إلى أن قرار تصميم يتسرّب من النظام.

اطلب دائماً المكوّن مع مثال استخدام: رؤية <Button variant="primary" size="lg">جرّب مجاناً</Button> تتيح الحكم فوراً على بديهية الواجهة. وحدّد صيغة الإخراج منذ البداية — HTML/CSS خالص، React، مع Tailwind أو بدونه — لأن التحويل لاحقاً يهدر الوقت ويُدخل انحرافات.

الحالات التفاعلية: hover وfocus وdisabled

إليك الفارق الأبرز بين عرض تجريبي ومكوّن احترافي: الحالات. الزر الحقيقي يعيش أربع حيوات على الأقل: السكون، وhover (المرور — إشعار بأن العنصر قابل للنقر)، وfocus (التحديد بلوحة المفاتيح — لا غنى عنه، سنعود إليه)، وactive (لحظة النقر)، وdisabled (الإجراء غير متاح). مكوّن بلا حالات ليس منتهياً: إنه صورة تشبه زراً.

يجب أن تكون كل حالة مدرَكة لكن متسقة: عند المرور، نغمّق اللون قليلاً (ومن هنا token الـ--color-primary-hover) ويمكن رفع الظل بلطف؛ وفي حالة disabled، نخفض العتامة ونغيّر المؤشر. ويجب أن تكون الانتقالات ناعمة — 150 إلى 200 ميلي ثانية — لتناسب أجواء Sereno المهدّئة. وفكّر في المكوّنات بعد الزر: حقل النموذج له حالاته أيضاً (focus، خطأ، ممتلئ)، والبطاقة القابلة للنقر لها تأثير مرورها.

حوّل زر صفحة هبوط Sereno إلى مكوّن React قابل لإعادة الاستخدام:
- props: variant (primary | secondary | ghost)، size (sm | md | lg)، disabled
- حالات بصرية: hover (تغميق نحو --color-primary-hover، انتقال 180ms)، focus-visible (حلقة 2px بلون --color-accent، مزاحة 2px)، active (تصغير طفيف في المقياس)، disabled (عتامة 0.5، cursor not-allowed)
- استخدم حصرياً متغيرات CSS من نظام التصميم المقدَّم — لا قيم صلبة
- الإتاحة: عنصر <button> أصلي، focus مرئي بلوحة المفاتيح، ارتفاع أدنى 44px في حجم md
قدّم الكود كاملاً + 3 أمثلة استخدام (واحد لكل variant) + قائمة الـtokens المستخدمة.

الإتاحة في الكود: ما بعد التباينات

في الفصل 2، كانت الإتاحة تخص التباينات. في الكود، تكتسب بُعدين إضافيين. أولاً التنقل بلوحة المفاتيح: جزء من مستخدميك لا يستعمل الفأرة (إعاقة حركية، قارئات شاشة، أو مجرد تفضيل). كل عنصر تفاعلي يجب أن يكون قابلاً للوصول بمفتاح Tab وأن يُظهر بوضوح أنه محدَّد — هذا دور حالة focus-visible، تلك الحلقة حول الزر التي يحذفها بعض المصممين «لأنها قبيحة». لا تحذفها أبداً: صمّمها لتكون جميلة.

ثانياً دلالية HTML: الزر يجب أن يكون <button>، لا <div> منمّقاً بمعالج نقر. العنصر الأصلي يمنحك مجاناً الـfocus بلوحة المفاتيح، والتفعيل بمفتاحي Enter وSpace، والإعلان الصحيح لقارئات الشاشة. المنطق نفسه للعناوين (<h1>...<h2> بالترتيب، دون قفز مستوى)، والقوائم والروابط. يُنتج الذكاء الاصطناعي HTML دلالياً صحيحاً... إن طلبته. أضف بشكل منهجي «HTML دلالي ومتاح» إلى موجّهات الكود، واطلب تدقيقاً: «افحص هذا المكوّن من زاوية الإتاحة واذكر المشكلات».

صورة ← واجهة: الانطلاق من لقطة شاشة أو رسم تخطيطي

قدرة مبهرة ومفيدة فعلاً: إعطاء صورة للذكاء الاصطناعي — لقطة شاشة، تصميم مُصدَّر، أو صورة رسم تخطيطي بقلم لبّاد على طرف طاولة — وطلب إعادة إنتاج بنيتها كوداً. تحلل النماذج الحالية التخطيط، وتتعرف على المكوّنات (تنقّل، hero، بطاقات، نماذج)، وتُنتج واجهة عاملة قريبة من الأصل.

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

هذه صورة الرسم التخطيطي الذي أنجزه العميل في ورشة العمل [صورة مرفقة].
أعد إنتاج بنية هذا التخطيط بـHTML/CSS:
- حدّد كل منطقة (تنقّل، hero، أعمدة، footer) وسمِّها في تعليقات
- طبّق نظام تصميمي المقدَّم أدناه — البنية من الرسم، والأسلوب من الـtokens
- حيثما كان الرسم ملتبساً، اختر التفسير الأبسط وأشِر إليه في تعليق
[الصق هنا كتلة :root]

إبقاء الكود نظيفاً وموصولاً بالـtokens

الحلقة الأخيرة: جودة الكود المُسلَّم. ثلاثة متطلبات يجب صياغتها صراحةً. أولاً: الكود يعيد استخدام الـtokens — كل قيمة صلبة هي خلل تماسك (يمكنك طلب تدقيق: «اذكر كل القيم الصلبة المتبقية في هذا الكود واستبدلها بالـtokens المناسبة»). ثانياً: التعليقات تشرح الخيارات غير البديهية، لا كل سطر — «لماذا هذا الـz-index» يستحق تعليقاً، أما «هذا زر» فلا. ثالثاً: الأسماء (الفئات، الـprops، الملفات) تتبع اصطلاحاً متسقاً يستطيع مطوّر العميل مواصلته.

اعتد أيضاً المراجعة النقدية: الكود المولَّد صحيح عموماً، لكنه ليس دائماً الأمثل. قواعد CSS مكررة، محدِّد مفرط التخصيص، حالة منسية — اطلب من الذكاء الاصطناعي مراجعة كوده بنفسه («راجع هذا المكوّن كمطوّر senior متطلّب: الجودة، الإتاحة، الاتساق مع الـtokens») قبل التسليم. المكوّن النظيف يُصان؛ والمكوّن المرقَّع يصبح سريعاً غير قابل للإدارة، وسمعة الاستوديو على المحك في كل تسليم.