المقارنة بين الأبطال Angular مقابل Angular مقابل Vue
في الوقت الحالي، هناك عدد قليل من أطر الواجهة الأمامية التي يشيع استخدامها وتطويرها باستمرار من قبل منشئيها، ويختلف كل منها قليلاً عن الآخر. ومع ذلك، قد يكون هناك شيء مشترك بينهم. هنا...
خلال الشهرين الماضيين، كنت أعمل على مشروع لأحد عملائنا. عندما كنت في البداية، واجهت اختيار المكتبة للتصميم.
بعد مقارنة الحلول الشائعة مثل 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
مكتبة، ستحصل على شيء مثل هذا (تحية كبيرة لصديقي برزيميك أدامتشيك الذي أراني هذه المكتبة)
الأفضل هو أن عليك فقط كتابة متغير الشرط على مستوى المكون و
ليس على مستوى التصميم. إنه يوفر الوقت حقًا. لسوء الحظ، هذا الحل له سلبياته.
SCSS سهل وودود ولكن كن حذرًا عند استخدامه مع Next.js. هذا الإطار لا
السماح باستيراد ملفات الأنماط مباشرةً إلى ملف المكون (وحدات CSS فقط).
إذا كنت تفضل ملفًا واحدًا لكل مكون، فعليك إنشاء index.scss
تحتوي على كل SCSS الملفات و
استيرادها إلى _app.tsx
ملف. المشكلة الوحيدة هي أنه يجب عليك استيراد كل ملف يدويًا من ملفات SCSS الذي أنشأته. ومع ذلك، في React، لا توجد هذه المشكلة ويمكنك استيراد SCSS الملفات أينما تريد. لا تفهمني خطأ. المكونات المصممة جيدة حقًا. كما قلت من قبل، يعد تمرير متغيرات JS بالإضافة إلى السمة العامة ميزات مذهلة. عندما تقوم ببناء تطبيق كبير حيث يكون التحسين أمرًا بالغ الأهمية، فمن المحتمل أن تلبي هذه المكتبة احتياجاتك. ولكن في حالتنا هذه، فإن الترحيل إلى SCSS الفوز بالجائزة الكبرى
في الختام، في حين أن هناك حججًا صحيحة لكل من مكونات SCSS والمكونات المصممة في تطوير الويب ، يعتمد القرار النهائي على عوامل مختلفة. SCSS صيغة مألوفة أكثر ل المطورون ذوو الخبرة في CSS التقليدي ويوفر تكاملاً سلسًا مع قواعد الكود و مكتبات المكونات .
من ناحية أخرى المكونات المصممة عرض محسّن تجربة المطور مع قدرته على تغليف الأنماط داخل المكونات وتبسيط عملية التصميم. كما أنه يعزز أيضًا نمطية الشيفرة البرمجية وإمكانية إعادة استخدامها، مما يمكّن مهندسي الواجهة الأمامية من إدارة دليل المكونات وإنشاء واجهة مستخدم متسقة عبر تطبيق الويب . بالنظر إلى أهمية بيانات المستخدم الأمان والأداء، من المهم تقييم تأثير كلا النهجين على حجم الحزمة النهائية وأوقات التحميل. في النهاية، فإن الاختيار بين مكونات SCSS والمكونات المصممة يجب أن يستند إلى الاحتياجات المحددة للمشروع، ومجموعة مهارات فريق التطوير والأهداف العامة ل تطبيق الويب . من المستحسن أن يقوم المطورون بتقييم جميع العوامل، والبقاء على اطلاع دائم من خلال منشورات المدونة ومناقشات الصناعة، واتخاذ قرار مستنير يتماشى مع متطلبات مشروعهم ويعزز من عملية تطوير الواجهة الأمامية .