Como convencer meu chefe (e outros desenvolvedores) a usar / considerar JavaScript Discreto


21

Sou muito novo em nossa equipe de desenvolvimento.

Eu preciso de alguns argumentos fortes e / ou exemplos de "armadilhas", para que meu chefe finalmente entenda as vantagens do JavaScript Discreto, para que ele e o resto da equipe parem de fazer coisas como estas:

<input type="button" class="bow-chicka-wow-wow" 
       onclick="send_some_ajax(); return false;" value="click me..." />

e

<script type="text/javascript">

function send_some_ajax()
{
  // bunch of code ... BUT using jQuery !!!
}
</script>

Sugeri usar um padrão bastante comum:

<button id="ajaxer" type="button">click me...</button>

e

<script type="text/javascript">

// since #ajaxer is also delivered via ajax, I bind events to document 
//  -> not the best practice but it's not the point....

$(document).on('click', '#ajaxer', function(ev) {
var $elem = $(this);
ev.preventDefault();

});

A razão pela qual meu chefe (e outros) não deseja usar essa abordagem é que a Inspeção de eventos no FireBug (ou Chrome Dev Tools) não é mais simples, por exemplo, com

<input type="text" name="somename" id="someid" onchange="performChange()">

ele pode ver imediatamente qual função é executada no evento de mudança e pular direto para ele em um enorme arquivo JS cheio de código espaguete .

No caso do JavaScript discreto, a única coisa que ele veria é:

<input type="text" name="somename" id="someid" />

e ele não tem idéia se alguns eventos, se houver, foram vinculados a esse elemento e qual função será acionada.

Eu estava procurando uma solução e a encontrei:

$(document).data('events') // or .. $(document).data('events').click

mas essa "abordagem" levou "muito tempo ..." para descobrir qual função dispara em qual evento, então me disseram para interromper eventos de vinculação como esse.

Estou pedindo alguns exemplos ou fortes vantagens ou qualquer outro tipo de sugestão para "Por que devemos usar o UJS"

ATUALIZAÇÃO: a sugestão de "mudar de emprego" não é uma solução ideal.

ATUALIZAÇÃO 2: Ok, eu não apenas sugeri o uso de ligação de eventos jQuery, mas o fiz . Depois que escrevi toda a delegação de eventos, o chefe veio até mim e me perguntou: por que estou delegando eventos com uma abordagem diferente e uma abordagem que ele não sabe

Mencionei alguns benefícios óbvios, como - Existem 15 campos de entrada e todos têm um onchangeevento (não apenas alguns deles também onkeyup). Portanto, é mais pragmático escrever esse tipo de delegação de eventos para TODOS os campos de entrada, em vez de fazê-lo 15 vezes, especialmente se todo o HTML for renderizado com o eco do PHP ->echo '... <input type="text" id="someid" ... />...'


A "classe" em seu primeiro codebox provavelmente precisa de um =.
Joe Z.

6
Você pode: 1) convencer seu chefe a permitir que você use técnicas que ele não conhece; 2) ensine novas técnicas ao seu chefe; 3) pare de usar técnicas que seu chefe não conhece; ou 4) mudar de emprego. Esqueci uma opção? Se você não deseja 4 e não consegue ter sucesso em 1 e 2, sua única opção restante é 3. Lembre-se de que seu valor de mercado depende do que você conhece. Então, depois de aprender tudo o que seu chefe aprova, suas opções restantes são: 3A) pare de aprender e observe seu valor de mercado cair; 3B) aprenda e use novas técnicas em seu tempo livre. A opção 3A custa dinheiro, a opção 3B custa tempo.
Viliam Búr 21/02

1
Eu usaria uma abordagem como o github: todo elemento que tem eventos vinculados em JS tem uma js-this-class-do-somethingclasse, portanto, você pode facilmente CTRL + F para ela no código.
usar o seguinte código

O FireQuery pode ajudar com a parte "leva muito tempo". Não tenho certeza de quão bem ele funciona com eventos, mas deve pelo menos informar que um elemento possui eventos.
Izkata 24/02

1
Aqui é um utilitário agradável que eu amo para uso quando se trabalha com eventos
karka91

Respostas:


49
  1. Pare de usar palavras - chave e tente fazer argumentos fortes. Até a página da Wikipedia para JavaScript Discreto diz que o termo não está formalmente definido. Pode ser um termo genérico para uma série de boas idéias, mas se isso soa como um mero modismo ou moda, seu chefe e colegas de trabalho não prestarão muita atenção. Pior, se você continuar falando sobre algo que eles consideram inútil, eles podem começar a desconsiderar idéias completamente não relacionadas que você defende.

  2. Descubra por que você acha que as idéias discretas de JavaScript são importantes. É porque você leu que elas são consideradas práticas recomendadas? Você já teve problemas que podem ser atribuídos a não seguir essas idéias? Quanto a adoção dessas idéias afetará os resultados da empresa?

  3. Entre na cabeça do seu chefe. Por que ele faz as coisas do jeito que faz e por que ele rejeitou suas alterações? Ele provavelmente não é estúpido e provavelmente é mais experiente do que você, então provavelmente tem algumas boas razões para fazer as coisas do seu jeito. Você já fez alusão a alguns deles - siga esse tópico até o fim. Em seguida, descubra se e como suas sugestões melhorarão as coisas com as quais ele está mais preocupado.

  4. Dica 1: gerentes gostam de dinheiro. Quanto mais diretamente você puder vincular suas sugestões ao aumento da renda ou à redução de gastos, maior será o impacto do seu argumento. Dica 2: Tempo é dinheiro. Dica 3: Por si só, o apelo estético do código não ganha dinheiro. O oposto, de fato - leva tempo para fazer o código parecer bonito. Código feio que funciona bem é bom para a maioria dos gerentes.

  5. Não basta falar sobre isso, faça . Se você tiver a sorte de ter um projeto pequeno e independente, pergunte ao seu gerente se você pode fazê-lo usando o estilo "UJS" como uma espécie de demonstração. Quando estiver pronto, faça uma revisão de código onde possa explicar como tudo funciona e por que você acha que é melhor que o estilo atual.

  6. O idealismo é ótimo, mas não o deixe atrapalhar. É mais importante ser visto como alguém que faz as coisas do que como um diletante que reclama do estilo de codificação rude. Isto é especialmente verdade se você é o cara novo. Se você não conseguir obter tração com o UJS agora, faça um bom trabalho e, lentamente, crie um caso para as mudanças que gostaria de fazer à medida que ganha credibilidade.

  7. Read Switch: Como mudar as coisas quando a mudança é difícil . Isso lhe dará muito mais boas idéias sobre como construir seu caso com eficiência.


A essência da resposta é provar que o ujs funciona de forma realista. Mostre a eles que funciona.
usar o seguinte

2
@AvinashR O ponto é que o que motiva os gerentes geralmente não é o mesmo que motiva os desenvolvedores. Nós, desenvolvedores, gostamos de código para ser agradável e arrumado, com design elegante etc. Os gerentes querem maximizar o lucro. Se sua alteração resultar em mais vendas, ótimo. Se resultar em menor tempo de desenvolvimento ou menos tempo gasto em retrabalho ou correção de bugs, ótimo. Fico feliz em ouvir que os clientes gostam da sua GUI, mas o chefe atribui isso ao UJS ou à aparência da GUI? Se os clientes analisarem seu código e disserem "queremos que nosso código seja assim!" deve ser fácil defender o seu caso.
Calebe

3
Além de "Switch", eu também recomendaria "Driving Technical Change" de Terrance Ryan: terrenceryan.com/book . Além disso, em "Hello HTML5 and CSS3", Rob Crowther coloca de maneira simples: "HTML para conteúdo, CSS para apresentação e JavaScript para comportamento". Mantendo o JavaScript fora do HTML, você pode criar uma biblioteca de comportamentos e reutilizar o HTML em todo o lugar, sem codificação extra. Isso, ao ponto 4 de Caleb, economiza tempo e dinheiro.
Adrian J. Moreno

2
Ponto 3: Não exagere na experiência. Prefiro querer no meu time um super talentoso Leo Messi de 22 anos do que um jogador de 32 anos experiente e preguiçoso e experiente na Premier League. O sangue jovem, fresco e talentoso é frequentemente muito valioso.
Robert Niestroj

1
"Os gerentes querem maximizar o lucro". - Os gerentes também querem reduzir o risco; pode ser outra avenida.
Roger Lipscombe

8

O que você pode fazer é fornecer uma demonstração da depuração de um html do USJ usando as ferramentas FireQuery e Chrome Query .

O FireQuery é uma extensão do firebug e faz um bom trabalho. Quanto à Consulta do Chrome, não posso garantir o quanto ela é boa, mas definitivamente é usada por alguns dos desenvolvedores ( uma postagem no stackoverflow ).

Saiba também que a .datafunção é removida para retornar os dados internos do evento desde o jQuery 1.8.0 e substituída pelos $._data(element, "events")que podem ser instáveis, conforme o registro de alterações oficial

Agora isso foi removido no 1.8, mas você ainda pode acessar os dados dos eventos para fins de depuração via $ ._ data (elemento, "events"). Observe que essa não é uma interface pública suportada; as estruturas de dados reais podem mudar de forma incompatível de versão para versão.

ATUALIZAÇÃO:
Quando comecei a trabalhar, tive o mesmo dilema. Mas, após a criação de uma demonstração com GUI (aplicativo de página única) totalmente funcional, que incluiu abas de abertura dinâmica (que também podem ser fechadas), menu Accordion (criado dinamicamente a partir do db), eles finalmente entenderam que é melhor usar o USJ todo o caminho.

Além disso, a vantagem de usar o USJ é que você pode minificar todo o aplicativo em um pequeno script (ilegível). Também mostre a eles os scripts para google.com / github.com (como exemplo) e ressalte que mesmo eles estão com o código compactado, o que é sempre melhor, pois o visualizador do site terá dificuldade em decodificar as falhas de segurança e utilizá-los para iniciar um ataque completo no seu site (assustá-los), mesmo que improvável.

ATUALIZAÇÃO 2 :
Aliás, eu não sabia que estava fazendo USJ até ver essa pergunta, então obrigado de uma maneira.


2

Manipuladores de eventos em linha fedem porque:

  • Sem delegação de eventos - o que é ótimo quando você deseja poder extrair elementos de uma página e de fora de uma página dinamicamente sem precisar religar.

  • Você vinculou o comportamento às tags HTML em vez dos atributos de classe / ID das tags HTML. Digamos que você tenha uma classe de "combo_box" em todo o seu aplicativo. De repente, em metade das páginas antigas, você deseja uma pequena variação nas caixas de combinação quando elas estão em um recipiente diferente. Ligado a uma classe, você pode alterar esse comportamento com base no contexto do contêiner, por exemplo "#special_container .combo_box". Dentro do maldito HTML, você pode encontrar cada pequena caixa de seleção com uma classe .combo_box em qualquer número de páginas para alterar essas referências de manipulador uma a uma em vez de ajustar ou escrever algumas novas linhas de código para filtrar a partir de um único local de arquivo .

  • Se você deseja vários manipuladores, envolva-os em uma função e vincule-os desnecessariamente a arquivos HTML específicos. Quão sustentável é isso?

  • Um ponto mais sutil é que é muito mais fácil / mais sustentável / flexível e robusto lidar com comportamentos com mais mentalidade no painel de controle. Ao vincular a partir de um local central, você tem um local onde pode obter uma visão geral de todo o comportamento acontecendo na página ao mesmo tempo, o que é útil quando, por exemplo, você precisa descobrir por que determinadas páginas são executadas ocasionalmente em um determinado bug difícil de entender, mas não em outros.

  • Este é o lado do cliente. Temos vários navegadores, todos interpretando uma complexidade complexa de suas próprias maneiras. Junte tudo e deixe que o IDE resolva isso para você, mentalidades que não funcionam bem aqui. Manter seu código rígido, mínimo, com poucas conexões e limpeza não está na moda, é absolutamente essencial para estabelecer um front-end sustentável que seja fácil de modificar e atualizar e, sim, é aí que os $$$ assumem que seu gerente realmente tem visão de futuro .

  • Não é mais! @ # $ Ing 2002 mais. Esse argumento é tão antigo quanto as tabelas como o layout. Supere isso e comece a confiar em um desenvolvedor experiente especializado no lado do cliente que você mesmo contratou expressamente porque lhe faltava a experiência (não que eu esteja canalizando qualquer raiva da experiência pessoal ou algo assim).

E, para refutar o argumento de seu chefe, não é tão difícil rastrear qual classe ou ID está sendo usado na delegação de eventos ou na ligação de manipulador com CTRL + F e uma ferramenta que permite exibir todas as JS na página como meu próprio questionário embaraçosamente pessoal Versão do bookmarklet somente para protótipo / eu apressadamente me juntei quando a barra de ferramentas de desenvolvimento da Web começou a me afetar (maldita codificação de cores). Marque o marcador no link na página js fiddle ou copie o JS e faça o seu.

Um link de violino de JS que provavelmente expirará


+1 Finalmente, alguém apontou as principais desvantagens do JS embutido. Usarei esses argumentos no próximo debate com o meu chefe.
V-Light

@ V-Light Eles trabalharam?
Erik Reppen

2
Não! A opção 'ChangeYourOrganization' foi a solução
V-Light

0

Uma grande vantagem da sua técnica sugerida é que você só precisa vincular uma vez o manipulador de eventos a um pai, como "documento", e esse manipulador poderá capturar os eventos provenientes de todos os filhos que satisfizeram o seletor especificado, como "button.anyclass " Economiza memória e manutenção, de forma que apenas seja necessária uma instância de edição e isso afeta todos os elementos.

Com relação a não ser capaz de reconhecer ao mesmo tempo a função vinculada, sua equipe poderia padronizar uma maneira de declarar tais funções provavelmente na maior parte da parte inferior da página. Portanto, todos sabem onde procurar, a convenção de nomenclatura também é muito importante. Os comentários seriam extremamente benéficos, mas verifique se o servidor está sendo removido pelo servidor antes de servi-lo como resposta ao navegador.

Além disso, se você deseja fornecer ofuscamento e minificação de javascript para fins de segurança, sua técnica tornaria isso possível, diferente do estilo antigo que sua equipe ainda está usando.


-2

A resposta óbvia é que você pode vincular apenas uma função ao botão com o atributo onclick, enquanto o evento JQuery permite vincular várias funções. Um problema comum com o evento onload: se o seu documento é composto por mais de um arquivo, as colisões geralmente acontecem.

Outra solução que poderia saturar você e seu chefe é o uso de ligação de dados, com uma biblioteca como Knockout ou Angular, que acompanharia as modificações na sua exibição e suprimiria a necessidade de grande parte dos manipuladores de eventos.


1
sobre Knockout, Angular e outros frameworks JS para crianças legais ... infelizmente não é uma opção. O motivo é o mesmo que acima: é "demais" ou "muito novo" ou "muito legal" ou apenas "não queremos aprender algo novo, vamos fazê-lo da maneira antiga (estúpida / burra) .." . "
V-Light

@ Niphra: Além disso, você só pode vincular uma função a apenas um componente.
Bruno Schäpper

3
@ V-Light: "Você pode alterar sua organização ou alterar sua organização." Talvez isso é interessante para você: jamesshore.com/Change-Diary
de Bruno Schapper

Ei, minha empresa adere ao ASP clássico porque o ASP.NET é "muito novo", mas ainda assim consegui usar o Knockout em nosso código. Tente ver quais são realmente as preocupações e veja se você pode fazer uma alteração.
DistantEcho

1
@ Niphra "minha empresa continua com o Classic ASP:" isso é .... aterrorizante.
Michael Paulukonis
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.