Angular.js: طلب التعليقات: `angular.component ()` - اسم وحدة التحكم في التوجيه الافتراضي

ج) يميل المبرمجون إلى استخدام isolate:false والوصول إلى وحدات تحكم الأجداد مباشرة.

drpicox - يغريني القول إننا نحظر isolate: false للمكونات التي تم إنشاؤها باستخدام هذا المساعد.

أوافق ، بعد النظر في هذا:

• isolate: true عندما يكون التقييد هو "E": بالنسبة لي فهي مكونات حقًا ، حيث يكون لتدوين $ ctrl معنى كامل
• isolate: false عندما يكون التقييد هو "A": بالنسبة لي هم _decorators_ ، وهو نوع من مُحسِّن للمكونات الحالية ، وفي هذه الحالة يتعارض $ ctrl ، لذا لا بأس بالتسمية الحالية

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

لذلك ربما تكون فكرة جيدة لحظر isolate: false .

في مسار التفكير الآخر ، حول _decorators_ ، يجب أن تكون الوظيفة للحصول على وحدة تحكم المكون "E" للكيان الحالي فكرة جيدة ، خاصة لكتابة _decorators_ عامة للتعامل مع أي مكون حالي (يتطلب قوى لمعرفة مقدمًا أي وحدة تحكم هو ولا يمكنك استخدام نوع من الواجهة لما تبحث عنه).

أنا أحب $cmp ، لكني أجد $comp أفضل ، لأنه أوضح.

أنا أحب $cmp ، لكني أجد $comp أفضل ، لأنه أوضح.

أحب $comp . كلما رأيت $cmp أفكر "قارن".

اقتراح مختلف: لماذا لا يكون اسم المكون كاسم مثيل وحدة التحكم؟
على سبيل المثال: ملف تعريف المستخدم -> domain.userProfile

tabanliviu هكذا يتم ذلك حاليًا على master لكن petebacondarwin المذكور في هذه المشكلة بالذات ، في المنشور الأول ، لماذا الاسم الشائع أفضل.

mgol : +1: أعتقد أنني لم أفهم ذلك عندما قرأت التذكرة. هل ينبغي اعتبار هذا التغيير أكثر من مشكلة ngUpgrade؟ أعتقد في سياق 1.x الزاوي أن التنفيذ الحالي هو حل جيد. ربما يتم تعريض هذا كوظيفة إعدادات تأخذ اسم المكون وإخراج اسم وحدة التحكم؟ بهذه الطريقة فإنه يخدم النمط الحالي ومسار الهجرة في المستقبل.

وقت الدرّاجات.

+1 لـ $ ctrl.

يحتوي Ctrl على الكثير من الثقافة الموجودة مسبقًا في وثائق Angular 1 وأمثلة على أنها لاحقة "وحدة التحكم". جرب استخدام "angular ctrl" على Google للحصول على مقياس جيد.

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

: +1: لـ $ctrl ، $vm كإعداد افتراضي يبدو أشبه ببيان حول كيفية استخدام وحدات التحكم.

+1 لـ $ctrl .

لقد ناقشنا هذا الأمر بشدة على فريق ng-forward وقررنا أن ctrl مصطلح أقل تحميلًا من vm .

أنا أصوت لـ $ctrl وسأكون سعيدًا جدًا إذا كان هذا يشجع ppl على عدم الاتصال بوحدات التحكم الخاصة بهم vm بعد الآن: P

أوه ، أود أيضًا أن أضيف ذلك

يمكن الخلط بين هذا وبين إدخال عناصر ConTRoL

ناه. ليس صحيحا.

$ctrl

أعتقد أن هذا سيكون أكثر قابلية للفهم وبديهية للجميع.

+1 $ctrl

اقتراحات أخرى:

1. $ مثل - مثل وحدة تحكم
2. $ at - like @ - بينما في نص القهوة يشير إلى سياق "هذا"
3. فئة $ - على الرغم من وجود 5 أحرف ، إلا أنها قريبة من تدوين فئة المكون ng2.
4. proxies $ - منذ ذلك الحين من الناحية المفاهيمية ، فإن مثيل Ctrl هو وكيل لطبقة الخدمات
5. ctx $ - اختصار للسياق
   شكرا.

لقد قمت بالتصويت لـ $this لأنه في ng2 this من وحدة التحكم هي سياق القالب (وفي رأيي ، فإن component جيد جدًا في دور أداة الانتقال بين ng1 و ng2).

+1 لـ $ ctrl

أفضل أيضًا خاصية $ctrl ، لأنها تمثل وحدة التحكم في المكون.

+1 لـ $ ctrl

+1 لهذا $

كنت سأذهب حتى مع this وأسقط $ إذا لم يكن هناك الكثير من الاختراق للقيام بذلك. إنه أيضًا الخيار الوحيد الذي لا يختصر لشيء آخر ، وأنا أكره الاختصارات. :)

سأختار $ ctrl أو $ cc (اختصارًا لوحدة التحكم في المكونات)

+1 لـ $ ctrl

يمكننا تسميتها $troll فقط ، فهي تحتوي على القليل من $this ونصفها $controller . لا ، فقط أمزح ، أنا بخير مع $ctrl . : +1:

$ ctrl + 1

$ vm

الايجابيات

• أقل المفاهيم الجديدة
• قصيرة
• لا يمثل الكائن حقًا (لكن المطورين الذين ينتقلون سيحصلون عليه ... وهذه هي النقطة)

سلبيات

• لا يمثل الكائن حقًا (لكن المطورين الذين ينتقلون سيحصلون عليه ... وهذه هي النقطة)

$ctx - اختصار للسياق.

أكثر عمومية من $ctrl ، وأقل مجهولاً من $vm ، ولا يوجد إرباك مثل $comp أو $this .

ألقيت نظرة على محركات النموذج (Jade ، و Handlebars ، و Moustache.js ، و Dust.js ، و Nunjucks ، و EJS ، وما إلى ذلك) ويبدو أن الأسماء context ، locals أو data يتم استخدام

أيضًا $ctx ، للسياق ، ليس لديه نفس الحمل المعرفي مثل $ctrl (أو $this ) ، وبالفعل ، قلت in Angular 2, where the context is the controller .

albertosantini - تتمثل إحدى مشكلات $ctx في أن السياق الفعلي هو النطاق الحالي ، والذي يمكن الوصول إليه أيضًا مباشرةً بواسطة this .

$vc - اختصار لـ View Controller.
لقد وجدت مرجعًا في مستندات Apple

TLDR.

"... تحدد فئة UIViewController طرق وخصائص إدارة طرق العرض الخاصة بك ومعالجة الأحداث ..."

أصوت بقوة لـ $this :

<textarea ng-change="$this.handleChange">

_Pros: _

• أكبر ميزة : لست بحاجة إلى إجراء أي ctrl = this داخل وحدة التحكم الخاصة بك ، لجعل الكيانين يبدوان متشابهين.
• أي شيء بخلاف $this يبدو وكأن Angular تقدم _ "لغة أكثر احتكارية" _ ، وهي إحدى الشكاوى الشائعة حول Angular . سوف تصبح وحدة التحكم الخاصة بك ملوثة من هذا القبيل:

  controller: function() {
    var ctrl = this;

    ctrl.items = [];
    ctrl.text = '';
    ctrl.handleSubmit = function () {
        ctrl.items.push({text: ctrl.text});
        ctrl.text = '';
    };
  }

بدلاً من الأنظف والأنيق والحيادي لإطار العمل

  controller: function() {
    this.items = [];
    this.text = '';
    this.handleSubmit = function () {
       this.items.push({text: this.text});
       this.text = '';
    };

• هذا الأخير هو وظيفة JavaScript نقية يمكن إعادة استخدامها في أي مكان باستخدام Angular أو بدونه. الأول سيبدو خارج السياق في أي مكان آخر.
• لاحظ كيف أن أداة تمييز بناء الجملة هي صديقك في المقتطف الأخير وكيف تقاومك في السابق. قراءة الكود هي قضية مهمة.
• يشبه بناء الجملة هذا React كما يظهر في صفحتهم المقصودة :

<textarea onChange={this.handleChange}>

• في React يتم التعامل مع كل من سياق DOM والمثال المتحكم على أنهما نفس الكيانات تمامًا ، وحتى React تستفيد من ذلك ، مدعيةً أن نهجهما أبسط.
• من المؤكد أن Angular ليس رد فعل ، لكن الكثير من الناس يستخدمون أو ينظرون إلى كليهما ، لذا فإن المزيد من التشابه سيبدو أكثر ودية ويعرف أيضًا باسم أقل إرباكًا لهم.

dmitriz مشكلة واحدة مع $this في AngularJS ، هي أن السياق (على سبيل المثال ، this ) في القالب ليس هو المتحكم. يبدو أنهما في React (و Angular 2) هما نفس الشيء حقًا ولذا فمن المنطقي استخدام this (أو $this ). في Angular 1 ، فإنهما ليسا متماثلين ، وبالتالي فإن $this قد يسبب في الواقع مزيدًا من الالتباس.

فيما يتعلق بجانب JavaScript للأشياء ، من الشائع جدًا في كود ES5 أن يكون الاسم المستعار this لشيء آخر بسبب مشاكل الربط this عند استدعاء الطرق المجانية. لذلك ستظل وحدات التحكم في كثير من الأحيان تحتوي على شيء مثل var that = this أي حال ، وفي هذه الحالة قد يستخدم المرء أيضًا var ctrl = this .

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

dmitriz ، ليس عليك أن يكون لديك نفس الاسم المستعار في وحدة التحكم وفي العرض (لا أفعل ذلك أبدًا). بالإضافة إلى أنني أستخدم دائمًا var self = this في وحدة التحكم ، لتجنب الاضطرار إلى .bind(this) لعمليات رد الاتصال وما إلى ذلك.
لذا ، لا ينبغي أن تكون هذه مشكلة يا إيمو.

فيما يتعلق بالخيارات الأخرى:

• $ctx : لا أحب هذا ، لأنه (كما ذكر petebacondarwin ) ، المتحكم ليس سياق التعبيرات.
• $this : لا أحب هذا ، لأنه (في التعبيرات الزاويّة) this هو اسم مستعار خاص للنطاق الحالي ، لذا فإن وجود this --> scope و $this --> controller سيكون أكثر إرباكًا. (كنت سأحب ذلك بخلاف ذلك.)
• $vm : لا يعجبني هذا (للأسباب التي سبق ذكرها) ، لكن يمكنني التعامل معها إذا لم يكن هناك ما يفي بقيودنا بشكل أفضل.
• $cmp : ليس مرضيًا للغاية (لأنه ليس دقيقًا بنسبة 100٪) ، ولكنه إعلاني بدرجة كافية. يمكن أن يتماشى معها إذا لم يكن هناك ما يفي بقيودنا بشكل أفضل.
• $comp : أفضل $cmp ، لأنه أقصر (ولم أجده أكثر "قادرًا على الخلط" مع compare عن $comp ).
• $ctrl : أحب هذا كثيرًا. إنه قصير جدًا وتوضيحي ودقيق قدر الإمكان. لقد قمت دائمًا بلصق وحدات التحكم الخاصة بي بـ ctrl ولم أشهد أبدًا أي ارتباك مع ConTRoL (لكن الأشخاص الأكثر دراية يصرون على وجود ارتباك :)). إذا قررنا أن الارتباك ليس مشكلة ، فسأذهب بالتأكيد مع هذا ، لكنني بخير مع شيء آخر.
• $troll : تحتاج إلى مزيد من التفكير. من المؤكد أن لديها إمكانية: stuck_out_tongue:
• خيارات أخرى ( $as ، $at ، $cc ، $prox ، $vc ): أعتقد أنهم يقدمون مفاهيم جديدة وسيكونون أكثر مربكًا أكثر من كونه مفيدًا.

أنا أصوت لـ $ctrl ، لأنها _ هي وحدة التحكم في التوجيهات. بسيط.

ضد الآخرين:

• $vm - كما أشرنا سابقًا ليست نية مطلوبة للاستخدام => إما ارتباك في قراءة النمط / الكود أو اختيار أقل للمطور (مجبر على تنفيذ vm)
• $cmp - حسنًا ، ليس المكون نفسه ولكن (فقط) وحدة التحكم؟ حتى مضللة فعلا؟
• $this - سبق ذكره أيضًا ، إنه محير. ما الذي يجعله مثيل وحدة التحكم "هذا" في النطاق؟ معنويًا ، لا أرى أن هذا يمكن أن يكون .. حسنًا .. مفهوم؟
• $ctx - في الواقع مثل $this .

كما قال باسكال بالفعل: لا أرى التباسًا مع عناصر التحكم. ما لم تقم Angular2 بحقن جميع عناصر DOM / المدخلات بهذه الطريقة (مثل $ ctrl و $ val و $ cmbx وما إلى ذلك) ، لا أرى أن هذه مشكلة.

+1 $ctrl

في نفس السطر من التعليقات السابقة:

• $vm ، $as ، $at ، $cc ، $prox ، $vc ، $ctx ،. ..: يقدم مفاهيم جديدة غير ضرورية للمبرمجين
• $this : نظرًا لوجود this بالفعل ، فقد يكون الأمر محيرًا للمبرمجين
• $cmp أو $comp : (الأفضل أولاً) يجب أن يكون لطيفًا لأنه يركز المبرمجين على نموذج المكوّن ، لكنهم قد لا يكونون مباشرة إلى الأمام
• $ctrl : هو فقط ما يتم نشره في النطاق ، وحدة التحكم ، لذلك يبدو من الواضح حقًا أنه من السهل فهمه واستخدامه

أرى ، شكرًا للتوضيح ، لم أكن أعرف this = $scope لكن ، نعم ، هذا يستبعد ذلك.

إذن ، يبدو أن $ctrl هو الخيار الأفضل التالي ، بصرف النظر عن $troll وهو :)

+1 لـ $ctrl : الأكثر بديهية والأكثر عمومية

petebacondarwin شكرا على التفاصيل.

لذا +1 $ctrl .

أفضل الاسم التعريفي $ctrl كاسم افتراضي.

لماذا لا خير؟

تضمين التغريدة

لماذا لا يعتبر VM تمثيلاً جيدًا؟

(إذا كنت قد ناقشتها بالفعل بشأن قضية مختلفة ، فما عليك سوى الارتباط بها إذا استطعت)

نظرًا لأن AFAIK ، فإن وحدات التحكم في Angular أقرب إلى نماذج العرض بدلاً من وحدات التحكم الكلاسيكية من MVC. لكن ربما أفتقد شيئًا ما.

+1 ل $ vm

أوافق على نقاط QuinntyneBrown -

إنه أقصر.

لكن الأهم -

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

إذا قمنا بتغيير هذا هنا ، يجب أن نأخذ في الاعتبار تأثير ذلك على المطورين الجدد (ربما إرسال PR إلى دليل النمط)

لهذا السبب أحب الاسم الأقصر "$ vm" (راجع للشغل ، لماذا يجب أن يبدأ بـ $ ؟ :)

(راجع للشغل ، لماذا يجب أن تبدأ بـ $؟ :)

تبدأ الأسماء المعرفة الزاويّة بـ $ عندما تشترك في مساحة الاسم مع تعريفات المبرمج ، فإنها تتجنب الاصطدامات. في هذه الحالة ، يتم تعريفه بواسطة Angular ويتم تعريفه داخل النطاق ، حيث يمكن للمبرمج أن يكون له تعريفاته الخاصة. باستخدام $ نتجنب تضارب الأسماء ويتصرف Angular باستمرار مع ما يتوقعه المبرمجون.

(johnpapa) الغرض من دليل الأسلوب هذا هو تقديم إرشادات حول إنشاء تطبيقات Angular من خلال إظهار الاصطلاحات التي أستخدمها ، والأهم من ذلك ، لماذا أختارها.

النمط Y032 استخدم متغير الالتقاط لهذا عند استخدام وحدة التحكم اختر اسم متغير ثابت مثل vm ، والذي يرمز إلى ViewModel.

لذلك لا يهم إذا كان vm ، أو ctrl ، أو troll ، يجب أن يكون متغيرًا ثابتًا.
بالإضافة إلى ذلك ، كما أشرت سابقًا ، فإن الفكرة ليست إضافة مفاهيم جديدة: vm تعني ViewModel ، إذا كنت لا تستخدم نماذج العرض أو لم تكن على دراية بها ، فلن تفهم ما يعنيه vm أو ViewModel ، والذي سيكون محيرًا.

أنا لست من محبي الأسماء المربكة. أعتقد أن ctrl محير. فمن تحكم؟ التحكم (مثل عنصر تحكم HTML)؟ وليس هذا لمكون؟

أصوت إما لـ vm أو comp . يشيع استخدام vm ويسهل شرحه. comp جديد ، لكن ليس من الصعب التكهن.

ماذا عن $ctlr (أي ConTroLleR) بدلاً من $ctrl ؟

+1 دولار شركات

petebacondarwin يا كمية عسر القراءة (مثلي) الذين سوف يقصفوننا بمشاكل حول هذا ... :)

drpicox شكرا للتوضيح ، أرى نقاطك وهي صالحة. إنه أمر صعب ، لكن يمكنني مشاركة ذلك على الأقل من تجربتي ، لم أجد صعوبة في تعليم المطورين اتفاقية "vm" ، وساعدت عددًا قليلاً من الشركات في بناء تطبيقهم الضخم بهذه الطريقة ، لقد حصلوا عليه بسرعة كبيرة ، لكن ربما م وحده في هذه التجربة.

لكني أفهم نقاطك. أتفق مع $

ما زلت مقابل $ vm ، لكنني بخير مع $ comp أيضًا ...

يبدو أن wesleycho من فريق Angular UI Bootstrap ضد vm :
https://github.com/angular/angular.js/issues/10007#issuecomment -166707284

+1 لـ $ctrl

shairez أشاركك تمامًا وجهة نظرك حول وجود اتفاقية ، فأنا مهندس معماري مستقل ولدي عشرات المشاريع في الخلف ، وقد ساعدت اتفاقية vm كثيرًا ، لكن لا يزال لدي بعض المشكلات. اتضح أن هناك من يقاوم استخدامه. من المحتمل أن تكون المقاومة أقل إذا كانت هذه الاتفاقية تأتي من Angular نفسها ، لكنني متأكد من أنه إذا كان الاسم $ctrl فسوف يقبلونها كما هي ، دون أي مقاومة. $ctrl هو مجرد أمر مستقيم للأمام.

حسنًا ، تم التصويت عليه ويبدو كالتالي:

$comp  4
$cmp   2
$ctrl  19
$vm    3
$this  3
$ctx   2
$vc    1

المفضل الواضح هو $ctrl . بالإضافة إلى كونه شائعًا ، فإنه يجتاز المعايير المنشورة في الجزء العلوي من هذا العدد. بالإضافة إلى أنه لا يقدم أي مفهوم جديد بشكل خاص. الشيء الذي يشار إليه حقًا هو وحدة تحكم (عنصر / وحدة تحكم توجيهية) يفهمها مطورو Angular بالفعل ، وكما اعتاد بعض المطورين على استخدام vm في توجيهاتهم ، فلن يستغرق المطورون وقتًا طويلاً على هذا الافتراضي.

رائع ، $ ctrl هو كذلك!

الإصدار 1.4 وأقل - لا يمكن تسمية "كاسم" بـ $ctrl

مصدر قلق آخر أود أن أثيره هو أنه في الزاوية 1.4 وأقل ، لا يمكننا حقًا استخدام "كأسماء" بدءًا من علامة $ .

يعطي الخطأ التالي:
Error: [$controller:ctrlfmt] Badly formed controller string

تواجه بعض الشركات مشكلة في الترقية إلى أحدث الإصدارات ، وقد يستغرق الأمر عدة أشهر.

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

بالنسبة لهم ، التبديل من vm إلى $ctrl أمر مستحيل.

ما رأيك؟ أي اقتراحات؟

ربما تهاجر على مراحل:
ابدأ بتحويل vm إلى ctrl
عند إصدار 1.5 ، "قم بترقية" ctrl إلى $ctrl

هناك طريقة أخرى محتملة - على الرغم من الإسهاب - وهي إنشاء وحدة تحكم كاسم مستعار في وقت التشغيل ، والتحقق angular.version . شيء مثل:

 angular
        .module('github')
        .directive('issueThread', issueThread);

    /* <strong i="14">@ngInject</strong> */
    function issueThread () {
        // this can be required as a module if using some module loader
        // or - another way is using global on angular namespace (i know it a bad practice - hwoever just to indicate reuse of this check 
        let prefix = angular.version.minor === 5 ? '$' : '';
        let controllerAs = prefix + 'ctrl';
        // with template strings
        var controllerAs = `${prefix}ctrl`;

        var directive = {
            controller: controller,
            restrict: 'E'
        };
        return directive;

        function controller() {
        }
    }

orizens ماذا عن القوالب؟

shairez Uhmmm من المنطقي ، الرموز $ مخصصة فقط للأجزاء الداخلية الزاويّة ... قد يكون لها نوع من التوافق الأمامي في المرحلة الثانوية التالية أمر رائع.

drpicox حصلت على نقطة هناك :).
مرة أخرى ، أحد الحلول التي يمكنني التفكير فيها (حل مبتكر ...) هو ، "استبدال" ctrl بـ $ ctrl في قالب في وقت التشغيل / الإنشاء. يمكن تحقيق ذلك بسهولة إذا تم بناء المشروع باستخدام es6 والوحدات النمطية. خلاف ذلك ، إنها مهمة gulp / grunt / npm في وقت الإنشاء.

لماذا لا تستخدم فقط controllerAs ؟
إنه ليس حلاً مثاليًا (وقد نحتاج بالفعل إلى مراجعة RegExp الذي يستخرج المعرف من سلسلة وحدة التحكم (إن وجد) ، ولكن استخدام controllerAs متوافق مع الإصدارات السابقة والعودة :)

(إذا أراد أي شخص الحصول على فرصة لتحديث هذا المعرف باستخراج RegExp ، فهو موجود بالمناسبة.)

gkalpak هذه نقطة جيدة ، فالمضي قدمًا في الترويج لاستخدام الخاصية controllerAs أمر جيد لأن المزيد والمزيد من الناس سينتقلون أيضًا إلى استخدام المكونات في 1.4 والإصدارات الأقل على ما أعتقد.

لكن ، أعتقد أنه قد يكون محيرًا إذا بدأنا في تعليم الناس حوالي $ctrl وفي بعض الحالات يكون الأمر ناجحًا وفي بعض الحالات لا يكون كذلك.

لذا فإن التوافق إلى الأمام (لست متأكدًا من كيفية ذلك) ، هو فكرة رائعة!

shairez هل (هل يمكنك) إنشاء عدد جديد لتتبع هذا؟

لقد قمت بإنشاء # 13736 والذي يسمح للمعرف $ ، عند استخدام <ctrl> as <identifier> .
لا تزال المعرفات المسموح بها مختلفة بين controller: '... as ...' مقابل controllerAs: '...' .

ومع ذلك ، لست متأكدًا من أن الترويج لـ controller: '... as $ctrl' هو وسيلة جيدة لمواكبة الاتفاقيات. يعد ترقية controller: '... as $ctrl' controller: '...', controllerAs: '$ctrl' .

شكرًا gkalpak - أوافق على أنه ينبغي لنا على الأرجح تشجيع استخدام الخاصية controllerAs بدلاً من وحدة التحكم كتركيب.

شيء واحد هو: توثيق المكون يقول: "تعريفات المكونات بسيطة للغاية ولا تتطلب الكثير من التعقيد وراء تحديد التوجيهات العامة".
عنصر آخر: الضابط في التوجيه ضروري فقط إذا قمت ببناء توجيهات معقدة تتحدث مع بعضها البعض. بخلاف ذلك ، تكون وظيفة الارتباط أكثر من كافية (على سبيل المثال ، "استخدم وحدة التحكم عندما تريد عرض واجهة برمجة تطبيقات لتوجيهات أخرى. بخلاف ذلك ، استخدم الرابط" في توجيه دليل المطور ، ومن تجربتي تنفذ التوجيهات نفس الوظيفة مع الارتباط بدلاً من وحدات التحكم المستخدمة مئات المرات في نانوغرام تكرار أسرع بكثير.
وبالتالي...
لا أجد في المكون (التوجيه البسيط) طريقة القيام بـ "البسيط" (وظيفة الارتباط) ، فقط الشيء الثقيل (وحدة التحكم).
هل افتقد شيء؟
شكرا على الشرح.

frfancha - يرجع تحسن الأداء إلى عدم الاضطرار إلى استخدام $injector لإنشاء وحدة التحكم ، أليس كذلك؟ ربما لديك بعض قياسات الأداء التي يمكنك تقديمها؟

تتمثل فكرة مساعد المكون في تسهيل كتابة توجيهات نوع المكون (عزل ، عنصر) (بمعنى LOC) ؛ وأسهل في كتابة التعليمات البرمجية التي تكون أكثر انسجامًا مع كيفية إنجاز الأشياء في Angular 2.

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

أعتقد أننا بحاجة إلى إلقاء نظرة على مستندات API الأخرى وأدلة المطورين للتأكد من أنها متوافقة مع المساعد الجديد component() .

petebacondarwin في البداية ، كتبنا جميع توجيهاتنا باستخدام وحدة التحكم ، فقط لأنها عُرضت بهذه الطريقة في البرنامج التعليمي الأول الذي اتبعناه.
فقط بعد أن وجدنا أن الأمر استغرق حوالي 15 ثانية "لفتح" صفحة معينة بها 1000 توجيه (5 في "صفوف" في ng-تكرار x 200) ، قرأنا المزيد عن التوجيهات وفهمنا أن أدوات التحكم غير مجدية إذا لم تفعل ذلك " التحدث "بين التوجيهات (من خلال مطالبة مراقب واحد آخر). بعد "إعادة كتابة" الكل باستخدام وظائف الارتباط بدلاً من وحدات التحكم (إعادة الكتابة كلمة كبيرة حيث كانت مجرد نسخ / لصق الرمز في الرابط بدلاً من وحدة التحكم) ، كان وقت عرض الصفحة 8 ثوانٍ.
لاحظ أن هذه هي إجراءات Firefox ، في ذلك الوقت لم نستخدم Chrome. الآن نستخدمه وأقدر الوقت في Chrome ليكون هو الثالث من Firefox (واستخدام الذاكرة هو الرابع (وبدون تسرب الذاكرة ، وهو أمر رائع ، في Firefox يُعرف تطبيقنا بأنه "بطيء في فترة ما بعد الظهر)).
بشكل عام ، نحن سعداء جدًا بالزاوية (لقد قمنا بتحويل جميع تطبيقات إدخال البيانات الخاصة بنا من تطبيق windows Smalltalk إلى WEB API + angular (في حالة اهتمامك برؤيتها ، فأنا أحيانًا في لندن).
لكنني مندهش من اختيار وحدة التحكم لدعم "الطريقة البسيطة" للقيام بالتوجيه

شكرا gkalpak !

petebacondarwin ، قضية منفصلة لم تعد ذات صلة ، أليس كذلك؟ (بسبب العلاقات العامة)

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