Componente web para un bloque de código

Llegaremos a eso, pero primero, una introducción larga.

Todavía no estoy seguro de saber cuál es el mejor momento para utilizar componentes web nativos. La plantilla no es particularmente sólida, por lo que eso no me atrae. No hay gestión estatal y me gusta tener formas estándar de manejar eso. Si de todos modos estoy usando otra biblioteca para componentes, parece que me quedaría con eso. Entonces, por el momento, mi lista de verificación es algo como:

• No utilizar ningún otro marco de JavaScript que tenga componentes.
• Las necesidades de plantillas no son particularmente complejas
• No es necesario un renderizado particularmente eficaz
• No necesito gestión estatal.

Estoy seguro de que hay herramientas que ayudan con estas cosas y más (el episodio devMode con algunas personas de Stencil fue bueno), pero si voy a entrar en el mundo de las herramientas, estaría muy tentado a ir con una marco, y probablemente no marco más otra cosa con mucha superposición.

Las razones por las que me siento tentado a optar por componentes web nativos son:

• Son nativos. No hay descargas de frameworks.
• Shadow DOM es una verdadera encapsulación de una manera que un marco realmente no puede hacer.
• Puedo crear mi propio elemento HTML que uso en HTML, con mi propio diseño API.

Parece que el punto ideal para los componentes web nativos son los componentes del sistema de diseño. Usted construye su propia pequeña API para los componentes de su sistema, y ​​las personas pueden usarlas de una manera mucho más segura que simplemente copiar y pegar este fragmento de HTML . Y supongo que si los consumidores del sistema quisieran el marco BYO , podrían hacerlo.

Entonces puedes usar like our-tabs active-tab="3"en lugar de div ... a href="#3". Refactorizar los componentes ciertamente se vuelve mucho más fácil a medida que los cambios se filtran por todas partes.

Los he usado aquí en CSS-Tricks para nuestro circle-textcomponente. Toma el radio como parámetro y el contenido a través de, uh, contenido, y genera un resultado svgque funciona. Nos brindó una buena API para la creación que abstrajo la complejidad.

¡Entonces!

Se me ocurrió que un “bloque de código” podría ser un buen caso de uso para un componente web.

• La API sería buena para ello, ya que podría tener atributos que controlen cosas útiles y el código en sí como contenido (lo cual es un gran recurso).
• Realmente no necesita estado.
• El resaltado de sintaxis es un gran bloque retorcido de CSS, por lo que sería genial aislarlo en Shadow DOM.
• Podría tener funciones útiles como un botón de “hacer clic para copiar” que a la gente le gustaría tener.

En conjunto, podría parecer que sí, podría usar este tipo de componente.

Probablemente esto no esté realmente listo para producción (por un lado, no está en npm ni nada por el estilo todavía), pero aquí es donde estoy hasta ahora:

¡Aquí hay un volcado de pensamientos!

• ¿Qué haces cuando un componente depende de una biblioteca de terceros? El resaltado de sintaxis aquí se realiza con Prism.js . Para hacerlo más aislado, supongo que podrías copiar y pegar toda la biblioteca en algún lugar, pero eso parece una tontería. ¿Quizás simplemente lo documentas?
• El diseño de componentes web todavía no parece tener una gran historia , a pesar de que Shadow DOM es interesante y útil.
• Insertar texto preformateado para usarlo en una plantilla es muy extraño. Estoy seguro de que es posible hacerlo sin necesidad de una preetiqueta dentro del elemento personalizado, pero claramente es mucho más fácil si tomas el contenido del archivo pre. Hace que la API aquí sea un poquito menos amigable (porque preferiría usarla code-blocksola).
• Me pregunto cuál es una buena práctica para transmitir atributos que necesita otra biblioteca. ¿Está data-lang="CSS"bien usarlo (se siente mejor) y luego convertirlo class="language-css"en la plantilla porque eso es lo que quiere Prism? ¿O es una mejor práctica simplemente transmitir los atributos tal como están? (Fui con este último).
• La gente se queja de que en realidad no existen “métodos de ciclo de vida” en los componentes web nativos, pero al menos tienes uno: cuando la cosa se procesa: connectedCallback. Entonces, supongo que deberías hacer toda la manipulación de HTML y demás antes de hacer el archivo final shadowRoot.appendChild(node);. No voy a hacer eso aquí, sino que ejecuto Prism en todo el conjunto shadowRootdespués de agregarlo. Parecía funcionar de esa manera. Me imagino que probablemente sea mejor, y posible, hacerlo con anticipación en lugar de permitir todo el repintado causado por la inyección de tramos y demás.
• El objetivo de esto es una buena API. Me parece que sería mejor si fuera posible colocar HTML sin escape allí para resaltarlo y poder escaparlo por usted. Pero eso hace que la alternativa realmente muestre ese HTML que podría ser malo (o incluso teóricamente inseguro). ¿Cuál es una buena historia para eso? ¿Quizás poner el HTML en los comentarios HTML y probar si !--es el comienzo del contenido y manejarlo como una situación especial?

De todos modos, si quieres bifurcarlo o hacer algo más elegante con él, déjamelo saber. Quizás eventualmente podamos ponerlo en npm o lo que sea. Tendremos que ver qué tan útil cree la gente que podría ser.