Migración Frankenstein: enfoque independiente del marco (Parte 2)

 

 

 

  • Patrones de diseño para interfaces de IA, con Vitaly Friedman
  • Creación y mantenimiento de sistemas de diseño exitosos, con Brad Fost

  • Índice
    1. Repositorios de código
  • 1. Identificar microservicios
  • 2. Permitir el acceso de host a alienígena
    1. Agregar Alien como submódulo de su host
  • 3. Escriba un microservicio/componente alienígena
  • 4. Escriba un contenedor de componentes web en torno al servicio Alien
    1. Convenio de denominación
  • 5. Reemplace el servicio de host con un componente web
    1. 5.1. Actualice Webpack y Babel cuando sea necesario
    2. 5.2. Reemplazo de componentes reales
    3. 5.3. Información general sobre el estilo del componente alienígena
    4. 5.4. Estilos de fijación para el componente alienígena
  • Recientemente discutimos qué es la “migración Frankenstein”, la comparamos con los tipos de migraciones convencionales y mencionamos dos componentes principales: microservicios y componentes web . También obtuvimos una base teórica de cómo funciona este tipo de migración. Si no leyó u olvidó esa discusión, es posible que desee volver primero a la Parte 1 porque ayuda a comprender todo lo que cubriremos en esta segunda parte del artículo.

     

    En este artículo, pondremos a prueba toda la teoría realizando la migración paso a paso de una aplicación, siguiendo las recomendaciones de la parte anterior . Para simplificar las cosas, reducir las incertidumbres, las incógnitas y las conjeturas innecesarias, para el ejemplo práctico de la migración, decidí demostrar la práctica en una aplicación sencilla de tareas pendientes.

    Es hora de poner la teoría a prueba. ( Vista previa grande )

    En general, supongo que comprende bien cómo funciona una aplicación genérica de tareas pendientes. Este tipo de aplicación se adapta muy bien a nuestras necesidades: es predecible, pero tiene una cantidad mínima viable de componentes necesarios para demostrar diferentes aspectos de Frankenstein Migration. Sin embargo, no importa el tamaño y la complejidad de su aplicación real, el enfoque es bien escalable y se supone que es adecuado para proyectos de cualquier tamaño.

    Una vista predeterminada de una aplicación TodoMVC ( vista previa grande )

    Para este artículo, como punto de partida, elegí una aplicación jQuery del proyecto TodoMVC , un ejemplo que quizás a muchos de ustedes ya les resulte familiar. jQuery es lo suficientemente heredado, puede reflejar una situación real con sus proyectos y, lo más importante, requiere mantenimiento y trucos importantes para impulsar una aplicación dinámica moderna. (Esto debería ser suficiente para considerar la migración a algo más flexible).

    ¿Qué es ese “más flexible” al que vamos a migrar entonces? Para mostrar un caso muy práctico y útil en la vida real, tuve que elegir entre los dos frameworks más populares actualmente: React y Vue. Sin embargo, cualquiera que elija, perderíamos algunos aspectos de la otra dirección.

    Entonces, en esta parte, analizaremos los dos siguientes:

    • Una migración de una aplicación jQuery a React , y
    • Una migración de una aplicación jQuery a Vue .

    Nuestros objetivos: resultados de la migración a React y Vue. ( Vista previa grande )

    Repositorios de código

    Todo el código mencionado aquí está disponible públicamente y puedes acceder a él cuando quieras. Hay dos repositorios disponibles para que juegues:

    • Frankenstein TodoMVC
      Este repositorio contiene aplicaciones TodoMVC en diferentes marcos/bibliotecas. Por ejemplo, puedes encontrar ramas como vue, angularjsy en este repositorio.reactjquery
    • Frankenstein Demo
      Contiene varias ramas, cada una de las cuales representa una dirección de migración particular entre aplicaciones, disponibles en el primer repositorio. Hay ramas como migration/jquery-to-reacty migration/jquery-to-vue, en particular, que cubriremos más adelante.

    Ambos repositorios están en progreso y periódicamente se les deben agregar nuevas sucursales con nuevas aplicaciones y direcciones de migración. (¡ Tú también eres libre de contribuir! ) El historial de confirmaciones en las ramas de migración está bien estructurado y podría servir como documentación adicional con incluso más detalles de los que podría cubrir en este artículo.

     

    ¡Ahora, ensuciémonos las manos! Tenemos un largo camino por delante, así que no esperen que sea un camino tranquilo. Depende de usted decidir cómo desea seguir este artículo, pero puede hacer lo siguiente:

    • Clona la jqueryrama del repositorio Frankenstein TodoMVC y sigue estrictamente todas las instrucciones a continuación.
    • Alternativamente, puede abrir una rama dedicada a la migración a React o a la migración a Vue desde el repositorio de demostración de Frankenstein y seguir el historial de confirmaciones.
    • Alternativamente, puede relajarse y seguir leyendo porque voy a resaltar el código más crítico aquí mismo, y es mucho más importante comprender la mecánica del proceso que el código real.

    Me gustaría mencionar una vez más que seguiremos estrictamente los pasos presentados en la primera parte teórica del artículo.

    ¡Vamos a sumergirnos de lleno!

    1. Identificar microservicios
    2. Permitir el acceso de host a alienígena
    3. Escribir un microservicio/componente alienígena
    4. Escribir un contenedor de componentes web alrededor del servicio Alien
    5. Reemplazar el servicio de host con un componente web
    6. Enjuague y repita para todos sus componentes
    7. Cambiar a extraterrestre

    1. Identificar microservicios

    Como sugiere la Parte 1 , en este paso tenemos que estructurar nuestra aplicación en servicios pequeños e independientes dedicados a un trabajo en particular . El lector atento podría notar que nuestra aplicación de tareas pendientes ya es pequeña e independiente y puede representar un único microservicio por sí sola. Así es como lo trataría yo mismo si esta aplicación viviera en un contexto más amplio. Recuerde, sin embargo, que el proceso de identificación de microservicios es completamente subjetivo y no existe una única respuesta correcta.

    Entonces, para ver el proceso de migración de Frankenstein con más detalle, podemos ir un paso más allá y dividir esta aplicación de tareas pendientes en dos microservicios independientes:

    1. Un campo de entrada para agregar un nuevo elemento.
      Este servicio también puede contener el encabezado de la aplicación, basándose únicamente en la proximidad del posicionamiento de estos elementos.
    2. Una lista de elementos ya agregados.
      Este servicio es más avanzado y, junto con la propia lista, también contiene acciones como filtrado, acciones de elementos de la lista, etc.

    La aplicación TodoMVC se divide en dos microservicios independientes. ( Vista previa grande )

    Consejo : para comprobar si los servicios seleccionados son realmente independientes, elimine el marcado HTML que representa cada uno de estos servicios. Asegúrese de que las funciones restantes sigan funcionando. En nuestro caso, debería ser posible agregar nuevas entradas localStorage (que esta aplicación usa como almacenamiento) desde el campo de entrada sin la lista, mientras que la lista aún muestra las entradas localStorage incluso si falta el campo de entrada. Si su aplicación arroja errores al eliminar el marcado de un posible microservicio, consulte la sección "Refactorizar si es necesario" en la Parte 1 para ver un ejemplo de cómo lidiar con tales casos.

     

    Por supuesto, podríamos continuar y dividir aún más el segundo servicio y la lista de elementos en microservicios independientes para cada elemento en particular. Sin embargo, puede que sea demasiado granular para este ejemplo. Entonces, por ahora, concluimos que nuestra aplicación tendrá dos servicios; son independientes y cada uno de ellos trabaja para su propia tarea particular. Por lo tanto, hemos dividido nuestra aplicación en microservicios .

    2. Permitir el acceso de host a alienígena

    Permítanme recordarles brevemente cuáles son.

    • Host
      Así es como se llama nuestra aplicación actual. Está escrito dentro del marco del que estamos a punto de alejarnos . En este caso particular, nuestra aplicación jQuery.
    • Alien
      En pocas palabras, esta es una reescritura gradual de Host en el nuevo marco al que estamos a punto de pasar . Nuevamente, en este caso particular, es una aplicación React o Vue.

    La regla general al dividir Host y Alien es que debería poder desarrollar e implementar cualquiera de ellos sin romper el otro, en cualquier momento.

    Mantener al anfitrión y al alienígena independientes entre sí es crucial para la migración Frankenstein. Sin embargo, esto hace que organizar la comunicación entre los dos sea un poco desafiante. ¿Cómo permitimos que el Anfitrión acceda a Alien sin aplastarlos?

    Agregar Alien como submódulo de su host

    Aunque hay varias formas de lograr la configuración que necesitamos, la forma más sencilla de organizar su proyecto para cumplir con este criterio es probablemente git submodules . Esto es lo que vamos a utilizar en este artículo. Dejaré que usted lea detenidamente cómo funcionan los submódulos en git para comprender las limitaciones y los problemas de esta estructura.

    Los principios generales de la arquitectura de nuestro proyecto con submódulos de git deberían verse así:

    • Tanto el Host como el Alien son independientes y se mantienen en gitrepositorios separados;
    • El anfitrión hace referencia a Alien como un submódulo. En esta etapa, el Host elige un estado particular (compromiso) de Alien y lo agrega como lo que parece una subcarpeta en la estructura de carpetas del Host.

    React TodoMVC agregado como un submódulo git en la aplicación jQuery TodoMVC. ( Vista previa grande )

    El proceso de agregar un submódulo es el mismo para cualquier aplicación. La enseñanza git submodulesestá más allá del alcance de este artículo y no está directamente relacionada con Frankenstein Migration en sí. Así que echemos un breve vistazo a los posibles ejemplos.

    En los fragmentos a continuación, usamos la dirección React como ejemplo. Para cualquier otra dirección de migración, reemplácela reactcon el nombre de una rama de Frankenstein TodoMVC o ajuste los valores personalizados cuando sea necesario.

    Si sigues usando la aplicación jQuery TodoMVC original:

    $ git submodule add -b react [email protected]:mishunov/frankenstein-todomvc.git react$ git submodule update --remote$ cd react$ npm i

    Si sigue la migration/jquery-to-reactrama (o cualquier otra dirección de migración) del repositorio de demostración de Frankenstein, la aplicación Alien ya debería estar allí como un archivo git submoduley debería ver la carpeta respectiva. Sin embargo, la carpeta está vacía de forma predeterminada y es necesario actualizar e inicializar los submódulos registrados .

     

    Desde la raíz de tu proyecto (tu Host):

    $ git submodule update --init$ cd react$ npm i

    Tenga en cuenta que en ambos casos instalamos dependencias para la aplicación Alien, pero éstas quedan protegidas en la subcarpeta y no contaminarán nuestro Host.

    Después de agregar la aplicación Alien como un submódulo de su Host, obtendrá aplicaciones Alien y Host independientes (en términos de microservicios). Sin embargo, el Host considera a Alien una subcarpeta en este caso y, obviamente, eso le permite al Host acceder a Alien sin problemas.

    3. Escriba un microservicio/componente alienígena

    En este paso, tenemos que decidir qué microservicio migrar primero y escribirlo/usarlo en el lado de Alien. Sigamos el mismo orden de servicios que identificamos en el Paso 1 y comencemos con el primero: campo de entrada para agregar un nuevo elemento. Sin embargo, antes de comenzar, acordemos que más allá de este punto, usaremos un término más favorable componente en lugar de microservicio o servicio a medida que avanzamos hacia las premisas de los marcos frontend y el término componente sigue las definiciones de prácticamente cualquier moderno. estructura.

    Las ramas del repositorio Frankenstein TodoMVC contienen un componente resultante que representa el primer servicio "Campo de entrada para agregar un nuevo elemento" como un componente de encabezado:

    • Componente de encabezado en React
    • Componente de encabezado en Vue

    Escribir componentes en el marco de su elección está más allá del alcance de este artículo y no forma parte de Frankenstein Migration. Sin embargo, hay un par de cosas a tener en cuenta al escribir un componente Alien.

    Independencia

    En primer lugar, los componentes de Alien deben seguir el mismo principio de independencia, previamente establecido por parte del Host: los componentes no deben depender de otros componentes de ninguna manera.

    Interoperabilidad

    Gracias a la independencia de los servicios, lo más probable es que los componentes de su Host se comuniquen de alguna manera bien establecida, ya sea un sistema de gestión de estado, comunicación a través de algún almacenamiento compartido o, directamente, a través de un sistema de eventos DOM. La "interoperabilidad" de los componentes de Alien significa que deberían poder conectarse a la misma fuente de comunicación, establecida por el Host, para enviar información sobre sus cambios de estado y escuchar cambios en otros componentes. En la práctica, esto significa que si los componentes de su Host se comunican a través de eventos DOM, desafortunadamente, construir su componente Alien exclusivamente con la administración del estado en mente no funcionará perfectamente para este tipo de migración. Correo temporal gratis

    Como ejemplo, eche un vistazo al js/storage.jsarchivo que es el canal de comunicación principal para nuestros componentes jQuery:

     

    ...fetch: function() { return JSON.parse(localStorage.getItem(STORAGE_KEY) || "[]");},save: function(todos) { localStorage.setItem(STORAGE_KEY, JSON.stringify(todos)); var event = new CustomEvent("store-update", { detail: { todos } }); document.dispatchEvent(event);},...

    Aquí usamos localStorage(ya que este ejemplo no es crítico para la seguridad ) almacenar nuestras tareas pendientes y, una vez que se registran los cambios en el almacenamiento, enviamos un evento DOM personalizado en el documentelemento que cualquier componente puede escuchar.

    Al mismo tiempo, en el lado del Alien (digamos React) podemos configurar una comunicación de gestión de estado tan compleja como queramos. Sin embargo, probablemente sea inteligente dejarlo para el futuro: para integrar con éxito nuestro componente Alien React en Host, debemos conectarnos al mismo canal de comunicación utilizado por Host. En este caso, es localStorage. Para simplificar las cosas, simplemente copiamos el archivo de almacenamiento del Host en Alien y le conectamos nuestros componentes :

    import todoStorage from "../storage";class Header extends Component { constructor(props) { this.state = { todos: todoStorage.fetch() }; } componentDidMount() { document.addEventListener("store-update", this.updateTodos); } componentWillUnmount() { document.removeEventListener("store-update", this.updateTodos); } componentDidUpdate(prevProps, prevState) { if (prevState.todos !== this.state.todos) { todoStorage.save(this.state.todos); } } ...}

    Ahora, nuestros componentes Alien pueden hablar el mismo idioma con los componentes Host y viceversa.

    4. Escriba un contenedor de componentes web en torno al servicio Alien

    Aunque sólo estamos en el cuarto paso, hemos logrado bastante:

    • Hemos dividido nuestra aplicación Host en servicios independientes que están listos para ser reemplazados por servicios Alien;
    • Hemos configurado Host y Alien para que sean completamente independientes entre sí, pero muy bien conectados a través de git submodules;
    • Hemos escrito nuestro primer componente Alien utilizando el nuevo marco.

    Ahora es el momento de establecer un puente entre el Host y el Alien para que el nuevo componente Alien pueda funcionar en el Host.

    Recordatorio de la Parte 1 : asegúrese de que su anfitrión tenga un paquete de paquetes disponible. En este artículo, nos basamos en Webpack, pero eso no significa que la técnica no funcione con Rollup o cualquier otro paquete de su elección. Sin embargo, dejo el mapeo de Webpack para tus experimentos.

    Convenio de denominación

    Como se mencionó en el artículo anterior, utilizaremos componentes web para integrar Alien en Host. Del lado del Host, creamos un nuevo archivo: js/frankenstein-wrappers/Header-wrapper.js. (Será nuestro primer contenedor Frankenstein). Tenga en cuenta que es una buena idea nombrar sus contenedores del mismo modo que sus componentes en la aplicación Alien, por ejemplo, simplemente agregando un -wrappersufijo “ ”. Verá más adelante por qué es una buena idea, pero por ahora, aceptemos que esto significa que si se llama al componente Alien Header.js(en React) o Header.vue(en Vue), se debe llamar al contenedor correspondiente en el lado del Host Header-wrapper.js.

     

    En nuestro primer contenedor, comenzamos con el texto estándar fundamental para registrar un elemento personalizado :

    class FrankensteinWrapper extends HTMLElement {}customElements.define("frankenstein-header-wrapper", FrankensteinWrapper);

    A continuación, tenemos que inicializar Shadow DOM para este elemento.

    Consulte la Parte 1 para obtener el razonamiento sobre por qué usamos Shadow DOM.

    class FrankensteinWrapper extends HTMLElement { connectedCallback() { this.attachShadow({ mode: "open" }); }}

    Con esto, tenemos todas las partes esenciales del componente web configuradas y es hora de agregar nuestro componente Alien a la mezcla. En primer lugar, al comienzo de nuestro contenedor Frankenstein, debemos importar todos los bits responsables del renderizado del componente Alien.

    import React from "../../react/node_modules/react";import ReactDOM from "../../react/node_modules/react-dom";import HeaderApp from "../../react/src/components/Header";...

    Aquí tenemos que hacer una pausa por un segundo. Tenga en cuenta que no importamos las dependencias de Alien desde el servidor node_modules. Todo proviene del propio Alien que se encuentra en react/la subcarpeta. Es por eso que el Paso 2 es tan importante y es crucial asegurarse de que el Anfitrión tenga acceso completo a los activos de Alien.

    Ahora, podemos renderizar nuestro componente Alien dentro del Shadow DOM del componente web:

    ...connectedCallback() { ... ReactDOM.render(HeaderApp /, this.shadowRoot);}...

    Nota : En este caso, React no necesita nada más. Sin embargo, para renderizar el componente Vue, necesita agregar un nodo envolvente para contener su componente Vue como el siguiente:

    ...connectedCallback() { const mountPoint = document.createElement("div"); this.attachShadow({ mode: "open" }).appendChild(mountPoint); new Vue({ render: h = h(VueHeader) }).$mount(mountPoint);}...

    La razón de esto es la diferencia en cómo React y Vue representan los componentes: React agrega el componente al nodo DOM al que se hace referencia, mientras que Vue reemplaza el nodo DOM al que se hace referencia con el componente. Por lo tanto, si lo hacemos .$mount(this.shadowRoot) con Vue, esencialmente reemplaza Shadow DOM.

    Eso es todo lo que tenemos que hacer con nuestro envoltorio por ahora. El resultado actual para el contenedor Frankenstein en las direcciones de migración jQuery-to-React y jQuery-to-Vue se puede encontrar aquí:

    • Frankenstein Wrapper para el componente React
    • Frankenstein Wrapper para el componente Vue

    Para resumir la mecánica del envoltorio Frankenstein:

    1. Crea un elemento personalizado,
    2. Iniciar Shadow DOM,
    3. Importe todo lo necesario para renderizar un componente Alien,
    4. Renderice el componente Alien dentro del Shadow DOM del elemento personalizado.

    Sin embargo, esto no convierte nuestro Alien en Host automáticamente. Tenemos que reemplazar el marcado Host existente con nuestro nuevo contenedor Frankenstein.

     

    Abróchense los cinturones, ¡puede que no sea tan sencillo como cabría esperar!

    5. Reemplace el servicio de host con un componente web

    Continúemos y agreguemos nuestro nuevo Header-wrapper.jsarchivo index.htmly reemplacemos el marcado de encabezado existente con el frankenstein-header-wrapperelemento personalizado recién creado.

    ...!-- header--!-- h1todos/h1--!-- input placeholder="What needs to be done?" autofocus--!-- /header--frankenstein-header-wrapper/frankenstein-header-wrapper...script type="module" src="js/frankenstein-wrappers/Header-wrapper.js"/script 

    Desafortunadamente, esto no funcionará tan simple como eso. Si abres un navegador y revisas la consola, ahí Uncaught SyntaxErrorte espera. Dependiendo del navegador y su soporte para módulos ES6 , estará relacionado con las importaciones de ES6 o con la forma en que se representa el componente Alien. De cualquier manera, tenemos que hacer algo al respecto, pero el problema y la solución deberían ser familiares y claros para la mayoría de los lectores.

    5.1. Actualice Webpack y Babel cuando sea necesario

    Deberíamos involucrar algo de magia de Webpack y Babel antes de integrar nuestro contenedor Frankenstein. La manipulación de estas herramientas está más allá del alcance del artículo, pero puedes echar un vistazo a las confirmaciones correspondientes en el repositorio de demostración de Frankenstein:

    • Configuración para migración a React
    • Configuración para migración a Vue

    Básicamente, configuramos el procesamiento de los archivos, así como un nuevo punto de entrada frankenstein en la configuración de Webpack para contener todo lo relacionado con los contenedores de Frankenstein en un solo lugar.

    Una vez que Webpack en Host sepa cómo procesar el componente Alien y los componentes web, estaremos listos para reemplazar el marcado de Host con el nuevo contenedor Frankenstein.

    5.2. Reemplazo de componentes reales

    El reemplazo del componente debería ser sencillo ahora. En index.htmltu Host, haz lo siguiente:

    1. Reemplace headerel elemento DOM con frankenstein-header-wrapper;
    2. Agregue un nuevo guión frankenstein.js. Este es el nuevo punto de entrada en Webpack que contiene todo lo relacionado con los contenedores de Frankenstein.
    ...!-- We replace header --frankenstein-header-wrapper/frankenstein-header-wrapper...script src="./frankenstein.js"/script

    ¡Eso es todo! Reinicie su servidor si es necesario y sea testigo de la magia del componente Alien integrado en Host.

    Sin embargo, todavía parece que falta algo. El componente Alien en el contexto del Host no tiene el mismo aspecto que en el contexto de la aplicación Alien independiente. Simplemente no tiene estilo.

    Componente Alien React sin estilo después de integrarse en Host ( vista previa grande )

    ¿Por que es esto entonces? ¿No deberían integrarse los estilos del componente con el componente Alien en Host automáticamente? Ojalá lo hicieran, pero como ocurre en demasiadas situaciones, depende. Estamos llegando a la parte desafiante de la migración de Frankenstein.

     

    5.3. Información general sobre el estilo del componente alienígena

    En primer lugar, la ironía es que no hay ningún error en la forma en que funcionan las cosas. Todo es como está diseñado para funcionar. Para explicar esto, mencionemos brevemente diferentes formas de diseñar componentes.

    Estilos globales

    Todos estamos familiarizados con esto: los estilos globales pueden distribuirse (y generalmente lo hacen) sin ningún componente en particular y aplicarse a toda la página. Los estilos globales afectan a todos los nodos DOM con selectores coincidentes.

    Algunos ejemplos de estilos globales son stylelas link rel="stylesheet"etiquetas que se encuentran en su index.html. Alternativamente, se puede importar una hoja de estilo global a algún módulo JS raíz para que todos los componentes también puedan acceder a ella.

    El problema de diseñar aplicaciones de esta manera es obvio: mantener hojas de estilo monolíticas para aplicaciones grandes se vuelve muy difícil. Además, como vimos en el artículo anterior, los estilos globales pueden romper fácilmente los componentes que se representan directamente en el árbol DOM principal como en React o Vue.

    Estilos incluidos

    Estos estilos suelen estar estrechamente relacionados con un componente en sí y rara vez se distribuyen sin el componente. Los estilos normalmente residen en el mismo archivo que el componente. Buenos ejemplos de este tipo de estilo son los componentes con estilo en React o módulos CSS y CSS con alcance en componentes de un solo archivo en Vue. Sin embargo, no importa la variedad de herramientas para escribir estilos agrupados, el principio subyacente en la mayoría de ellas es el mismo: las herramientas proporcionan un mecanismo de alcance para bloquear estilos definidos en un componente de modo que los estilos no rompan otros componentes o globales. estilos.

    ¿Por qué los estilos con alcance pueden ser frágiles?

    En la Parte 1, al justificar el uso de Shadow DOM en Frankenstein Migration, cubrimos brevemente el tema del alcance frente a la encapsulación y en qué se diferencia la encapsulación de Shadow DOM de las herramientas de diseño de alcance. Sin embargo, no explicamos por qué las herramientas de alcance proporcionan un estilo tan frágil para nuestros componentes, y ahora, cuando nos enfrentamos al componente Alien sin estilo, se vuelve esencial para comprenderlo.

    Todas las herramientas de alcance para marcos modernos funcionan de manera similar:

    • Escribes estilos para tu componente de alguna manera sin pensar mucho en el alcance o la encapsulación;
    • Ejecuta sus componentes con hojas de estilo importadas/integradas a través de algún sistema de agrupación, como Webpack o Rollup ;
    • El paquete genera clases CSS únicas u otros atributos, creando e inyectando selectores individuales tanto para su HTML como para sus hojas de estilo correspondientes;
    • El paquete hace una styleentrada en headsu documento y coloca allí los estilos de sus componentes con selectores combinados únicos.

    Eso es practicamente todo. Funciona y funciona bien en muchos casos. Excepto cuando no es así: cuando los estilos de todos los componentes se encuentran en el ámbito de estilo global, resulta fácil romperlos, por ejemplo, utilizando una mayor especificidad . Esto explica la posible fragilidad de las herramientas de alcance, pero ¿por qué nuestro componente Alien no tiene ningún estilo?

    Echemos un vistazo al Host actual usando DevTools. Al inspeccionar el contenedor Frankenstein recién agregado con el componente Alien React, por ejemplo, podemos ver algo como esto:

    Envoltorio Frankenstein con componente Alien en su interior. Tenga en cuenta las clases CSS únicas en los nodos de Alien. ( Vista previa grande )

    Entonces, Webpack genera clases CSS únicas para nuestro componente. ¡Excelente! ¿Dónde están entonces los estilos? Bueno, los estilos están precisamente donde están diseñados para estar: en el archivo head.

    Si bien el componente Alien está dentro del contenedor Frankenstein, sus estilos están en el `` del documento. ( Vista previa grande )

    Entonces todo funciona como debería y este es el principal problema. Dado que nuestro componente Alien reside en Shadow DOM, y como se explica en la Parte 1 , Shadow DOM proporciona una encapsulación completa de los componentes del resto de la página y estilos globales, incluidas las hojas de estilo recién generadas para el componente que no puede cruzar el borde de la sombra y llegar al componente alienígena. Por lo tanto, el componente Alien no tiene estilo. Sin embargo, ahora, la táctica para resolver el problema debería ser clara: de alguna manera deberíamos colocar los estilos del componente en el mismo Shadow DOM donde reside nuestro componente (en lugar del documento head).

    5.4. Estilos de fijación para el componente alienígena

    Hasta ahora, el proceso de migración a cualquier framework era el mismo. Sin embargo, las cosas empiezan a divergir aquí: cada marco tiene sus recomendaci






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Migración Frankenstein: enfoque independiente del marco (Parte 2)

    Migración Frankenstein: enfoque independiente del marco (Parte 2)

    Patrones de diseño para interfaces de IA, con Vitaly Friedman Creación y mantenimiento de sistemas de diseño exitosos, con Brad Fost Índice

    programar

    es

    https://pseint.es/static/images/programar-migracion-frankenstein-enfoque-independiente-del-marco-parte-2-1002-0.jpg

    2024-04-04

     

    Migración Frankenstein: enfoque independiente del marco (Parte 2)
    Migración Frankenstein: enfoque independiente del marco (Parte 2)

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20