Los proyectos anteriores se han construido utilizando Grunt, y luego se usan IN3SJS para hacer modular. El funcionario de Requirjs proporciona un complemento Grunt para compresión y fusión. El proyecto actual ha alcanzado Gulp, y utiliza SEAJ en modularidad, por lo que, naturalmente, también pensé en el problema de la fusión y la compresión del módulo.
Luego, cuando resolví este problema por primera vez, no fue muy suave. No había un complemento Gulp particularmente popular para la fusión y compresión de SEAJS en NPM. Aunque también leo muchos problemas en SEAJS GitHub, la mayoría de ellos solo pueden fusionar todos los archivos de módulos en un archivo total. Esto definitivamente no es un problema para las aplicaciones de una sola página. Sin embargo, para las aplicaciones de varias páginas, obviamente viola el núcleo de la carga a pedido en la idea de modularidad, por lo que lo que quiero es un método que pueda fusionarse a pedido en función de los módulos de los que depende cada página.
El significado de esta fusión a pedido es que, por un lado, solo fusiona los módulos de los que depende una página y, por otro lado, también puede filtrar algunos módulos que no participan en la fusión. La razón para considerar esto es que algunos módulos, como jQuery, son bibliotecas dependientes de terceros, y pueden tener un archivo grande. Lo más importante es que difícilmente cambiará su código, por lo que si estos módulos no se fusionan en el JS de la página, ayudará a utilizar mejor el caché del navegador. Este artículo presenta un método simple y factible para hacer compresión de SEAJS en pequeños y medianos proyectos basados en Gulp.
Nota: Para ilustrar el efecto de la fusión de SEAJS, este artículo proporciona una demostración de demostración, que tiene dos páginas: Login.html y Regist.html, que se utilizan para simular dos archivos independientes en aplicaciones de varias páginas. Puede verlo a través del siguiente enlace:
http://liuyunzhuge.github.io/blog/seajs/dist/html/login.html
http://liuyunzhuge.github.io/blog/seajs/dist/html/regist.html
Tomando login.html como ejemplo, al ver el archivo fuente de esta página, verá que, además de referirse a SEAJS y archivos de configuración relacionados, Common.js, solo hace referencia a la aplicación/inicio de sesión como el JS principal de la página. Este módulo de aplicación/inicio de sesión corresponde a js/app/login.js:
Pero, de hecho, este login.js se basa en más módulos JS, y puede ver los recursos JS detallados cargados por esta página a través de la fuente de Chrome:
Antes de que la fusión de login.js, su código se veía así:
Sin embargo, en las dos primeras capturas de pantalla, no vimos los tres archivos: mod/mod1.js, mod/mod2.js, deps/fastClick.js. Además de Login.js, también vimos lib/bootstrap.js, lib/jQuery.js, lib/jQuery.validate.js. Este es el efecto de la fusión. Por un lado, los módulos debajo de la carpeta JS/LIB no participarán en la fusión. Por otro lado, por otro lado, los otros módulos en los que dependen los Js principales de la página se fusionan en el archivo JS principal de la página.
El código relacionado con esta demostración se puede ver a través del siguiente enlace:
https://github.com/liuyunzhuge/blog/tree/master/seajs
1. Fusionar ideas
De hecho, el método es relativamente simple, lo presentaré al final.
1) Permítanme hablar primero sobre una estructura de carpetas que organizo el módulo Seajs, que es así:
Esta estructura se toma prestada de las necesidades e intenta aplanar la organización de archivos, lo que no debería ser demasiado problemático para proyectos front-end pequeños y medianos. Las funciones de cada carpeta son:
1) JS/APP almacena el JS principal de cada página, básicamente la lógica de una página y una JS
2) JS/DEPS almacena módulos de terceros que deben fusionarse en JS principal
3) JS/LIB almacena módulos de terceros que no necesitan participar en la fusión
4) JS/MOD Tiendas algunos módulos JS escritos por ellos mismos en cada proyecto
5) Common.js es el archivo de configuración SEAJS.
2) En común.js, todos los módulos bajo JS/lib están configurados en la opción de alias, porque estos JS no participan en la fusión y deben usarse en el caché del navegador. El alias puede facilitarnos actualizar las direcciones de carga de estos archivos al modificar o actualizar los archivos en JS/lib:
La base está configurada en la carpeta JS. En el desarrollo del módulo, cuando quiero requerir otros módulos, mi hábito es escribir identificadores de módulos como MOD/MOD1 directamente sin identificación relativa. Incluso si el módulo al que el módulo se definirá existe en la misma carpeta que, esta es también la razón por la que establecí el directorio base en la carpeta JS, que es un poco similar al directorio raíz del sitio.
3) Idea de fusión: utilice principalmente los dos complementos Gulp: Gulp-Sajs-Transport y Gulp-Sajs-Concat. Aunque no son muy populares en GitHub, han resuelto bien mi problema y son muy simples de usar:
(Para obtener más contenido, debe verificar el enlace del código fuente proporcionado al comienzo de este artículo para encontrar el archivo gulpFile.js relevante)
Gulp-Sajs-Transport puede ayudarlo a convertir los archivos de módulos SEAJS de módulos anónimos a módulos nombrados. Por ejemplo, js/mod/mod1.js se ve así antes de construir:
Pero después del procesamiento del transporte, se convertirá:
Este es un punto más crítico en el trabajo de fusión de SEAJS. No es como requirirjs, solo concats directamente; Primero debe procesarse mediante una tarea de transporte, convertir el módulo anónimo en un módulo con nombre y usar el segundo parámetro de Definir para describir todas las dependencias de este módulo, al igual que requeríajs. Solo después de completar el transporte se puede utilizar el-sajs-confat se puede utilizar para las fusiones. Por razones, consulte: https://github.com/seajs/seajs/issues/426.
Cuando se fusiona Gulp-Sajs-Concat, es muy simple. Solo dígale una opción base. Esta opción base es consistente con la opción base en JS/Common.js. Porque Gulp-Sajs-Concat puede encontrar otros archivos de módulos de los que depende en función de los módulos después de la base y el transporte.
4) Este método debe usarse al usar JS principal en la página:
El nombre de uso del parámetro debe ser consistente con la ID del módulo principal de la JS principal fusionada. Por ejemplo, después de fusionar JS/App/Login.js, se ve así:
El primer módulo correspondiente define es el módulo principal en el archivo fusionado. El contenido de la caja roja es la ID del módulo principal. Cuando los SEAJ usan el módulo, el nombre del parámetro debe ser el mismo que esta ID. De lo contrario, incluso si SEAJS carga con éxito este archivo, no ejecutará ningún código en el módulo. Debido a que SEAJS tiene una regla: ID y principio de coincidencia de ruta, que está algo relacionado con esto, es decir: cuando SEAJS usa contener múltiples módulos en un archivo, el módulo principal en este archivo se encontrará de acuerdo con el nombre del parámetro del uso. Solo cuando sean exactamente coincidentes.
5) Ofuscación de compresión: use Gulp -uglify:
Pero para prestar atención al Mangle, debe excluir el módulo de exportaciones Requerir, de lo contrario, causará algunos problemas inesperados.
2. Resumen de este artículo
Aunque el contenido de este artículo es muy simple, tomó mucho tiempo resolver el problema de este artículo cuando corté Gulp y Seaajs por primera vez. Aunque el progreso fue mucho más suave que mi situación en ese momento cuando me estaba preparando para la demostración ... sin importar qué, espero que el contenido de este artículo pueda ayudar a algunos amigos más o menos.