Angular: الاقتراح: الحاجة إلى القدرة على إضافة توجيهات إلى عناصر المضيف في إعلان المكون.

تم إنشاؤها على ٢٣ مايو ٢٠١٦  ·  114تعليقات  ·  مصدر: angular/angular

لقد كنت أحفر في Angular 2 وواجهت عقبة طريق محتملة لتوسيع أنواع معينة من المكونات.

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

  • قم بتمديد TouchClass مباشرة. يبدو هذا أقل من مثالي نظرًا لأن الكتابة المطبوعة لا تدعم الميراث متعدد الفئات ، وأود أيضًا أن أعرض السلوك للمستهلكين لاستخدامه في فصولهم الخاصة.
  • توريث فئات متعددة وهمية من خلال واجهة. هذا يبدو وكأنه اختراق ويتطلب مني إعادة تعريف shim api في كل فصل أحاول الاختلاط به. https://www.stevefenton.co.uk/2014/02/TypeScript-Mixins-Part-One/
  • قم بإنشاء دالة مساعدة تقوم بذلك من خلال خدمة مباشرة على elementRef.nativeElement في مُنشئ المكون. لا أريد فعل ذلك حقًا لأنه ينص في المستندات على أن العنصر الأصلي سيكون فارغًا عند العمل في عامل ، وهذه القدرة هي أكثر شيء متحمس له.

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

السلوك الحالي
إعلان توجيه في componentMetadata.host يعامله كسمة عادية

السلوك المتوقع / المطلوب
سيتم معالجة التوجيه المعلن في المضيف في وقت الترجمة.

/**
 * App
 */
@Component({
    selector: 'app-component',
    template: '<g-btn>TEST</g-btn>',
    directives: [gBtn, gTouch]
})

export class AppComponent {
    constructor() {

    }
}

/**
 * Touch Directive
 * Will be used in lots and lots of components
 */
@Directive({
    selector: '[g-touch]',
    host: { 
        '(touchstart)': '...',
        '(touchend)': '...',
        '(touchmove)': '...',
        '(touchcancel)': '...'
    }
})

export class gTouch {
    constructor() {

    }
}

/**
 * Simple button component
 */
@Component({
    selector: 'g-btn',
    template: '<ng-content></ng-content>',
    host: {
        'role': 'button',
        // WOULD LOVE FOR THIS TO COMPILE THE DIRECTIVE!
        // right now it just adds an attribute called g-touch
        'g-touch': ' ' 
    }
})

export class gBtn {

    constructor() {

    }
}

بعض الأفكار حول كيفية عمل ذلك:

// Option 1: just scan the host properties for directives.
// This would be my ideal, simple and understandable
@Component({
    selector: 'g-btn',
    template: '<ng-content></ng-content>',
    host: {
        'role': 'button',
        'g-touch': true // or {prop: 'foo'} or string
    }
})

// Option 2: definitely more declarative using a hostDirectives property
// more declarative, albeit more annoying to have to reimport the touch class
@Component({
    selector: 'g-btn',
    template: '<ng-content></ng-content>',
    hostDirectives: gTouch,
    host: {
        'role': 'button',
        'g-touch': true
    }
})

// Option 3: declare host directives as its own thing, still just
// use keys pointing to bool, obj, or string
@Component({
    selector: 'g-btn',
    template: '<ng-content></ng-content>',
    hostDirectives: {
        'g-touch': {someOption: someOption}
    },
    host: {
        'role': 'button',
    }
});

// Option 4: Not a huge fan of this one, but understandable if
// people want to keep one host property
@Component({
    selector: 'g-btn',
    template: '<ng-content></ng-content>',
    host: {
        'role': 'button',
        _directives: {
            'g-touch': true
        }
    }
});

شكرًا للجميع ، Angular 2 تبدو رائعة !. اسمحوا لي أن أعرف إذا كان هناك شيء مفقود.

core directive matching host and host bindings feature

التعليق الأكثر فائدة

IgorMinar عمل Ivy يجعل هذا أكثر جدوى. ولكن نعم الماضي v6.

ال 114 كومينتر

أقوم حاليًا بتطوير عميل كبير وبالتالي أحاول تقسيم جميع المشكلات المتعلقة بواجهة المستخدم الرسومية إلى توجيهات Angular2 قابلة لإعادة الاستخدام. هذا يقودني دائمًا إلى نفس المشكلة ، كما أوضح جيمس تمامًا.
هذا حقًا يجب أن يعمل بطريقة ما من أجل بنية معيارية وديناميكية جيدة. مثال اللمس هو واحد فقط من العديد من السيناريوهات التي تتطلب ذلك. على سبيل المثال ، السحب والإفلات ، تغيير حجم المراقبة ، إلخ.
قدم مثالًا آخر على أنه غطاس:
https://plnkr.co/edit/J65THEMic0yhObt1LkCu؟p=info

هل هناك أي فرصة لإضافة هذه الوظيفة في أي وقت قريب؟

إليك سؤال StackOverflow يتعلق بهذا: http://stackoverflow.com/questions/37148080/use-angular2-directive-in-host-of-another-directive

@ Andy1605 هل وجدت طريقة للتغلب على هذا؟ لقد قمت نوعًا ما بجدولة العمل مع NG2 بسبب هذا أثناء RCs. أرغب في استعادته احتياطيًا ، لكن هذه المشكلة بالذات تمنعني من إنشاء أنماط واجهة مستخدم قابلة للتوسيع.

أشعر أيضًا أن Angular يفتقد ميزة أساسية هنا. يجب أن يكون من الممكن للمكون الإعلان عن (متعددة) توجيهات السمات لمضيفه. عدم القدرة على القيام بذلك هو عائق كبير لمشروعي أيضًا.
هل يعرف أحد ما إذا كان سيتم تنفيذ ذلك في المستقبل أو إذا كانت هناك أسباب لعدم القيام به؟

لقد اقترحت حلاً لهذه المشكلة (وإن كان للإصدار الزاوي 1) هنا: https://github.com/angular/angular.js/issues/15270.

فكرتي هي ، بدلاً من مجرد امتلاك القدرة على إضافة التوجيهات ، سيكون لإطار التجميع نقطة توسع جديدة تسمى "hostTransforms" (في حالة الزاوية 1 ، "nodeTransforms") والتي سيكون لها حق الوصول إلى إعلان المكون غير المعدل وغير المصفاة والعقدة الأصلية لمضيفة المكون غير المجمعة عندما يصادف المترجم مكونًا لأول مرة ويتم تحضيره لإدراجه في DOM. بهذه الطريقة يمكن للمطور أن يوسع أدوات تزيين المكونات بخصائص مخصصة ، ثم يستخدم nodeTransforms لتحويل تلك الخصائص المخصصة إلى شيء مألوف للإطار الزاوي ، قبل التجميع مباشرة. تحقق من موضوع طلب الميزة للحصول على أمثلة.

أنا أكثر دراية بكود المصدر الزاوي أكثر من الكود المصدري الزاوي 2 ، لذلك لست متأكدًا مما إذا كانت عملية التنفيذ ستكون هي نفسها هنا. ولكن نظرًا لأن هذا يبدو طلبًا شائعًا جدًا ، فأنا أرغب في رؤيته إما مطبقًا في الزاوية 2 و backported ، أو تم تنفيذه في angularjs وإعادة توجيهه (هل هذا شيء؟).

+1

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

ماذا عن إنشاء علامة جديدة مشابهة لـ <ng-container> تتيح لك تطبيقها في قالب المكون بدلاً من خاصية البيانات الوصفية host ؟ شيء مثل <ng-host [attributeDirective]> للإشارة إلى أنه تمت إضافة التوجيهات إلى مكون المضيف.

jjstreet يبدو replace: true (من الواضح أنه ليس متطابقًا ، لكنه متشابه) ، والذي تم إهماله منذ فترة. ولكن ربما تم إهمال replace: true لسبب لا ينطبق هنا.

@ pkozlowski-openource هل يمكننا الحصول على رد من أي نوع من فريق ng2 على هذا؟

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

+1 هذه الميزة مطلوبة للحصول على كود نظيف وقابل لإعادة الاستخدام في مكونات واجهة المستخدم

+1

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

أود إضافة حالة استخدام أخرى لهذا الغرض. سيسمح لـ ng2-mobx (https://github.com/500tech/ng2-mobx) بالتخلص من مكون التغليف وتبدو أكثر نظافة.

أود أن أحصل على هذا أيضًا. أحتاجه حاليًا لإنشاء توجيه مخصص routerLink . أرغب في إعادة استخدام الزاوي وتزويده بالمعلمات المعدة بواسطة توجيه mi.

لذا فبدلاً من <a [routerLink]="repeatedCodeToGetLink()"> سيكون لدي <a [myRouterLink]> وسيتم تطبيق [routerLink] ديناميكيًا مع المعلمات التي تم حلها.

متحمس حقا حول احتمالات هذا!

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

لقد قدمت مثالاً مفصلاً عن كيفية قدرتنا على استخدام هذه الميزة لحل https://github.com/angular/flex-layout/issues/162 الذي فتحناه لفترة من الوقت. ( انظر المثال والشرح هنا )

نحن نتطلع حقًا إلى أي تعليقات ، وأرى أن هذه المشكلة هي ثالث أكبر مشكلة في جميع المشكلات المفتوحة في هذا الريبو. نأمل أن نتمكن من رؤية هذا في الإصدار التالي أو في وقت أقرب (الأصابع متقاطعة)!

/ سم مكعبtboschIgorMinarmheveryjelbournhanslThomasBurleson

jjstreet أعتقد اقتراحك

<ng-host myDirective="foo"></ng-host> 

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

انظر https://github.com/angular/angular/issues/7297

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

Parent.html
<my-component myDirective>

مكونات
@HostListener('myEvent') handler() { // do stuff }

ولكن سيكون من الأنظف إذا تمكنا من إضافة سمات مباشرة في المضيف ...

إليكم كيف كنت أتعامل مع هذا ، لكنني أعتقد حقًا أن تنفيذ هذه الميزة من الأرض سيكون أفضل حل.

مجرد تذكير شهري بأننا ننتظر تعليقًا إيجابيًا أو سلبيًا على هذا من فريق Angular.

tbosch - أي أفكار عامة حول أولوية هذه المسألة. يؤثر أيضًا على @angular/flex-layout .

fadzic لا يمكنك فقط إضافة التوجيه إلى عنصر المضيف من خلال القيام بذلك ...

مكونات
@HostBinding('attr.myHilite') myHilite = new myHiliteDirective()

أو مثل هذا إذا كنت بحاجة إلى معلمات مثل ElementRef أو Renderer2
@HostBinding('attr.myHilite') myHilite = new myHiliteDirective(this.elementRef, this.renderer)

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

btinoco لا يعمل لأنه لم يتم استدعاء أي طرق دورة حياة. سيتعين عليك توصيل كل شيء يدويًا في كل مكون يستخدم التوجيه بدلاً من مجرد الحصول على سلك Angular من أجلك.

hccampos شكرا على ngOnInit الخاص بتوجيهي (ما لم أستخدم التوجيه في المكون الخاص بي يدويًا) أو اتصل بالتوجيه ngOnInit() على المكون الخاص بي ngOnInit() . مرة أخرى أشكرك على إخباري بذلك.

btinoco - نعم. إنها قضية خفية ولكنها سيئة. واحد يأمل @ الزاوي / المرن التصميم سيتم إصلاحه قريبًا. ؛-)

هل من أخبار من فريق Angular عن هذا؟ لقد مر عام على فتح الإصدار ...

كان العثور على هذا الوصف التفصيلي حول هذه المشكلة رائعًا للغاية ،
ثم لم يكن العثور على أي تعليقات من فريق Angular رائعًا للغاية :(

فيما يتعلق بالحلول التي تعمل بالفعل:

يبدو طلب هذه الميزة إلى حد كبير مثل mixins. في الواقع ، الرصاصة رقم 2 في الوصف
من هذه الميزة يطابق في الواقع المسؤول
توثيق TypeScript ، انظر هنا .
في الزاوية ، يصبح هذا أسوأ قليلاً ، عند مزج فئة بـ @Input() s ، فأنت
يجب إعادة التصريح عنها في الفئة الأساسية.

الحل الآخر الذي يعمل بالفعل اليوم هو جعل المكون يحتوي على عنصر غلاف وتطبيق التوجيهات هناك.
على سبيل المثال ، إذا احتوى المكون على قالب مثل <wrapper g-touch>...

بخصوص "إنشاء دالة مساعدة تقوم بها من خلال خدمة مباشرة على elementRef.nativeElement":
نعم ، تبدو هذه فكرة جيدة أيضًا. لا يهمني WebWorkers في الوقت الحالي ،
لأنها لا تزال تجريبية وتفتقد بعض الميزات الأكبر للإنتاج ،
وتقريبا لن تعمل أي مكتبة على WebWorkers.
انظر أيضًا إلى مكتبة المواد الخاصة بنا والتي تصل إلى DOM مباشرة.

فيما يتعلق بالخيار 1) من الاقتراح:

الدلالات الحالية لارتباطات خاصية المضيف هي ،
أنهم قاموا بتعيين خاصية myDir على عنصر HTML الأساسي ،
لكن ليس أي توجيه. ومع ذلك ، إذا كان بإمكان host أيضًا تقديم توجيهات ، فيمكن للمستخدمين كتابة ما يلي
وسوف يتم الخلط بين سبب عدم تحديث هذا الخاصية في التوجيه myDir :

@Component({
  host: {
    '[myDir]': true
  },
  template: '...'
})
class MyComp {}

فيما يتعلق بالخيار 1) والخيار 3):
إن تقديم نوع من الارتباطات host بين التوجيهات على نفس العنصر يمكن أن:

  • يؤدي إلى دورة في الرسم البياني لربط البيانات ، والتي لا يدعمها Angular ، وبالتالي
    يؤدي إلى صعوبة تصحيح الأخطاء بسبب القيم التي لا معنى لها / أخطاء "تم تغيير التعبير بعد التحقق".
  • يؤدي إلى زيادة الأداء ، مقارنةً بالتوجيهات التي تحقن بعضها البعض
    والتواصل مباشرة.

فيما يتعلق بالخيار 2) من الاقتراح:

  • نعم ، إن الحاجة إلى الرجوع إلى فئة gTouch تبدو غريبة ، مثل جميع التوجيهات الأخرى
    يتم تشغيلها عبر NgModule s.

ThomasBurleson لنتحدث دون اتصال عن حالة الاستخدام الخاصة بك بمزيد من التفاصيل ...

tbosch أود اقتراح خيار آخر: تقديم علامة زاوية أصلية ، دعنا نسميها <ng-host> .

ملاحظة: اقترح mhevery إدخال علامة <ng-host> في https://github.com/angular/angular/issues/7546 ، ومع ذلك ، على الرغم من أنني أستخدم نفس اسم العلامة هنا ، ما أنا عليه الاقتراح منفصل ويقصد تحديدًا معالجة المشكلة التي أثيرت هنا.

لن يتم تنفيذ علامة ng-host كصنف توجيه / مكون عادي ، ولكن سيكون بدلاً من ذلك رمز إطار عمل "سحري" ... مشابه لـ ng-content ، ng-container ، إلخ .. . ،
ستعمل العلامة ببساطة كمؤشر لمضيف المكون بطريقة مماثلة لمحدد css

لتجنب السيناريوهات الغامضة ، لن يُسمح لكل مكون إلا أن يحتوي ، على الأكثر ، على كتلة <ng-host> ويجب أن تكون العلامة / العقدة الجذرية لقالب هذا المكون.

إليك كيف يمكن للمرء استخدامه:

// Option 5: Use `<ng-host>`.. Very declarative and intuitive
@Component({
  selector: 'g-btn',
  template: `
    <!-- 
      Besides comments, having dom code inside the template but outside of a declared 
      ng-host code block would raise an error (hopefully at compile-time) .
    -->

    <ng-host role="button" g-touch> 
      <ng-content></ng-content>
    </ng-host>
  `
})

بالمناسبة tbosch ، شكرًا لك على الرد على الإطلاق. نحن نقدر حقًا مشاركتك وتعليقاتك على هذه المشكلة.

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

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

MikeMatusz يبدو أنني كنت أفكر في ذلك أيضًا ، إليك مقتطفتي من https://github.com/angular/flex-layout/issues/162#issuecomment -290350270.

@Directive({
  selector: 'fxLayoutFullPage',
  hostDirectives: [LayoutDirective],
  host: { 
    'fxLayout': 'column', 
    'style': 'min-height:100vh; background-color:yellow'
  }, 
}) class LayoutFullPageDirective {}

هل سيكون من الممكن إنشاء مصمم عقارات يقوم بإنشاء أمر توجيهي؟
على سبيل المثال:
@HostDirective(LayoutDirective) myLayoutDirective: LayoutDirective;

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

أين هذا الموقف؟ أنا جديد إلى حد ما على Angular2 / 4 ، وما أريد فعله هو إنشاء توجيه يطبق عدة توجيهات أخرى في وقت واحد. لذلك بدلاً من:

<button directiveA directiveB directiveC>BUTTON TEXT</button>

يمكنني فقط أن أكتب:

<button customDirectiveABC>BUTTON TEXT</button>

يجب أن يكون الشعور مثل هذا سهلًا - التكوين الأساسي / الجفاف. لكن بقدر ما أستطيع أن أقول أنه غير ممكن؟

soynog ، أشعر بنفس الشيء تمامًا. أود أيضًا أن أعرف أين يقف هذا.

كنت آمل أن أكون قادرًا على إنشاء مربعات حوار قابلة للسحب باستخدام Angular Material و angular2-pullgable (نظرًا لأن الزاوية / المادة # 1206 غير مدعومة بعد) حيث أرغب في إضافة توجيه ديناميكيًا إلى md-dialog-container ذلك MdDialog ، ولكن يبدو أنه من الصعب الحصول على سلوك مترجم Angular 1.x هنا للتوجيهات الديناميكية.

tbosch ، ThomasBurleson ، هل كانت حالة الاستخدام غير المتصلة بالإنترنت التي ناقشتها تتعلق بالقضايا أو الأهداف التي أثارها توماس في الزاوية / المادة # 1206 بالصدفة؟ أنا فقط أحاول أن أحيط رأسي حول التغييرات السلوكية بين 1.6.x و 2+ إطارات.

هل هناك أي تحديثات بشأن هذه القضية؟ اكتسبت قوة جذب في البداية ولكني أعتقد أنها لم تحظ بأي اهتمام بعد الآن.

نعم أي تحديث على ذلك؟

هذا شيء أحتاجه بشدة ، أتمنى أن يشق هذا الاقتراح طريقه إلى المنبع.

سيكون هذا رائعًا ، أدركت اليوم أنني لا أستطيع تطبيق التوجيهات برمجيًا / ديناميكيًا ، لقد حزنت.

+1
نفس الشيء بالنسبة لي :)
أنا أبحث عن طريقة للالتفاف على توجيهات متعددة ملزمة في توجيه مخصص يقوم بكل ما أحتاجه. على سبيل المثال :

<my-cmp [myDirective]="content"
        [isOpen]="myCondition"
        customProp2="customClass"
        customProp1="customText">
 ...
</my-cmp>

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

<my-cmp myCustomDirective>
</my-cmp>

وفي توجيهي المخصص

<ng-host [myDirective]="content"
        [isOpen]="myCondition"
        customProp2="customClass"
        customProp1="customText">
</ng-host>

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

IgorMinar - هل يمكننا

أود أن أعرف ما إذا كانت هذه الميزة ستعتبر نمطًا سيئًا أم لا. أي واحد؟

darkbasic - AFAIU ، بدون هذه الميزة ، سيحتاج المطور إلى إدخال عنصر غلاف (على ng-container ) ببساطة لإضافة التوجيهات الأصلية إلى عرض القالب والمحتوى.

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

bradlygreen أي تعليق؟

هذه الميزة هي الطلب الأكثر شيوعًا (إن لم يكن أعلى 5) من بين جميع الإصدارات المفتوحة لهذا الريبو ... عبر الإنترنت ، نشاهد تقارير (مدعومة ببيانات تجريبية) عن تراجع Angular كإطار عمل فعلي ... أعتقد أحد الأشياء التي تدفع إلى الشعور بأن المجتمع لا يُسمع. المنافسة؛ تكتسب vue.js و response ، تقدمًا وتجاوزت الزاوية لأنها على الرغم من أنها قد لا تنفذ بالضرورة كل الأشياء الصغيرة التي يريدها كل شخص ، إلا أنها تقدم ملاحظات مستمرة حول العناصر المطلوبة الأكثر شيوعًا. إنه لأمر محبط للغاية الانتظار طويلاً وعدم سماع أي شيء .. ولا حتى عبارة بسيطة "لا ، لن نفعل ذلك".

(راجع قسم أطر Js "الزوايا الزاويّة" )

. حل بقائمة بسيطة من التوجيهات التطبيقية) ... لذا فإن الموقف الملموس لفريق Angular core سيكون موضع ترحيب كبير ... 🥇

لا يوجد وقت محدد لوقت محدد ، ولكننا نعمل على جعل هذه الفئة من الأشياء أسهل بكثير في برنامج العرض في 2018.

نأمل أن تتحسن الأمور بشكل كبير في عام 2018. نحن نخسر

ارى:

somombo تم تأكيد هذا المقال ليكون هراء منذ وقت طويل

الأشخاص الذين يعرفون بالفعل أشياءهم سخروا من المؤلف ولم يأخذه أي منهم على محمل الجد ، الإعجابات من رد فعل ، vue fanboys ، بشكل طبيعي.

لذا فإن حقيقة الأمر هي أن هذه المشكلة هنا ذات أولوية منخفضة للغاية بالنسبة للفريق الزاوي ، وهي في الواقع أقل أولوية محتملة.

انظر قائمة الأولويات المنشورة في AngularHQ (ابحث عن الإصدار رقم 8785)

هذا هو الحال على الرغم من أن هذه المشكلة قد أثارت الكثير من النقاش والاهتمام من المجتمع كما يتضح من عدد التعليقات.

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

لا تنس أن تشكر فريق Angular الخاص بنا على كل العمل الرائع الذي قاموا به!

أود أيضًا أن أدلي بصوتي لهذه الميزة. لقد كان هذا سبب الكثير من الحزن في محاولة للتغلب على هذه المشكلة.

somombo من فضلك لا تقرأ الكثير في الأولوية في AngularHQ حتى الآن. لم يتم توضيح صيغة الأولوية بشكل كامل. بعد قولي هذا ، أعتقد أننا يجب أن نعيد النظر في طلب الميزة هذا بعد سفن v6. أخشى أنه ليس لدينا النطاق الترددي لذلك عاجلاً وأن العمل على هذا سيتعارض مع العمل الجاري بالفعل في مجال المترجم / الأساسي.

هذا ليس طلب إصلاح سريع. أظن أن الأمر سيستغرق جهدًا كبيرًا لإنجازه بشكل صحيح ، لكن الأشياء التي نعمل عليها من أجل الإصدار 6 ستجعل هذا الأمر أسهل في التنفيذ.

IgorMinar عمل Ivy يجعل هذا أكثر جدوى. ولكن نعم الماضي v6.

IgorMinar و mhevery لا أستطيع التأكيد بما فيه الكفاية على مدى امتناني (والبقية منا أيضًا ، أنا متأكد) لأنك قدمت لنا هذه التعليقات الملموسة حول ماهية أفكارك وما يجب أن يحدث أولاً قبل أن تتمكن هذه المشكلة يتم التعامل معها بشكل صحيح.

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

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

شكرا لك على كل العمل الرائع!

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

export class gBtn extends gTouch

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

NateMay مشكلتان في ذلك - أولاً ، يمكنك فقط تمديد فئة واحدة ، وثانيًا ، لقد كسرت حقنة التبعية.

فقط أضف سنتي. أقوم ببناء SPA متعدد الطبقات بتخطيط زاوي ومادي ومرن باستخدام الحالات المتداخلة لـ @ uirouter / angular. ومن ثم فإن عدم القدرة على تطبيق التوجيهات المرنة بسهولة على عناصر المكونات أمر محدود للغاية.

لذا التصويت لهذه الميزة من فضلك.

+1 لهذه الميزة المضافة

من الممكن إضافة توجيه إلى ng-container ، والذي لن يظهر في DOM.

كنت بحاجة إلى هذا من أجل واجهة برمجة تطبيقات intersection-Observer (التي تثير الأحداث عندما تدخل العناصر / تغادر منفذ العرض). لديّ توجيه intersector ، والذي يحتوي على أحداث enter() و leave() عندما يصبح العنصر مرئيًا / مخفيًا. لدي مكونات معينة تحتاج إلى استخدام واجهة برمجة التطبيقات هذه داخليًا ، لكنني لم أرغب في إضافة عنصر DIV إضافي في القالب.

إذن ما فعلته هو ما يلي بـ component.html :

<ng-container intersector (enter)="weCameOnScreen()" (leave)="byeBye()">
     ... components normal template ...
</ng-container>

ثم يقوم مُنشئ التوجيه intersector.directive.ts بحقن ElementRef .

    constructor(private intersectorElementRef: ElementRef) { ... }

بالنسبة لعنصر DOM العادي ، ستعمل فقط على intersectorElementRef.nativeElement ، ولكن بالنسبة لـ ng-container فإن العقدة هي في الواقع عقدة تعليق. لذلك أنا فقط أتحقق لمعرفة ما إذا كان تعليقًا ، وإذا كان كذلك ، فأنا أرتقي إلى مستوى أعلى.

public ngAfterViewInit(): void 
{
    // if the directive is applied to an ng-container must go a level up
    this.domElement = (this.intersectorElementRef.nativeElement.nodeType == 8) ? this.intersectorElementRef.nativeElement.parentElement : this.intersectorElementRef.nativeElement;

   registerIntersector(this.domElement ...);

لن ينجح هذا في جميع المواقف ، لكنني على ما يرام مع هذا في الوقت الحالي. أعتقد أنه في مترجم IVY قد لا يستخدمون التعليقات بعد الآن - لذلك قد ينكسر هذا. الشيء المهم هو أن لديّ توجيهًا واحدًا يمكنني استخدامه على عُقد DOM أو في ما يُعتبر فعليًا بمثابة " HostBinding " للتوجيه.

كنت أتمنى حقًا أن يكون من الممكن إضافة التوجيهات بشكل ديناميكي. أريد أن أكون قادرًا على تغليف توجيهات المستوى الأدنى في "ترتيب أعلى" ، وتوجيهات أكثر تجريدًا. سألت السؤال التالي حول تجاوز سعة المكدس ، وكنت أتساءل عما إذا كان سيكون هناك حل لهذا في المستقبل: https://stackoverflow.com/questions/51608645/abstract-away-leaflet-directive-in-custom-directive

كما قال mhevery .. نحن بحاجة إلى التحلي بالصبر وانتظار وصول الإصدار الكامل Ivy (ng v7.0.0؟). على ما يبدو ، سيكون من الأسهل عليهم تنفيذها باستخدام Ivy ... بعد Ivy ، يجب أن نذكر الفريق بمدى أهمية هذه الميزة بالنسبة لنا ، حتى لا ينسوها

الاشتراك في هذا. أحتاج أيضًا إلى أن أكون قادرًا على إرفاق توجيه ديناميكيًا بالمكون الذي قمت بإنشائه باستخدام developerComponentFactory / createComponent.

const componentFactory = this.componentFactoryResolver.resolveComponentFactory(componentItem.component);

const componentRef = viewContainerRef.createComponent(componentFactory);
(<DynamicComponent>componentRef.instance).data = componentItem.data;
(<DynamicComponent>componentRef.instance).cssClassList = componentItem.cssClassList;
// Add directive to new component here
// componentRef.addDirective(someDirective)

أي تحديث؟؟؟
واجهت حالة استخدام أخرى حيث أستخدم توجيهًا من جهة خارجية.
في بعض السيناريوهات ، أحتاج إلى إزالة / إضافة توجيه على عنصر HTML ديناميكيًا.
هل هذا ممكن بأي شكل من الأشكال أم في انتظار الحل؟

micronyks ... في الواقع ليس من الممكن إضافة توجيه ديناميكيًا. علينا أن ننتظر Ivy الذي يجب أن يضيف إمكانية إنشاء مثل هذه الميزة.

@ mlc-mlapis لكن أي خطة متى سيأتي IVY؟ في أي إصدار؟

micronyks ... الزاوي 7 بالجدول الزمني.

لنكن عقلانيين هنا يا رفاق ، يحاول Angular Team العمل بجد على العديد من الميزات الضخمة المطلوبة بشدة (PWAs و SSR و Ivy والعناصر المخصصة بشكل خاص) آخرها هي ميزة ذات أولوية عالية جدًا كما يمكنني فهمها ، لأن الكثير من الشركات الكبيرة (مثل Microsoft) كانت تطلب ذلك إلى الأبد ، وهناك سبب لذلك. لتحقيق عناصر مخصصة فعالة يحتاجون إلى Ivy ، بمجرد الانتهاء من Ivy ، كما قال mhevery ، سيسمح المحرك بالتوجيهات الديناميكية بسهولة أكبر.

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

دعونا نتذكر أن Angular Team ليس بهذا الحجم ، إنه مجرد عشرات الأشخاص الذين يحاولون إنشاء إطار عمل رائع للجميع ، لكن هذا يستغرق وقتًا.

... نعم ، من الضروري التحلي بالصبر قليلاً الآن وانتظر حتى اللحظة التي يمكننا فيها تقديم المزيد من المساعدة مع Ivy ... عندما يكتمل المترجم ويتوفر بعض مستندات التصميم التفصيلية.

avatsaev يمكنني أن أتفق مع كل ما قلته. لا يجب أن تطلب أشياء هنا. ولكن يمكنك شرح المشكلات التي تتعامل معها عند العمل مع Angular.

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

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

أقوم ببناء مولد نموذج ، باستخدام Angular Material و Flex-Layout ، والذي يأخذ تكوين JSON وينشئ نموذجًا. ستساعدني هذه الميزة في تطبيق توجيهات التنسيق المرن على المكون المضيف في وقت التشغيل. أشعر أن أحد أكبر أصول Angular هو القدرة على إنشاء كود في وقت التشغيل من التكوين ، وهذا سيقطع شوطًا طويلاً لجعل هذا الرمز أكثر تنوعًا. أردت فقط إسقاط حالة استخدام جيدة. نافذ الصبر ؛)

هذه هي حالة الاستخدام الخاصة بي

NateMay هذا هو التنفيذ

NateMay هذا هو التنفيذ

ممكن توضح؟ أعتقد أنك تقصد المجال الديناميكي

يقوم dynamic-field.directive بالأشياء الفاخرة ولكن هناك الكثير من الأشياء الأخرى التي تحدث أيضًا. لقد أضفت للتو CONTRIBUTING.md في المجلد الجذر ، والذي يحتوي على إرشادات للإعداد محليًا. كن حذرًا من استخدام أي شيء قيد الإنتاج لمدة شهرين. أقوم بإجراء تغييرات كبيرة بينما أعمل من أجل تطبيق مستقر.

+1

إلى حد بعيد ، الحلول الخاصة بي ، جميعها لها جوانب سلبية.

  1. has-it ، عرّف خاصية عضو جديدة كهذا التوجيه داخل صنف المكوّن الخاص بي ، مرّر جميع وسيطات المُنشئ المطلوبة إلى هذا التوجيه عند استدعاء دالة المُنشئ (على سبيل المثال ، ElementRef ، ViewContainerRef ، TemplateRef ... أي متغيرات قابلة للحقن يطلبها) ، واستدعاء رد الاتصال الخاص بدورة الحياة يدويًا إذا كان لديه ، مثل ngInit() ngAfterViewInit() في وظيفة رد اتصال دورة الحياة المقابلة للمكون الحالي.
@component(...)
class MyComponent {
   theDirective: TargetDirective;
   constructor(el: ElementRef) {
       this.theDirective = new TargeDirective(el);
   }

  ngOnInit() {
     this.theDirective.ngOnInit();
  }
  ...
}
  1. قم بلف كل شيء في قالب المكونات داخل قالب ng عالي المستوى ،
    <ng-template><div targetDirective>....</div></ng-template> تقديمهم في ngAfterViewInit() مثل:
const vf = this.viewContainerRef.createEmbeddedView(this.templateRef);
vf.detectChanges();

بهذه الطريقة ، ينشئ Angular element مع هذا التوجيه عليه والمحتوى الفعلي للمكوِّن بداخله مباشرةً بعد عنصر المكون الأصلي في شجرة DOM.

<my-component></my-component>
<div targetDirective>....</div>

بهذه الطريقة يشبه ما يفعله <route-outlet> .

هناك آثار جانبية واضحة

هل يمكن لأي شخص تأكيد ما إذا كان هذا ممكنًا الآن مع Ivy؟ إذا كان الأمر كذلك ، فهل لدى أي شخص مثال؟

دعونا نتذكر أن Angular Team ليس بهذا الحجم ، إنه مجرد عشرات الأشخاص الذين يحاولون إنشاء إطار عمل رائع للجميع ، لكن هذا يستغرق وقتًا.

يمكن أن يكون أكبر من خلال وجود مجتمع من المساهمين.

ومع ذلك ، فإن فرصة إصلاح المساهمة لهذا يتم قبولها منخفضة للغاية.

لذا بدلاً من ذلك ، عدنا إلى عشرات الأشخاص.

هل يمكن لأي شخص تأكيد ما إذا كان هذا ممكنًا الآن مع Ivy؟ إذا كان الأمر كذلك ، فهل لدى أي شخص مثال؟

نظرًا لعدم وجود كلمة حتى الآن ، اعتقدت أنني سأقدم أقرب شيء تمكنت من العثور عليه ، وهو مقال منذ فترة عن تطبيق mixins مع Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -و-مزيج-مع-الزاوي-اللبلاب -75748fcbc310

وفقًا للمقال ، أعتقد أن أحد الحلول الممكنة للمسألة الأصلية لهذا الموضوع هو استخدام الميزة الجديدة المسماة ... "الميزات".

... يمكنك أن تتخيل أن محاولة البحث في Google عن أي شيء يتعلق بهذه الميزة يعد بمثابة كابوس. على أمل أن يطلقوا بعض الوثائق الرسمية لبلاب قريبا! :)

nayfin يقوم أيضًا ببناء مصمم / منشئ النماذج المرئية
وبعد بضعة أشهر من العمل للتوقف عن الحقائق ، ليس لدي أي طريقة لنشر التوجيه إلى div المضاف ديناميكيًا يجعلني أشعر بالجنون .... يجب أن يكون غافلًا جدًا عن استدعاء بعض MyDirectiveFactory :: application (HTMLElement)

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

سيكون رائعًا أن تكون قادرًا على إضافة التوجيهات ديناميكيًا مثل:

const msked = componentFactory.createDirective(MaskedInputDirective);
msked.textMaskConfig = {};
this.elementRef.directives.add(msked);

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

tsteuwer يمكنك دائمًا استخدام: محدد المضيف في scss لتطبيق خصائص النمط على العنصر المضيف.

لكن نعم ، أود أيضًا القدرة على تطبيق التوجيهات على العنصر المضيف. سيكون مفيدًا في جعل عنصر المضيف قابلاً للتمرير وتطبيق CdkScrollable من Angular Material CDK.

قم بلف كل شيء في قالب المكونات داخل قالب ng عالي المستوى

البديل الأكثر رشاقة قليلاً لهذا هو استخدام https://github.com/trotyl/angular-contrib وإضافة

host: { ngNoHost: '' }

يعمل هذا المشروع على تقشير العارض ويجعل العناصر الفرعية للعناصر ذات السمة ngNoHost ، sans parent.

لها العديد من نفس العيوب بالطبع.

من المؤسف أن هذا لا يزال مفتوحًا بعد 3 سنوات. ستعمل التوجيهات المرتبطة بالعنصر المضيف حقًا على تحسين إمكانية إعادة استخدام الكود.

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

tsteuwer يمكنك دائمًا استخدام: محدد المضيف في scss لتطبيق خصائص النمط على العنصر المضيف.

لكن نعم ، أود أيضًا القدرة على تطبيق التوجيهات على العنصر المضيف. سيكون مفيدًا في جعل عنصر المضيف قابلاً للتمرير وتطبيق CdkScrollable من Angular Material CDK.

ليست مثالية ولكن يمكنك إنشاء CdkScrollable برمجيًا بهذه الطريقة:
this.scrollable = new CdkScrollable (this.elementRef، this.scrollDispatcher، this.zone) ؛
this.scrollable.ngOnInit () ؛

عليك تدميرها يدويًا أيضًا:
إذا (this.scrollable) {
this.scrollable.ngOnDestroy () ،
}

https://github.com/angular/angular/issues/8785#issuecomment -361004682 عمل IgorMinar يجعل هذا أكثر جدوى. ولكن نعم الماضي v6.

mhevery متابعة تعليقك: point_up_2: والآن بعد أن هبطت Ivy بالكامل أخيرًا ، هل يمكننا أن نتمتع بهذه الميزة في (أو قبل) إصدار v10؟ إذا لم يكن الأمر كذلك ، فيرجى إطلاعنا على الاعتبارات الأخرى التي قد تعيق هذا الأمر أكثر.

هل هناك أي تغييرات؟

إذا كانت هذه الميزة المحددة موجودة في استطلاع Angular https://twitter.com/angular/status/1252646001162088448؟s=20 ، فأنا أراهن أنه سيكون أعلى إدخال تم التصويت عليه.

هناك الكثير من الميزات التي ستكون الأعلى تصويتًا ، هذه الميزة بالتأكيد ولكن أيضًا تستخدم Observables مقابل @output والعديد من الميزات الأخرى. لسوء الحظ ، لن يتم تنفيذها بالوتيرة الحالية.

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

فكرة عظيمة @ princemaple!

على الرغم من أن هذا ليس مثاليًا ، إلا أنه يمكن معالجته بالفعل في قسم "التعليقات الإضافية" في الاستطلاع (من السؤال 2)
حيث تقول:

"How else should we improve Angular for you?"

لذلك ، في الأساس ، كل من يهتم برؤية هذه الميزة ، يرجى فقط الإجابة على الاستبيان وإعلانه بوضوح ، وأنك تهتم كثيرًا برؤية "المشكلة رقم 8785" مطبقة وحلها.

هنا الرابط المباشر للمسح:
https://goo.gle/angular-survey-2020

قد تكون القوة معك! 🙂

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

لقد تحدثت مع أعضاء الفريق الزاوي فيما يتعلق بهذه المقالة

هل يمكن لأي شخص تأكيد ما إذا كان هذا ممكنًا الآن مع Ivy؟ إذا كان الأمر كذلك ، فهل لدى أي شخص مثال؟

نظرًا لعدم وجود كلمة حتى الآن ، اعتقدت أنني سأقدم أقرب شيء تمكنت من العثور عليه ، وهو مقال منذ فترة عن تطبيق mixins مع Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -و-مزيج-مع-الزاوي-اللبلاب -75748fcbc310

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

لست متأكدًا مما إذا كان هناك أي سبب تقني يمنعنا من القيام بذلك ، لكنني أعتقد أنه إذا كانت لدينا القدرات للقيام بذلك ، فسيؤدي ذلك إلى تحسين يومي بشكل جذري مع الزاوي.

"لقد قمنا بزيادة استثماراتنا بشكل كبير في العمل مع المجتمع. في الأسابيع الثلاثة الماضية ، انخفض عدد المشكلات المفتوحة لدينا بأكثر من 700 مشكلة عبر إطار العمل والأدوات والمكونات. لقد تطرقنا إلى أكثر من 2000 مشكلة ، ونخطط للقيام باستثمارات كبيرة خلال الأشهر القليلة المقبلة ، والعمل مع المجتمع للقيام بالمزيد ". -StephenFluin
من إعلان Angular 10

لذا أعتقد أن هذا يعني أننا سنرى هذه المشكلة ملغاة في الإصدار 11؟ 🤞😏

ما هي أفضل طريقة "للعمل مع المجتمع" (وإرضاءهم) من العمل على إضافة واحدة من أكثر الميزات المطلوبة !؟ (هذه 😉)

استمع لهم!

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

mhevery كيف يختلف عن تطبيقها من الأصل في القالب؟

@ k3nsei من الضروري رؤيته من وجهة نظر NgModule ، والتي هي في الواقع العنصر الأساسي الذي ينشئ البنية التحتية لجميع مكوناته.

@ mlc-mlapis لدينا HostBinding و HostListener لذا ربما يكون HostDirective خيارًا جيدًا لهذه الوظيفة. لقد رأيت محادثات مفادها أن Ivy apis تتيح مثل هذه الوظائف.

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

@ k3nsei يمكن أن يكون الأمر كذلك ، لكنني لست متأكدًا مما إذا لم يكن ديناميكيًا للغاية ، لذا فهو أقل أداء من الهياكل الثابتة بدقة.

"فقط لتعيين التوقعات ، ما تطلبه ليس قدرًا ضئيلًا من العمل وهياكل البيانات الحالية ليست مصممة حقًا لهذا الغرض. لذا فإن دعم شيء كهذا يتطلب بعض الهندسة الكبرى." - https://github.com/angular/angular/issues/8785#issuecomment -654391378

شكرا لاستجابتك في الوقت المناسبmhevery.

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

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

نشكرك بصدق ونقدر اتصالاتك الجادة ونأمل أن نستمر في أن نكون جزءًا من الحوار حول ما نحتاج إليه مقابل ما هو واقعي / عملي نضيفه.

على الرغم من أنني أفهم أن Ivy تجعل هذا أسهل من ذي قبل.

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

IgorMinar عمل Ivy يجعل هذا أكثر جدوى. ولكن نعم الماضي v6.

على الرغم من أنني أفهم أن Ivy تجعل هذا أسهل من ذي قبل

فهمي الجديد "أسهل" لا يزال لا يعني "سهل"

فهمي الجديد "أسهل" لا يزال لا يعني "سهل"

Ivy: الشيء الذي قضيت عامين فيه وما زلت لا يعالج أيًا من أكثر مشكلات Angular شيوعًا.

Ivy: الشيء الذي قضيت عامين فيه وما زلت لا يعالج أيًا من أكثر مشكلات Angular شيوعًا.

pauldraper أعتقد أن قضايانا ليست "مشكلاتهم" نظرًا لأن هذه

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

pauldraper أعتقد أن قضايانا ليست "مشكلاتهم" نظرًا لأن هذه

somombo أشعر بخيبة أمل من حقيقة أن هذه المشكلة لا تزال مفتوحة بعد كل هذه السنوات ، لكن لا يمكنني أن أتفق معك. النقطة الأولى في خريطة الطريق تتعلق صراحة بمعالجة مشكلات github المفتوحة. لن يكون إدراجهم جميعًا في خريطة الطريق منطقيًا ، أليس كذلك؟ هذه القضية هي واحدة من أكثر upvoted (أو أكثر upvoted) وآمل أن يتم أخيرا المتخذة حلها.

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

كلا ، هذا مجرد تفكير أمني ، اقرأ من خلال https://github.com/angular/angular/issues/5689 لا يوجد أي مؤشر على الإطلاق أنهم يريدون معالجة أي من أكثر القضايا التي تم التصويت عليها ، باستثناء "النماذج المكتوبة بقوة" في مستقبل

pauldraper أعتقد أن قضايانا ليست "مشكلاتهم" نظرًا لأن هذه

somombo أشعر بخيبة أمل من حقيقة أن هذه المشكلة لا تزال مفتوحة بعد كل هذه السنوات ، لكن لا يمكنني أن أتفق معك. النقطة الأولى في خريطة الطريق تتعلق صراحة بمعالجة مشكلات github المفتوحة. لن يكون إدراجهم جميعًا في خريطة الطريق منطقيًا ، أليس كذلك؟ هذه القضية هي واحدة من أكثر upvoted (أو أكثر upvoted) وآمل أن يتم أخيرا المتخذة حلها.

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

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

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

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

هذا مثال:

@Directive({
  selector: 'app-popup',
  attachDirectives: [
    FocusAreaDirective
  ]
})
export class PopupDirective {

  // Attached directives can be injected, just like template-declared directives today
  constructor(public focusArea: FocusAreaDirective) {
  }

}

يمكن استخدام خصائص @Input() و @Output() في التوجيه المرفق في القالب ، ويجب استدعاء طرق دورة الحياة في التوجيه المرفق كجزء من دورة حياة مكون المضيف. يمكن أن يرتبط التوجيه المرفق أيضًا بالعنصر المضيف. في الأساس ، يعمل تمامًا مثل التوجيه المعلن عن القالب اليوم ، ولكن لا يلزم الإعلان عنه في القالب.

أعتقد أن هذه الميزة ستوفر فائدة كبيرة لـ Angular ، مما يتيح لهياكل مكونات أنظف / أبسط عبر تكوين توجيهي.

اليوم ، لديك خياران إذا كنت تريد شكلًا مشابهًا من إعادة استخدام التوجيه:

  • اشتراط أن يتم دائمًا الإعلان عن مجموعة من التوجيهات ذات الصلة معًا في ترميز القالب ؛ واكتشاف ورمي الأخطاء إذا لم تكن التوجيهات المطلوبة موجودة في المنشئ. لا توجد طريقة لطلب التصريح عن التوجيهات المطلوبة على نفس العنصر. هذا فوضوي من وجهة نظر تأليف وتوثيق القالب ، وليس واجهة برمجة تطبيقات أو عقدًا قويًا بسبب التكرار ، ولكنه بخلاف ذلك ليس فظيعًا.
  • إنشاء مثيل للتوجيهات المرفقة يدويًا داخل توجيه المضيف ، وإعادة توجيه معاملات المُنشئ ، وخصائص @ Input / Output ،

بعبارة أخرى ، يؤدي غياب الميزة أحيانًا إلى إنشاء مقايضة غير ضرورية بين استخدام مكون نظيف + بسيط ، وتأليف مكون بسيط ونظيف.

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

amakhrov : نقطة جيدة - استبعدت المدخلات من

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

أنا أقف بشكل صحيح.
هذه المشكلة مدرجة الآن ضمن قسم "المستقبل" من خارطة الطريق الرسمية. راجع https://angular.io/guide/roadmap#support -adding-directives-to-host-element

دعم إضافة توجيهات لعناصر المضيف

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

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

شكرا للفريق لوضعه هناك! 🙏🏾

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات