Esto no es un tutorial o una revisión completa, sino notas de sangre caliente después de compilar una biblioteca de componentes. Todo comenzó con la historia cotidiana habitual: hay un código heredado, necesita sujetar pipmochek y pequeños palos al legado, no puede reescribir nada, una vez, y no toque nada aquí con las manos; no toques los paquetes grandes y aterradores por si acaso, y de hecho, ¿por qué no tomas el mejor marco
Vanilla JS y comienzas a escribir en él, como legaron tus abuelos?
Pero como se preveía que el volumen de trabajo fuera muy notable, por alguna razón nadie experimentó ningún impulso creativo por la idea de escribir todo en JS desnudo. Fuimos a mirar las herramientas y elegir entre ellas aquellas que no asustarían a los consumidores de nuestros componentes hasta que les temblaran las rodillas.
Las herramientas
Aunque ya he echado a perder toda esta sección, hay que decir algo aquí. En primer lugar, los componentes web se volvieron absolutamente incontestables: cuando el resultado de la creatividad es una biblioteca de componentes, y no se puede arrastrar un gran monstruo a la Angular, que se modularizará por completo, lo que queda es que no es necesario arrastrar el código de la biblioteca, y funciona "así" en los navegadores modernos. Los componentes web en sí mismos siguen siendo el mismo increíble marco Vanilla JS, con solo un poco de modularidad resuelta. Todavía queda mucho para escribir con sus propias manos: necesita un contenedor con estandarización, y también es deseable que haya un mínimo de repetitivo para cada componente.
No hay muchos envoltorios de este tipo, e incluso lo suficientemente maduros para su uso en un
producto serio:
Híbridos, LitElement, Stencil. Y todos hacen lo mismo de la misma manera, la diferencia está en las pequeñas cosas. Hybrids está tratando de estar a la moda y sin clases, Stencil está de moda y reacciona, LitElement ni siquiera parece estar esforzándose. Y de acuerdo con los resultados de elegir entre insignificantes insignificancias, LitElement se mantuvo en la salida: OOPshniki apartó la nariz de los híbridos y los no aficionados de la reacción, de Stencil, en el que JSX generalmente sintió una repetición de las ideas no indiscutibles de la reacción.
A la batalla?
No es tan interesante hablar sobre lo que puede, está todo en la documentación, por lo que continuaré hablando principalmente sobre lo que no puede: por lo general, no escriben sobre esto en la documentación.
Patrones
En términos de plantillas, LitElement utiliza lit-html, que es perfectamente minimalista:
const template = html` <div attr=${a} .property=${b} ?booleanAttr=${c} @click=${handleClick} ></div> `;
Esto no es html, pero debe recordar exactamente tres construcciones en un símbolo aquí: ".", "?", Y "@". Todo lo demás es html. Con respecto a JSX, con su className y el resto, es un poco mejor y está legalmente separado del código JS / TS. Pero, por cierto, el primer "imposible" se sigue a partir de aquí: vincular algo horrible no funciona, solo se puede vincular en los valores de atributos y propiedades, y en el contenido del texto. Por supuesto, en los literales de plantilla etiquetados no hay magia, y a costa de una cierta cantidad de perversiones, puede juntar una cadena en tiempo de ejecución y adjuntar carpetas de lit-html, pero esto en realidad está entrando en el render con sus manos, y con el mismo éxito puede recopilar líneas y enviarlas en innerHTML. De la manera normal, todo esto se hace a través de la composición de las plantillas y el desglose de componentes complejos en componentes más simples. La plantilla es bastante pequeña: el enlace de la plantilla está prácticamente ausente, porque es solo una variable, y para crear un componente, necesita cinco líneas "adicionales".
Componentes
El único (pero significativo) problema de los componentes es que para "mezclar" completamente los componentes con el renderizado de los hijos, en algún lugar dentro de la plantilla del padre se necesita el DOM DOM. Que, por supuesto, está incluido en LitElement de forma predeterminada, y en general parece no estar mal. Pero el DOM de sombra actualmente tiene un gran problema con los estilos, similar a los módulos css: para aislar estilos, aísla perfectamente, pero en el camino esto reduce toda la cascada. Es simplemente imposible entrar en estilos aislados desde el exterior. Generalmente (casi) nada.
Esto interfiere enormemente, por ejemplo, con la capacidad de rodar componentes de diferentes temas. Todo lo que se puede hacer con el DOM de sombra es empaquetar todas las opciones de estilo dentro del componente o tratar de hacer que el tema sea completamente dependiente de las variables css: esta es la "casi" con la que puedes cambiar los estilos aislados. Pero con lo cual es necesario proporcionar variables literalmente para cualquier estilización razonable y, con una alta probabilidad, aún se agrega más.
Afortunadamente, Shadow DOM en LitElement simplemente se puede deshabilitar en el componente. Desafortunadamente, esto también deshabilitará la capacidad de apuntar a elementos secundarios del elemento en los lugares correctos de la plantilla a través de <slot>. Afortunadamente, habiendo pervertido un poco, puede obtener tanto el primero como el segundo: para esto,
solo necesita poner una raíz de sombra en cada ranura necesaria, y no tener nada en ella excepto, de hecho, <slot>. Por lo tanto, la estilización del componente estará abierta y las ranuras estarán presentes. Quería dar un breve ejemplo, pero desafortunadamente el código para manipular las tragamonedas no funciona brevemente de todos modos; las personas muy interesadas pueden leer
este problema aquí. Me inspiraron las ideas de allí.
Bueno, también vale la pena mencionar que en el futuro previsible, el soporte para navegadores y los polyfills
:: part y :: theme probablemente desaparecerán, y con ellos, el DOM DOM se convertirá finalmente en la solución que todos han estado esperando durante muchos años, por lo que está aislado y extensible / mutable Pero hasta ahora esto todavía no está allí.
Implementar
En este punto, ya no se escribe sobre "lo que es imposible", porque todo puede ser más avanzado: existen bibliotecas iluminadas en forma de módulos ES y, por lo tanto, sin ningún problema, son recogidas por cualquier cosa (incluso con un navegador simple que pueda manejar módulos) ) Para IE y el Edge actual, necesita conectar un polyfill de componentes web, para módulos, si desea levantarlos directamente desde el navegador, necesita algo que alivie el dolor de las importaciones del navegador, por ejemplo
es-module-shims. Bueno, o un paquete.
Los componentes web conectados a la aplicación son simples y curiosos de usar, puede comenzar a usarlos en html y extraer sus métodos y propiedades en el código. Puede ver qué tan bien se puede adjuntar todo esto a otra biblioteca o marco
aquí (la reacción ha sobresalido, pero en promedio todo es muy bueno). Nos aferramos a AngularJS, y todo fue trivial: ng-prop le permite transferir algo al componente, y ng-on le permite escuchar eventos.
Resumen
Si necesita construir una interfaz de usuario de componentes y fijarla a algo en lo que absolutamente no desea entrar (código heredado, marco de miedo pasado de moda y otros lugares malos), los componentes web ayudan muy bien. Las principales bibliotecas "maduras" que se administran con ellas son de tamaño pequeño, no hay problemas técnicos serios de modularidad y diseño, y puede simplemente tomarlo y hacerlo. Qué tipo de biblioteca tomas, aunque no sea tan importante, hay muy pocas diferencias entre ellos en este momento; Específicamente, el LitElement que tomamos no creó un problema adicional para nosotros y funcionó de la manera esperada en todos los casos.