ما وراء التصميم المتجاوب: رحلتي في عالم Tamagui

لسنوات، كان وعد "Write Once, Run Anywhere" يبدو وكأنه حلم بعيد المنال. لقد مررنا جميعاً بهذا الموقف: تبني واجهة مستخدم رائعة باستخدام React Native للجوال، ثم تقضي الأسابيع الثلاثة التالية في صراع مع CSS media queries وسلوكيات الـ DOM لتجعلها تبدو مقبولة على شاشة مقاس 27 بوصة باستخدام Next.js.

لقد جربت كل شيء—NativeWind، و styled-components، والـ StyleSheet التقليدي. كل واحد منهم كان له حدود. NativeWind يقربك من الهدف، لكن الـ DX غالباً ما تشعرك وكأنك تحارب الأداة بدلاً من بناء المنتج. ثم وجدت Tamagui.

إذا كنت تبني في بيئة Expo و Next.js، فإن Tamagui ليس مجرد UI kit آخر؛ إنه تحول جذري (paradigm shift) في كيفية تعاملنا مع الـ unified design system. إليك ما تعلمته حول احترافه.

المشكلة: فخ "أدنى قاسم مشترك"

في الماضي، كانت مشاركة التنسيقات (styles) بين Expo (Native) و Next.js (Web) تعني إما:

1. الاعتماد المفرط على JavaScript styles، مما يقتل أداء الويب (لا يوجد CSS صديق للـ SSR).
2. صيانة مكتبتي UI منفصلتين، مما يقتل إنتاجية المطور.

يحل Tamagui هذه المعضلة بكونه compiler أولاً. فهو يأخذ كود التنسيق عالي المستوى الخاص بك ويحوله إلى atomic CSS محسّن للويب، بينما يبقي عليه كـ high-performance JSI-based styles للـ native.

1. قوة الـ Shorthands والـ Tokens

أحد أكبر اكتشافاتي كان إدراك مدى تقليل العبء المعرفي (cognitive load) عندما يكون نظام التصميم الخاص بك مدمجاً في الـ props. في إعداداتي، أقوم بتعريف نظام tokens صارم للمسافات (spacing)، والألوان، والأحجام (sizing).

// tamagui.config.ts snippet
const tokens = createTokens({
  size: { sm: 30, md: 50, lg: 80 },
  space: { sm: 10, md: 20, lg: 40 },
  color: {
    primary: '#0070f3',
    background: '#ffffff',
  },
  // ...
})

بمجرد ضبط ذلك، أتوقف عن التفكير بالـ pixels. أبدأ بالتفكير في الأنظمة. تتيح لي ميزة Shorthands كتابة px="$md" بدلاً من paddingHorizontal: 20. قد يبدو الأمر بسيطاً، ولكن في المشاريع واسعة النطاق، هذا الاتساق هو ما يمنع "تشتت الواجهة" (UI drift).

2. مكونات متكيفة (Adaptive Components) من واقع الحياة

التصميم المتجاوب (Responsive design) عادة ما يتعلق فقط بالتخطيط (Flexbox wrapping). أما التصميم الموحد فيتعلق بالسلوك. خذ الـ Modal كمثال. على جهاز الجوال (Expo)، ربما تريد bottom-sheet. أما على سطح المكتب (Next.js)، فستحتاج إلى centered dialog.

مكون Adapt في Tamagui هو السر. لقد استخدمته لبناء navigation معقد يبدو native لكل منصة دون كتابة سطر واحد من if (Platform.OS === 'web').

import { Sheet, Dialog, Adapt } from 'tamagui'

export const MyAdaptiveDialog = () => (
  <Dialog modal>
    <Dialog.Trigger>Open UI</Dialog.Trigger>
    
    {/* On small screens, turn this dialog into a Sheet! */}
    <Adapt when="sm" platform="touch">
      <Sheet dismissOnSnapToBottom>
        <Sheet.Frame>
          <Sheet.Contents />
        </Sheet.Frame>
      </Sheet>
    </Adapt>

    <Dialog.Portal>
       <Dialog.Content>
          <Dialog.Title>Settings</Dialog.Title>
          {/* Content */}
       </Dialog.Content>
    </Dialog.Portal>
  </Dialog>
)

3. احتراف الـ Compiler لـ Next.js

أحد أكبر التحديات التي واجهتها في البداية هو ضبط أداء Next.js بشكل صحيح. إضافة @tamagui/next-plugin أساسية هنا؛ فهي تقوم باستخراج الـ styles إلى ملفات CSS ثابتة (static) أثناء عملية الـ build.

من تجربتي، الخطأ الذي يقع فيه معظم المطورين هو عدم تفعيل الـ compiler أثناء التطوير (development). رغم أنه أبطأ في الـ hot-reload، إلا أنه يضمن أن ما تراه في المتصفح هو بالضبط ما سيتم شحنه في الـ production CSS المحسّن. هذا يلغي أخطاء "Hydration Mismatch" المخيفة التي تظهر في العديد من تطبيقات React Native Web.

4. ميزة الأداء: الاستخراج الثابت (Static Extraction)

لماذا يهم هذا؟ على الويب، يقوم Tamagui بتحويل هذا:

<Stack padding="$4" backgroundColor="$primary" hoverStyle={{ scale: 1.1 }} />

إلى هذا (تقريباً):

<div class="_pd_16px _bg_blue _hover_scale_1_1"></div>

لا يوجد أي عبء تشغيل (runtime overhead) لتلك التنسيقات. أما في جانب الجوال، فتظل كـ optimized View props. هذه هي المرة الأولى التي أشعر فيها أنني لا أضحي بنتائج Lighthouse للويب مقابل مرونة الجوال.

دروس من الميدان

إذا كنت تبدأ للتو مع Tamagui في Expo/Next.js monorepo (مثل Solito)، فإليك قواعدي الذهبية الثلاث:

1. الـ Strict Typing هو صديقك. استخدم TamaguiCustomConfig لضمان أن مكوناتك تقبل فقط الـ tokens التي قمت بتعريفها. هذا يمنع الفريق من استخدام "magic numbers".
2. اعتمد على الـ Themes. تتيح لك الـ nesting themes في Tamagui تغيير قسم كامل من تطبيقك من الفاتح إلى الداكن أو من طابع الشركات إلى طابع مرح بمجرد تغليفه بمزود <Theme name="dark"> واحد.
3. لا تبالغ في التجريد (Abstraction). لقد قضيت وقتاً طويلاً أحاول تغليف مكونات Tamagui داخل مكونات مخصصة بي. Tamagui هو أساس نظام التصميم الخاص بك. استخدمه مباشرة وقم بالتجريد فقط عندما يكون لديك منطق معقد مكرر.

كلمات أخيرة

التوسع لما وراء التصميم المتجاوب البسيط يعني بناء تطبيقات تحترم المنصة التي تعمل عليها. من خلال الاستفادة من Tamagui مع Expo و Next.js، أصبح لدينا أخيراً الأدوات لبناء نظام تصميم موحد لا يبدو وكأنه تسوية. الأمر تقني، وله منحنى تعلم، لكن النتيجة—مصدر واحد للحقيقة لواجهة المستخدم—تستحق كل ساعة قضيتها في ملف الإعدادات.

بالتوفيق في البرمجة يا زملائي. لنبنِ شيئاً عالي الأداء.