Table Excerpt Include | ||||||||
---|---|---|---|---|---|---|---|---|
|
Table Excerpt Include | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Tabla de contenidos | ||||||
---|---|---|---|---|---|---|
|
Advertencia |
---|
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC. La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabeceras de la tablas dónde se indican las fechas de entrada en vigor y versión.
Expandir | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
Este apartado se centra en conocer el estándar y la filosofía de WebComponents haciendo referencia a sus especificaciones, el ciclo de vida de los componentes, navegadores que soportan esta tecnología, así como las limitaciones que se pueden encontrar al usar WebComponents. Finalmente se definen una serie de pautas a tener en cuenta a la hora de crear o categorizar WebComponents y un caso práctico donde plasmar dichas pautas.
Un componente web es la forma en la que se une el marcado HTML, los estilos CSS y la funcionalidad JavaScript hacia un mismo fin.
Cuando se habla de un Web Component se hace referencia a un estándar que abarca a ese conjunto de características nativas HTML, CSS y JavaScript que buscan una mecánica general para crear un modelo estándar, abierto y resolutivo de componentes que sirva para la mayoría de los problemas desde un enfoque general.
NOTA: Cuando se habla del estándar Web Component se tendrá de referencia la versión V1 del mismo, considerada como estándar abierto.
Los objetivos principales del uso de WebComponents son los siguientes:
Haciendo referencia a las características web relacionadas con HTML, CSS y JavaScript mencionadas previamente, los WebComponents están basados una serie de especificaciones:
Cuando se habla de custom elements o elementos personalizados se hará de una característica de los WebComponents que permite crear etiquetas HTML personalizadas a las que se atribuyen un determinado marcado HTML, estilo y funcionalidad.
Los elementos pueden heredar de otro elemento HTML nativo o desde otro elemento personalizado. Por ejemplo, si interesa crear un componente basado en una etiqueta <button>, es posible extender del elemento nativo de HTML y así ya contar con toda su funcionalidad teniendo la posibilidad de eliminarla, modificarla o extenderla.
Cuando se habla de templates o plantillas se hace referencia a elementos que contienen tanto HTML como CSS y que de forma inicial no son visibles en la web. Estas plantillas son reconocidas por el navegador como <template> y <slot> y, a partir de JavaScript, es posible acceder al código interno y manipularlo, clonarlo en numerosas partes del sitio web y finalmente hacerlas visibles cuando se desee.
Antes de detallar lo que es Shadow DOM, es necesario conocer el significado de DOM. El DOM (Document Object Model) es la composición de elementos HTML que dan lugar a una página web. Esta estructura se representa en forma de árbol de tal manera que es posible conocer elementos padres o hijos de cada elemento.
Shadow DOM o DOM oculto, es un sistema que permite tener oculto o en la sombra un fragmento del DOM, es decir, se encarga de encapsular parte del DOM para que no interfiera en otras partes de la página. El principal caso de uso está relacionado con el aislamiento de los estilos para evitar tanto alteraciones del Shadow en el DOM principal como alteraciones del DOM principal en el Shadow.
A la hora de crear un Shadow DOM, existen algunas características:
Puede encontrarse más información al respecto en los siguientes enlaces:
Los WebComponents generalmente necesitan contar con información de entrada y también poder emitir información fuera de su contexto. En este caso existen atributos y propiedades para la entrada de información y eventos para su salida.
De manera más visual, la siguiente imagen indica cómo debe hacerse la comunicación entre componentes desarrollados con web components (lit), de modo que:
1) El componente padre modifica los atributos del componente hijo para comunicarse con el.
2) El componente hijo usa (genera) eventos para comunicarse con el componente padre.
Puede encontrarse más información al respecto en la siguiente página de la documentación oficial de lit (Events).
A la hora de cargar una página que hace uso de Web Components hay que tener en cuenta que existen varias fases o estados por los que pasa el componente, lo que se conoce como el ciclo de vida del mismo. Cada estado tiene un comportamiento nativo sin embargo es posible personalizarlo.
A continuación, se muestran las fases del ciclo de vida de un Web Component teniendo en cuenta el estándar (existen algunas librerías que incluyen estados adicionales que ofrecen un mayor grado de gestión del componente):
Puede encontrarse más información al respecto en la siguiente página de la documentación oficial de lit (Lifecycle).
Debido a que los navegadores sufren cambios y actualizaciones en sus funcionalidades, no sería correcto indicar cuáles de ellos presentan impedimentos ante cualquiera de las especificaciones de WebComponents. Por esta razón, es necesario determinar esa compatibilidad mediante una herramienta online:
La herramienta muestra un listado de navegadores a lo largo de las columnas, si las especificaciones previamente indicadas están implementadas en la versión concreta del mismo, o cuando empezarán a funcionar:
Hay que tener en cuenta que si se tiene un alto porcentaje de usuarios que utilizan una versión de un navegador que no soporta WebComponents y sus especificaciones, haya que buscar alternativas o abstenerse a utilizarla hasta que ese porcentaje se reduzca. Afortunadamente la mayor parte de los navegadores relevantes soportan estas especificaciones y además están dentro de la estrategia silenciosa de actualización denominada Evergreen Browsers.
Un navegador como por ejemplo Internet Explorer 11 que no presentan compatibilidad con este tipo de estándares, sin embargo, es posible darle soporte haciendo uso de polyfill (implementa características más comunes en navegadores antiguos u obsoletos). A pesar de ello, es recomendado no tener en cuenta la compatibilidad con IE11 en cuanto a la accesibilidad desde navegadores ya que cuanta con un soporte limitado y próximo a desaparecer para principales sistemas operativos :
En esta sección se mostrarán las pautas asociadas a Web Components en función de su naturaleza, en este caso en base a su categorización y nomenclatura:
Partir de un sistema de diseño proporciona una gran ventaja a la hora de desarrollar componentes, mejorar el ciclo de vida del desarrollo de productos.
Cuando los desarrolladores toman como referencia el diseño a la hora de definir componentes de la interfaz, se agiliza la identificación de los mismos, su categorización y el desarrollo de los mismos ya que es posible intuir el comportamiento asociado a ellos a partir de los diseños. El resultado son repositorios de componentes limpios, con división clara en base a su funcionalidad y negocio, reutilización, composición y una mejor comunicación con los diseñadores.
Al igual que en la etapa de diseño, en esta etapa de desarrollo de Web Components también se hace uso del modelo atómico, pero en este caso toma más relevancia el ámbito de cada fase del modelo atómico:
Pauta de Categorización (PC) | Ámbito | Criterios de verificación | Criterios de aceptación |
PC1 – Definición de átomos | PC1.1 - No funcional | PC1.1.1 - Carencia de funcionalidad | Carentes de funcionalidad, únicamente aportación visual |
PC1.1.2 - Indivisible | Indivisibles en cualquier otro elemento | ||
PC1.1.3 - Solo añaden características | Utilizados para enriquecer otros elementos en forma de propiedades (colores, dimensiones, fuentes, tipografía…) | ||
PC1.1.4 - Carencia de eventos | No envía ni recibe eventos | ||
PC1.2 - Funcional UI | PC1.2.1 - Componentes abstractos | Presentan funcionalidad UI pero no presentan utilidad o coherencia por si solos. Principalmente elementos HTML básicos como <input>, <h1>, <label>, <p>… | |
PC1.2.2 - Pueden presentar estado UI | Pueden presentar estados a nivel de UI como deshabilitado, seleccionado, enfocado… | ||
PC1.2.3 - Indivisible | Indivisibles en cualquier otro elemento funcional | ||
PC1.2.4 - Capaz de emitir eventos | Capacidad de emitir eventos no de recibirlos | ||
PC2 – Definición de moléculas | PC2.1 - Funcional UI | PC2.1.1 - Puede estar compuesta por átomos y otra molécula más simple | El componente puede estar formado por alguna de las siguientes alternativas: - combinación de más de un componente átomo - combinación de uno o más componentes átomos y un componente molécula más simple. Una molécula simple puede combinarse con otros átomos para dar lugar a otra molécula más compleja con propósito único Todas las alternativas de combinación tiene que tener coherencia funcional de UI. |
PC2.1.2 - Componente funcional UI con propósito simple | Presentan funcionalidad UI con un único propósito | ||
PC2.1.3 - Pueden presentar estado UI | Pueden presentar estados a nivel de UI como deshabilitado, seleccionado, enfocado… | ||
PC2.1.4 - Capaz de emitir eventos | Capacidad de emitir eventos y suscribirse a los de los elementos que lo forman. | ||
PC3 – Definición de organismos | PC3.1 - Funcional de negocio | PC3.1.1 - Composición de átomos, moléculas u otros organismos | El componente puede estar formado por alguna de las siguientes combinaciones: - al menos dos moléculas con o sin átomos - composición de uno o varios organismos y uno o varios(as) átomos/moléculas. Todas las alternativas de combinación tienen que tener coherencia funcional de negocio. |
PC3.1.2 - Componente funcional UI y de negocio | Componente funcional y de negocio: - Lógica de negocio intrínseca de la aplicación - Se conoce el origen del estado | ||
PC3.1.3 - Capaz de emitir eventos | Capacidad de emitir eventos y suscribirse a los eventos de los elementos que lo forman. | ||
PC4 – Definición de plantillas | PC4.1 - Funcional de negocio | PC4.1.1 - Composición de componentes | Distribución de los componentes átomos, moléculas y organismos, así como la aplicación del estilado. |
PC5 – Definición de páginas | PC5.1 - Funcional de negocio | PC5.1.1 - Gestión de eventos y comunicación | Es capaz de orquestar y gestionar los eventos de todos los elementos que dan lugar a la página (átomos, moléculas, organismos y plantillas) |
PC5.1.2 - Gestión de navegación | Determina la navegación interna y externa de la página | ||
PC5.1.3 - Gestión de estado | Determina el estado global de la página |
A la hora de definir el custom element de un Web Component será necesario tener en cuenta una serie de pautas:
Pauta de Nomenclatura (PN) | Criterio de verificación |
PN-1 Nombre compuesto | PN-1.1 Al menos formado por dos palabras |
PN-2 Separación con guion | PN-2.1 La separación de las palabras se realiza mediante en carácter guion “-” |
PN-3 Minúsculas | PN-3.1 Las palabras que forman el nombre serán minúsculas |
PN-4 Único | PN-4.1 No puede haber más de un custom element con el mismo nombre |
Teniendo en cuenta las pautas de categorización, a continuación se muestra un ejemplo donde se hace uso de ellas para la categorización de componentes según su funcionalidad y negocio:
Dentro de esta categoría se va a hacer una subdivisión en función del ámbito que pueden tener los átomos. Existirán los átomos no funcionales y por otro lado los funcionales. Éstos últimos ya considerados Web Components:
|
|
|
|
|
|