He estado tratando de encontrar un buen patrón para dividir mi código, ya que actualmente estoy agrupando N versiones de cada componente de React, y solo uso una a la vez.
El patrón actual es
import { Component1 as Component1_Lib1, Component2 as Component2_Lib1, } from 'lib1'; import { Component1 as Component1_Lib2, Component2 as Component2_Lib2, } from 'lib2'; export const SiteSpecificComponent1 = (site) => { return { site1: Component1_Lib1, site2: Component1_Lib2 }[site] };etc.
Estos se utilizan luego en varios componentes compartidos en los sitios. El paquete siempre incluirá todas las versiones de cada componente.
He estado tratando de diseñar un patrón para dividir esto limpiamente. He analizado la carga diferida y la importación condicional, pero aún no se me ha ocurrido nada, así que acudo a usted. ¿Hay algún truco de compilación o patrón de arquitectura con el que esté familiarizado que pueda ayudarme a dividir los componentes no utilizados de mi paquete?
Gracias por cualquier ayuda.
Idealmente, debe confiar en que Tree Shaking hará su trabajo de modo que solo se empaqueten los componentes necesarios. Sin embargo, el éxito de la sacudida de árboles depende de dos factores:
type: "module" en su archivo package.json o usando archivos *.mjs )sideEffects para declarar el paquete sin efectos secundarios (su módulo en realidad no debería tener efectos secundarios como singleton, usar un objeto de ventana global en la parte superior del módulo, etc.) Sin embargo, esto no es suficiente. La presencia del siguiente código no permitirá que la sacudida del árbol funcione correctamente, ya que Webpack/Rollup no puede determinar cuál sería el valor del site en el momento de la compilación. Esto significa que termina eligiendo todo en el código incluido.
export const SiteSpecificComponent1 = (site) => { return ({ site1: Component1_Lib1, site2: Component1_Lib2 })[site]; }; Para resolver este problema, debemos hacer una suposición acerca de sus sitios. Si estas diferentes versiones de los componentes están destinadas a ser utilizadas en diferentes sitios/aplicaciones, entonces probablemente signifique que la aplicación tendría un script de compilación separado y también un repositorio separado. Ahora, si está utilizando la pila tecnológica más reciente: Node 16, Webpack 5, TypeScritp 4.5, Jest 28, entonces puede utilizar los nuevos campos de exports de package.json que admiten exportaciones de submódulos o rutas secundarias. Su package.json se verá así:
// package.json file { "name": "your-lib-name", "type": "module", "exports": { "site1": "./dist/site1.js", "site2": "./dist/site2.js" } }En cada archivo, solo exportaría componentes que pertenecen a un sitio o aplicación en particular. Por ejemplo,
// site1.js export { Component1 as Component1_Lib1 } from 'lib1'; export { Component1 as Component1_Lib2 } from 'lib2'; // site2.js export { Component2 as Component2_Lib1 } from 'lib1'; export { Component2 as Component2_Lib2 } from 'lib2'; // Usage import { Component1_Lib1 } from 'you-lib-name/site1.js'; import { Component2_Lib1 } from 'you-lib-name/site2.js';Por supuesto, pierde la capacidad de obtener dinámicamente el nombre del componente mediante la invocación de un método, pero esto es más fácil de combinar, ya que se puede sacudir fácilmente.