Un microfrontend es un componente web que tiene su propia lógica de negocio y se integra de manera transparente en una interfaz de usuario común

Dicho componente está definido por una api que expone para quien necesite integrarlo.

Un fragment es un componente web que ofrece una unidad de interfaz de usuario (UI) que representa un componente funcional.

Son los elementos que, cuando se combinan, forman un microfrontend completo.

Cada fragment puede ser desarrollado, probado y desplegado de forma independiente, permitiendo la modularidad en el desarrollo de frontal.

Una capability es una funcionalidad o característica específica y trasversal que pueden estar distribuidos en uno o varios microfrontends/fragments.

Un Web Component es una tecnología estándar de la web que permite crear componentes de interfaz de usuario encapsulados y reutilizables que pueden integrarse fácilmente en cualquier aplicación web, independientemente del framework, tecnología o biblioteca de JavaScript utilizada.

Puede actuar como un "fragment" o una parte reutilizable de la interfaz que es completamente independiente y puede ser integrado sin conflicto en la aplicación mayor.

Los componentes desarrollados pueden:

• No tener lógica de negocio, es decir, un componente general y trasversal cuya lógica es puramente visual y marcada por lo definido por el sistema de diseño (un botón, una tabla genérica, etc). El catálogo ofrecido por el se encuentra en el Storybook de la STIC.
• Tener lógica de negocio: , es decir, un componente (organismo de negocio) que implementa una lógica de negocio relacionada con el negocio de la aplicación donde se integra (tabla de usuarios, tabla de pacientes etc). En caso de ser reutilizable, entonces consideraríamos ese componente web como un fragment o un microfrontend en función de su granularidad y componibilidad (búsqueda de paciente, botón para generar una incidencia en CGES de forma automática).

SI.

Explicación:

• Un microfrontend es un web component y como todo web component puede ser utilizado para componer nuevos componentes.
• En caso de que un microfrontend forme parte de otro microfrontend, conceptualmente para este nuevo microfrontend, dejará de ser un microfrontend y pasará a ser un fragment.

La tecnología, determinada por el departamento de arquitectura de la stic, para el desarrollo de web component son:

• Desarrollo: Typescript y Lit
• Testing:
  • Definidor: @openwc/testing que se basa en chai y mocha.
  • Runner: Web Test Runner
  • Mocker: Sinon
  • Browser HeadLess: Puppeteer

No, en nuevos desarrollos no está permitido usar otra tecnología diferente a Lit

Explicación:

• Para poder mantener la solución simple, compatible y fácilmente integrable en las diferentes aplicaciones del SAS.
• Es muy ligero y hay una gran empresa como google, dando soporte al framework.

No se aconseja. 

Explicación:

• Aunque oficialmente entre las versiones actuales (2 y 3) no existen diferencias de calado que puedan generar incompatibilidades o conflictos, no garantizamos el correcto funcionamiento de los recursos ofrecidos por parte de la STIC
• Tampoco ofrecemos soporte para aquellos desarrollos que no se encuentren en la misma X.Y.Z (mayor.minor.path)
• Estamos trabajando para ofrecer un mecanismo de actualización del framework dentro de una misma mayor, que reduzca el impacto en los proyectos que hagan uso de dicha tecnología.

En caso de necesitar un nuevo componente que no se encuentra dentro de los desarrollados por el equipo del catálogo de componentes, se debe crear un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS

El ticket deberá contener:

• La explicación de la necesidad funcional
• El diseño, alineado con las directrices marcadas por el sistema de diseño, por parte del equipo de UX asignado al proyecto
• Una entrada en la tabla que identifica los componentes utilizados en el proyecto

Una vez creado y asignado el ticket al departo con la información se procederá a:

• Si es un componente con carácter general, o solo tienen cabida dentro del catálogo del proyecto.
• En caso de determinar que es un componente general
  • Analizar la necesidad y evaluar si algún componente existente cubre la necesidad
  • Se responderá al ticket con la estimación (fecha y versión) de diseño (en caso de ser necesario) y del desarrollo del componente
  • En caso de ser necesario, se realizará el diseño del componente y se publicará en el sistema de diseño. 
  • Se publicará en el catálogo de componentes el componente solicitado

En caso de necesitar una nueva funcionalidad de un componente  dentro de los desarrollados por el equipo del catálogo de componentes, se debe crear un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS

El ticket deberá contener:

• La explicación de la necesidad funcional
• El diseño, alineado con las directrices marcadas por el sistema de diseño, por parte del equipo de UX asignado al proyecto
• Una entrada en la tabla que identifica los componentes utilizados en el proyecto

Una vez creado y asignado el ticket al departo con la información se procederá a:

• Si es un necesidad que encaja dentro de un componente con carácter general, o solo tienen cabida dentro del catálogo del proyecto.
• En caso de determinar que es un componente general
  • Analizar la necesidad y evaluar si algún otro componente existente cubre la necesidad
  • Se responderá al ticket con la estimación (fecha y versión) de diseño (en caso de ser necesario) y del desarrollo de la nueva funcionalidad del componente
  • En caso de ser necesario, se realizará el diseño de la nueva funcionalidad del componente y se publicará en el sistema de diseño. 
  • Se publicará en el catálogo de componentes la nueva funcionalidad del componente solicitada

En caso de detectar un error en alguno de los componentes desarrollados por el equipo del catálogo de componentes, se debe comunicar al responsable técnico del proveedor para que se ponga en contacto con el departamento de arquitectura.

En caso de que el proveedor no disponga de un referente tecnológico, se debe crear una CGES al departamento de arquitectura de la stic con la incidencia y la mayor información de contexto posible que nos permita evaluar el error y reproducirlo y dar una estimación (fecha y versión) de resolución del error

En caso de que un proyecto tenga una necesidad que entre en conflicto con la normativa de desarrollo redactada, se deberá crear un ticket Jira de decisión técnica (Tarea genera → tipo: decisión → subtipo: técnica) y asignársela al responsable del departamento LUIS MARTINEZ FONTIVEROS . 

Una vez asignada, el departamento analizará la necesidad y dará respuesta dentro del mismo ticket.

SI.

Explicación:

• Existe un equipo encargado de desarrollar y mantener un catálogo de componentes, el cual se puede consultar, ver la información, probar y configurar en directo a través de su playground.
• Tanto los nuevos componentes como los existentes se busca alinearlos con las directrices marcadas en el sistema de diseño.
• Los componentes están con constante evolución tratando de mantener una retrocompatibilidad dentro de la misma versión mayor.
• Si quiere mantenerse al día de los cambios que ocurren en el catálogo suscríbase al blog 

SI, puedes encontrar las directrices de diseño de interfaces de usuario aquí

Todavía no, se está trabajando en ello.

NO.

Explicación:

• Inicialmente, se barajó la implementación del concepto del app-shell (referencia 1, referencia 2). Pero después de varias aproximaciones, el departamento de arquitectura de la STIC, decidió descartarla por la dificultad que añadía a la solución y dada la lista variopinta de las tecnologías con las que están desarrolladas las aplicaciones del SAS. 
• Se consideró que gracias a la uniformidad tecnológica en el desarrollo de los microfrontend y el conjunto de estándares, normativas, herramientas, componentes y capabilities ofrecidas daba un marco completo de trabajo para poder integrar los microfrontales en el heterogéneo catálogo del SAS

Un microfrontend se integra como un componente web normal.

Se debe importar su modulo y hacer uso de su tag, propiedades y eventos tal y como esté definido en el api proporcionado.

Un microfrontend aislado se integra como un componente web normal,

 Se debe hacer uso de la versión aislada del microfrontend, importar su modulo y hacer uso de su tag, propiedades y eventos tal y como esté definido en el api proporcionado.

Si, para ello debe existir, o se debe crear, un componente web que exponga la aplicación en modo microfrontend.

El web component debe tener una propiedad que permita configurar al host el tipo de integración que quiere hacer:

• Stand-Alone: El MICROFRONTEND se encarga de renderizar: header, footer, menú y notificaciones de la aplicación embebida
• Integrada: El HOST se encarga de renderizar: header, footer, menú y notificaciones de la aplicación embebida. El microfrontend enviará  a través de eventos definidos en el api, las notificaciones que el host debe visualizar

Para una integración en build-time necesitas en tiempo de construcción integrar, en la aplicación host, el código del microfrontend.

Para ello hay dos opciones:

• Usar un gestor de paquetería de javascript (npm, yarn, pnpm etc) y el fichero package.json para definir y obtener el código del microfontend
• Incorporarlo de forma manual

Para ambas opciones el proceso es similar

• Obtener el código del repositorio de artefactos
• Incorporarlo en el código de la aplicación  (en caso de ser necesario)
• Bundelizarlo.

Para una integración en run-time necesitas que el microfrontend esté publicado en el CDN.

Hay dos mecanismos de integración:

• Script: añades al host los scripts, del entorno adecuado, marcados por la documentación del microfrontend para su integración.
• Importmap: añades al host la definición, del entorno adecuado, de los importmaps marcados por la documentación del microfrontend para su integración.

Todos los microfrontales están desarrollados en base a las directrices marcadas por el sistema de diseño e instanciando para ello el componente de theme de la stic

Hay tres escenarios:

• El host sigue las directrices marcadas por el sistema de diseño e instancia el componente de theme de la stic.
  • El microfrontend quedará automáticamente integrado sin discrepancia visual
• El host NO sigue las directrices marcadas por el sistema de diseño pero si hace uso del componente de theme de la stic.
  • El microfrontend quedará automáticamente integrado sin discrepancia visual
• El host NO sigue las directrices marcadas por el sistema de diseño  y NO hace uso del componente de theme de la stic.
  • El microfrontend quedará integrado CON discrepancia visual ya que implementará el theming por defecto que es el del componente theme de la stic.
  • En estos casos se recomienda integrarlo en una pantalla, dialog o ventana a parte para que el choque visual se minimice

Hay dos escenarios:

• Alineamiento Tecnológico: Desde el host se dispone de capacidad para poder alinear a nivel tecnológico y a nivel de versiones los diferentes conflictos tecnológicos
• NO Alineamiento Tecnológico: El host debe utilizar la versión aislada del microfrontend, que le permita cargar en un contexto independiente y evitar los conflictos tecnológicos

Para aquellos microfrontend que requieran de seguridad y no tengan un acceso anónimo, el host debe obtener y transmitir el token JWT para integrarse de forma segura con el microfrontend.

Se debe consultar la documentación del microfrontend, donde se especificará el mecanismo de integración segura.

La comunicación con un microfrontend se realiza de la misma forma estandarizada que para un Web-Component:

• Host → Microfrontend: a través de las  propiedades definidas en el api del microfrontend.
• Microfrontend → Host: a través de los eventos, definidos en el api del microfrontend, que emite el microfrontend.

La comunicación entre dos microfrontend se realiza de la misma forma estandarizada que para un Web-Component, a través de un padre. En este caso es el host el que debe actuar como tal escuchando los eventos de un microfrontend y transformando la respuesta a una propiedad del otro microfrontend.

La navegación siempre será interna, es decir, nunca a través de la url del navegador.

Se debe hacer uso de la propiedad definida en el api del microfronted.

El microfrontend en su documentación proporcionará una lista de los path y paramétricas asociadas.

El módulo del microfrontend, ofrecerá una constante con los path disponibles a utilizar para mitigar el fallo humano.

En un microfrontal hay dos tipos de configuraciones:

• Interna: Es responsabilidad del microfrontend establecer los valores
• Externa: Es responsabilidad del host establecer los valores

Se debe consultar la documentación del microfrontend para revisar las configuraciones que se deben realizar en el microfrontend y los mecanismos que se determinen

El estado entre el host y el microfrontend NUNCA será compartido, es decir, un host  NUNCA podrá acceder a la información de contexto de un microfrontend de manera directa y viceversa.

En caso de necesitar un mecanismo de conocimiento del estado, cada elemento (host y microfrontend) deberá persistir en su propio contexto la información del otro.

En caso de considerar relevante compartir información sobre su estado, ambos elementos deberán usar los mecanismos de comunicación estándar para un componente web:

• Host → Microfrontend: a través de las  propiedades definidas en el api del microfrontend.
• Microfrontend → Host: a través de los eventos, definidos en el api del microfrontend, que emite el microfrontend.

Un microfrontend se versiona siguiendo las pautas marcadas por el versionado semántico [mayor.minor.patch]. Con esto se garantiza la retrocompatibilidad del microfrontend en cualquier versión dentro de una misma mayor.