javascript - example - Administrar los complementos de jQuery

title html attribute (6)

A menudo, cuando se trabaja con jQuery, surge la necesidad de incluir múltiples complementos. Esto puede convertirse rápidamente en un trabajo desordenado, especialmente cuando algunos complementos requieren componentes adicionales (imágenes y archivos CSS).

¿Cuáles son algunas de las formas "recomendadas" de:

a. Administre los archivos / componentes requeridos ( .js , .css e imágenes) de una manera que sea fácil de mantener, y;
segundo. Mantenga estos paquetes de complementos actualizados a las últimas versiones.

No necesariamente estoy buscando una herramienta para hacer esto (aunque supongo que una que podría realizar esta gestión sería útil), sino más bien una forma de pensar.

Los CDN son excelentes, pero no para la depuración. A veces, la depuración realmente requiere acceso local a los scripts y los CDN son inútiles hasta el modo de producción. Por este motivo, todavía me gusta mantener las versiones tanto depuradas como minimizadas para luego comparar los resultados y comparar el tiempo de respuesta hasta que cambiemos a producción.

Mi forma personal "recomendada" es mantener todos mis archivos JavaScript en una carpeta de inclusión, todos los archivos CSS en otra y todas las imágenes en un tercer directorio. Escribo funciones de acceso directo para mis proyectos que luego puedo usar como <?php scriptlink( ''jquery.tooltip'' ); ?> <?php scriptlink( ''jquery.tooltip'' ); ?> o <?php stylelink( ''jquery.thickbox'' ); ?> <?php stylelink( ''jquery.thickbox'' ); ?> . Cada función de acceso directo toma un nombre de archivo (solo) como argumento y genera la etiqueta HTML completa para ese tipo de recurso, es decir (en orden) <script type="text/javascript" src="/includes/js/jquery.tooltip.js"></script> o <link rel="stylesheet" href="/includes/css/jquery.thickbox.css" />

La mayoría de los complementos de jQuery que he encontrado y que requieren imágenes permiten especificar una variable de configuración en el propio script o en el código utilizado para invocar el complemento. Las hojas de estilo se incluyen con bastante facilidad sin perder el tiempo con el script.

Hasta ahora, este método me ha mantenido bastante sano, así que creo que funciona bastante bien. No me arranco el pelo por donde pegué un complemento en particular; Simplemente lo incluyo con una función. (El sistema también admite subdirectorios del directorio de inclusión, por ejemplo, <?php scriptlink( ''ui/accordion'' ); ?> igual a <script type="text/javascript" src="/includes/js/ui/accordion.js"></script> .)

YMMV, por supuesto, pero el único problema que he tenido es con las actualizaciones cuando los autores de los complementos comienzan a distribuir una versión jquery.plugin.pack.js lugar de jquery.plugin.min.js o viceversa, porque realmente tengo que recordar Para cambiar los nombres de archivo que busco.

(Ya que he omitido la implementación de esas funciones simples, tal vez su versión buscará diferentes variantes del nombre de archivo dado. Si el argumento de scriptlink() es jquery.plugin , la función podría verificar el sistema de archivos para ver si jquery.plugin.pack.js existe, y si no, busca jquery.plugin.min.js , y si no, busca jquery.plugin.js , etc.)

Podría utilizar el CDN de Google (Red de entrega de contenido) para complementos más populares. Google lo mantiene actualizado, puede elegir / cambiar rápidamente entre versiones y también puede obtener los beneficios del almacenamiento en caché de otros sitios web que usan CDN.

Ejemplo para jQuery:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js"></script>

Y, si desea utilizar una versión superior automáticamente, cambie la versión a 1.4 (actualizaciones automáticas 1.4.x) o incluso 1 (actualizaciones automáticas 1.xx). Desafortunadamente, no todos los complementos están disponibles, pero muchos de los principales están disponibles.

Recomendaría no actualizarlos a menos que esté experimentando un problema con la versión que tiene o si desea utilizar una nueva función disponible en el complemento actualizado. Como dice el dicho, si no está roto, no lo arregles.

Todos mis complementos de jQuery están organizados en subcarpetas que incluyen el número de versión, por ejemplo,

/assets/js/plugin.1.4.1/plugin.1.4.1.min.js
/assets/js/plugin.1.4.1/images/image.gif

Si necesito actualizar a 1.4.2, puedo colocarlo en una nueva carpeta sin demasiados problemas, incluso puedo usar una versión específica del complemento en diferentes partes del sitio si es necesario. Cuando el sitio es grande y su uso de algunos complementos diferentes, es útil ver rápidamente los números de versión sin excavar alrededor de los comentarios de origen en un archivo plugin.js.

Si un complemento requiere CSS, quitaré los estilos básicos del complemento y los incluiré en mi hoja de estilo principal. Solicitar archivos CSS adicionales es costoso y 9 de cada 10 se personalizará de todos modos. Del mismo modo, con las imágenes, si estoy haciendo alguna personalización de la imagen, las agruparé en mi sprite de imagen principal, de lo contrario, solo vincularé las imágenes en ese directorio plugin.1.4.1.

Sí, terminas con algunos archivos más en tu repositorio, pero eso significa:

puede actualizar fácilmente los complementos simplemente actualizando sus rutas
puede depurar problemas de complementos más fácilmente porque puede ver cuán desactualizado está
puedes revertir a una versión anterior si todo se rompe

Actualización: en estos días hay Bower , Component y Browserify que se encargan de todo lo siguiente automáticamente.

Me sorprende que nadie haya cubierto lo que hago todavía. Así es como administro los scripts y los recursos.

Tengo cada proyecto que trabajo en la configuración con SVN . Casi todos los scripts que incluyo tienen un espejo SVN (github tiene svn en estos días), esto significa que luego puedo usar los externos de SVN y obtener cualquier rama o versión o lo que quiera de ese proyecto directamente en la carpeta de scripts del proyecto. Como estamos usando SVN, es fácil hacer un seguimiento, administrar y actualizar estos scripts.

Si un proyecto no está en SVN, simplemente lo agrego a un proyecto SVN común que he realizado, así que por ejemplo el Proyecto A y el Proyecto B, ambos usan jquery-project-not-in-svn , así que seguimos jquery-project-not-in-svn en nuestro repositorio SVN de proyectos comunes, y luego use los externos SVN en los Proyectos A y B para referenciarlo, como se explicó anteriormente.

Ahora que cubre la gestión, recuperación y actualización.

Así es como cubro las inclusiones y solicitudes de guiones.

Como cada proyecto ahora tiene su propio directorio de scripts que contiene todos los scripts que necesita (que es administrado por SVN externos), ahora tenemos que preocuparnos de reducirlos para reducir la carga en nuestro servidor. Cada proyecto tiene un Makefile en su raíz, que contiene la update comando. Este comando realizará lo siguiente:

Realizar una actualización de SVN (esto actualizará todos los externos de SVN de manera apropiada)
Una vez hecho esto, empaquetará y reducirá todos los archivos js en scripts/all.js y scripts/all.min.js

No puedo compartir el Makefile exacto pero puedo compartir uno que es público y que maneja el empaquetado / fusión y la minificación de CSS y Javascript. Aquí está el enlace: http://github.com/balupton/jquery-sparkle/blob/9921fcbf1cbeab7a4f2f875a91cb8548f3f65721/Makefile

Al hacer estas cosas, hemos logrado:

Gestión de recursos de script externos sobre múltiples proyectos.
Actualización de recursos de script apropiados automáticamente
Empaquetando todos los recursos de script usados del proyecto en un archivo
Reducir ese archivo, de modo que solo se realice una solicitud JS y una solicitud CSS.

Así que buena suerte, siéntase libre de publicar un comentario si desea obtener más información.