Bagaimana cara meyakinkan bos saya (dan pengembang lainnya) untuk menggunakan / mempertimbangkan JavaScript yang tidak mengganggu

Saya cukup baru di tim pengembang kami.

Saya memerlukan beberapa argumen yang kuat dan / atau contoh "jebakan", sehingga bos saya akhirnya akan memahami kelebihan JavaScript yang Tidak Mengganggu, sehingga dia, dan anggota tim lainnya, berhenti melakukan hal-hal seperti ini:

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

dan

<script type="text/javascript">

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

Saya menyarankan menggunakan pola yang cukup umum:

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

dan

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

});

Alasan mengapa atasan saya (dan lainnya) tidak ingin menggunakan pendekatan ini adalah bahwa Inspeksi Peristiwa di FireBug (atau Chrome Dev Tools) tidak sederhana lagi, misalnya dengan

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

dia dapat segera melihat fungsi apa yang dijalankan pada perubahan-peristiwa dan langsung menuju ke sana dalam file JS besar penuh dengan kode spaghetti .

Dalam kasus Unobtrusive JavaScript, satu-satunya hal yang akan dilihatnya adalah:

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

dan dia tidak tahu apakah beberapa peristiwa, jika ada, terikat pada elemen ini dan fungsi mana yang akan dipicu.

Saya mencari solusi dan menemukannya:

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

tetapi, "pendekatan" ini menyebabkannya butuh "terlalu lama ..." untuk mengetahui fungsi mana yang menyala pada peristiwa mana, jadi saya disuruh menghentikan acara mengikat seperti itu.

Saya meminta beberapa contoh atau keuntungan kuat atau saran lain untuk "Mengapa kami harus menggunakan UJS"

UPDATE: saran untuk "mengganti pekerjaan" bukanlah solusi yang ideal.

UPDATE 2: Ok, saya tidak hanya menyarankan untuk menggunakan jQuery-binding, saya melakukannya . Setelah saya menulis semua Peristiwa-Delegasi, Bos datang kepada saya dan bertanya kepada saya, mengapa saya melakukan delegasi acara dengan pendekatan dan pendekatan yang berbeda yang dia tidak tahu

Saya menyebutkan beberapa manfaat yang jelas, seperti - Ada 15 bidang input dan semuanya kemudian memiliki onchangeacara (tidak hanya, beberapa di antaranya juga onkeyup). Jadi lebih pragmatis untuk menulis semacam ini acara delegasi untuk SEMUA bidang input, alih-alih melakukannya 15 kali, terutama jika semua HTML akan di-render dengan gema PHP ->echo '... <input type="text" id="someid" ... />...'

1. Berhentilah menggunakan kata kunci dan cobalah membuat argumen yang kuat. Bahkan halaman Wikipedia untuk Unobtrusive JavaScript mengatakan bahwa istilah tersebut tidak didefinisikan secara formal. Ini mungkin istilah selimut untuk sejumlah ide bagus, tetapi jika itu terdengar seperti mode atau mode belaka atasan dan rekan kerja Anda tidak akan membayar banyak perhatian. Lebih buruk lagi, jika Anda terus melakukan sesuatu yang mereka anggap tidak berguna, mereka mungkin mulai mengabaikan ide-ide yang sama sekali tidak terkait yang Anda sarankan.

2. Cari tahu mengapa Anda menganggap ide JavaScript yang tidak mencolok itu penting. Apakah karena Anda membaca bahwa itu dianggap praktik terbaik? Sudahkah Anda mengalami masalah yang Anda anggap tidak mengikuti ide-ide ini? Berapa banyak mengadopsi ide-ide ini akan berdampak pada garis bawah perusahaan?

3. Masuk ke dalam kepala bos Anda. Mengapa dia melakukan hal-hal seperti yang dia lakukan, dan mengapa dia menolak perubahanmu? Dia mungkin tidak bodoh, dan dia mungkin lebih berpengalaman daripada kamu, jadi dia mungkin punya beberapa alasan bagus untuk melakukan sesuatu dengan caranya. Anda sudah menyinggung beberapa dari mereka - ikuti utas itu sampai akhir. Kemudian cari tahu apakah dan bagaimana saran Anda akan meningkatkan hal-hal yang paling ia pedulikan.

4. Petunjuk 1: Manajer menyukai uang. Semakin langsung Anda mengikat saran Anda dengan peningkatan pendapatan atau pengurangan pengeluaran, semakin besar dampak argumen Anda. Petunjuk 2: Waktu adalah uang. Petunjuk 3: Dengan sendirinya, daya tarik estetika dari kode tidak menghasilkan uang. Sebaliknya, sebenarnya - butuh waktu untuk membuat kode terlihat bagus. Kode jelek yang berfungsi dengan baik baik-baik saja dengan sebagian besar manajer.

5. Jangan hanya membicarakannya, lakukan saja . Jika Anda cukup beruntung memiliki proyek kecil yang mandiri, tanyakan kepada manajer Anda apakah Anda dapat melakukannya menggunakan gaya "UJS" sebagai semacam demonstrasi. Saat Anda siap, tahan tinjauan kode tempat Anda bisa menjelaskan cara kerjanya dan mengapa menurut Anda lebih baik daripada gaya saat ini.

6. Idealisme itu hebat, tetapi jangan biarkan hal itu menghalangi. Ini lebih penting untuk dilihat sebagai seseorang yang menyelesaikan sesuatu daripada sebagai dilettante yang mengeluh tentang gaya pengkodean kasar. Ini terutama benar jika Anda adalah pria baru. Jika Anda tidak bisa mendapatkan daya tarik dengan UJS sekarang, lakukan pekerjaan yang baik dan perlahan-lahan buat kasus untuk perubahan yang ingin Anda lakukan saat Anda mendapatkan kredibilitas.

7. Baca Beralih: Cara Mengubah Hal-hal Ketika Perubahan Sulit . Ini akan memberi Anda lebih banyak ide bagus tentang bagaimana membangun kasus Anda secara efektif.

Yang dapat Anda lakukan adalah memberi mereka demo debug html USJ menggunakan alat FireQuery serta Chrome Query .

FireQuery adalah ekstensi pembakar dan melakukan pekerjaan yang cukup bagus. Adapun Chrome Query, saya tidak dapat menjamin seberapa bagus, tetapi pasti digunakan oleh beberapa pengembang ( posting di stackoverflow ).

Ketahui juga bahwa .datafungsi tersebut dihapus untuk mengembalikan data acara internal sejak jQuery 1.8.0 , dan diganti dengan $._data(element, "events")yang dapat menjadi tidak stabil, sesuai dengan changelog resmi

Ini sekarang dihapus di 1.8, tetapi Anda masih bisa mendapatkan data acara untuk keperluan debugging melalui $ ._ data (elemen, "events"). Perhatikan bahwa ini bukan antarmuka publik yang didukung; struktur data aktual dapat berubah secara tidak kompatibel dari versi ke versi.

UPDATE:
Ketika saya mulai bekerja saya memiliki dilema yang sama. Tetapi setelah membuat demo dengan GUI yang berfungsi penuh (aplikasi halaman tunggal) yang termasuk tab membuka secara dinamis (dapat ditutup juga), menu Akordeon (dibuat secara dinamis dari db), mereka akhirnya mengerti bahwa lebih baik menggunakan USJ sepanjang jalan.

Selain itu plus menggunakan USJ adalah Anda dapat mengecilkan seluruh aplikasi Anda menjadi skrip kecil (tidak dapat dibaca). Juga perlihatkan kepada mereka skrip untuk google.com / github.com (sebagai contoh), dan tunjukkan bahwa meskipun mereka memiliki kode yang dikompresi, yang selalu lebih baik, karena pemirsa situs akan kesulitan memecahkan kode kesalahan keamanan dan gunakan mereka untuk memulai serangan penuh di situs Anda (menakut-nakuti mereka), meskipun tidak mungkin.

UPDATE 2 :
Btw, saya tidak tahu saya melakukan USJ sampai saya melihat pertanyaan ini, jadi terima kasih dalam satu cara.

Penangan event inline bau karena:

• Tidak ada delegasi acara - yang sangat bagus ketika Anda ingin dapat merobek elemen masuk dan keluar dari halaman secara dinamis tanpa harus rebind.

• Anda telah mengikat perilaku ke tag HTML alih-alih atribut kelas / ID dari tag HTML. Katakanlah Anda memiliki kelas "combo_box" di seluruh aplikasi Anda. Tiba-tiba, pada setengah halaman lama Anda, Anda ingin sedikit variasi pada kotak kombo Anda ketika mereka berada di wadah yang berbeda. Terikat ke kelas, Anda dapat mengubah perilaku itu berdasarkan konteks wadah, misalnya "#special_container .combo_box". Terikat di dalam HTML terkutuk Anda dapat menemukan diri Anda melacak setiap kotak pilih kecil dengan kelas .combo_box di halaman nomor mana pun untuk mengubah referensi penangan itu satu per satu daripada mengubah atau menulis beberapa baris kode baru untuk disaring dari satu lokasi file tunggal .

• Jika Anda ingin beberapa penangan, Anda harus membungkusnya dalam suatu fungsi dan kemudian mengikatnya secara tidak perlu ke file HTML tertentu. Seberapa terpelihara itu?

• Poin yang lebih subtil adalah jauh lebih mudah / lebih mudah dirawat / fleksibel dan kuat untuk menangani perilaku dengan lebih banyak mentalitas panel kontrol. Dengan mengikat dari lokasi pusat, Anda punya tempat di mana Anda bisa mendapatkan gambaran umum dari semua perilaku yang terjadi pada halaman sekaligus, yang berguna ketika, misalnya, Anda perlu mencari tahu mengapa halaman tertentu kadang-kadang berjalan menjadi bug tertentu yang sulit dimengerti tetapi tidak pada yang lain.

• Ini adalah sisi klien. Kami memiliki beberapa peramban yang semuanya menafsirkan kerumitan berat dengan cara mereka sendiri untuk memperhitungkan. Slop-it-all-together dan biarkan IDE mengatasinya agar mentalitas Anda tidak bekerja dengan baik di sini. Menjaga kode Anda tetap ketat, minimal, longgar digabungkan, dan bersih tidak modis, sangat penting untuk membangun ujung depan yang mudah dikelola yang mudah dimodifikasi dan diperbarui dan ya, di situlah $$$ datang dengan asumsi manajer Anda benar-benar memiliki pandangan jauh ke depan .

• Bukan! @ # $ Ing 2002 lagi. Argumen ini setua tabel dengan tata letak. Atasi itu dan mulailah memercayai pengembang khusus sisi klien yang berpengalaman yang Anda rekrut sendiri karena Anda tidak memiliki keahlian mereka (bukannya saya menyalurkan kemarahan dari pengalaman pribadi atau apa pun).

Dan untuk membantah argumen bos Anda, sebenarnya tidak terlalu sulit untuk melacak kelas atau ID apa yang digunakan dalam delegasi acara atau pengikatan pawang dengan CTRL + F dan alat yang memungkinkan Anda melihat semua JS pada halaman seperti jquery memalukan pribadi saya sendiri / versi bookmarklet-saja prototipe Aku buru-buru berbatu ketika bilah alat web dev mulai menggerogotiku (terkutuk-kode warna). Bookmark dari tautan di halaman biola js atau salin JS dan buat sendiri.

Tautan biola JS yang mungkin akan kedaluwarsa pada akhirnya

Salah satu keuntungan utama dari teknik yang Anda sarankan adalah Anda hanya perlu mengikat sekali event handler ke orang tua seperti "dokumen" dan handler ini akan dapat menangkap peristiwa yang datang dari semua anak yang memenuhi pemilih yang diberikan seperti "button.anyclass ". Menghemat memori dan dapat dipelihara sehingga hanya perlu satu kali edit dan itu mempengaruhi semua elemen.

Sehubungan dengan tidak dapat langsung mengenali fungsi terikat, tim Anda hanya bisa menstandarkan cara mendeklarasikan fungsi tersebut mungkin di bagian paling bawah halaman. Jadi, Anda semua tahu di mana mencarinya, konvensi penamaan juga sangat penting. Beberapa komentar akan sangat bermanfaat, tetapi pastikan dilucuti oleh server sebelum menyajikannya sebagai respons terhadap browser.

Juga, jika Anda ingin memberikan kebingungan dan minifikasi javascript untuk tujuan keamanan, teknik Anda akan memungkinkan, tidak seperti gaya lama yang masih digunakan tim Anda.

Jawaban yang jelas adalah bahwa Anda hanya dapat mengikat satu fungsi ke tombol Anda dengan atribut onclick, sedangkan acara JQuery memungkinkan Anda untuk mengikat beberapa fungsi. Masalah umum dengan peristiwa onload: jika dokumen Anda terdiri dari lebih dari satu file, sering terjadi tabrakan.

Solusi lain yang dapat memuaskan Anda dan bos Anda adalah penggunaan pengikatan data, dengan perpustakaan seperti Knockout atau Angular, yang akan melacak modifikasi pada pandangan Anda dan menekan kebutuhan untuk sebagian besar penangan acara.