Xiao A es un ingeniero front-end de un cierto equipo empresarial, responsable de escribir programas del proyecto JavaScript.
Conflicto variable global
Según su propia experiencia, Xiao se extrajo por primera vez algunas funciones comúnmente utilizadas y las escribió en funciones y las colocó en una base de archivos públicos.js:
La copia del código es la siguiente:
var _ = {
$: function (id) {return document.getElementById (id); },
getCookie: function (key) {...},
setcookie: function (clave, valor) {...}
};
Xiao A pone estas funciones en el objeto _ para evitar que muchas variables globales causen conflictos. Le dijo al resto del equipo que si alguien quiere usar estas funciones, solo introduce base.js.
Xiao C es el colega de Xiao A. Le dijo a Xiao A: Su página ha introducido una biblioteca de clase llamada Underscore.js, y esta biblioteca de clases también ocupará esta variable global, que entrará en conflicto con el "Base.js". Xiao pensó para sí mismo que Underscore.js es una biblioteca de terceros y probablemente sea difícil de modificar, pero Base.js se ha extendido en muchas páginas y es imposible modificarla. Al final, Xiao A no tuvo más remedio que cambiar la variable global ocupada por un subscore.js.
En este momento, Xiao A descubrió que poner funciones en un espacio de nombres puede reducir la probabilidad de conflictos variables globales, pero no resuelve el problema de los conflictos variables globales.
confiar
Con el desarrollo del negocio, Xiao A ha escrito una serie de bibliotecas de funciones y componentes de la interfaz de usuario, como las pestañas de componentes de conmutación de etiquetas.
Un día, el nuevo colega Xiao D y Xiao A informaron que había citado Tabs.js en la página, pero la función no era normal. Xiao A encontró el problema de un vistazo. Resultó que Xiao D no sabía que Tabs.js se basaba en Base.js y Util.js, por lo que no agregó referencias a estos dos archivos. Entonces inmediatamente hizo cambios:
La copia del código es la siguiente:
<script src = "tabs.js"> </script>
<script src = "base.js"> </script>
<script src = "util.js"> </script>
Sin embargo, la función sigue siendo anormal. En este momento, Xiao A enseñó a Xiao D una lección: "Todos dijeron que es una dependencia, por lo que la parte dependiente debe colocarse ante la parte dependiente". Resulta que Xiao D pone base.js y util.js tras pestañas.js.
Xiao pensó para sí mismo que él es el autor y naturalmente conoce la dependencia de los componentes, pero es difícil para los demás decir, especialmente los recién llegados.
Después de un tiempo, Xiao se agregó funciones al componente de conmutación de la etiqueta. Para implementar esta función, Tabs.js también debe llamar a las funciones en UI.JS. En este momento, Xiao A descubrió un problema grave. ¡Necesitaba agregar referencias de UI.JS a todas las páginas que llamaron tabs.js! ! !
Después de un tiempo, Xiao un pestañas optimizado, y este componente ya no se basa en Util.js, por lo que eliminó las referencias a Util.js de todas las páginas que usan Tabs.js para mejorar el rendimiento. Algo grande le sucedió cuando hizo la modificación. El MM en el equipo de prueba le dijo que algunas páginas eran anormales. Cuando Xiao A lo vio, de repente se dio cuenta de que otras funciones de algunas páginas usaban funciones en Util.js. Eliminó la referencia a este archivo y causó un error. Para garantizar que la función sea normal, restauró el código nuevamente.
Xiao Un pensamiento nuevamente, ¿hay alguna manera de modificar las dependencias sin modificar la página uno por uno, y no afecta a otras funciones?
Modular
Cuando Xiao A estaba comprando en Internet, descubrió accidentalmente un nuevo método de codificación modular que puede resolver todos los problemas que encontró antes.
En la programación modular, cada archivo es un módulo. Cada módulo es creado por una función llamada Define. Por ejemplo, después de transformar base.js en un módulo, el código se convertirá en este:
La copia del código es la siguiente:
Definir (función (requerir, exportar, módulo) {
exportaciones. $ = function (id) {return document.getElementById (id); };
exports.getcookie = function (key) {...};
exports.setcookie = function (clave, valor) {...};
});
Todas las interfaces proporcionadas por Base.js se agregan al objeto Exports. Exports es una variable local, y el código de todo el módulo no ocupa la mitad de la variable global.
Entonces, ¿cómo se llama a la interfaz proporcionada por cierto módulo? Tome Tabs.js como ejemplo, depende de Base.js y Util.js:
La copia del código es la siguiente:
Definir (función (requerir, exportar, módulo) {
var _ = require ('base.js'), util = require ('util.js');
var div_tabs = _. $ ('Tabs');
// .... otros códigos
});
Un módulo puede obtener las interfaces de otros módulos a través de la función local que requiere. En este momento, las variables _ y Util son ambas variables locales, y el desarrollador controla el nombre de la variable. Si no le gusta _, también puede usar la base:
La copia del código es la siguiente:
Definir (función (requerir, exportar, módulo) {
var Base = require ('base.js'), util = require ('util.js');
var div_tabs = base. $ ('Tabs');
// .... otros códigos
});
Una vez que desee eliminar util.js y agregar ui.js, simplemente modifique las pestañas.
La copia del código es la siguiente:
Definir (función (requerir, exportar, módulo) {
var Base = request ('base.js'), ui = require ('ui.js');
var div_tabs = base. $ ('Tabs');
// .... otros códigos
});
Cargador
Debido a la falta de soporte nativo del navegador, si queremos codificar de manera modular, debemos confiar en algo llamado cargador.
Actualmente, hay muchas implementaciones de cargadores, como Request.js y SEAJS. La Biblioteca de Class Jraiser también tiene su propio cargador.