Window.pipedriveLeadboosterConfig = { القاعدة: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', الإصدار: 2, } ؛(الدالة () { var w = نافذة إذا كان (w.LeadBooster) { console.warn('LeadBooster موجود بالفعل') } وإلا { { w.LeadBooster = { q: [], على: دالة (ن، ح) { { هذا.q.push({ t: 'o'، n: n، n: n، h: h }) }, الزناد: الدالة (n) { هذا.q.push({ t: 't'، n: n: n }) }, } } })() لماذا يجب عليك استخدام SCSS بدلاً من المكونات المصممة؟ - The Codest
The Codest
  • نبذة عنا
  • الخدمات
    • تطوير البرمجيات
      • تطوير الواجهة الأمامية
      • تطوير الواجهة الخلفية
    • Staff Augmentation
      • مطورو الواجهة الأمامية
      • مطورو الواجهة الخلفية
      • مهندسو البيانات
      • مهندسو السحابة
      • مهندسو ضمان الجودة
      • أخرى
    • استشاري
      • التدقيق والاستشارات
  • الصناعات
    • التكنولوجيا المالية والمصرفية
    • E-commerce
    • أدتك
    • التكنولوجيا الصحية
    • التصنيع
    • الخدمات اللوجستية
    • السيارات
    • إنترنت الأشياء
  • القيمة مقابل
    • CEO
    • CTO
    • مدير التوصيل
  • فريقنا
  • دراسات الحالة
  • اعرف كيف
    • المدونة
    • اللقاءات
    • ندوات عبر الإنترنت
    • الموارد
الوظائف تواصل معنا
  • نبذة عنا
  • الخدمات
    • تطوير البرمجيات
      • تطوير الواجهة الأمامية
      • تطوير الواجهة الخلفية
    • Staff Augmentation
      • مطورو الواجهة الأمامية
      • مطورو الواجهة الخلفية
      • مهندسو البيانات
      • مهندسو السحابة
      • مهندسو ضمان الجودة
      • أخرى
    • استشاري
      • التدقيق والاستشارات
  • القيمة مقابل
    • CEO
    • CTO
    • مدير التوصيل
  • فريقنا
  • دراسات الحالة
  • اعرف كيف
    • المدونة
    • اللقاءات
    • ندوات عبر الإنترنت
    • الموارد
الوظائف تواصل معنا
السهم الخلفي العودة إلى الوراء
2021-10-05
تطوير البرمجيات

لماذا يجب عليك استخدام SCSS بدلاً من المكونات المصممة؟

The Codest

ياتسيك لودزيك

مصمم المنتجات

خلال الشهرين الماضيين، كنت أعمل على مشروع لأحد عملائنا. عندما كنت في البداية، واجهت اختيار المكتبة للتصميم.

بعد مقارنة الحلول الشائعة مثل CSS العادي، Emotion, SCSS و المكونات المصممةاخترت أخيراً آخر واحد. بدا كل شيء على ما يرام. لديها مكتبة شائعة جدًا في الوقت الحاضر، مما يعني
هناك بالفعل مجتمع كبير بالفعل، لذا إذا واجهت أي مشاكل، فسأجد على الأرجح حلاً في مكان ما على Stack Overflow أو GitHub. إلى جانب ذلك, المكونات المصممة لديها بعض ميزات التحسين مما يعني أنها تعرض فقط عند الحاجة إليها. إن المشروع كان من المتوقع أن يتم إنشاؤها باستخدام React وTypecript. تحتوي هذه المكتبة على دعم رائع لكلا التقنيتين. تبدو رائعة، أليس كذلك؟

بدأت البرمجة بعد ذلك. بعد مرور شهر، عندما نما التطبيق، أصبحت الواجهة الأمامية الفريق وأنا ركزنا على تقديم الميزات، اكتشفنا أن المكونات المصممة كان للمكتبة هدفها الخاص وسأخبرك لماذا.

أولاً، اصطلاح التسمية. للتمييز بين المكونات المصممة من مكونات React، اضطررت إلى استخدام مصممة البادئة التي انخفضت الكود سهولة القراءة. ثم (ما قد يكون غريبًا)، دعم Typescript. المكونات المصممةكما تعلم، تعتمد على نهج CSS-in-JS. هذا يعني أن بإمكانك تمرير أي خاصية إليها وتغيير نمطها، أي المدخلات بناءً على هذه الخاصية، وأنا شخصيًا أعتقد أن هذه الميزة رائعة. في تايبسكريبت، يجب عليك أيضًا تنفيذ نوع هذه الخاصية مما يجعلها شيفرة أطول أي المكون المصمم. قد تقول: "لكن الأمر سيستغرق حوالي 5 ثوانٍ أخرى، فما هي مشكلتك". أنت على حق، على الرغم من أنه عندما يتوسع التطبيق بسرعة ويكون عدد المكونات
زيادة، يمكن بسهولة مضاعفة هذه الثواني الخمس بمئات المرات. مشكلة أخرى هي وضع المكونات المصممة.

بعض مطورو JS في نفس الملف مع المكون الذي تنتمي إليه، والبعض الآخر ينشئ ملفات منفصلة لها. كلا الطريقتين جيدتان لأسباب عديدة. يعتمد الأمر في الغالب على مدى تعقيد المكون. يمكن لاتباع إحدى هاتين الطريقتين أن يحافظ على التماسك ولكن دمجهما يعطي العكس تمامًا. استقلنا من نهج CSS في JS وانتقلنا إلى SCSS. لم يكن الأمر سهلاً وسريعاً ولكن بقليل من المساعدة نجحنا في ذلك. بدأنا بتصميم علامات html في منهجية BEM، وبالطبع وضعنا الأنماط في ملفات منفصلة، واحد لكل مكون. قلت أن تمرير دعائم JS إلى المكونات المصممة ميزة رائعة، ولكن في SCSS مستحيل. أعتقد أننا جميعًا نتفق أيضًا على أن الصيغة التي يريدها React لترميز الفئات الشرطية فظيعة.

رمز أسماء الفئات المتفاعلة

حسناً، هناك حل واحد مثير للاهتمام. إذا قمت بتوصيل منهجية BEM مع CLSX مكتبة، ستحصل على شيء مثل هذا (تحية كبيرة لصديقي برزيميك أدامتشيك الذي أراني هذه المكتبة)

كود clsx

تبدو أنظف بكثير، ألا تعتقد ذلك؟

الأفضل هو أن عليك فقط كتابة متغير الشرط على مستوى المكون و
ليس على مستوى التصميم. إنه يوفر الوقت حقًا. لسوء الحظ، هذا الحل له سلبياته.
SCSS سهل وودود ولكن كن حذرًا عند استخدامه مع Next.js. هذا الإطار لا
السماح باستيراد ملفات الأنماط مباشرةً إلى ملف المكون (وحدات CSS فقط).

إذا كنت تفضل ملفًا واحدًا لكل مكون، فعليك إنشاء index.scss تحتوي على كل SCSS الملفات و
استيرادها إلى _app.tsx ملف. المشكلة الوحيدة هي أنه يجب عليك استيراد كل ملف يدويًا من ملفات SCSS الذي أنشأته. ومع ذلك، في React، لا توجد هذه المشكلة ويمكنك استيراد SCSS الملفات أينما تريد. لا تفهمني خطأ. المكونات المصممة جيدة حقًا. كما قلت من قبل، يعد تمرير متغيرات JS بالإضافة إلى السمة العامة ميزات مذهلة. عندما تقوم ببناء تطبيق كبير حيث يكون التحسين أمرًا بالغ الأهمية، فمن المحتمل أن تلبي هذه المكتبة احتياجاتك. ولكن في حالتنا هذه، فإن الترحيل إلى SCSS الفوز بالجائزة الكبرى

التلخيص

في الختام، في حين أن هناك حججًا صحيحة لكل من مكونات SCSS والمكونات المصممة في تطوير الويب ، يعتمد القرار النهائي على عوامل مختلفة. SCSS صيغة مألوفة أكثر ل المطورون ذوو الخبرة في CSS التقليدي ويوفر تكاملاً سلسًا مع قواعد الكود و مكتبات المكونات .

من ناحية أخرى المكونات المصممة عرض محسّن تجربة المطور مع قدرته على تغليف الأنماط داخل المكونات وتبسيط عملية التصميم. كما أنه يعزز أيضًا نمطية الشيفرة البرمجية وإمكانية إعادة استخدامها، مما يمكّن مهندسي الواجهة الأمامية من إدارة دليل المكونات وإنشاء واجهة مستخدم متسقة عبر تطبيق الويب . بالنظر إلى أهمية بيانات المستخدم الأمان والأداء، من المهم تقييم تأثير كلا النهجين على حجم الحزمة النهائية وأوقات التحميل. في النهاية، فإن الاختيار بين مكونات SCSS والمكونات المصممة يجب أن يستند إلى الاحتياجات المحددة للمشروع، ومجموعة مهارات فريق التطوير والأهداف العامة ل تطبيق الويب . من المستحسن أن يقوم المطورون بتقييم جميع العوامل، والبقاء على اطلاع دائم من خلال منشورات المدونة ومناقشات الصناعة، واتخاذ قرار مستنير يتماشى مع متطلبات مشروعهم ويعزز من عملية تطوير الواجهة الأمامية .

مقالات ذات صلة

تطوير البرمجيات

المقارنة بين الأبطال Angular مقابل Angular مقابل Vue

في الوقت الحالي، هناك عدد قليل من أطر الواجهة الأمامية التي يشيع استخدامها وتطويرها باستمرار من قبل منشئيها، ويختلف كل منها قليلاً عن الآخر. ومع ذلك، قد يكون هناك شيء مشترك بينهم. هنا...

أوليفيا أوريميك

اشترك في قاعدة معارفنا وابقَ على اطلاع على آخر المستجدات في قطاع تكنولوجيا المعلومات.

    نبذة عنا

    The Codest - شركة دولية لتطوير البرمجيات لها مراكز تقنية في بولندا.

    المملكة المتحدة - المقر الرئيسي

    • المكتب 303 ب، 182-184 شارع هاي ستريت نورث E6 2JA
      لندن، إنجلترا

    بولندا - مراكز التكنولوجيا المحلية

    • مجمع مكاتب فابريتشنا المكتبي، أليجا
      بوكوجو 18، 31-564 كراكوف
    • سفارة الأدمغة، كونستروكتورسكا
      11, 02-673 02-673 وارسو، بولندا

      The Codest

    • الصفحة الرئيسية
    • نبذة عنا
    • الخدمات
    • دراسات الحالة
    • اعرف كيف
    • الوظائف
    • القاموس

      الخدمات

    • استشاري
    • تطوير البرمجيات
    • تطوير الواجهة الخلفية
    • تطوير الواجهة الأمامية
    • Staff Augmentation
    • مطورو الواجهة الخلفية
    • مهندسو السحابة
    • مهندسو البيانات
    • أخرى
    • مهندسو ضمان الجودة

      الموارد

    • حقائق وأساطير حول التعاون مع شريك خارجي لتطوير البرمجيات
    • من الولايات المتحدة الأمريكية إلى أوروبا: لماذا تقرر الشركات الأمريكية الناشئة الانتقال إلى أوروبا؟
    • مقارنة مراكز تطوير التكنولوجيا في الخارج: تك أوفشور أوروبا (بولندا)، آسيان (الفلبين)، أوراسيا (تركيا)
    • ما هي أهم التحديات التي تواجه CTOs ومديري تكنولوجيا المعلومات؟
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • شروط استخدام الموقع الإلكتروني

    جميع الحقوق محفوظة © 2025 بواسطة The Codest. جميع الحقوق محفوظة.

    arArabic
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek arArabic