Buenas tardes
La historia de esta publicación es bastante simple y quizás familiar para muchos. La compañía desarrolla muchos productos, en nuestro caso, principalmente para un cliente. Recientemente, todas las soluciones se desarrollan para la web y se transfieren las soluciones de escritorio existentes en la web.
A este respecto, si había un deseo de aumentar la velocidad de desarrollo y garantizar la uniformidad de los productos, se decidió desarrollar una base de componentes comunes. No hablaremos sobre cómo se creó el kit de interfaz de usuario y sobre las largas batallas con los diseñadores, pero quiero hablar sobre la implementación de esta tarea.
En el frente, tenemos democracia o incluso anarquía. Las personas son libres de usar las soluciones con las que se sienten cómodas. En este momento hay proyectos en batalla en AngularJS, Angular, React, Vanilla, y también hay proyectos en Vue para uso interno. En este punto, nuestra mirada se volvió hacia los componentes web.
Componentes web
Echemos un vistazo rápido al concepto de componentes web. Se basa en el concepto de elementos personalizados, que le permite ampliar la clase HTMLElement creando sus propias etiquetas html, con la lógica empresarial oculta al usuario. Suena bien, se ve bien. Veamos que podemos hacer. En lo sucesivo, el código fuente se da en mecanografiado.
Para crear un elemento personalizado, debemos hacer lo siguiente. Describa la clase y registre el componente.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('Here I am'); } } if (!customElements.get('new-custom-element')) { customElements.define('new-custom-element', NewCustomElement); }
Además, al conectar este código a cualquier html (compilándolo en JS), podemos usar el componente (de hecho, volveremos a esto si sus clientes no se atreven a usar Chrome).
Los elementos personalizados también nos dan algunos ganchos para seguir la vida útil de los componentes.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('I am created'); } connectedCallback() { console.log('Now I am in Dom'); this._render(); this._addEventListeners(); } disconnectedCallback() { console.log('I am removed now'); this._removeEventListeners(); } static get observedAttributes() { return ['date']; } attributeChangedCallback(attrName, oldVal, newVal) { switch (attrName) { case 'date': { break; } } } adoptedCallback() { } }
También podemos generar eventos en componentes a través del método dispatchEvent
export class NewCustomElement extends HTMLElement {
El futuro ha llegado, dijeron, escribes el código una vez y lo usas en todas partes, dijeron
Nos familiarizamos un poco con los componentes, ahora hablaré sobre los sentimientos que quedaron después de trabajar con esta tecnología. En general, en el artículo
Componentes web en el mundo real, el autor describió una actitud hacia la tecnología que resultó ser muy cercana a mí.
Veamos qué ventajas tenemos.
- Reutilizable : tenemos una biblioteca realmente reutilizable. Por el momento, funciona en un proyecto de vainilla, conectándose como un paquete compilado de Webpack, y en un proyecto angular 7, conectando fuentes de mecanografiado en el AppModule
- Comportamiento comprensible : si sigue las mejores prácticas , obtenemos componentes con un comportamiento comprensible que se pueden integrar fácilmente en los marcos existentes, por ejemplo, para angular, usar plátanos en una caja, en aplicaciones nativas a través de atributos o trabajar con propiedades que reflejen atributos
- Estilo unificado : esta es una repetición del punto sobre la reutilización, pero aún así. Ahora todos los proyectos usan bloques de construcción individuales para la construcción de la interfaz de usuario.
- Honestamente, no puedo encontrar más ventajas : cuéntanos cómo te ayudaron WebComponents.
A continuación, trataré de describir cosas que probablemente no me gustaron.
- Costos laborales : los costos de desarrollar componentes son incomparablemente más altos que el desarrollo de un marco.
- Nomenclatura : los componentes compiten globalmente, por lo que tanto los nombres de clase como los nombres de etiqueta deben tener el prefijo. Dado que todavía tenemos bibliotecas de componentes implementadas en marcos que fueron nombrados como <nombre-componente- compañía >, tuvimos que prefijar los componentes web dos veces con <nombre-componente-compañía>.
- ShadowRoot : de acuerdo con las mejores prácticas, se recomienda el uso de shadowRoot. Sin embargo, esto no es muy conveniente, ya que no hay posibilidad de influir en la apariencia del componente desde el exterior. Y tal necesidad a menudo se encuentra.
- Renderizado : sin marcos, debe olvidarse del enlace de datos y la reactividad (LitElement para ayudar, pero esta es otra dependencia).
- El futuro no ha llegado : para mantener el soporte al usuario en el nivel anterior (lo tenemos ie11 y todo lo que es más reciente), debe sujetar los polífilos, es5 es el estándar objetivo, lo que crea problemas adicionales.
- Polifilos mismos : para obtener todo esto bajo IE, tuve que atormentar mucho y tomar algunas decisiones feas, ya que los polycoms del componente web rompen algo dentro del hangar, causando un desbordamiento de la pila de llamadas. Como resultado, tuve que rellenar polyphiles, habiendo recibido dependencias adicionales.
No sé qué conclusión sacar de todo esto. Si Microsoft crea un navegador basado en cromo y deja de admitir IE y Edge, entonces sí, será más fácil respirar.
Hay un beneficio extraño: puede dar el desarrollo de componentes web limpios a desarrolladores novatos: déjelos ver cómo es, escriba en JS sin marcos. Un colega durante mucho tiempo no pudo entender por qué el cambio de propiedad en el componente no se reflejó de inmediato en el DOM. Aquí están las personas que crecen en marcos. Y yo soy igual.