لا يبدو لي أن ngModules تمنع الإعداد الذي تريده ، هل لعبت به حتى الآن؟ يمكن أن يكون لديك عدة وحدات مختلفة والقيام بتحميل بطيء ، إلخ. http://plnkr.co/edit/NAtRQJBy50R19QAl90jg؟p=info

لشيء أكثر شبهاً بما يبدو أنك تحاول القيام به ، حافظ على انتقال المواد 2: https://github.com/angular/material2/pull/950/files

مرحبًا qdouble ،

شكرا لك على الرد السريع.
بالنظر إلى https://github.com/jelbourn/material2/blob/ecbb4f42e0473899f6ad15d8e4ed8f262ded7a99/src/components/button-toggle/button-toggle.ts ، هل تقول ذلك من أجل تحقيق الوظيفة نفسها التي لدينا الآن ، نحن بحاجة للإعلان عن NgModule على كل مكون؟ (هذا ما تم إضافته في نهاية الملف أليس كذلك؟)

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

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

فيما يتعلق بالمسألة الثانية ، يمكنك إعلان ngModule والمكون بجوار بعضهما البعض ، لذلك بينما يضيف 3 أو 4 أسطر إضافية من التعليمات البرمجية إلى ملفاتك ، لا أعتقد أنه يخلق مشكلة كبيرة.

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

qdouble شكرا.

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

أترك هذا مفتوحًا لمعرفة ما إذا كان لدى شخص ما شيء يضيفه إلى المسألة.

تفهم jpsfs ، إذا كنت في موقفك ، فأنا أفضل بالتأكيد ترك كلا الخيارين مفتوحين :)

لقد كتبوا سبب إهمال توجيهات المكونات في المستند الذي نشرته ، بقدر ما يتم إنشاء نطاقين ، فإنهم يعتقدون أن نطاق ngModule صغير بما يكفي وأنه يتماشى أكثر مع نموذج ES6.

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

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

حتى إنني أعمل حاليًا على تصميم الهندسة المعمارية لتطبيق ضخم للمؤسسات.
على عكس وضعك jpsfs ، أنا متحمس لـ NgModules واعتمد إلى حد كبير بنية تطبيقي حول NgModule.

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

عند التحميل البطيء ، بدلاً من تحميل الكود لكل مكون ، يبدو أنه سيتم تحميل كل رمز NgModule مرة واحدة ، بحيث تصبح وظيفتك قابلة للاستخدام بالكامل بمجرد تنزيلها.

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

نحن نعمل حاليًا أيضًا على تطبيق يحتوي على الكثير من المكونات (ليس المئات ولكن العشرات). ليست هناك حاجة معمارية بالنسبة لنا لتقسيم هذا التطبيق إلى عدة وحدات (تحميل كسول) ، ولكن الآن نقوم باستيراد كل هذه المكونات إلى ملف bootstrap وتمريرها إلى declarations بطريقة ما يشعر بالخطأ ويفكك تغليف المكون . كما قال jpsfs ، قبل ذلك كان من الواضح جدًا المكونات والتوجيهات التي يستخدمها مكون آخر. لذلك سأكون ممتنًا أيضًا أن يكون لديّ الاختيار:

• إذا كان توجيهًا شائع الاستخدام ، فقم بإعلانه في الوحدة النمطية
• إذا كان شيئًا مثل TaskListItem فقط قم باستيراده بـ TaskList .

ربما يمكن لبعض الأعضاء الأساسيين أن يخبروا المزيد عن قرار إهمال النهج الثاني. بعد أن عملت معها لعدة أشهر الآن ، أشعر أنني بحالة جيدة ؛)

لتكرار وجهة نظر choeller ، فإنه من الغريب الابتعاد عن القدرة على توفير تغليف المكون.

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

الآن يجب أن تكون جميع المحددات فريدة لكل مكون ، أليس كذلك؟ أم أنني أسيء فهم كيفية عمل ذلك؟

شعرت أن الوظيفة الأصلية تتطابق مع المزايا المماثلة التي توفرها محاكاة CSS shadow-DOM ، حيث لا يمكننا القلق بشأن تصادمات المحدد وما إلى ذلك عبر التطبيقات الكبيرة. كان ذلك IMO ميزة كبيرة.

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

angular.module("myApp")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.controller("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.component("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.directive("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")
.service("…")

اعتقدت أن هذا ينتمي إلى الماضي. بدأت العمل مع ng-metadata لتحسين مشاريع angular 1 القديمة والاستعداد للهجرة. أحب حقًا حقيقة أن لديها شجرة تبعية وليست قائمة عالمية "ما قد يظهر في هذا التطبيق".

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

DaSchTourdamiandennis أنا أتفهم انتقاد هذه البنية ، ومع ذلك ، فإن الإشارة إليها على أنها نوع من النطاق العالمي غير دقيقة ، والمنهجية التي يقترحون عليك اتباعها هي أن يكون لديك وحدات مميزة: https://angular.io/docs/ts /latest/guide/ngmodule.html#! # وحدات مميزة

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

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

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

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

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

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

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

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

@ qdouble نمط التصميم بسيط. إنها تستخدم شجرة تبعية بدلاً من نقل التبعيات إلى نطاق وحدة عالمية. أعتقد أن النقطة الرئيسية هي أن المكونات القابلة لإعادة الاستخدام يجب أن تكون الآن وحدات ، حتى لو كانت صغيرة جدًا ولديها وظائف قليلة جدًا. المادة الزاويّة 2 مثال جيد جدًا. الزر هو وحدة نمطية ، بما في ذلك مكون واحد. ربما يكون مفهومًا خاطئًا لدى العديد من المطورين ، أن الوحدة هي شيء يحتوي على أكثر من مجرد زر. والآن دعونا نفكر في خطوة أخرى إلى الأمام. فقط باتباع الأفكار الواردة في هذه المقالة https://angularjs.blogspot.com/2016/08/angular-2-rc5-ngmodules-lazy-loading.html أجد نفسي عند هذه النقطة ، لدي الكثير من الوحدات التي استيراد قائمة من وحدات المواد الزاوية 2 وتتكون كل وحدة من هذه الوحدات من مكون واحد.
في fakt هذا هو بالضبط ما تفعله المادة الزاوية 2.

لا أحد يفهم الهدف حقًا ، لماذا يتعين علينا الآن لف "جميع" مكوناتنا في وحدات. أو ربما علينا أن ننظر إلى هذا على أنه انقسام في الإعلان. تبعيات المكون هي الآن وحدة نمطية وتعريف المكون كما كان.

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

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

أجد نفسي عند هذه النقطة ، لدي الكثير من الوحدات التي تستورد قائمة من وحدات المواد الزاوية 2 وتتكون كل وحدة من هذه الوحدات من مكون واحد.

يمكنك استخدام الوحدات المشتركة لهذا: https://angular.io/docs/ts/latest/guide/ngmodule.html#! # وحدة مشتركة

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

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

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

أخذ مثالchoeller
تحتوي وحدة TaskDashboard النمطية على الأشياء التالية

1. مكون قائمة المهام
2. مكون Taskitem
3. مكون Taskfilter
4. خدمة المهام

مطلوب مكون Taskitem فقط داخل Tasklist وتعتمد قائمة المهام على مكون Taskitem. لا يحتاج Taskfilter إلى مكون Taskitem. الآن ليس لدي Taskitem كاعتماد في قائمة المهام. الخطوة التالية هي أن أقوم بإنشاء وحدة TaskSearch. أقوم بإضافة الأشياء التالية.

1. مكون قائمة المهام
2. مكون البحث
3. خدمة المهام

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

حسنًا ، أثناء قراءة دليل الوحدات ، وجدت هذا السطر

يجب أن تنتمي المكونات والتوجيهات والأنابيب إلى وحدة واحدة بالضبط.

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

أثناء العمل على الأخطاء الغريبة وغير المراوغة التي تظهر عند استخدام ngModule وجدت أيضًا أن توسيع المكونات الآن لا يعمل بشكل جيد كما كان من قبل. كان لدي مجموعة من المكونات مع التبعيات المطلوبة التي يمكنني ببساطة توسيعها. الآن عليّ الاهتمام باستيراد التبعيات في الوحدة التي أقوم بتضمين المكون الممتد فيها.

DaSchTour في مثالك ، يجب أن يكون Taskitem جزءًا من وحدة قائمة المهام ... بحيث يكون ذلك مكونين في وحدة واحدة منطقيًا ، وليس واحدًا لكل منهما.

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

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

لدي شعور أن هناك بعض عدم التوافق بين التصميم والواقع هنا.

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

TL ؛ د
إنه لأمر رائع أن تكون قادرًا على تحديد بعض التبعيات على مستوى الوحدة النمطية ، لكن من المحزن حقًا أننا لم نعد قادرين على تحديد التبعيات على مستوى المكون بعد الآن

DaSchTour ، يرتبط مكون الزر في material2 بوحدة نمطية لجعله مستقلاً. أولئك الذين يحتاجون إلى استخدام الزر يمكنهم استيراد ButtonsModule . أيضًا إذا رأيت كود الوحدة النمطية ، فهو يحتوي على مكونين MdButton و MdAnchor ، ثم التغليف في ButtonsModule يجعل الأشياء أسهل في الاستخدام

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

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

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

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

هذا جيد جدا تلخيصkylecordes. تساعد NgModules في تكوين جيد للتطبيق. تشكل الوحدات الصغيرة القابلة لإعادة الاستخدام التطبيق بالكامل.
يتضمن benfit التوافر المحيط للتوجيهات. اعتدنا سابقًا على إضافة ROUTER_DIRECTIVES في التطبيق بالكامل. الآن RouterModule.forRoot() يفعل ذلك لنا.
BrowserModule و CommonModule و FormsModule أكثر منطقية من تضمين التوجيهات من خلال كل مكون.

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

علاوة على ذلك ، يوجد LazyLoading. إذا لم يكن الأمر كذلك بالنسبة لـ NgModules ، فكيف يمكن للمرء تحديد عدد المكونات والخدمات التي تحتاج إلى العمل معًا لإنشاء وحدة قابلة للتوجيه. لا يمكنك تنزيل ملفات فضفاضة لأن هذا سيؤدي إلى عدد كبير من طلبات الشبكة. عدا ذلك ، تحتاج إلى إنشاء حزمة حيث تقوم بإدراج جميع الملفات التابعة ، وإنشاء حزمة واحدة. تقوم NgModule بذلك باستخدام بناء جملة بديهي.

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

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

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

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

علاوة على ذلك ، يوجد LazyLoading. إذا لم يكن الأمر كذلك بالنسبة لـ NgModules ، فكيف يمكن للمرء تحديد عدد المكونات والخدمات التي تحتاج إلى العمل معًا لإنشاء وحدة قابلة للتوجيه. لا يمكنك تنزيل ملفات فضفاضة لأن هذا سيؤدي إلى عدد كبير من طلبات الشبكة. عدا ذلك ، تحتاج إلى إنشاء حزمة حيث تقوم بإدراج جميع الملفات التابعة ، وإنشاء حزمة واحدة. تقوم NgModule بذلك باستخدام بناء جملة بديهي.

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

يبدو الأمر حقًا وكأن ngModule هو حل يبحث عن مشكلة ...

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

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

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

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

على الأقل ، لا أرى أي سبب لعدم تعايش ngModule مع خاصية التوجيهات / الأنابيب. البديل هو أن كل مكون منفرد في كل تطبيق مكتوب لـ ng2 ، حتى RC5 يستخدم الآن رمزًا مهملاً يحتاج إلى إعادة هيكلة غير تافهة. هذه في الحقيقة ليست نوع التغييرات التي كنت أتوقعها في وقت متأخر من التطوير ... إنه أمر محبط للغاية بصراحة.

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

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

يجب أن تطلب منك معظم التطبيقات إنشاء وحدة نمطية لكل مكون فردي = غير صالح (خاصة إذا كنت تستخدم أنماط مكونات ذكية / غبية وأنماط ميزات)

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

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

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

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

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

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

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

ماذا سيكون التغيير القادم؟ لا أستطيع حتى أن أتخيل ، لكني أخشى أن يجد شخص ما طريقة لتقديم التغيير الجديد القادم.

من منشور مدونة RC5:

إذا كنت قد كتبت أي رمز Angular 2 على الإطلاق ، فربما سألت نفسك على الأرجح "ولكن لماذا يجب أن أدرج كل هذه الأشياء !؟" - خاصةً إذا لاحظت أن بعض التوجيهات والأنابيب في Angular 2 "خاصة" - فهي متاحة للتطبيق بأكمله دون أن تفعل شيئًا (* ngFor / * ngIf / * ngSwitch ، على سبيل المثال).

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

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

إذا كانت الشفرة موجودة بالفعل للتعامل مع رفع التوجيهات في وحدة ngModule واحدة ، وكان هذا الرمز يعمل بشكل غير مرئي للمستخدم النهائي ، فما هو الضرر في السماح لكلا النهجين؟ هذا سؤال حقيقي ، لأنني قد لا أكون على دراية ببعض التعقيدات حول ما يمكن أن يحدث إذا قام المطور بخلط النهج ومطابقته. هناك الكثير من "الاختيارات المنقسمة" الأخرى في Angular 2 - النماذج التي تعتمد على النموذج مقابل النماذج ، و 3 خيارات مختلفة للغة ، ومدخلات / مخرجات / ديكورات مضيفة مقابل نهج الملكية - ما هو الضرر الذي يلحق بآخر في هذه المرحلة؟

يمكنني المضي قدمًا ، ولكن النقطة التي أحاول توضيحها هي أن فريق Angular والمجتمع قد استثمروا قدرًا كبيرًا من الوقت لإيصال الرسالة التي مفادها أن كونك أكثر وضوحًا هو أمر جيد ، فقط للانقضاض عليه - عند الإصدار مرشح 5_ في جميع الأوقات - لتقديم حل لم يكن يمثل مشكلة لبعض الوقت.

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

أثارت هذه المناقشة مشكلة كبيرة جدًا للعديد من المطورين الذين أرادوا البدء في التطوير مبكرًا باستخدام الزاوية 2 المتوقعة للغاية: كسر التغييرات. لقد قمت بإثبات مفهوم يعتمد على الزاوية 2 منذ الإصدار التجريبي 17 وجعلت الشركات والمؤسسات الهامة تتبناه. أنا لست نادما ولكني لست متأكدا من أنني أبليت بلاء حسنا. كان بعض أحدث المشاريع هو POC وكانت المعركة ضد Vue.js. من الواضح أن Angular 2 فاز بهذه المعركة. لكن اليوم ، مع إعادة كتابة التعليمات البرمجية بالكامل ، وتغيير التغييرات ، وإصدار ليس حقًا RC ، يبدأ الناس في مطاردتي ويصبح الأمر جادًا جدًا. لم يكن الأمر كذلك إذا عرضت تطوير Vue أو React وهذا أمر محبط للغاية بسبب تشويه سمعة Angular 2 التي يمكن أن تضع الناس فيها.

يبدو لي أنني لا أشارك نفس تعريف Release Candidate مثل Angular Team.

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

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

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

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

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

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

يمكنني القول أنه بدلاً من استخدام الوحدات النمطية ، كان بإمكاننا استخدام المكونات كوحدات للتطبيق. ربما كان هذا ما كان يفعله الناس قبل RC-5 على أي حال.

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

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

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

والأسوأ من ذلك ، إذا كان لدي تطبيق بدأ بـ rc-2 أو 3 (والذي كان نظريًا مستقرًا تقريبًا) ، فعلي الآن أن أقوم بالكثير من العمل لإنشاء تطبيق angular2 rc-5 جيد وأحتاج إلى شرح العميل وغيره بطريقة ما المطورين هذا. وحتى لو فعلت ذلك ، فإن الله يعلم ما الذي ستغيره بعد ذلك وربما يكون عملي في طريقه.

أعلم أن Angular 2 كانت مرحلة مبكرة منذ فترة حتى الآن ، لكننا RC-5 ، يمتلك الأشخاص مشاريع قوية جدًا باستخدام Angular 2 حتى الآن وما زلت تقوم بتغييرات ليس فقط من وجهة نظر API ولكن الانهيار كوسيلة التفكير في الزاوي.

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

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

إذا كان للوحدة الجديدة قالب ، فقد يكون المكون. فكر في الأمر.

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

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

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

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

• اضطررت إلى تغيير محدد المكون من فئة إلى عنصر ، لأنه في مكون غير مرتبط تمامًا ، يتم استخدام هذه الفئة للتصميم وبدأت فجأة في إنشاء مثيل للمكون.
• أنا متأكد تمامًا من أن # 10850 موجود فقط ، لأن لدي مكونين يسميان SpectrumComponent (صفحة واحدة كاملة للتنقل إليها بدون محدد ومكون واحد "مشترك" مستخدم في مكونات متعددة للتصور باستخدام محدد). من المحتمل أن يتم الخلط بين عملية الرفع بسبب ذلك - لا تفعل الإعلانات directives: .

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

يبدو أنه من المألوف هذه الأيام تجاهل معنى "Beta" و "Release Candidate" (يعتبر ASP.NET Core مثالاً بارزًا آخر) في المشاريع الكبيرة. لكن مواجهة التغييرات التي قد تؤدي إلى كسر التطبيق بصمت في أي مكان حرفيًا أمر محبط أكثر مما ينبغي. آمل حقًا أن تؤتي الوعود القادمة مع هذه التغييرات ثمارها قريبًا.

ngModules منطقي. لا تؤدي إزالة القدرة على التصريح / التزويد على مستوى المكون.

مثال صغير

لدي تطبيق يحتوي على عدد من مربعات الحوار المختلفة (بعضها بسيط - دعنا نسميها بسيط -1 وبسيط -2 ، وواحد معقد يحتوي على مكونات أخرى - دعنا نسمي هذا المركب 3).

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

- dialogs
   - simple-1 (containing single component and template for simple-1 dialog)
   - simple-2 (containing single component and template for simple-2 dialog)
   - complex-3 (contains the main complex-3 component plus a number of other internal components)
      - internal-component-1
      - internal-component-2
      - internal-service-3

بالنسبة لي ، هذه ميزة مثالية تم تعيينها في وحدة ميزة معزولة. لذلك أضيف

   dialogs.module.ts
   - simple-1
   - simple-2
   - complex-3
      - internal-component-1
      - internal-component-2
      - internal-service-3

وأضيف Simple1Component و Simple2Component و Complex3Component كإعلانات إلى DialogsModule. مثالي ويعمل بشكل جيد ويعطي معنى كاملًا.

ولكن...

ماذا عن كل تلك المكونات الداخلية في المجمع 3. لدي الآن خياران

• أضف كافة المكونات والخدمات الخارجية المعقدة إلى DialogsModule. يعد هذا قرارًا سيئًا لأنه يكسر تغليف المركب 3 لأنه الآن يعرف كل شيء في وحدة الحوارات عن الأجزاء الداخلية (المكون الداخلي 1 والمكون الداخلي 2 والخدمة الداخلية 3)
• اجعل المركب 3 وحدة في حد ذاته. يعمل هذا على إصلاح مشكلة تحديد النطاق (وأعتقد أنه يمكنني تصدير الوحدات النمطية من وحدة نمطية أخرى بحيث يحتاج العميل فقط إلى استيراد وحدة الغلاف) ولكن الآن يترك لي مزيجًا من المكونات والوحدات النمطية لمجموعات مماثلة (مربعات حوار).

لا يبدو أي من هذين الأمرين منطقيًا حقًا ، ومع اتساع نطاق التطبيق ، سيزداد الصراع بين الاثنين فقط.

الحل الوحيد المعقول / الواضح / القابل للصيانة بالنسبة لي هو استخدام الوحدة لتصدير مكونات المستوى الأعلى (simple-1، simple-2، complex-3) لكن دع المركب 3 _component_ يحدد مكوناته الداخلية الخاصة بنفسه.

/ سم مكعب: robwormald

لقد كنت أفكر فيما قاله kylecordes سابقًا حول استخدام نظام وحدة Typescript الحالي لتعريف مجموعات حبوب الدورة التدريبية من التعليمات البرمجية ، بدلاً من إضافة شيء ngModules الجديد. أود تقديم مثال للنظر فيه ، يستخدم وحدات Typescript لتعريف ngModules بطريقة 1 إلى 1. التعليقات والأفكار مرحب بها.

https://github.com/jbalbes/autoNgModule

10901

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

هذا مثير للاهتمام. لدينا بالفعل تطبيق مؤسسي على Angular1. ونحن نستخدم needjs لتحديد الحزمة (الحزم) للوحدات النمطية المختلفة (تحتوي كل وحدة على 10-20 توجيهًا / خدمة / فلاتر). نقوم بتجميع هذه الحزم في ملف واحد للإنتاج (باستثناء التوجيهات الرئيسية). يتم تحميل التوجيهات كسولًا في التطبيق عند استخدامها (لدينا توجيه أساسي يقوم بتحميل التعليمات المطلوبة كسول).

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

يسمح Angular1 بتحميل التوجيهات البطيئة إلى وحدة نمطية عن طريق الحصول على مرجع لموفري التسجيل.
هل هذا النوع من مكونات التحميل البطيء إلى وحدة نمطية وتجميعها إلى dom ممكن في Angular2؟

أتفق مع ما اقترحه الآخرون بأن ngModules هو حل يبحث عن مشكلة. الفائدة المحتملة لـ LazyLoading في ذهني لا تبرر الإهمال القسري لتوجيهات المكون / تبعيات الأنابيب. ربما أكون مخطئًا هنا ، لكنني أشعر أن غالبية التطبيقات لن ترى حقًا أي فائدة محققة من Lazy Loading ، والتي تعد بالنسبة لي الفائدة الحقيقية الوحيدة التي تقدمها ngModules على الإطلاق.

ربما تحاول ngModules (ومهلا ، ربما تنجح) جعل هيكل / أنماط التطوير أجمل ، ولكن بناءً على ما نظرت إليه وناقشت معه القليل من API حتى الآن ، فإنها تتحرك في اتجاه أكثر تعقيدًا اتبع وصيانه.

أيضًا ، هل نحتاج حقًا إلى نظام وحدة آخر؟

لا أحد يستطيع أن يجادل في أن NgModule تضيف نوعًا جديدًا من الأشياء التي لم يكن علينا التعامل معها من قبل. وأنا مثل أي شخص أقدر كثيرًا بساطة ما قبل RC5 ، خاصة البرامج الصغيرة جدًا ، التي ضاعت. أفتقد بشدة أيضًا أن أكون قادرًا على إخبار الناس أن Angular 1 لديها نظام الوحدات الخاص بها ، ولكن مع Angular 2 ، نستخدم فقط نظام الوحدة للغة الأساسية. أووبس.

ومع ذلك ، يوجد في الواقع الكثير من الأشخاص ، بما في ذلك العديد من العملاء المحتملين التقنيين وصناع القرار الآخرين في الشركات الكبيرة الذين يحاولون بناء أشياء كبيرة ، والذين يهتمون للغاية بالتحميل البطيء والتجميع المسبق للقالب ... وكلاهما ممكَّن بشكل كبير بواسطة NgModule.

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

kylecordes مشكلة حول الاسم https://github.com/angular/angular/issues/10087

ألن يؤدي المنطق المعروض هناك أيضًا إلى استبعاد استخدام كلمة "وحدة" أيضًا ، نظرًا لأنه يتعارض مع العديد من المفاهيم ، إن لم يكن أكثر؟

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

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

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

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

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

في الواقع ، كان من المفترض أن تستفيد Angular 2 من مجموعة تقنيات الويب الناشئة الغنية التي لم تكن متوفرة عند تطوير AngularJS. ومع ذلك ، في حين أن التبرير للعديد من قرارات التصميم التي تم اتخاذها لـ Angular 2 كان "يجب دعم مكونات الويب" ، ومن المفارقات أن إطار العمل يختلف عن المعايير بطرق متزايدة باستمرار. الآن هناك أسباب وجيهة للابتعاد عن المعيار ، عندما تكون المعايير سيئة.

أشعر أن إطار العمل لا يستخدم أدواته الأساسية لتأثيرها الكامل. على سبيل المثال ، تعريفات TypeScript ليست اصطلاحية تمامًا ويتم تناثرها مع any و any[] . يتجاهلون أيضًا ميزات اللغة القوية التي تعمل على تحسين قابلية استخدام واجهات برمجة التطبيقات وإمكانية استخدامها. تحتوي أيضًا على أشياء بغيضة مثل export declare type Type = Function .

ومن المثير للاهتمام ، أنه يبدو أن عددًا لا بأس به من القرارات قد تبين أنها مرتبطة بـ Dart. Dart ليس شيئًا يهتم به معظم مستخدمي Angular. لديها فكرة مختلفة تمامًا عن الأنواع وكيفية استخدامها مقارنةً بـ TypeScript. غالبًا ما يكون التشغيل المتداخل Dart <-> جافا سكريبت غير بداية.

aluanhaddad ، تم تقسيم تطبيق dart إلى مشروع منفصل مؤخرًا ، لذلك نأمل أن يتم معالجة بعض مخاوفك قريبًا.

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

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

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

. jbalbes شكرًا لك ، من الجيد سماع ذلك.

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

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

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

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

عصابة ، NgModule هو تهيج كما أوضح الكثير ببلاغة. لكنها عمليا ليست بهذا الحجم من الشيء. هنا (Oasis Digital / Angular Boot Camp) قمنا بالفعل بتحديث العديد من الأشياء الصغيرة ، وبعض الأشياء الصغيرة جدًا ، إلى RC5 ، وقد تم ذلك في فترة قصيرة (بعد فترة طويلة من الدراسة والفهم).

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

اعتقدت فقط أنني سأقدم أفكاري في الجانب الآخر من خمسة أيام من الضغط على منصتنا للوصول إلى RC6 * (نحن في حفلات ليلية ، لم يسقط RC6 تقنيًا حتى الآن في وقت كتابة هذا التقرير). أشعر أنه على الرغم من أن تعليقاتي الأصلية لا تزال صالحة ، إلا أن هناك شعورًا بالارتياح لبلوغ هذا الإنجاز. تستمر أكبر الصعوبات في استخدام بناء جملة التوجيه الجديد - الكثير من القواعد الفارغة path: '' ! (أنا أستطرد) ولكن هذا شيء ربما نتخلى عنه بعيدًا.

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

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

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

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

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

يوجد دائمًا أعضاء في فريق Angular يقدمون الدعم بشأن Gitter والقضايا.
يجب أن تدرك أيضًا أن عبء الاتصال غير متماثل تمامًا ، مع وجود عدد قليل من أعضاء فريق Angular لآلاف المطورين.

أوافق تمامًا على أن هذا أسهل في التصميم الرئيسي (تقريبًا RC6) مع انتهاء العام الماضي + من الإهمال في النهاية.

kylecordes بأي طريقة يسهل العمل بها على المستوى الرئيسي؟

تم إصدار مستند تصميم NgModules (المعروف سابقًا باسم AppModules عندما تمت كتابة مستند التصميم) قبل أكثر من شهر قبل إصدار RC5 ، وكنت على استعداد لذلك.
علاوة على ذلك ، نظرًا لأن NgModule كان مفهومًا جديدًا ، كان من الصعب الحصول عليه تمامًا وترحيل تطبيقك المتوسط ​​إلى الكبير.
ما فعلته بدلاً من ذلك هو ، أولاً فهم الفروق الدقيقة في NgModules وكيفية التفكير في NgModules لتصميم تطبيق Angular 2. ثم أنشأ تطبيق التعلم الذاتي مع تطبيق NgModules.
الخطوة الثانية هي - فكر في كيفية كسر التطبيق الحالي في وحدات ثم ترحيلها من أعلى إلى أسفل. إنشاء وحدة نمطية واحدة في كل مرة بدءًا من AppModule. لقد ساعد هذا حقًا ويبدو التطبيق النهائي أكثر تنظيماً.

ونعم ، كان Gitter مفيدًا حقًا في تقديم المساعدة بشأن NgModule حتى قبل إصدار RC5. بعد RC5 ، لدينا مستندات ومدونات متاحة لنا لتعلم أفضل بكثير.

zoechi بدون إخراج هذه المناقشة عن مسارها كثيرًا ، أشعر أنه يجب علي توضيح تعليقاتي. لم أكن أشير إلى التوثيق على الإطلاق ، فقد أتت معظم فهمي من مراجعة الالتزامات والقضايا هنا في GitHub ، وأنا بخير في ذلك. إحباطاتي تأتي من نقص التمثيل هنا في هذه القضية ، لدينا 61 تعليقًا وعدًا. ببساطة ، "نحن ندرك مخاوف الجميع هنا في هذه المشكلة ، ونعتقد حقًا أن هذا هو أفضل نهج لـ Angular 2 وندرك الصعوبات التي ستسببها ولكنها أفضل لمستقبل المنتج". Gitter رائع ولكن غالبًا ما تضيع الرسائل الفردية في بحر من الأشخاص الذين يحاولون فهم جوانب مختلفة من Angular 2. لقد تواصلت من خلال هذا الوسيط ولكن نظرًا لاختلافات المنطقة الزمنية أو الأولويات الأخرى ، لم أتمكن من الحصول على التعليقات الموثوقة. يمكن استخدامها لاتخاذ قرار مستنير. ما ساعده هو هذه المغامرات في البودكاست الزاوي https://devchat.tv/adv-in-angular/106-aia-angular2-rc5-and-beyond. لقد منحني هذا الثقة للمضي قدمًا في ترقيات NgModule.

أتمنى لك كل خير.

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

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

أول شيء يجب فهمه حولNgModule () (و Component وأي مصمم أنجوكار آخر) هو أنها مجرد بناء وقت تجميع - فهي موجودة للسماح للمجمع الزاوي باكتشاف الرسم البياني للتبعية في أحد التطبيقات.

نسخة (مبسطة) لما يبدو عليه المصممون لدينا:

//simplified Component decorator
export function Component(componentConfig){
  return function(componentClass){
    Reflect.defineMetadata('annotations', componentConfig, componentClass);
  }
}

إنهم لا يغيرون أو يعدلون سلوك الفصل المزخرف بأي شكل من الأشكال - فهم ببساطة يرفقون بعض البيانات الوصفية. يستخدم Angular تلك البيانات الوصفية لإنشاء تطبيقك وتجميع القوالب.

في وضع JiT ، يحدث هذا "في الوقت المناسب" - بين استدعاء bootstrapModule وعرض المكون الأول الخاص بك ، يقوم مترجم Angular باسترداد البيانات الوصفية المرفقة بالفئات باستخدام Reflect API:

let metadata = Reflect.getOwnMetadata('annotations', componentClass);

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

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

لذلك ، في حين أن مصممي الديكورComponent أعطانا القدرة على التحليل الثابت للمكون ، لم تكن لدينا القدرة على التحليل الثابت بشكل موثوق لتطبيق _Application_

الأشياء التي تندرج تحت مظلة "تطبيق"

• PLATFORM_DIRECTIVES / الأنابيب / المزودون
• الأشياء التي أضفتها مسبقًا إلى bootstrap ()
• إعدادات مستوى المترجم
• مكونات جذر متعددة
• استخدام جانب الخادم.

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

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

المزيد للمتابعة في الرد التالي ...

robwormald لا أستطيع أن أضع في رمز تعبيري مقدار التقدير لهذا النوع من المعلومات الأساسية.

شكرا لك!

مشكلة أخرى واجهتنا حلها NgModules:

ضع في اعتبارك حالة تريد فيها إنشاء DialogService أو ما شابه ذلك.

تاريخيًا ، كنت ستفعل شيئًا مثل:

@Injectable()
export class MyDialogService {
  //inject the dynamic compiler 
  constructor(private componentResolver:ComponentResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //compile the component into a factory, async
    return this.componentResolver.resolveComponent(component)
      .then(componentFactory => {
         //dynamically insert the compiled componentFactory into the view:
        return target.createComponent(componentFactory);
      })
  }
}

... الذي تريد استخدامه

myDialogService.showDialog(MyRandomDialogComponent).then(...)

أشياء يجب ملاحظتها هنا -

• يجب أن يكون تجميع المكون في وضع JiT _must_ غير متزامن ، بسبب Templates الخارجية و styleUrls
• يقبل viewContainer _componentFactory_ - حتى الآن هناك مشكلة في التعليمات البرمجية الخاصة بك: عليك إما إعادة كتابة التعليمات البرمجية للتبديل بين الأوضاع (بين JiT و AoT) ، _ أو_ يجب أن تفترض دائمًا أن واجهة برمجة تطبيقات إدخال المكون غير متزامنة. قد يكون هذا جيدًا في حالة وجود مربع حوار ، ولكن إذا كنت تقوم بإنشاء واجهات مستخدم معقدة ديناميكيًا (فكر في لوحة معلومات أو عرض الشبكة أو أي شيء آخر) ، فإنك تتحمل قدرًا كبيرًا من جدولة الوعد غير الضرورية.
• الخدمات / المكونات الخارجية أو المشتركة (مثل SharedDialogService) لها نفس المشكلة ، حيث يتعين عليك قبول _either_ Component أو ComponentFactories

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

لذلك ، عند إضافة مكون إلى مصفوفة مكونات الإدخال الخاصة بك في مصمم NgModule:

@NgModule({
  declarations: [ MyRandomDialogComponent ],
  entryComponents: [ MyRandomDialogComponent ]  
})
export class MyApp {}

ما يخبرنا به هذا المترجم هو "إنشاء تعيين لي بين MyRandomDialogComponent و MyRandomDialogComponentNgFactory" ، وتخزينه في NgModuleFactory حيث تم التصريح عنه_

وبالتالي ، تبدو النسخة المدفوعة من NgModule من مربع الحوار أعلاه كما يلي:

@Injectable()
export class MyDialogService {
  //inject the component factory resolver 
  constructor(private componentFactoryResolver:ComponentFactoryResolver){}

  //accept a component and a viewContainerRef
  showDialog(component:Type, target:ViewContainerRef){
    //*retrieve* the componentFactory by component, sync
   let componentFactory = this.componentFactoryResolver.resolveComponentFactory(component)
   //add the componentFactory to the view, sync
   return target.createComponent(componentFactory);
  }
}

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

شكرا لك على الشرح robwormald

سؤال واحد هو: هل يستلزم ذلك إزالة التوجيه / التصريحات الأنابيب؟ هل هناك سبب يمنعهم من التعايش مع NgModule؟

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

أرى أيضًا أن طلب السحب لإزالة التوجيهات / إعلانات الأنابيب قد تم رفعه (https://github.com/angular/angular/pull/10912) - آمل أن نتمكن من الحصول على رد بشأن هذه النقطة قبل تعيين أي شيء حجر.

شكرا لك مقدما. كان Angular بلا شك ممتعًا للعمل معه وأنا أقدر كثيرًا العمل الشاق للفريق خلال العام الماضي +

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

يعد إغراق التطبيق بالكامل في NgModule واحدًا "جيدًا" من حيث أن إغراق حالة التطبيق بالكامل في $ rootScope كان "جيدًا" في Angular1 (اقرأ: إنه يعمل ، ولكن تصميمه الرديء للتطبيق)

في Angular 1 ، يؤدي إدخال وحدة نمطية إلى تطبيق "تلويث" تطبيقك بالكامل إلى حد ما ، حيث تم إلقاء كل شيء في كيس حاقن واحد.

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

عندما يجتاز Angular تطبيقك ويترجمه ، يتم _جمع كل مكون يواجهه في السياق الذي تم الإعلان عنه فيه.

على سبيل المثال - تخيل أن لديك SharedModule مع بعض الوظائف التي تريد مشاركتها عبر أحد التطبيقات

@Component({
  selector: 'shared-component-one',
  template: `
    <div>Shared Component One</div>
    <shared-component-two>
  `
})
export class SharedComponentOne {}

@Component({
  selector: 'shared-component-two',
  template: `
    <div>Shared Component Two</div>
  `
})
export class SharedComponentTwo {}

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

كل من SharedComponentOne و SharedComponentTwo _declared_ في SharedModule - تشير الإعلانات إلى _ownership_ - لذا فإن كلا المكونين مملوكين لـ SharedModule. ومع ذلك ، _only_ SharedComponentOne هو _exported_ من الوحدة النمطية - يبقى SharedComponentTwo _private_ إلى SharedModule.

إذا كنت ستحضر SharedModule وتستخدمه في وحدة أخرى ، مثل:

@Component({
  selector: 'some-component',
  template: `
    <div>hello from some component</div>
    <shared-component-one></shared-component-one>
  `
})
export class SomeComponent {}

@NgModule({
  imports: [ SharedModule ],
  declarations: [ SomeComponent ]
})
export class SomeModule {}

... عندما يبدأ المترجم في تجميع SomeComponent ، يكتشف محدد shared-component-one ، ولأن SharedModule (الذي يصدر SharedComponentOne ) يتم استيراده إلى SomeModule ، يعرف أن العنصر المشترك واحد === SharedComponentOne.

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

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

ضع في اعتبارك ما إذا كان لديك شيء مثل ميزة علامات التبويب:

@Component({
  selector: 'my-tabs',
  template: '...'
})
export class TabsComponent {}

@Component({
  selector: 'my-tab',
  template: '...'
})
export class TabComponent {}

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

export const TAB_DIRECTIVES = [ TabsComponent, TabComponent ]

قد تحتوي ميزة علامات التبويب الأكثر تعقيدًا على خدمة تدير مثيلات متعددة من علامات التبويب ، لذلك يتعين عليك أيضًا التعامل مع هذه الحالة ...

export const TAB_PROVIDERS = [ ... ]

واستخدامه يصبح تمرينًا في تذكر كل الأشياء التي لديك لتصديرها واستيرادها ...

import {TAB_DIRECTIVES, TAB_PROVIDERS}

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

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

بالنسبة للمكتبات مثل تصميم المواد ، والتي قد تحتوي على عدد من الميزات المنتشرة عبر وحدات نمطية متعددة ، يمكنك الاستفادة من دلالات الاستيراد / التصدير نفسها لجعلها أكثر قابلية للنقل:

@NgModule({
  exports: [ TabsModule, NavbarModule ]
})
export class MaterialSharedModule {}

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

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

في RC5 ، قمنا بعمل نوع من الرفع الآلي للمكونات. التوجيهات في النطاق "العالمي". كانت هذه محاولة لتسهيل الانتقال ، وبينما نجح الأمر بالنسبة لمعظم الناس ، تسبب السلوك القديم والجديد المختلط في حدوث بعض الأخطاء الغريبة والسلوك الذي يكون محبطًا مؤقتًا. يختفي هذا في RC6 (وقد تم تحسين رسائل الخطأ)

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

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

روب

عمل جيد ، robwormald

أود إضافة بعض الملاحظات الإضافية:

الموفرون

ركز روب على _declarations_ و _imports_ و _exports_. الوحدة _Providers_ مختلفة.

حياة @Component.providers ! سيتم التخلص من @Component.directives و @Component.pipes فقط.

يمكنك استخدام كلاً من @NgModules.providers و @Component.providers . لها أغراض مختلفة:

أ) @NgModules.providers _ تمديد_ التطبيق عن طريق إضافة موفري إلى الحاقن "الرئيسي" (حاقن جذر التطبيق للوحدات النمطية المحملة بشغف). هذه هي الطريقة التي يضيف بها RouterModule خدمة توجيه إلى تطبيقك دون الحاجة إلى توفيرها.

ب) يفرض @Component.providers _ تقديم الخدمة ضمن نطاق مثيل المكون (والشجرة الفرعية للمكون الخاص به).

كلا النهجين تلبية الاحتياجات المختلفة.

نصيحتي العامة: _ إذا كان لديك مقدم خدمة على @Component اليوم ، اتركه هناك_

وحدات الميزة

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

أبحث عن طبقات طبيعية في تطبيقي. أنا لا أذهب للجنون. أنا لا أضع كل مكون نمطيًا.

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

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

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

اكتشاف تبعيات التصريح

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

يؤدي الترحيل من مرحلة ما قبل RC5 إلى تعزيز الشعور بالخسارة. علينا القيام بالعمل الشاق المتمثل في اكتشاف التبعيات في قوائمنا السابقة directives و pipes . وعلينا التخلص من الخداع. هذا هو الكراهية الأساسية للعيش على حافة الهاوية.

لا ينبغي أن يغير RC هذا كثيرًا

نعم. لن تحصل على جدال من الفريق حول ذلك. لم يكن ذلك مقصودًا. لو علمنا أننا بحاجة إلى NgModule لكنا حصلنا عليه في مرحلة تجريبية.

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

لقد قمت بتحويل عدد من التطبيقات الآن وساعدت الآخرين على القيام بذلك. بمجرد تجاوز مرحلة "_نقلوا الجبن (مرة أخرى) _" ، كانت هذه هجرة ميكانيكية ويبدو أن الجميع يعتقدون أنهم في مكان أفضل. ربما كانوا فقط لطيفين معي. OTOH ، أنا لا أتسكع مع أشخاص كل هذا لطيف ؛-)

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

ضع في اعتبارك أنه ليس بديلاً عن وحدات ES - إنه زيادة ستسمح لهز الشجرة ووحدات ES بالعمل بشكل أفضل لجميع المطورين الزاويون ، ومن الناحية اللغوية ، فهي تشبه كيفية عمل الوحدات النمطية ES (الواردات والصادرات والإعلانات)

لذا فإن التسمية صعبة. NgModule هو عليه.

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

شكراً جزيلاً لك @ robwormaldwardbell على التعليقات الثاقبة للغاية. أعتقد بالنسبة لي أن أعظم راحة

"لقد أكملنا API لـ 2.0.0 ، ولذا سنراقب خلال الأشهر القليلة القادمة بعد الإصدار لمعرفة الأنماط التي تتطور ، وأين يمكننا السكر وتقديم استنتاجات أفضل لـ 2.1."

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

أعتقد بصدق أنه يمكنك القول أن SaltyDH. انتهى الزاوي 2.

هذا لا يعني أن Angular 2 قد تم تطويرها. سيكون هناك إصدارات مستقبلية. لكن الزخم المؤدي إلى 2.0 ... انتهى ...!

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

مجرد فكرة سريعة عن التسمية والنسخ في واجهة برمجة التطبيقات لـ NgModule ، والتي أشعر أنها مرهقة بعض الشيء.

IMO هذا:

@NgModule({
  declarations: [ SharedComponentOne, SharedComponentTwo ],
  exports: [ SharedComponentOne ]
})
export class SharedModule {}

... يمكن أن يكون أكثر وضوحًا وإيجازًا على النحو التالي:

@NgModule({
  private: [ SharedComponentTwo ],
  public: [ SharedComponentOne ]
})
export class SharedModule {}

1) WRT للتسمية (العامة والخاصة مقابل الإعلانات والصادرات) ، إنها في الأساس كيف robwormald أعلاه وأنا متأكد من أن العديد من الآخرين يشرحونها

2) (تجاهل التسمية) لماذا يجب تكرار SharedComponentOne ؟ بالتأكيد يمكنك القول ما إذا كان "تصدير" يجب أن يكون "تصريحًا" ، لذلك يمكن التخلص منه بهذه الطريقة؟

فقط سنتان على شيء شخصي للغاية - شكرًا مرة أخرى على التفسيرات التفصيلية!

robwormaldwardbell شكرًا على التفسيرات التفصيلية.

وكما قلت سابقًا في هذا الموضوع ، فإن NgModules يساعدنا على التنظيم بشكل أفضل. من الأمثلة الحديثة إنشاء توجيهات المدقق للنماذج القائمة على القوالب. قبل RC5 ، كان علينا استيراد كل توجيه على المكون حيث نقوم بإنشاء نموذج. الآن نقوم فقط بتجميعها في VaildatorModule واستيراد الوحدة حيثما لزم الأمر. أي مدقق نضيفه لاحقًا ، متاح تلقائيًا للوحدات النمطية حيث قمت باستيراد ValidatorModule . أنا فقط بحاجة إلى تحديث القالب دون القلق بشأن التبعيات.

يتم استخدامJamesHenry declarations و imports و exports للحفاظ على NgModules متماشية مع وحدات ES6 كما هو الحال في import و export و declare أشياء في وحدات ES6.
أنا أتفق مع السكر ، الأشياء التي يتم تصديرها يمكن تفكيكها وتحويلها إلى إعلانات بطريقة سحرية.

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

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

2) if it is an "export" it must be a declaration, so it could just be desugared that way? -> يعمل هذا حتى تستخدم ngModule لإعادة التصدير ، كما في مثال MaterialModule أعلاه - هناك الكثير من الحالات التي يمكنك فيها استخدام ngModule لإعادة تصدير شيء معلن في وحدة نمطية أخرى ، و ثم تنهار الاستدلالات.

robwormald تعليقات رائعة! بالتأكيد تستحق منشور مدونة.

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

أنا متأكد من أنها ستغرق مع الوقت

shlomiassaf شكرا!

يجب أن تذكر أيضًا ، في حالات مثل حالتك:

لاحظ أنه عند استخدام جهاز توجيه angular ، فإنك تضيف مكونات إلى الإعلانات وتكوين المسار ، ولكن _لا _ إلى مكونات الإدخال ، على الرغم من حقيقة أن جهاز التوجيه هو تعريف مكونات الإدخال. (تذكر - entryComponent === الشيء الذي تريد الإشارة إليه بالفئة بدلاً من المحدد)

هناك خدعة رائعة يمكن لأي مكتبة الاستفادة منها - هناك رمز سحري يسمى ANALYZE_FOR_ENTRY_COMPONENTS - راجع https://github.com/angular/angular/blob/master/modules/٪40angular/router/src/ router_module.ts # L117 لمعرفة كيفية استخدام جهاز التوجيه له.

لذلك بالنسبة إلى libs التي تتعامل مع المكونات المدرجة ديناميكيًا ، يمكنك القيام بشيء مثل:

@NgModule({
  providers: [ DialogService ]
})
export class DialogModule {
  static withComponents(componentList): NgModuleWithProviders {
    return {
      ngModule: DialogModule,
      providers : [
         { provide: ANALYZE_FOR_ENTRY_COMPONENTS, useValue: componentList, multi: true }
      ]
     }
  }
}

تستخدم مثل

@NgModule({
  declarations: [ MyConfirmDialog, MyQuestionDialog ],
  imports: [
    DialogModule.withComponents([ MyConfirmDialog, MyQuestionDialog ])
  ]
})
export class MyAppModule {}

قد تعمل من أجل حالة الاستخدام الخاصة بك ، قد لا.

JamesHenry مهم جدًا ألا يتم الخلط بين declarations وبين private . أنت تقول _This module تعلن عن هذا المكون_. أنت لا تدلي بأي تصريح حول عام أو خاص. أنت تقدم مطالبة بالملكية.

إن الأمر يشبه ما يحدث في وحدات ES6. أي شيء تحدده داخل الملف "ينتمي" إلى الوحدة المحددة بواسطة هذا الملف. سواء كانت عامة أم لا تعتمد على استخدامك للكلمة الرئيسية export .

وكما هو الحال مع وحدات ES6 يمكنك إعادة تصدير الأشياء التي قمت باستيرادها.

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

لذا ، بالنسبة لي ، يعد declarations بديلاً عن لصق تلك الملفات في ملف واحد كبير فظيع. هذا _ my_ النموذج العقلي على أي حال.

شيء واحد يجب ملاحظته هو الفرق المنطقي بين مقدمي الخدمات والمكونات في سياق الوحدة النمطية.

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

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

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

wardbell شكرًا وارد ، هذا رائع حقًا! فقط للتوضيح لأن هذا تم طرحه للتو في المناقشات ، عندما نقول أن Angular 2 عبارة عن واجهة برمجة تطبيقات كاملة ، ما هي مساحات الأسماء التي نتحدث عنها هنا؟ @ مستطيل / ؟؟؟

robwormald شكرا! نصيحة رائعة !!!
واحد بنكهة السكر! ستنفذ.

أنا لست موظفًا في Google وربما لا يستطيع أحد موظفي Google التصريح بذلك. يمكنني فقط الإبلاغ عما أراه بأم عيني: تجميد خطير للغاية لواجهة برمجة التطبيقات عبر مجموعة مكتبات @angular/ .

هناك أفكار جيدة معلقة على الرف لأنها لم تكن جيدة بما يكفي أو عميقة بما يكفي لتبرير تعليق الإصدار. هذا ما ينبغي أن يكون. الأفكار الجيدة لا تتوقف أبدا. ولكن حان الوقت لنقول _هذا هو Angular 2.0_ الخاص بك.

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

wardbell أردد ما تقوله عن الصادرات.
تمت تعبئة الفهرس مرة واحدة بـ

export * from 'a.component'
export * from 'b.component'
export * from 'c.component'
export * from 'p.directive'
export * from 'x.service'
export * from 'z.pipe'

الآن إلى export * from my.module فقط
بقية الأشياء نظيفة يجلس في صادرات NgModule مثل
exports: [ AComponent, BComponent, CComponent, PDirective ] وهكذا

wardbell أعتقد أن @NgModules.providers كان يجب أن يكون @NgModules.rootProviders أو @NgModules.appProviders .

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

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

ربما كان من الممكن أن يكون هناك اسم مختلف. أنت تعرف كيف أن يذهب. لكن rootProviders لم يكن ليكون تحسنًا للأسباب التي قدمتها للتو.

وافق wardbell ، لم أفكر في هذا السيناريو.

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

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

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

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

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

أيضًا ، تفشل NgModules تمامًا في معالجة مشكلة كبيرة:

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

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

wardbell إن أكبر إحباط بالنسبة لي بشأن RC هو الانطباع بأن إصدار بيتا قد تم دفعه للتو إلى RC بسبب ng-conf و google i / o. لإحراز تقدم ، يجب توضيح السبب: لقد كان "التسويق" وكخبراء تقنيين يجب أن نكافح اتجاه هذه المفاهيم المرنة للنضج. قد تعرف شركة تصنيع سيارات شهيرة في الوادي حيث يدور النقاش حول ما إذا كان من الصواب بيع إصدار تجريبي لمنتج ما لأنه قد يستغرق عمراً. لا أريد المبالغة ، لكن بصفتي تقنييين ، يجب أن نتحدث عما إذا كانت هذه هي الطريقة التي تسير بها صناعتنا لأنها تسير في اتجاه خاطئ.

يعجبني نهج ngmodule لكن لدي سؤال robwormald :

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

شكرا على الجواب!

لذلك يمكنني أن أشعر بالألم مع المكتبات / مكتبات التطبيقات المعيارية و ngModule.

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

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

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

بهذه الطريقة؟ إذا رأيت أحد المكونات. أعلم أنه يجب أن يكون جزءًا من ngModule. إذا كانت لدي حالة للعديد من المكونات لتجميعها معًا ، يمكنني استخدام NgModule. إذا كنت أرغب فقط في مكون مستقل مثل "المكونات القديمة" ، فأنا أستخدم ComponentModule وأعرف جميع التبعيات وأنه يمكن أن يكون اعتمادًا على الوحدة النمطية للوحدات النمطية الأخرى ، ولكن ليس جزءًا منها

nathraQ إذا كان الأسلوب الصحيح هو استخدام NgModule لكل مكون ، وربما يكون كذلك ، فلا يجب تقديم NgModule ، ويجب تحسين المكون للتو. فيما يتعلق بالنموذج المعياري ، فإن Angular 2 ثقيلة جدًا عليها بحيث لا تكاد تكون مهمة في هذه المرحلة.

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

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

كلاهما مفيد. الآن علينا معرفة كيفية دمجها بشكل مفهوم للجميع

واو ، لقد كانت قراءة طويلة: ابتسم:

يمكنني رؤية إيجابيات وسلبيات التغيير الجديد ، لكنه جعلني أفكر في سيناريو واحد واجهت مشكلة في Angular 1.

whatsapp -

إذا استخدمت نمط SharedModule ، وقمت باستيراد مكتبتين من طرف ثالث (ui-bootsrap مقابل angular-strap أي شخص؟) كلاهما يستخدم نفس المحدد لمكون ، دعنا نقول my-selectbox

سأحصل على خطأ إذا حاولت استيراد كليهما؟ حق؟

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

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

هل هناك حل موصى به لهذه المشكلة؟ أم أنها "وحدة الغلاف"؟
(آمل ألا نعود لاستخدام بادئة للمحددات ، فهذا لم يكن ممتعًا)

شكرا لك مقدما!

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

nathraQ كل هذه الأنماط يمكن تحقيقها باستخدام وحدات ECMAScript. إن مقدمة NgModule لا تصلنا إلى أي مكان ، وحقيقة أن مكتبات مثل AngularMaterial تحول المكونات إلى NgModules فقط للحفاظ على التغليف المقدم سابقًا تثبت هذه النقطة.

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

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

@ emilio-martinez ، كما كتب aluanhaddad ، أعطانا ES6 و "الطريق الزاوي القديم 2" مساحة الأسماء التي نحتاجها.

لقد عملت في مشاريع كبيرة جدًا مع Angular 1 ، حيث كان لدي محدد اسمه: mb-product-list يمكن أن يصطدم بسرعة كبيرة مع الآخرين إذا كان مشروعًا كبيرًا (حتى في فريق من أكثر من 5 مطورين).

في محاولة لحلها بمزيد من مسافات الأسماء ، ينتهي بك الأمر بـ: mb-somefeature-product-list مما يجعل القوالب تبدو متسخة.

كنت سعيدًا جدًا لرؤيتها تم حلها في ng2 بسبب البيانات الوصفية directives .
يمكنك تثبيت أي حزمة تريدها npm ، واستيراد ما تحتاجه فقط منها لكل مكون.

تتميز ngModules بفوائدها المؤكدة ، فهي تساعد في تحميل الأجزاء غير المتزامنة وتساعدنا أيضًا في كتابة واردات أقل وتحسين الإنتاجية.

لكن استخدام النمط SharedModule يقدم مساحة اسم عالمية ، كما كان الحال في ng1.

على الأقل مع الموفرين ، يتم تحديد مسافة الاسم بواسطة رمز ES6 ، موقع الملف.

مع المكونات ، بسبب المحددات ، سيصرخ أن هناك مكونين لهما نفس المحدد.

أتمنى أن يكون لدينا طريقة سهلة لتهيئة مساحة اسم خاصة لاستخدام حالات التعارض مع مكونات خارجية أو مكونات مشتركة محلية.

شيء مثل "تجاوز المحدد".

هذا ما كنت أسأل عنه

شكرًا robwormald على رؤيتك التفصيلية ، ولكن هناك شيء واحد من مبتدئين مثلي (في الغالب ، أنا مطور خلفية). أنا أتعلم Angular 2 ومع الكتابة المطبوعة. لذا فإن مفهوم الوحدة النمطية ES6 هو نوع من الضبابية بالنسبة لي
لدينا هيكل تطبيق معقد. إنه تطبيق تحليلات ، حيث يبلغ عدد مكوناتي 60 تقريبًا.
وأعتقد أنه مبني جيدًا تحت RC4. بصرف النظر عن تسجيل الدخول ، لم نستخدم أي نوع من التوجيه ، لأن الروترن يخلق المكون بأكمله. لذلك نحن نخطط كتطبيق قائم على علامات التبويب ، وهناك علامتا تبويب رئيسيتان (1 ، تحليل 2. لوحة تحكم).
ستحتوي علامة تبويب التحليلات على عدة علامات تبويب لكل منها تحليل واحد تحتها. سوف لوحة القيادة لديها أيضا
علامات تبويب متعددة ولكن كل علامة تبويب ستتألف من تحليل متعدد تم حفظه في إطار
قسم التحليلات. لذا ، الانتقال ذهابًا وإيابًا من علامات تبويب متعددة (تحت كل من لوحة القيادة والتحليل)
وكذلك التبديل بين علامة تبويب لوحة التحكم وعلامة تبويب التحليلات ، نشعر أن التوجيه لن يخدم
غرضنا (صححني إذا كنت أقول شيئًا غبيًا).
الآن نوع RC5 NgModule من كسر تطبيقنا. نحن حقا لا نعرف كيف نفعل ذلك
إعادة تصميم تطبيقنا. هل يمكننا حقًا استخدام تجميع AoT في تطبيقنا؟ لا
كل شيء AoT يعتمد على التوجيه؟

توفر shairez NgModules بالضبط هذا النوع من مسافات الأسماء. اسمحوا لي أن أحاول توضيح هذا قليلاً ...

الشيء الأساسي الذي يجب إدراكه هنا هو أن المكون يتم تجميعه ، بشكل أو بآخر ، "داخل" الوحدة النمطية التي تم الإعلان عنها فيها - راجع https://plnkr.co/edit/9w10b1Y8Bjr5DDIxOwnC؟p=preview للحصول على مثال.

لاحظ أن هناك محددين متعارضين ( my-generic-selector ) - تستورد كل وحدة نمطية واحدة منها ، وتستطيع استخدامها داخليًا في تلك الوحدة ، دون تلويث أي مساحات أسماء "عالمية".

حتى تستخدم مثل

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one></feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two></feature-two>
</my-app>

يتوسع إلى

<my-app>
  <!-- belongs to FeatureModuleOne -->
  <feature-one>
    <!-- the generic imported in FeatureModuleOne -->
     <my-generic-selector></my-generic-selector>
  </feature-one>
  <!-- belongs to FeatureModuleTwo -->
  <feature-two>
    <!-- the generic imported in FeatureModuleTwo -->
    <my-generic-selector></my-generic-selector>
  </feature-two>
</my-app>

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

robwormald بالتأكيد ، هذا رائع وأفضل من Angular 1 بهذا المعنى.

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

إذا كنت سأحاول التصريح عن كل من GenericSelectorFeatureOne و GenericSelectorFeatureTwo داخليًا من SharedModule ، فسأحصل على خطأ صحيح؟

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

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

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

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

شكرًا هذه هي الإجابة التي كنت أبحث عنها ، سأختبرها.

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

شكرا على المساعدة robwormald !

من أحدث المستندات المتوفرة على https://angular.io ، هناك _many_ تحذيرات حول الأنماط المضادة والأخطاء التي يمكن أن تظهر بسهولة إذا تم تكوين NgModule s بشكل غير صحيح. فمثلا

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

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

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

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

هل يمكنني إعادة تصدير الفئات والوحدات النمطية؟
قطعا!
تعتبر الوحدات النمطية طريقة رائعة لتجميع الفئات بشكل انتقائي من الوحدات النمطية الأخرى وإعادة تصديرها في وحدة موحدة ومناسبة.
يمكن للوحدة النمطية إعادة تصدير الوحدات النمطية بالكامل والتي تقوم بإعادة تصدير جميع الفئات التي تم تصديرها بشكل فعال. تقوم شركة Angular's BrowserModule بتصدير بعض الوحدات النمطية مثل هذا:
الصادرات: [CommonModule، ApplicationModule]
يمكن للوحدة النمطية تصدير مجموعة من الإعلانات الخاصة بها ، والفئات المستوردة المحددة ، والوحدات النمطية المستوردة.

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

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

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

المستندات لا تذكر شيئًا عما إذا كانت عمليات إعادة التصدير متعدية ... الوحدة A تعيد تصدير CommonModule. الوحدة "ب" تستورد الوحدة "أ" الوحدة "ج" تستورد الوحدة "ب" هل يعني ذلك أن الوحدة "ج" يمكنها الآن استخدام التوجيهات من "الوحدة النمطية"؟

@ Martin-Wegner إنها انتقالية كما هو موضح هنا https://angular.io/docs/ts/latest/cookbook/ngmodule-faq.html#! # إعادة تصدير ف

aluanhaddad أين؟ لا يمكنني العثور على أي كلمة عن عمليات إعادة التصدير المتعدية بأكثر من قفزة واحدة ...

عند قراءة ما حصل عليه aluanhaddad من مستندات الزاوية أشعر أنني يجب أن أعيد النظر في كل ما تعلمته عن Angular 2 وربما حتى إذا لم يكن هناك إطار عمل يتعامل مع التبعيات بطريقة أفضل.

كما أفهمها. إذا كان لديّ App Module يستورد HttpModule ولديّ وحدة ميزات مع خدمة تستخدم خدمة Http ، فلا يجب أن أقوم باستيراد HttpModule على مستوى الوحدة النمطية للميزات ولكن على مستوى وحدة التطبيق. إذن ماذا يحدث إذا قمت بإنشاء وحدة ميزة مشتركة بين العديد من وحدات التطبيق؟ لا بد لي من استيراد HttpModule في وحدة التطبيق. لا أستطيع أن أقول أن وحدة الميزة الخاصة بي تعتمد على HttpModule. هذا قبيح حقًا ويعني أن تعريف NgModule يفتقر إلى الكثير من الميزات مثل PeerDependecies على سبيل المثال.
يا ولد. يبدو أن الزاوية 2 تتفكك. أخشى أن الوقت قد حان للبدء من جديد ، والتخلي عن الزاوية 2 والبدء بالزاوية 3.

في الواقع ، هناك الكثير من المعنى فيما قلته للتو. لقد بدأت هذا
angular2 هي رحلة منذ العام الماضي ولم يكن لديك أي سبب للشعور بالضرب
على الرغم من كل التغييرات الهائلة التي رأيناها حتى الآن (من ألفا إلى الإصدار التجريبي ،
و RC). إنه مفهوم في تلك المراحل وبما أنه عالق دينياً
إلى الفلسفة التي استخدمتها في تحويلي من Backbonejs البسيط.
لقد أثبتت الفكرة الكاملة لهذه الوحدات النمطية بالنسبة لي أنها تتعارض إلى حد ما
إنتاجي. ومن المحزن أن أشاهد كل الوقت الذي بذلت فيه التبشير
يذهب الخير الغني "للمكونات" البسيطة والخالية من سخام إلى
نفايات تماما.
في 29 آب (أغسطس) 2016 ، الساعة 9:44 صباحًا ، كتب "دانيال شوبا" [email protected] :

قراءة ما تم التقاطه من aluanhaddad https://github.com/aluanhaddad
مستندات الزاوي أشعر أنني يجب أن أعيد النظر في كل شيء لدي
تعلمت عن Angular 2 وربما حتى لو لم يكن هناك إطار عمل
يتعامل مع التبعيات بطريقة أفضل.

كما أفهمها. إذا كان لدي App Module يستورد HttpModule وأنا
لديك وحدة ميزة مع خدمة تستخدم خدمة Http ، لا ينبغي لي
استيراد HttpModule على مستوى وحدة الميزات ولكن على مستوى وحدة التطبيق. وماذا في ذلك
إذا قمت بإنشاء وحدة ميزة مشتركة بين العديد من وحدات التطبيق؟ عندي
حقًا على HttpModule يتم استيراده في وحدة التطبيق. لا استطيع ان اقول ،
أن وحدة الميزة الخاصة بي تعتمد على HttpModule. هذا حقا قبيح و
يعني أن تعريف NgModule يفتقر إلى الكثير من الميزات مثل على سبيل المثال
الاعتماد على الأقران.
يا ولد. يبدو أن الزاوية 2 تتفكك. أخشى أن الوقت قد حان
ابدأ من جديد ، اترك الزاوية 2 وابدأ بالزاوية 3.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/angular/angular/issues/10552#issuecomment -243066961،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AF675h8_np9i5cHgL8mMOOu8vMMQmWKkks5qkpv8gaJpZM4Jee-o
.

هل يمكن لشخص ما أن يصححني إذا كنت مخطئا.

أفكر في تنظيم التطبيق على النحو التالي.

تطبيق
| --القانون /
| ---- العديد من المكونات.
| ---- LawNGModule.
| --مستخدم /
| ---- العديد من المكونات
| ---- UserNGModule
| --AppNGModule
| --SomeFirstLeveComponents

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

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

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

robwormald ردًا على تعليقك أعلاه :

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

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

من أجل تسهيل الترحيل ، كنت أفكر في إنشاء وظيفة من شأنها إنشاء وحدات ديناميكية ؛ شيء من هذا القبيل:

function createModule (entryComponent: Type, dependencies: Type[]) {
    @NgModule({
        imports: [CommonModule, FormsModule],
        declarations: [entryComponent, ...dependencies],
        exports: [entyComponent]
    })
    class FeatureComponent {}
    return FeatureComponent;
}

لذا في حين أن هذا (على الأرجح؟) سيعمل مع تجميع JIT ، فإنه لن يعمل مع AoT لأن AoT يوزع شفرة المصدر بشكل ثابت ، ويبحث عن مصممي الديكور؟

هذا التعقيد الذي لا داعي له في عصر ES @ next .... aluanhaddad يقدم بعض النقاط الجيدة للغاية.

كما هي الأمور ، لا يمكنني رؤية نفسي / فريقي يتقدم مع Angular 2 إذا كان هذا هو الاتجاه المقصود. ويبدو أنه تم "إغلاق" هذا.

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

iyobo بخلاف الألم الأولي للتغيير ، فإن التعليقات على NgModules (وأنا أتحدث إلى الكثير من المطورين) كانت إيجابية.

عند النظر إليها بمعزل عن تطبيق hello world ، يمكنك القول إن "معقدها" ("غير ضروري" غير صحيح من الناحية الواقعية ، وفقًا للشرح أعلاه) ، لكنها تأتي حقًا في تطبيق حقيقي - تنظيم الميزات ، والتوجيه البطيء ، و أصبحت AoT كلها أبسط بكثير مع NgModules. بالنظر إلى الاختيار اليوم ، ما زلت أختار إضافة NgModules في إطار العمل.

أنا مع robwormald هنا ، كان الألم الأولي للترحيل من RC4 / 5 إلى NgModules قابلاً للإدارة بعد رؤية مزايا عدم الاضطرار إلى استيراد كل مكون / أنبوب فردي إلى صفحة تم إنشاؤها حديثًا.
تبدأ NgModules في التألق بعد أن تصبح أكثر تعقيدًا ووجود الكثير من المكونات المشتركة.

أسهل بكثير لاستيراد SharedModule والانتهاء من ذلك.

مرحبًا robwormald ، فإن الفكرة القائلة بأن المرء لا يتفق مع الاتجاه الحالي لـ Ng2 ليست بأي حال من الأحوال تأكيدًا واقعيًا على أنها تعمل فقط على تطبيقات مستوى "مرحبًا بالعالم".

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

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

يبدو لي أن NgModules هو حل في البحث عن مشكلة ، وليس حلًا لمشكلة حقيقية. ولكن بعد ذلك مرة أخرى ، لا يمكنني الادعاء بمعرفة كل شيء ...

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

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

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

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

يعجبني اقتراح poke بوجود بديل لأولئك الذين لا يفضلون استخدام Full NgModules.

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

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

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

في البداية كنت أقاوم هذا التغيير في إزالة الأنابيب والتوجيهات لكنني اعتدت عليه الآن ولا يبدو سيئًا كما اعتقدت في البداية.

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

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

@ لجميع مؤلفي Angular2 : هل يمكنك أن تخبرنا بصراحة ما هي الأجزاء السلبية من NgModules؟ أعلم أنه يمكنك كتابة كتاب عن كل الأشياء الجيدة. لا بأس. لكنني دائمًا أحتاج إلى التعامل مع الأشياء السيئة المخفية التي لن تتضح ما إذا كنت لن تتحدث عنها.

هل يمكن لأي شخص أن يوضح لي كيف يعمل NgModules في تطبيق معقد حقًا حيث تتطلب المكونات المتعددة عدة مكونات أخرى على مستويات متعددة؟

تتمثل إحدى طرق القيام بذلك في إنشاء وحدة تبعية لهذه المكونات فقط: لنفترض أن لديك ثلاث مجموعات من المكونات A ، B ، و C والتي تحتوي على مكونات متعددة كل مجموعة لديها تلك التي ترتبط إلى حد ما. لذا ستعمل هذه المجموعات الثلاث بشكل جيد مع ثلاث وحدات منفصلة.

الآن ، تتطلب المكونات في كل من هذه المجموعات مكونات متعددة من مجموعة D . هذه المكونات الموجودة في D تُستخدم فقط للمكونات في تلك المجموعات الثلاث. نظرًا لاستخدامها جميعًا ، لا يمكنك فقط إضافة المكونات إلى تلك الوحدات (نظرًا لأن المكونات قد تكون جزءًا فقط من وحدة واحدة). في هذه المرحلة ، يمكنك دمج A ، B ، C ، و D في وحدة نمطية عملاقة ، لذلك كل التبعيات موجودة. لكن هذا بالطبع فوضوي للغاية. بدلاً من ذلك ، تقوم فقط بإنشاء وحدة نمطية جديدة مقابل D تحتوي فقط على تلك التبعيات. لا تفعل هذه الوحدة أي شيء بخلاف توفير الوصول إلى هذه الوحدة. يمكنك الآن استيراد هذه الوحدة في كل من هذه الوحدات الثلاث الأخرى ، ويمكنك استخدام المكونات. ولكن نظرًا لأن المكونات لا تزال "خاصة" ، فلا يمكنك إعادة تصدير الوحدة أو استيراد الوحدة D في بعض الوحدات الأخرى.

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

يمكنني مشاركة الإعداد الحالي الخاص بي. لقد استخدمت 3 وحدات في التطبيق: CommonModule و AppModule و TestModule.

• تقوم CommonModule باستيراد وتصدير الأشياء الأكثر شيوعًا مثل HttpModule و FormsModule و MdInputModule وما إلى ذلك
• يستورد AppModule BrowserModule و CommonModule و app.routing والمكونات الفردية
• يستورد TestModule ويصدر BaseModule ، لكنه يستبدل بعض المزودين ، مثل XHRBackend مع MockBackend

لقد قدمت هذا الإعداد لتبسيط TestBed.configureTestingModule ،
لذلك لا بد لي من استيراد TestModule ثم مكون واحد فقط مثل:

TestBed.configureTestingModule({
  imports: [ TestModule ],
  declarations: [ MyFormComponent ]
});

أحد الجوانب السلبية الإضافية التي أصبحت واضحة بشكل صارخ عندما انتقلت من RC-4 إلى الإصدار هو أن NgModules تفرض عقوبة شديدة على عمليات إعادة البناء البسيطة حيث يحتاج المكون ببساطة إلى التجزئة. مع NgModules ، يجب عليك تغيير الوحدة الحاوية ، والتي قد تكون عدة مستويات في شجرة المكونات المفاهيمية ، أو ترقية المكون عن طريق لفه في NgModule ثم إزالته من NgModule الأصلي. مكونات إعادة الهيكلة أمر ضروري.

هذا مرتبط مباشرة بنقطةpoke

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

أنا لا أوافق بشدة. البنية المعيارية كما تقترحها Angular 2 أسهل في القياس والتعديل وإعادة البناء عند الضرورة. بالتأكيد ، من RC4 إلى RC5 كان هناك القليل من التعديل ، ولكن إذا كان هناك أي شيء ، فقد أثبتت NgModules أنها تسمح بتطبيق أكثر مرونة.

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

@ emilio-martinez: في رأيي ، لن يتم تقديم NgModule أبدًا ، إذا لم تكن Angular 2 بطيئة جدًا في bootstrapping ، عند إشراك JiT. جميع "التحسينات" الأخرى مثل "التحجيم والتعديل وإعادة البناء" قابلة للجدل ، كما تظهر هذه المناقشة.

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

أعتقد أننا سنجد جميعًا بعد عام من الآن أن العديد من تطبيقات Angular 2+ تجعل استخدامًا واسعًا وسلسًا للوحدات ، وتحميلًا بطيئًا ، و AOT. أعتقد أنه سيكون أمرًا روتينيًا تمامًا بالنسبة لمعظم التطبيقات أو جميعها تقريبًا لاستخدام هذه الأشياء لتنفيذ رؤية "التطبيق التدريجي" حيث تتمتع التطبيقات المعقدة الكبيرة بوقت تحميل أولي شبه فوري ثم تحميل الوظائف (أو التحميل المسبق البطيء بشكل متفائل) بحاجة إلى. والنتيجة هي في الواقع سلسة بشكل مثير للدهشة ، وتم تحقيقها بتكلفة منخفضة بشكل ملحوظ لمطور التطبيق الفردي: NgModule أساسًا هو تلك التكلفة ، وهو انتقال مزعج ولكن بعد ذلك فقط قدر متواضع جدًا من العمل المستمر لاستخدامه.

kylecordes آمل أن تكون على حق وأعتقد أن هذا هو الموقف الصحيح.

@ iurii-kyrylenko هذا صحيح جدا.

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

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

aluanhaddad أعتقد أن Angular يستخدم غلاف tsc للتجميع. إنه أمر رائع لأنه يمكنك حتى تنفيذه في سير عمل عداء المهام ، على سبيل المثال.

@ iurii-kyrylenko من الصعب أيضًا تحديد سرعة التمهيد بناءً على RC4. كان الكثير من العمل الذي تم إنجازه منذ ذلك الحين وحتى الإصدار النهائي عبارة عن تنظيف وتحسين. في تجربتي ، يعمل Angular المترجم JIT بشكل أسرع من RC4 على أي حال.

DaSchTour ، هل يمكنك توضيح الأخطاء التي وجدتها أثناء العمل مع NgModule؟

@ emilio-martinez ، إنها ليست أخطاء في NgModule ولكنها أخطاء ستنشأ بسبب فقد الواردات أو حالات الخدمة المكررة التي كان من الممكن حذفها أو العثور عليها في مرحلة مبكرة من التطوير. يتعلق الأمر باستيراد الأشياء في المكان الذي أستخدمها فيه وليس في مكان ما لا أرى فيه ما إذا كانت هناك حاجة إليها أو استخدامها وفي أي مكان يتم احتياجها واستخدامها.

فكر فقط في عمل TypeScript بهذه الطريقة. لدي ملف أساسي للوحدة النمطية الخاصة بي ، دعنا نسميه _index.ts_ يبدو هكذا.

import {foo} from bar;
import {StartComp} from start;

StartComp.boot();

من لدينا ملف يسمى start.ts يبدو مثل هذا.

export class StartComp {
   public static boot() {
      foo()
   }
}

هذا ما يفعله Angular مع NgModules. مع بعض السحر ، قمت باستيراد شيء ما إلى وحدة وسيظهر في الطرف الآخر من تطبيقي. يجب أن تعلم أن foo تم استيراده في index.ts ومن خلال تشغيل StartComp من الفهرس ، يمكن استخدام الواردات هناك في المكون.

التبعيات مخفية وتحتاج إلى تحقيق إضافي للعثور عليها.

@ اميليو مارتينيز

في تجربتي ، يعمل Angular المترجم JIT بشكل أسرع من RC4 على أي حال.

لدي مشروع متوسط ​​التعقيد ، يعتمد على MEAN stack و Angular 2 final. يستغرق الأمر حوالي 10 ثوانٍ لإكمال التمهيد في وضع JIT على جهازي الذي يعمل بنظام Android. أنا أعتبر هذا بمثابة تأخير كبير. حاليًا لا يمكنني استخدام تجميع AOT بدون تعديل كود المصدر الخاص بي (مشاكل مع الأعضاء الخاصين ، مشغل الفيس ...).

هل لدى أي شخص أي معلومات عن الأداء AOT + الحمل البطيء لمشاريع الحياة الحقيقية؟

أعتقد أن Angular يستخدم غلاف tsc للتجميع. إنه أمر رائع لأنه يمكنك حتى تنفيذه في سير عمل عداء المهام ، على سبيل المثال.

@ emilio-martinez هذا بالضبط ما لا أريده. أرغب في تجميع الكود الخاص بي باستخدام أي إصدار من TypeScript أرجوه ، على سبيل المثال 2.1.0-dev الذي يحتوي على مستوى منخفض من إصدار غير متزامن / انتظار. لا أريد أن يكون Angular مسؤولاً عن تجميع ملفات TypeScript الخاصة بي ، فلا ينبغي تفويض ذلك إلى إطار عمل ، إنه دور اللغة. بدون الابتعاد عن الموضوع ، لم أكن لأتطرق إلىScript بعمود يبلغ طوله عشرة أقدام ، والحمد لله ، لقد مات.
من ناحية سير العمل ، أستخدم JSPM وأحيانًا Webpack ، ليس عداء مهام تقليديًا ، وأترك ​​IDE الخاص بي يتعامل مع الوبر الخاص بي.

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

aluanhaddad من المهم أن نفهم أن هناك خطوتان مميزتان تحدثان أثناء تجميع AoT - الأولى هي إنشاء كود مطبوع جديد ، والثانية هي تحويل هذا الرمز إلى ES5 / 6. يقوم ngc بالأمرين معًا ، ولكن لا يوجد شيء متأصل في AoT يتطلب ذلك. داخل google ، نقوم بالأمرين معًا ، وبالتالي فإن هذه الحالة هي الأولوية. يمكن لأي شخص تنفيذ مضيف مترجم لدعم إنشاء الكود في أي بيئة يريدها.

نحن لا ندعم (حتى الآن) التجريد فوق أدوات الزخرفة المدمجة ، ولكن إذا أردت استخدام شيء مثل https://www.npmjs.com/package/core-decorators ، فسيكون ذلك جيدًا.

يقترح @ iurii-kyrylenko أن تشاهد الكلمة الرئيسية في اليوم الأول من AngularConnect ، حيث تحدث LucidCharts عن تجربتهم مع AoT. راجع https://youtu.be/xQdV7q3e_2w؟t=1411

IMHO - يجب أن يكون الهدف الأول للجميع هو الحصول على تجميع AoT في أقرب وقت ممكن. الأداء ببساطة لا يهزم.

robwormald لم ألقي نظرة على الخيارات المتاحة عند الاتصال بـ ngc - لذلك قد يكون هذا مغطى بالفعل. أعتقد أن هذه الخيارات يمكن أن تخفف من المخاوف مثل تلك التي تم التعبير عنها هنا ، إذا أوضحت أن NGC تفي بالغرض الأول كسبب رئيسي لوجودها في الغرض الثاني كنوع من الراحة / التحسين. إذا كانت الوثائق أو المساعدة تُظهر كيفية التشغيل بشكل منفصل عن الرف tsc لمن يفضلون القيام بذلك ، فقد يؤدي ذلك إلى مزيد من التخفيف من المخاوف؟

kylecordes لا أعتقد أن الوثائق ستغطي كيفية تنفيذ مضيف المترجم الخاص بك في أي وقت قريب. إنها حالة استخدام متقدمة ، وبالتالي تتطلب بعض التعلم الذاتي للتنفيذ. قمنا بتنفيذ شيء مشابه لـ CLI هنا https://github.com/angular/angular-cli/tree/master/packages/webpack

robwormald آه ، لا أقصد تنفيذ مضيف مترجم خاص بك. قصدت فقط "عملية الإنشاء" المكونة من سطرين - أولاً استدعاء ngc لإصدار بعض النصوص المطبوعة التي تم إنشاؤها ، ثم استدعاء tsc بنفسك لتجميع كل النصوص المطبوعة (المصدر الخاص بك بالإضافة إلى المصدر الذي تم إنشاؤه) إلى جافا سكريبت. يوفر هذا تأكيدًا سريعًا على أن الشفرة المطبوعة يتم تجميعها فقط إلى JS بواسطة المترجم المطبوع على الرف الجاهز.

robwormald أشكركم على ردكم.
فيما يتعلق بـ NGC ، ما أريد معرفته هو ما إذا كان بإمكاني التحكم في إصدار برنامج التحويل البرمجي TypeScript والإعدادات في تمرير TS -> TS . هل يمكنني تمرير TypeScript إلى NGC أم يجب علي استخدام إصدار معين يلتف بإصدار معين من TypeScript؟ كيف يقترن هم؟

فيما يتعلق بمصممي الديكور ، هل هناك مشكلة في تتبع الدعم لمصممي الديكور الذي يحدده المستخدم والذي يتجلى في الزخرفة الزاويّة؟ https://www.npmjs.com/package/core-decorators عبارة عن مجموعة متعامدة من الديكورات ، لكن لديّ مصممين يفرضون الأنماط والاتفاقيات في تطبيقات Angular الخاصة بي عن طريق تغليف الزخرفة الزاويّة. من حالات الاستخدام الواضحة لذلك إنشاء بادئات اسم مكون واسعة للحزمة وفرضها تلقائيًا ، ولكن هناك أخرى أيضًا.

بما أن NGC لا تدعم هذا ، فكيف تعرف أي مصمم ديكور خاص بالزاوية؟
هل تتطابق مع الزخرفة الزاويّة بالاسم؟
آمل ألا يكون ذلك لأن ذلك ينتهك نطاق جافا سكريبت المعجمي.
سيناريو بسيط
_awesome-element-decorators.ts_

import { Component } from '@angular/core';
import template from './awesome-component.html';
import style from './awesome-component.less';

export const awesomeComponet = <T extends new (...args) => any>(target: T) =>
  Component({template, styles: [style], selector: snakeCase(target.name) })(target);

_consumer.ts_

import { awesomeComponet } 'app/shared/awesome-component-decorators';

<strong i="19">@awesomeComponent</strong> 
export class AnAwesomeComponent { }

<strong i="20">@awesomeComponent</strong> 
export class AnotherAwesomeComponent { }

jpsfs هل وجدت أي حل لتحميل المكونات ديناميكيًا بدون إضافة إقرارات المكونات إلى وحدة تطبيق الجذر؟ .

أنا أيضًا جزء من مشروع الهجرة الزاوي 1.X إلى Angular 4. يحتوي هذا المشروع على عدد كبير من المكونات التي يُعاد استخدامها في تطبيق مختلف يتم تحميلها ببطء بناءً على سياق التطبيق.

حسب فهمي في Angular 4

يتعين علينا إضافة تبعيات المكون إلى إعلانات NgModule الجذر على النحو التالي.

استيراد {platformBrowserDynamic} من "@ angular / platform-browser-dynamic"؛
استيراد {Component، NgModule} من "@ angular / core" ؛
...
...
NgModule ({
الواردات: [BrowserModule] ، // استيراد Angular's BrowserModule
bootstrap: [BootStrapComp] ، // يشير إلى مكون التمهيد
التصريحات: [com1، comp2، comp5 ...... Comp n] // سجل المكون الخاص بنا مع الوحدة
})
تصدير فئة AppModule {}

platformBrowserDynamic (). bootstrapModule (AppModule) ؛

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

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

هل تتذكر الأوقات التي بدت فيها نقطة دخول تطبيقك هكذا؟

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

أنا أبحث عن شيء مماثل وحل سهل في angular2.

samudrak لا يمكنك تحميل المكون فقط إذا كنت تريد استخدام دعم Angular aot. ستحتاج إلى إعداد وحدة نمطية كسولة لكل مكون وتحميل الوحدة النمطية كسول. نستخدم نهجًا مشابهًا في تطبيقنا ...

مع دعم الاستيراد الديناميكي في ECMAScript والآن في TypeScript (مع التحقق من النوع الكامل المتعامد للتحميل) ، تعتبر حالة استخدام التحميل البطيء عشوائية إلى حد ما. بالطبع الإدراك المتأخر هو 20/20 ولم يكن هناك طريقة لمعرفة ما سيحدث.

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

اقرأ المزيد حول سياسة قفل المحادثة التلقائي .

_{_تم تنفيذ هذا الإجراء تلقائيًا بواسطة روبوت.}