web-dev-qa-db-ja.com

上司（および他の開発者）に邪魔にならないJavaScriptを使用/検討するように説得するにはどうすればよいですか

私は開発者チームでかなり新しいです。

私はいくつかの強力な議論および/または「落とし穴」の例が必要なので、上司はついに邪魔にならないJavaScriptの利点を理解し、彼とチームの他のメンバーが次のようなことをやめるようにします。

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

そして

<script type="text/javascript">

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

私はかなり一般的なパターンを使用することを提案しました：

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

そして

<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();

});

上司（および他の人）がこのアプローチを使用したくない理由は、FireBug（またはChrome Dev Tools））のイベント検査が単純ではなくなったためです。

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

彼は、change-eventでどの関数が実行されるかをすぐに確認し、spaghetti-codeでいっぱいの巨大なJSファイルでその関数に直接ジャンプできます。

Unobtrusive JavaScriptの場合、彼が目にするのは次のものだけです。

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

そして、もしあれば、いくつかのイベントがこの要素にバインドされたかどうか、およびどの関数がトリガーされるかはわかりません。

私は解決策を探していて、それを見つけました：

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

しかし、この「アプローチ」では、どの関数がどのイベントで発生するかを見つけるのに「時間がかかりすぎる...」という時間がかかったため、そのようなバインドイベントを停止するように言われました。

「UJSを使用する理由」の例、強力な利点、またはその他の種類の提案をお願いします

PDATE：「仕事を変更する」という提案は理想的な解決策ではありません。

PDATE 2：わかりました、私はjQueryイベントバインディングの使用を提案しただけでなく、私はそうしました。後すべてのイベント委任を書いて、ボスが私にやって来て私に尋ねました、なぜ私は異なるアプローチと彼にアプローチしてイベント委任をしているのですかdind't know

15の入力フィールドがあり、そのすべてにonchangeイベントがあります（それらの一部だけがonkeyupも持っている）ので、これを書くのがより実用的です。特に、すべてのHTMLがPHPのエコーでレンダリングされる場合は、15回行う代わりに、すべての入力フィールド用のイベント委譲イベントの種類-> echo '... <input type="text" id="someid" ... />...'

design-patternsjavascriptjquery
21
V-Light

  1. 流行語の使用を中止し、代わりに強力な引数を作成してください。 控えめなJavaScript のWikipediaページでさえ、この用語は正式に定義されていないと述べています。それは多くの良いアイデアの包括的な用語かもしれませんが、それが単なる流行や流行のように聞こえるなら、あなたの上司や同僚はあまり注意を払いません。さらに悪いことに、彼らが役に立たないと見なすものについて続け続けると、彼らはあなたが主張している完全に無関係なアイデアを無視し始めるかもしれません。

  2. 理由を理解するあなた控えめなJavaScriptのアイデアは重要だと思います。それはあなたがそれらを読んだからだベストプラクティスを再検討しましたか？これらのアイデアに従わないことに起因すると思われる問題に遭遇しましたか？これらのアイデアの採用は、会社の収益にどの程度影響しますか？

  3. 上司の頭の中に入ってください。なぜ彼は彼のように行動し、なぜあなたの変更を拒否したのですか？彼はおそらく愚かではなく、おそらくあなたよりも経験が豊富であるため、おそらく彼のやり方で行動することにはいくつかの正当な理由があります。あなたはすでにそれらのいくつかをほのめかしました-そのスレッドを最後までたどってください。次に、あなたの提案が彼が最も懸念していることを改善するかどうか、そしてどのように改善するかを考えます。

  4. ヒント1：マネージャーはお金が好きです。提案を収入の増加または支出の削減に直接結び付けることができるほど、議論に与える影響は大きくなります。 ヒント2：時は金なりです。 ヒント3：それ自体では、コードの美的魅力は利益につながりません。実際にはその逆です。コードを見栄えよくするには時間がかかります。うまく機能する醜いコードは、ほとんどのマネージャーにとって問題ありません。

  5. それについて話すだけではなく、やる。小さな自己完結型プロジェクトがうまくいく幸運に恵まれている場合は、一種のデモンストレーションとして「UJS」スタイルを使用してそれを実行できるかどうかマネージャーに尋ねてください。準備ができたら、コードレビューを開いて、すべてがどのように機能するか、現在のスタイルよりも優れていると思う理由を説明してください。

  6. 理想主義は素晴らしいですが、邪魔をさせないでください。物事を成し遂げる人として見られることは、物事を行う人としてよりも重要ですuncouthコーディングスタイルについて文句を言います。 これは、あなたが新人の場合は特に当てはまります。今、UJSで牽引力を得ることができない場合は、代わりにいくつかの良い仕事をしてゆっくりビルドしてください信頼を得るために加えたい変更の事例。

  7. Switch：変更が難しいときに変更する方法 をお読みください。それはあなたのケースを効果的に構築する方法についてより多くの良いアイデアをあなたに与えるでしょう。

50
Caleb

あなたができることは、FireQueryおよびChrome Queryを使用してUSJ htmlをデバッグするデモを彼らに与えることです。

FireQueryはFirebugの拡張機能であり、かなりうまく機能しています。 Chrome Queryについては、どれほど優れているかを保証できませんが、一部の開発者（ stackoverflow の投稿）で使用されています）。

jQuery 1.8.0 以降、内部イベントデータを返すために_.data_関数が削除されており、$._data(element, "events")に置き換えられているため、不安定になる可能性があります。公式の変更ログ

これは1.8で削除されましたが、デバッグのために$ ._ data（element、 "events"）を介してイベントデータにアクセスできます。これはサポートされているパブリックインターフェイスではないことに注意してください。実際のデータ構造は、バージョン間で互換性がなく変更される可能性があります。

更新：
私が働き始めたとき、私は同じジレンマを抱えていました。しかし、動的に開くタブ（閉じることもできる）、アコーディオンメニュー（dbから動的に作成される）を含む完全に機能するGUI（シングルページアプリケーション）を備えたデモを作成すると、USJをずっと使用する方がよいことを理解しました。

また、USJを使用する利点は、アプリケーション全体を小さな（判読できない）スクリプトに縮小できることです。また、google.com/github.comのスクリプトを（例として）示し、コードが圧縮されていることを指摘します。これは、サイトの閲覧者がセキュリティ上の欠陥をデコードするのに苦労するため、常に優れています。可能性は低いですが、それらを利用して、サイトに本格的な攻撃を開始します（それらを怖がらせます）。

更新2：
ところで、私がこの質問を見るまで、私がUSJをしていることを知りませんでした。

8
Avinash R

インラインイベントハンドラーは次の理由で悪臭を放ちます。

  • イベントの委任はありません-再バインドせずにページから要素を動的にリップできるようにしたい場合に最適です。

  • HTMLタグのクラス/ ID属性ではなく、HTMLタグに動作をバインドしました。アプリ全体で「combo_box」のクラスがあるとします。突然、古いページの半分で、コンボボックスが別のコンテナーにあるときに、コンボボックスにわずかな変化が必要になるでしょう。クラスに関連付けられると、コンテナーのコンテキストに基づいてその動作を変更できます。 "#special_container .combo_box"。のろわれたHTMLにバインドされていると、任意の数のページで.combo_boxクラスを使用して小さな選択ボックスをすべて追跡し、1行のファイルの場所からフィルター処理する新しいコード行をいくつか調整または書き込むのではなく、ハンドラーの参照を1つずつ変更します。 。

  • 複数のハンドラーが必要な場合は、ハンドラーを関数でラップし、それを不必要に特定のHTMLファイルにバインドします。それはどの程度維持可能ですか？

  • 微妙な点は、より多くのコントロールパネルの考え方で動作を処理する方がはるかに簡単/保守/柔軟で堅牢であることです。中央の場所からバインドすることで、ページで同時に発生するすべての動作の概要を同時に取得できる場所が得られます。これは、たとえば、特定のページがときどき実行される理由を理解する必要がある場合に便利です。他の人ではなく、理解するのが難しい特定のバグに。

  • これはクライアント側です。私たちは複数のブラウザを使用しており、それぞれが複雑な問題を独自の方法で解釈しています。すべてをまとめてIDE分類して、メンタリティがうまく機能しないようにします。コードをタイト、ミニマル、疎結合、クリーンに保つことはファッショナブルではありません。絶対に不可欠です。簡単に変更および更新できる保守可能なフロントエンドを確立するために、そうです。ここで、マネージャーが実際に先見の明があると仮定して、$$$が入ります。

  • それはもはや！@＃$ ing 2002ではありません。この引数は、レイアウトと同じくらい古いものです。それを乗り越えて、経験豊富なクライアント側の専門の開発者を信頼し始めてください。あなたが彼らの専門知識に欠けていたためです（私が個人的な経験や何かからの怒りを流しているわけではありません）。

そして、上司の主張に反論するために、CTRL + Fを使用したイベントの委任またはハンドラーバインディングで使用されているクラスまたはIDを追跡し、自分の個人的な恥ずかしいjqueryのようにページ上のすべてのJSを表示できるツールを追跡することはそれほど難しくありません/ prototype-onlyブックマークレットバージョンWeb開発ツールバーが私をはじきだし始めたとき、私は急いで一緒に石畳を作りました（くせの色分け）。 jsフィドルページのリンクからブックマークするか、JSをコピーして独自のものを作成します。

おそらく最終的に期限切れになるJSフィドルリンク

2
Erik Reppen

提案された手法の主な利点の1つは、「ドキュメント」などの親にイベントハンドラーを一度バインドするだけでよく、このハンドラーは、「button.anyclass」などの指定されたセレクターを満たすすべての子からのイベントをキャッチできることです。 」 1つの編集インスタンスのみを必要とし、すべての要素に影響を与えるように、メモリと保守性を節約します。

バインドされた関数を一度に認識できないことに関しては、チームはおそらくそのような関数をページの最下部に宣言する方法を標準化できます。どこを見ればわかるか、命名規則も非常に重要です。コメントは非常に有益ですが、ブラウザへの応答として提供する前に、サーバーによって削除されることを確認してください。

また、セキュリティ上の目的でJavaScriptの難読化と縮小を提供する場合、チームが現在も使用している古いスタイルとは異なり、この手法でそれが可能になります。

0
vine