Eu tenho reclamado recentemente. Todo mundo sabe que o front-end da Web se tornou muito pesado em comparação com alguns anos atrás. Várias estruturas JS, vários objetos e muitos projetos, os módulos públicos serão extraídos.
A tela da interface do usuário desses módulos é a mesma e a diferença é a lógica de segundo plano. Por exemplo, quando estamos fazendo negócios em viagens corporativas, geralmente temos um módulo público JS do centro de custo. Os clientes preenchem esse centro de custo ao reservar passagens aéreas. Esse centro de custos é distribuído nas extremidades da reserva, como online, offline e aplicativo, o que também é conveniente para liquidação mensal com a empresa do cliente na fase posterior.
Também sabemos que, depois que o projeto se torna maior, complicado e SOA, muitos problemas surgem. Assim como uma teoria na Web, todos os dados front-end não são confiáveis, os dados da interface da outra equipe não são os mesmos. Quando o projeto era jovem, não era tão não confiante e apenas registrava registros quando erros lógicos. Os processos comerciais normais geralmente raramente são registrados. Afinal, os logs de informações parecem desagradáveis e consumirão a largura de banda do servidor e também arrastarão o desempenho da web.
Mas o projeto é grande. Quando você encontra um bug estranho no projeto um dia, você confia nos troncos incompletos e finalmente rastreia a linha de interface por linha com o olho nu. No entanto, existem muitos parâmetros e é impossível restaurar com precisão os dados dos parâmetros da interface. No entanto, você está 100% confiante de que é definitivamente o problema de retorno da interface, mas não pode receber a mensagem completa. Neste momento, você não pode encontrar o provedor de interface. Eu estava impotente naquela época. Seria ótimo se você achar que seria melhor ter um log em todas as linhas.
Depois de aprender a lição, a tendência de registros de registros se tornou cada vez mais popular e, eventualmente, um grande evento no início do ano também foi causado. Eu disse muito de uma maneira confusa que o back-end da web é assim, então não precisamos gravar logs no front-end atual? Sabemos que, como é um módulo JS público, este módulo deve ter encapsulado alguns métodos por conta própria, e é absolutamente impossível permitir que os programas de terceiros operem seus próprios nós de texto, como o seguinte:
A cópia do código é a seguinte:
<!-Terceiro módulo->
Empresa: <input type = "text" id = "Company" value = "xxx Co., Ltd." />
Nome do funcionário: <input type = "text" id = "nome de usuário" value = "zhang san" />
<!-->
<script type = "text/javascript">
// Centro de custo
var costcenter = (function () {
var Company = (document.getElementById ("Company") || "") && Document.getElementById ("Company"). Value;
var userName = (document.getElementById ("nome de usuário") || "") && document.getElementById ("nome de usuário").
var resultado = {
getinfo: function () {
Return {Company: Company, Nome de usuário: nome de usuário};
},
Validação: function () {
retornar boolean (empresa && nome de usuário);
}
};
resultado de retorno;
}) ();
</script>
Para simplificar as operações, a interface do usuário de terceiros fornece nós da interface do usuário para nomes de empresas e nomes dos funcionários e encapsula uma classe CostCenter para fornecer métodos de leitura. Pode -se observar que meu programa programado só precisa ler o CostCenter.getInfo, que também desempenha um papel no encapsulamento.
Mas o problema ocorre aqui. No projeto real, o valor não pode ser obtido no centro de custo devido a vários motivos. Obviamente, também pode ser um bug na interface do usuário comum.
Mas naquela época você não tinha certeza se o valor foi realmente obtido, mas logicamente mesmo que o valor não fosse obtido, em princípio, você não poderia impedir o envio de pedidos. Portanto, para rastrear completamente o bug, você escreveu uma classe LogCenter Singleton para gravar o log. Geralmente, existe essa maneira de usar o JS para gravar logs.
<1> Ajax
Esse método é fácil de pensar, mas se você usar o XMLHTTPREQUEST nativo, precisará considerar a compatibilidade do navegador. No entanto, se você não precisar de nativos, precisa confiar em estruturas de terceiros, como o jQuery. No entanto, afinal, ainda existem muitas empresas que não usam jQuery, então isso precisa ser usado de acordo com as necessidades reais.
A cópia do código é a seguinte:
// Centro de log
var logCenter = (function () {
var resultado = {
Info: function (título, mensagem) {
// operação de Ajax
$ .get ("http://xxx.com", {"title": title, "mensagem": message}, function () {
}, "publicar");
}
};
resultado de retorno;
}) ();
<2> imagem
Existe um objeto chamado imagem em nosso DOM, para que possamos atribuir dinamicamente seu SRC com o objetivo de solicitar o URL de segundo plano e, ao mesmo tempo, precisamos passar as informações de título e mensagem no URL. Essa maneira dinâmica de imagem.SRC não precisa considerar problemas de compatibilidade do navegador, o que é muito bom.
A cópia do código é a seguinte:
// Centro de log
var logCenter = (function () {
var resultado = {
Info: function (título, mensagem) {
// operação de Ajax
$ .get ("http://xxx.com", {"title": title, "mensagem": message}, function () {
}, "publicar");
},
info_image: function (título, mensagem) {
//imagem
var iMg = new Image ();
img.src = "http://www.baidu.com?title=" + title + "& message =" + message + "& temp =" + (math.random () * 100000);
}
};
resultado de retorno;
}) ();
O exposto acima é o principal conteúdo deste artigo, e continuaremos a discuti -lo em profundidade no futuro