عناصر مخصصة في المعركة

مساء الخير

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

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

مكونات الويب

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

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

export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('Here I am'); } } if (!customElements.get('new-custom-element')) { /*  ,     */ customElements.define('new-custom-element', NewCustomElement); } 

علاوة على ذلك ، من خلال ربط هذا الرمز بأي html (تجميعه في JS) ، يمكننا استخدام المكون (سنعود إلى هذا ، في الواقع ، إذا تجرأ العملاء على عدم استخدام Chrome).

العناصر المخصصة تعطينا أيضا بعض السنانير لتتبع عمر المكون.

 export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('I am created'); } /*   ,     DOM,   ,  ,    ,       */ connectedCallback() { console.log('Now I am in Dom'); this._render(); this._addEventListeners(); } /*   ,     DOM,  ,    */ disconnectedCallback() { console.log('I am removed now'); this._removeEventListeners(); } /*      */ static get observedAttributes() { return ['date']; } /* ,       */ attributeChangedCallback(attrName, oldVal, newVal) { switch (attrName) { case 'date': { /*   ,      */ break; } } } /*      */ adoptedCallback() { /*  ,    ,      */ } } 

يمكننا أيضًا إنشاء أحداث في المكونات من خلال أسلوب dispatchEvent

 export class NewCustomElement extends HTMLElement { ////// _date: Date = new Date(); set date(val: Date) { this._date = val; this.dispatchEvent(new CustomEvent('dateChanged', { bubbles: true, cancelable: false, detail: this._date })); } ////// } 

قالوا إن المستقبل قد حان ، تكتب الرمز مرة واحدة وتستخدمه في كل مكان

تعرفنا قليلاً على المكونات ، والآن سأتحدث عن المشاعر التي بقيت بعد العمل مع هذه التكنولوجيا. بشكل عام ، في مقالة Web Components في العالم الحقيقي ، وصف المؤلف موقفًا تجاه التكنولوجيا التي أصبحت قريبة جدًا مني.

دعونا نرى ما هي المزايا التي حصلنا عليها.

• قابلة لإعادة الاستخدام : حصلنا على مكتبة قابلة لإعادة الاستخدام حقًا. في الوقت الحالي ، يعمل في مشروع الفانيليا ، حيث يتم الاتصال كحزمة Webpack مترجمة ، وفي المشروع الزاوي 7 ، حيث يتم الاتصال كمصادر للطباعة في AppModule
• سلوك يمكن فهمه : إذا اتبعت أفضل الممارسات ، فسوف نحصل على مكونات ذات سلوك مفهوم يمكن دمجها بسهولة في الأطر الحالية ، على سبيل المثال ، الزاوي أو استخدام الموز في مربع أو في التطبيقات الأصلية من خلال السمات أو العمل مع خاصية تعكس السمات
• نمط موحد : هذا هو بعض التكرار للنقطة على إعادة الاستخدام ، ولكن لا يزال. الآن جميع المشاريع تستخدم لبنات بناء واحدة لبناء واجهة المستخدم.
• بصراحة ، لا يمكنني الوصول إلى أي مزايا أخرى : أخبرنا كيف ساعدك WebComponents.

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

• تكاليف العمالة : تكاليف تطوير المكونات أعلى بشكل لا يضاهى من تطوير إطار العمل.
• التسمية : تتنافس المكونات على مستوى العالم ، لذلك يجب أن تكون بادئة أسماء الفئات وأسماء العلامات. نظرًا لأننا لا نزال ننفذ مكتبات مكونة ضمن أطر عمل تم تسميتها باسم <اسم الشركة - الشركة > ، فقد اضطررنا إلى بادئة مكونات الويب مرتين باستخدام < company-wc -component-name>.
• ShadowRoot : وفقًا لأفضل الممارسات ، يوصى باستخدام shadowRoot. ومع ذلك ، هذا ليس ملائمًا للغاية ، حيث لا توجد إمكانية للتأثير على مظهر المكون من الخارج. وغالبا ما تواجه مثل هذه الحاجة.
• تقديم : بدون أطر ، يجب أن تنسى ربط البيانات وتفاعلها (LitElement للمساعدة ، ولكن هذا تبعية أخرى).
• لم يأت المستقبل : من أجل الحفاظ على دعم المستخدم على المستوى القديم (لدينا الإصدار 11 وكل ما هو جديد) ، يجب عليك تثبيت polyphiles ، es5 هو المعيار المستهدف ، مما يخلق مشاكل إضافية.
• Polyphils أنفسهم : من أجل الحصول على كل هذه الأشياء تحت IE ، اضطررت إلى تعذيب الكثير واتخاذ بعض القرارات القبيحة ، لأن polcoms من webcomponent كسر شيء داخل الحظيرة ، مما تسبب في تجاوز مكدس استدعاء. نتيجة لذلك ، اضطررت إلى polyfill polyphiles ، بعد أن تلقيت تبعيات إضافية.

أنا لا أعرف أي استنتاج نستخلصه من كل هذا. إذا قامت Microsoft بعمل مستعرض يستند إلى chromium وتوقف عن دعم IE و Edge ، فحينئذٍ ، سيكون التنفس أسهل.

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