
React
استخدام المكونات الوظيفية
استخدم دائمًا مكونات TSX الوظيفية. لا تستخدمimport الافتراضي مع const، لأنه أصعب من حيث القراءة والدمج باستخدام إكمال التعليمات البرمجية.
المحددات
قم بإنشاء نوع الخصائص واطلق عليه(ComponentName)Props إذا لم يكن هناك حاجة لتصديره.
استخدام تفكيك الخصائص.
امتنع عن استخدام React.FC أو React.FunctionComponent لتحديد أنواع الخصائص
No Single Variable Prop Spreading in JSX Elements
تجنب استخدام انتشار متغير فردي للخصائص في عناصر JSX، مثل{...props}. غالبًا ما تؤدي هذه الممارسة إلى شكل تعليمي أقل قابلية للقراءة وأصعب في الصيانة لأنه من غير الواضح أي الخصائص يتلقاها المكون.
- نظرة سريعة تسهل معرفة الخصائص التي تمررها التعليمات البرمجية، مما يسهل من الفهم والصيانة.
- يساعد على منع نشوء تعقيدات كبيرة بين المكونات من خلال خصائصها.
- أدوات الفحص تجعل من السهل تحديد الخصائص التي بها أخطاء إملائية أو غير مستخدمة عندما تسرد الخصائص بشكل صريح.
JavaScript
Use nullish-coalescing operator ??
Use optional chaining ?.
TypeScript
استخدام type بدلاً من interface
استخدم دائمًا type بدلاً من interface، لأنهما تقريبًا دائمًا متداخلين، و type أكثر مرونة.
Use string literals instead of enums
الحروف المشفوعة هي الطريقة المفضلة للتعامل مع القيم الشبيهة بالأعداد المخصصة في TypeScript. من السهل توسيعها باستخدام Pick و Omit، وتقدم تجربة مطور أفضل، خاصة مع إكمال التعليمات البرمجية. يمكنك معرفة السبب في أن TypeScript توصي بتجنب الأعداد هنا.GraphQL والمكتبات الداخلية
يجب عليك استخدام الأعداد التي يقوم بإنشائها GraphQL codegen. من الأفضل أيضًا استخدام عدد مخصص عند استخدام مكتبة داخلية، بحيث لا تضطر المكتبة الداخلية إلى تعريض نوع حرف مشفوع غير متعلق بـ API الداخلي. مثال:Styling
استخدام مكونات منسقة
قم بتنسيق المكونات باستخدام styled-components.Theming
استخدام السمة لتنسيق معظم المكونات هو النهج المفضل.وحدات القياس
تجنب استخدام قيمpx أو rem مباشرة داخل المكونات المنسقة. بشكل عام، عادة ما تكون القيم المحددة مسبقًا موجودة بالفعل في السمة، لذا يفضل استخدام السمة لتحقيق هذا الغرض.
ألوان
امتنع عن تقديم ألوان جديدة، بدلاً من ذلك، استخدم اللوحة الموجودة في السمة. إذا كانت هناك حالة لا تتطابق فيها اللوحة، يرجى ترك تعليق لكي تتمكن الفريق من تصحيحها.تطبيق قاعدة “عدم استيراد الأنواع”
تجنب استيراد الأنواع. للحد من هذه الممارسة، تتحقق قاعدة ESLint وتبلغ عن أي استيرادات من هذا النوع. يساعد هذا على الحفاظ على الاتساق وقابلية القراءة في كود TypeScript.لماذا لا نوع استيرادات
- الاتساق: من خلال تجنب استيراد الأنواع واستخدام أسلوب استيراد واحد لكل من الأنواع والقيم، يبقى الكود موحدًا في أسلوب استيراد الوحدة.
- القراءة: استيرادات بلا نوع تحسن من قابلية القراءة للرمز من خلال توضيح عندما تقوم باستيراد القيم أو الأنواع. يقلل هذا من الغموض ويجعل من الأسهل فهم الهدف من الرموز المستوردة.
- الصيانة: يعزز الصيانة داخل قاعدة الكود لأن المطوّرين يمكنهم تحديد مواقع استيرادات الأنواع فقط عند استعراض أو تعديل الكود.
قاعدة ESLint
تفرض قاعدة ESLint،@typescript-eslint/consistent-type-imports, معيار عدم استيراد الأنواع. ستولد هذه القاعدة تحذيرات أو أخطاء عن أي انتهاكات لاستيراد الأنواع.
يرجى ملاحظة أن هذه القاعدة تتناول بشكل خاص حالات الحافة النادرة حيث تحدث استيرادات الأنواع دون قصد. يمنع TypeScript نفسه هذه الممارسة، كما هو موضح في ملاحظات إصدار TypeScript 3.8. في معظم الحالات، لا ينبغي لك أن تستخدم استيرادات الأنواع وحدها.
لضمان امتثال الكود الخاص بك لهذه القاعدة، تأكد من تشغيل ESLint كجزء من سير العمل الخاص بالتطوير لديك.