Angular-styleguide: تباعد أسماء المكونات

المكون هو مجرد غلاف توجيه بدون وظائف تجميع أو ارتباط. لذلك ، ما عليك سوى استخدام نفس الاصطلاح الذي تستخدمه للتوجيهات.

هم ليسوا نفس الشيء .. تحتوي المكونات على نطاق معزول افتراضيًا ، فهي تستخدم وحدة التحكم ، افتراضيًا ، تستبدل وحدة التحكم وظيفة الارتباط ويكون bindToController صحيحًا بشكل افتراضي ..

كل ما يمكنك القيام به بالمكون الذي يمكنك تحقيقه باستخدام التوجيه ولكن سبب وجود المكون هو جعل الانتقال إلى الزاوية 2 أسهل.

يمكنك قراءة المزيد من الميزات هنا: http://www.codelord.net/2015/12/17/angulars-component-what-is-it-good-for/

فهل يضاف هذا؟

أي اقتراحات أو تلميحات حول هذا؟

samithaf باستخدام فواصل النقاط بمحددات css.

لا ينبغي أن يحدك استخدام النقاط (على سبيل المثال ، يمكنك الهروب منها في محددات CSS) ، ولكنه أمر مرهق وغير تقليدي.

لقد استخدم الأشخاص - لمكونات تباعد الأسماء لسنوات ولا أرى سببًا لاستخدام أي فاصل آخر.

mackelitoblowsiegkalpak أستخدمه نمط التالي في تطبيق على نطاق واسع جدا المالي (100K + LOC) وكل شيء حتى الآن على ما يرام. كما ترى ، أستخدم فواصل النقاط لكي يكون كل شيء متسقًا. لكن باستثناء المرشحات. مع الأنماط يمكنك الهروب من النقطة.

const loginModule = angular.module('app.core.login', [])
.component('app.core.login', loginComponent)
.service('app.core.login.loginService', loginService);

samithaf كيف تقوم بحقن الخدمات في وحدة التحكم الخاصة بك؟ أفترض أنه يجب عليك استخدام نهج ['app.core.login.loginService' , function(loginService) {}] ؟

blowsie نموذج لاستخدام خدمة تسجيل الدخول على النحو التالي.

class LoginController {
  constructor($q, loginService) {
    this.loginService = loginService;
  }

  /**
   * <strong i="7">@method</strong> $onInit
   * This lifecycle hook will be executed when all controllers on an element have been constructed and after their bindings are initialized
   */
  $onInit() {
    this.loginService.invalidateSession();
  }

}

LoginController.$inject = ['$q', 'nw.core.login.loginService'];

export default LoginController;

إنه جيد جدًا للخدمات ولكنه غريب حقًا بالنسبة للمكونات:

<div><app.core.login></app.core.login></div>

وهو غير متوافق مع العالم من حوله (كل شخص يستخدم - كما قال gkalpak ).

أنا متأكد من أن تطبيق samithaf رائع مع هذا ولكن هناك فرق بين اصطلاح تسمية غريب يعمل جيدًا في مشروع وما يجب تعيينه في دليل نمط عالمي.

المشكلة الأساسية هنا هي: حاقن AngularJS مسطح ، لذلك نحتاج إلى التفكير بشكل شامل عندما نسمي مكونات الوحدة. هذا عيب في التصميم ثابت في Angular. تغيير الاصطلاح الأساسي ( - لمسافة الأسماء) المستخدمة من البداية من قبل الجميع تقريبًا ليس طريقة للذهاب IMHO.

مرحبًا @ MarcLoupias كما ذكرت لأن DI الزاوي مسطح لا يمكننا فعل الكثير. ولكن عند تحديد أسماء الوحدات بدون مساحة اسم يمكن أن يؤدي بسهولة إلى آثار جانبية. خاصة في مشروع واسع النطاق حيث يعمل لديك أكثر من 10 فرق سكرم. حتى الحل الذي توصلت إليه لا يتوافق مع الاتفاقية ، لا يمكنني التفكير في طريقة جيدة أخرى لحل هذه المشكلة. سيكون من الرائع لو أن فريق Angular يقوم تلقائيًا بمساحة الوحدات النمطية. لكنني لا أعتقد أنه سيحدث للزاوية 1.X ؛)

ولكن عند تحديد أسماء الوحدات بدون مساحة اسم يمكن أن يؤدي بسهولة إلى آثار جانبية.

نعم ، في مرحلة تهيئة الحاقن ، يكون سلوك الحاقن هو تجاوز الخدمة المعلنة بالفعل في الحاقن بصمت مع آخر إعلان.

خاصة في مشروع واسع النطاق حيث يعمل لديك أكثر من 10 فرق سكرم.

إنه شيء مثل أكثر من 50 مطورًا!

لا يمكنني التفكير في طريقة أخرى جيدة لحل هذه المشكلة.

تقسيم عملك في عدة تطبيقات؟ AngularJS غير مناسب حقًا للمشاريع الضخمة بسبب عيب تصميم مساحة اسم الحاقن.