Propongo e siguiente escenario en desarrollo: tenemos diferentes archivos JS en el proyecto estructurados por funcionalidad, también tendremos ficheros con funciones comunes, y por último ficheros con funciones que se usan en más de una página.
Si los dividimos de ese modo, es más fácil saber donde tenemos cada función, evitamos duplicarlas, y solo cargamos las necesarias para la página solicitada.
La opción de tener todo el código JS en un solo fichero no es la más eficiente porque tendríamos que cargar un fichero mucho más pesado, con funciones que en realidad no vamos a usar en todas las páginas.
Con un ejemplo se verá claro:
El fichero validacionAlta.js contendrá las funciones JS necesarias para el alta en la web, y solo se cargará en las páginas de alta. Por otro lado los ficheros validacionBuscador.js y validacionLogin.js contienen las funciones necesarias para el buscador y el login, y estas funcionalidades están en todas las páginas de la web, por lo que son necesarios en todas ellas. El fichero validacionForm.js tiene funciones varias que servirán para todos los formularios de la web.
En desarrollo se cargarán por separado, pero en la web del alta los agruparemos de forma que haremos una sola llamada al fichero que podríamos llamar composed_alta_20110101
La fecha actual servirá para tener diferentes versiones del fichero cada vez que lo generemos. De ese modo cuando hayan cambios y tengamos que subirlos a la web, el nuevo fichero se cargará con todos los cambios (pensemos que un fichero JS se guarda en la caché, y no se recarga a menos que se haga expresamente. Está claro que los usuarios al no conocer dichos cambios no harán el ctrol+F5).
Lo primero que hice fue reestructurar los JS que teníamos en el proyecto en ese momento, de forma que quedaran bien separados por funcionalidades y no hubiera duplicados.
Lo siguiente era revisar página a página los archivos JS que se estaban cargando, y pensar en las posibles agrupaciones.
En las páginas se elegirán los JS a incluir en función de un booleano, en pseudo-código (en desarrollo) sería:
// Si estamos en una de las páginas del alta
if (bJSAlta) {
include ‘validacionAlta.js’
include ‘validacionBuscador.js’
include ‘validacionForms.js’
include ‘validacionLogin.js’
// En cualquier otra página de la web
else {
include ‘validacionBuscador.js’
include ‘validacionLogin.js’
}
Y en producción sería:
if (bJSAlta) {
include ‘composed_alta_
else {
include ‘composed_all_
}
Para diferenciar entre desarrollo y producción podríamos tener una variable Application, bTest, que podríamos consultar para incluir un código u otro.
A partir de aquí empezamos con la composición propiamente dicha. Lo he automatizado de con un proceso hecho en Java, para no tener cada vez que revisar los cambios hechos por cada uno de los componentes del equipo técnico.
Ese proceso tiene programado lo siguiente:
Parseo del fichero de desarrollo que contiene los includes de los JS por funcionalidad. Cada vez que encontremos el if guardamos los includes y como key el boleano.
Merge de los archivos agrupados por la key de funcionalidad.
Compresion de los ficheros agrupados.
Modificamos el fichero que contiene los includes de los Compuestos JS, con la nueva fecha.
De esta forma cuando hayan cambios en algún JS se habrá modificado el fichero que contiene los includes, y por lo tanto al parsearlo trabajaremos siempre con los últimos cambios.
A continuación concatenamos los archivos por cada funcionalidad, y los comprimimos.
La modificicación del fichero que contiene los includes de producción nos ahorra la tarea de cambiar la versión una vez generado el nuevo nombre del fichero compuesto.
El compresor que he utilizado es YUI Compressor, que sirve tanto para JS como para CSS, y es gratis.
No hay comentarios:
Publicar un comentario