O Xiao A é um engenheiro de front-end de uma certa equipe empreendedora, responsável por escrever programas JavaScript.
Conflito variável global
De acordo com sua própria experiência, Xiao a extraía algumas funções comumente usadas e as escreveu em funções e as colocou em um arquivo público base.js:
A cópia do código é a seguinte:
var _ = {
$: function (id) {return document.getElementById (id); },
getCookie: function (key) {...},
setcookie: function (chave, valor) {...}
};
Xiao A coloca essas funções no objeto _ para impedir que muitas variáveis globais causem conflitos. Ele disse ao restante da equipe que, se alguém quiser usar essas funções, apenas apresente base.js.
Xiao C é o colega de Xiao A. Ele disse a Xiao A: Sua página introduziu uma biblioteca de classes chamada subscore.js, e essa biblioteca de classes também ocupará essa variável global, que entrará em conflito com o "base.js". Xiao um pensamento para si mesmo que o subscore.js é uma biblioteca de terceiros e provavelmente é difícil de modificar, mas base.js foi espalhado em muitas páginas e é impossível modificá-lo. No final, Xiao A não teve escolha a não ser alterar a variável global ocupada pelo subscore.js.
No momento, a Xiao A descobriu que colocar funções em um espaço para nome pode reduzir a probabilidade de conflitos variáveis globais, mas não resolve o problema dos conflitos variáveis globais.
confiar
Com o desenvolvimento do negócio, a Xiao A escreveu uma série de bibliotecas de funções e componentes da interface do usuário, como guias de componentes de comutação de tags.js, que requer chamadas funções em base.js e util.js.
Um dia, o novo colega Xiao D e Xiao A relataram que ele havia citado guias.Js na página, mas a função não era normal. Xiao A encontrou o problema rapidamente. Aconteceu que Xiao D não sabia que as guias. Então ele imediatamente fez alterações:
A cópia do código é a seguinte:
<script src = "tabs.js"> </script>
<script src = "base.js"> </script>
<script src = "util.js"> </sCript>
No entanto, a função ainda é anormal. Neste momento, Xiao A ensinou a uma lição: "Todo mundo disse que é uma dependência, para que a parte dependente deve ser colocada diante da parte dependente". Acontece que Xiao D colocou Base.js e Util.js após tabs.js.
Xiao pensou para si mesmo que ele é o autor e, naturalmente, conhece a dependência dos componentes, mas é difícil para outros dizer, especialmente os recém -chegados.
Depois de um tempo, Xiao A adicionou funções ao componente de comutação de tags. Para implementar esta função, o Tabs.js também precisa chamar funções no UI.JS. Neste momento, Xiao A descobriu um problema sério. Ele precisava adicionar referências a UI.JS a todas as páginas que chamavam tabs.js! ! !
Depois de um tempo, o Xiao um otimizado guias Algo grande aconteceu com ele quando ele fez a modificação. O MM na equipe de teste disse a ele que algumas páginas eram anormais. Quando Xiao A viu, ele de repente percebeu que outras funções de algumas páginas usavam funções no util.js. Ele removeu a referência a este arquivo e causou um erro. Para garantir que a função seja normal, ele restaurou o código novamente.
Xiao Um pensamento novamente, existe uma maneira de modificar as dependências sem modificar a página um por uma e não afeta outras funções?
Modular
Quando Xiao A estava comprando na Internet, ele acidentalmente descobriu um novo método de codificação modular que pode resolver todos os problemas que encontrou antes.
Na programação modular, cada arquivo é um módulo. Cada módulo é criado por uma função chamada define. Por exemplo, depois de transformar base.js em um módulo, o código se tornará assim:
A cópia do código é a seguinte:
Definir (função (requer, exporta, módulo) {
exports. $ = function (id) {return document.getElementById (id); };
exports.getCookie = function (key) {...};
exports.setcookie = função (chave, valor) {...};
});
Todas as interfaces fornecidas pelo Base.js são adicionadas ao objeto de exportação. As exportações são uma variável local e o código de todo o módulo não ocupa metade da variável global.
Então, como você chama a interface fornecida por um determinado módulo? Tome tabs.js como exemplo, depende do base.js e util.js:
A cópia do código é a seguinte:
Definir (função (requer, exporta, módulo) {
var _ = requer ('base.js'), util = requer ('util.js');
var div_tabs = _. $ ('tabs');
// .... outros códigos
});
Um módulo pode obter as interfaces de outros módulos através da função local exigir. No momento, as variáveis _ e utilizam variáveis locais, e o nome da variável é completamente controlado pelo desenvolvedor. Se você não gosta de _, também pode usar a base:
A cópia do código é a seguinte:
Definir (função (requer, exporta, módulo) {
var base = requer ('base.js'), util = requer ('util.js');
var div_tabs = base. $ ('tabs');
// .... outros códigos
});
Depois que você deseja remover o util.js e adicionar UI.js, basta modificar as guias.js:
A cópia do código é a seguinte:
Definir (função (requer, exporta, módulo) {
var base = requer ('base.js'), ui = requer ('ui.js');
var div_tabs = base. $ ('tabs');
// .... outros códigos
});
Carregador
Devido à falta de suporte ao navegador nativo, se quisermos codificar de maneira modular, devemos confiar em algo chamado carregador.
Atualmente, existem muitas implementações de carregadeiras, como requer.js e SEAJs. A biblioteca da classe Jraiser também possui seu próprio carregador.