Cada vez, cuando se menciona un grupo de estándares de Componentes Web en cualquier artículo o comentario, sucede casi lo mismo: las personas que, a menudo, tienen muy poca idea de lo que está en juego, comienzan a compartir opiniones "expertas". Cada vez, las discusiones se deslizan en un mismo escenario, cuyo nombre rima con la palabra "torre". Y me gustaría mucho una transición positiva, constructiva y a preguntas de aplicación práctica. En este artículo, intentaré responder de inmediato la gran mayoría de las preguntas típicas y refutar el máximo de conceptos erróneos comunes. Posteriormente, en una situación difícil, será posible ganar con un enlace. Entonces vamos.
Los fundamentos
Los componentes web son un conjunto de especificaciones modernas que consta de los siguientes elementos básicos:
Elementos personalizados : una capacidad nativa para crear sus propias etiquetas HTML, con el comportamiento especificado, la apariencia y su propio marcado interno.
Shadow DOM : separación de la estructura interna del componente con encapsulación de los estilos internos y el resto del cuerpo del documento.
Plantilla : una etiqueta especial que le permite almacenar piezas de marcado, aplicarlas y reutilizarlas si es necesario.
Importaciones HTML : la capacidad de importar bloques HTML almacenados en otros archivos HTML
El plato de todo lo anterior se puede sazonar con variables CSS nativas, módulos ES nativos y envío de servidor HTTP / 2. También hay espacios, atributos personalizados, eventos personalizados y otros detalles. Sobre ellos un poco más tarde, cuando pasamos a la práctica.
Sí, estos componentes web tuyos casi no son compatibles en ningún lado.
Los números secos son los mejores amigos de un ingeniero. Echemos un vistazo a "casi en ninguna parte" desde este ángulo:
Elementos personalizados : 78.71%
Shadow DOM - 79.12%
Plantilla - 89.61%
Importaciones HTML : 69.16%
Como podemos ver, las tecnologías anteriores funcionan en los navegadores para la gran mayoría de los usuarios. Las importaciones de HTML estropean un poco la imagen, pero no estamos obligados a usar el conjunto completo (prefiero módulos ES nativos para dividir todo en bloques convenientes), incluso individualmente, puede encontrar muchas cosas "sabrosas" en esta lista.
Recomiendo no confiar en mí ciegamente, sino seguir los enlaces provistos. Allí, por ejemplo, puede ver el estado actual de estas especificaciones y el hecho de que Custom Elements y Shadow DOM
han recibido soporte completo en Firefox, comenzando con la versión 63 . Cuando la mayoría de los usuarios de Fox actualizarán a esta versión, y este momento está a la vuelta de la esquina, los números generales serán aún más atractivos. Además, es posible que haya notado el "soporte incompleto" de Custom Elements y Shadow DOM en Safari. Un navegador de Apple no le permitirá heredar su componente de un elemento de navegador nativo incorporado, como un botón, seleccionar y similares. Safari también tiene algunos matices en los selectores CSS cuando se usa Shadow DOM. En la práctica, es bastante posible vivir con él y no llorar. Aparentemente, por tradición, Microsoft Edge es un extraño entre los navegadores modernos. Los desarrolladores afirman que se está implementando el soporte. Estamos esperando
Bueno, ¿qué hacer con el resto ~ 20% de los usuarios?
Polyfiles se pueden utilizar para apoyar a estos chicos. Sí, funcionará un poco más lento con los polifilos, pero esto no se nota a simple vista. Pero para todos los demás, será más rápido.
Hace cinco años intentamos hacer un proyecto sobre Polymer. Todo fue terriblemente lento.
En esos tiempos "distantes", el borrador del estándar (v0) estaba furioso, cuyo soporte se implementó solo en Chrome. Desde entonces, mucho ha cambiado: se adoptó una nueva versión del estándar: v1, se implementó el soporte nativo en varios navegadores, se reescribieron los polífilos, las buenas prácticas fueron la solución. El polímero en sí ha evolucionado de una vista previa tecnológica a una solución completamente funcional, lo cual es agradable de manejar.
Algunos polímeros ... ¿De qué se trata todo esto?
Polymer es una biblioteca para crear componentes web. Implementa soporte para todo el “azúcar” al que estamos tan acostumbrados cuando trabajamos con marcos front-end populares: enlaces de datos dinámicos, repetidores para trabajar con matrices, etc. Por el momento, la tercera versión estable ya se ha lanzado esta biblioteca El desarrollo se lleva a cabo con la participación activa de los desarrolladores de Chrome. El ecosistema es mantenido por Google.
La longitud total de las barbas de los desarrolladores es ...¿Cuándo usar componentes web?
Si necesita una biblioteca compartida universal de componentes de la interfaz de usuario. Un caso en la vida: un proyecto en el que la aplicación principal está escrita en React y el back office en Angular. Y quiero la similitud y todo tipo de reutilización de la base del código. Y los componentes web se sienten muy bien
en diferentes ecosistemas .
Si está cerca del diseño en el enfoque del navegador . Puede crear sin la reconstrucción constante de la aplicación y sin dependencias innecesarias. Esto hace que la creación de prototipos sea una experiencia muy agradable y permite que su aplicación evolucione sin problemas del estado del prototipo al estado de la versión de producción. Eso me encanta
Si le gusta el viejo OOP : cree una clase heredando de un elemento HTML, implemente las características y los bollos deseados en él, y luego herede las clases para componentes especializados de él. Y ahora tienes tu propio microframework. Belleza!
Si odia BEM : Shadow DOM aísla los estilos de componentes. No hay necesidad de nombres monstruosos de varios pisos, ni de proporcionar navegación a las declaraciones en un montón CSS común. Todo está empaquetado de manera compacta en un componente: estilos, diseño, lógica.
Si está desarrollando aplicaciones basadas en Electron. La versión actual de Chromium in Electron ya admite todo lo que necesita. A pesar del retraso general en las versiones.
Si quieres escribir tu framework / biblioteca. Los componentes web son una excelente base compositiva para tales experimentos.
Si necesita un enfoque híbrido: implementa páginas web clásicas con elementos SPA : las etiquetas personalizadas se pueden usar con cualquier motor de plantillas de servidor, pueden ser solo parte del marcado general y resolver su propósito en el momento adecuado. Puede mantener un delicado equilibrio de lo que se representa en el servidor y lo que funciona en el cliente.
Si sus usuarios usan navegadores modernos. Por si mismo
Si está desarrollando PWA : las principales plataformas móviles admiten todo de forma inmediata. Para un inicio rápido, hay un
kit pwa-starter .
Si está interesado en una mayor seguridad de la aplicación y una auditoría de dependencia detallada es prohibitiva para usted. Aquí todo es simple: menos dependencias, menos agujeros no controlados.
Si es un optimizador loco y le gusta trabajar con la API DOM : los componentes web son parte de la API DOM, con todas las características estándar de los elementos DOM comunes.
Si te quedaste por romper la compatibilidad con versiones anteriores de la biblioteca : cuando todo se basa en el estándar hardcore, de alguna manera es más confiable.
Cuando NO deberías usar componentes web
Cuando los requisitos para su proyecto existe la necesidad de admitir navegadores antiguos y exóticos. En este caso, no será envidiado en general. Mis condolencias
Cuando desarrolla productos simples con un ciclo de vida corto y no necesita desarrollar una sola base de código.Cuando se trata principalmente de un código heredado.Cuando usted y sus colegas usan solo algo de moda y no quieren saber nada más.¿Por qué necesito todo esto? Tengo React / Vue / Angular / etc, suficiente para mí ...
Entonces, que una parte importante de lo que hace JavaScript en bibliotecas y marcos populares se puede cambiar a una implementación de navegador de nivel inferior. Por el bien de la velocidad, reduciendo la cantidad exorbitante de dependencias, reduciendo la dependencia misma de las dependencias. Por el bien del bien.