Patronumu (ve diğer aygıtları) göze batmayan JavaScript kullanmaya / düşünmeye nasıl ikna ederim?


21

Geliştirme ekibimizde oldukça yeniyim.

Bazı güçlü argümanlara ve / veya "pitfall" örneklerine ihtiyacım var, böylece patronum sonunda Unobtrusive JavaScript'in avantajlarını anlayacaktır, böylece kendisi ve ekibin geri kalanı böyle şeyler yapmayı bırakacaktır:

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

ve

<script type="text/javascript">

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

Oldukça yaygın bir kalıp kullanmayı önerdim:

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

ve

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

});

Patronumun (ve diğerlerinin) bu yaklaşımı kullanmak istememelerinin nedeni, FireBug'daki (veya Chrome Dev Tools'daki) Etkinlik Denetimi'nin artık basit olmamasıdır;

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

change-event'te hangi fonksiyonun çalıştığını hemen görebiliyor ve spagetti koduyla dolu devasa bir JS dosyasından atlayabiliyor .

Göze çarpmayan JavaScript durumunda, göreceği tek şey:

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

ve eğer varsa, bazı olayların bu elemana bağlı olup olmadığı ve hangi fonksiyonun tetikleneceği konusunda hiçbir fikri yoktur.

Bir çözüm arıyordum ve buldum:

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

ama, bu "yaklaşım", hangi fonksiyonun hangi olayı tetiklediğini bulmak için çok uzun sürmesine neden oldu, bu yüzden böyle olayları bağlamayı kesmem söylendi.

Sizden "Neden UJS kullanmalıyız" için bazı örnekler veya güçlü avantajlar ya da başka tür öneriler için rica ediyorum.

GÜNCELLEME: "işi değiştirmek" önerisi ideal bir çözüm değildir.

GÜNCELLEME 2: Tamam, sadece jQuery olayı bağlayıcı kullanmasını önermedim , yaptım . Tüm Etkinlik Delegasyonunu yazdıktan sonra, Patron bana geldi ve neden, bilmediği farklı yaklaşım ve yaklaşımlarla etkinlik delegasyonu yapıyorum diye sordu.

Bazı açık yararlardan bahsettim, örneğin - 15 giriş alanı var ve hepsinin bir onchangeetkinliği var (sadece bazıları değil onkeyup). Bu nedenle, TÜM giriş alanları için bu tür bir olay delegasyonu yazmaları daha pragmatik, 15 kez yapmak yerine, özellikle de HTML’nin tamamı PHP’nin eko ile gösterilmesi durumundaecho '... <input type="text" id="someid" ... />...'


İlk kod kutunuzdaki "sınıf" muhtemelen bir = gerektirir.
Joe Z.

6
Şunları yapabilirsiniz: 1) patronunuzu bilmediği teknikleri kullanmanıza izin vermeye ikna edin; 2) patronunuza yeni teknikleri öğretin; 3) patronunuzun bilmediği teknikleri kullanmayı bırakın; veya 4) bir işi değiştirmek. Bir seçeneği mi unuttum? 4'ü istemiyorsanız ve 1 ve 2'de başarılı olamıyorsanız, kalan tek seçeneğiniz 3'tür. Pazar değerinizin bildiğinize bağlı olduğunu unutmayın. Böylece patronunuzun onayladığı her şeyi öğrendikten sonra, kalan seçenekleriniz şunlardır: 3A) öğrenmeyi bırakın ve piyasa değeri düşüşünüzü izleyin; 3B) boş zamanlarında yeni teknikleri öğren ve kullan. Seçenek 3A size para kazandırır, seçenek 3B size zaman kazandırır.
Viliam Búr

1
Github gibi bir yaklaşımı kullanırdım: JS'de bağlanmış olayları olan her elemanın bir js-this-class-do-somethingsınıfı vardır, böylece kodda kolayca CTRL + F yapabilirsiniz.
caarlos0

FireQuery "çok uzun sürüyor" kısmı için yardımcı olabilir. Olaylarla ne kadar iyi çalıştığından emin değilsiniz, ancak en azından bir öğenin üzerinde olaylar olduğunu söylemesi gerekir.
Izkata

1
İşte olaylar ile çalışırken kullanmayı seviyorum güzel bir yardımcı program
karka91

Yanıtlar:


49
  1. Buzzwords kullanmayı bırakın ve bunun yerine güçlü argümanlar yapmayı deneyin. Göze batmayan JavaScript'in Wikipedia sayfası bile terimin resmi olarak tanımlanmadığını söylüyor. Bir dizi iyi fikir için battaniye terim olabilir, ancak bir ses veya moda gibi geliyorsa, patronunuz ve iş arkadaşlarınız çok fazla ilgilenmeyeceklerdir. Daha da kötüsü, işe yaramaz olarak gördükleri bir şeye devam ederseniz, savunduğunuz tüm ilgisiz fikirleri indirmeye başlayabilirler.

  2. Göze batmayan JavaScript fikirlerinin neden önemli olduğunu düşündüğünüzü anlayın. En iyi uygulama olarak kabul edildiklerini okuduğunuz için mi? Bu fikirleri takip etmemeye bağlı kalabileceğiniz problemlerle karşılaştınız mı? Bu fikirlerin benimsenmesi şirketin özünü ne kadar etkileyecek?

  3. Patronunun kafasının içine gir. Neden işleri olduğu gibi yapıyor ve değişikliklerinizi neden reddetti? Muhtemelen aptal değildir ve muhtemelen sizden daha deneyimlidir, bu yüzden muhtemelen işlerini yapmak için iyi nedenleri var. Bunlardan bazılarına zaten bahsettiniz - sonuna kadar bu konuyu takip edin. Ardından önerilerinizin en çok endişe duyduğu şeyleri iyileştirip iyileştirmeyeceğini anlayın.

  4. İpucu 1: Para gibi yöneticiler. Önerilerinizi daha fazla gelire veya azalan harcamalara bağladığınızda, tartışmanızın etkisi o kadar fazla olacaktır. 2. İpucu: Zaman paradır. 3. İpucu: Kodun estetik çekiciliği tek başına para kazanmaz. Tersi, aslında - kodun güzel görünmesi zaman alıyor. İyi çalışan çirkin kod, çoğu yönetici ile gayet iyi.

  5. Sadece konuşma, yapma . Küçük, müstakil bir projenin gelmesi için yeterince şanslıysanız, yöneticinize "UJS" stilini bir tür gösteri olarak kullanarak yapıp yapamayacağınızı sorun. Hazır olduğunuzda, hepsinin nasıl çalıştığını ve neden geçerli stilden daha iyi olduğunu düşündüğünüzü açıklayabileceğiniz bir kod incelemesi yapın.

  6. İdealizm harika, ama yoluna girmesine izin verme. İşleri yapan bir kişi olarak görülmek, şifresiz kodlama tarzından şikayet eden bir diyetisyen olarak görülmesi daha önemlidir. Bu özellikle yeni adamsanız geçerlidir. Şimdi UJS ile çekiş yapamıyorsanız, bunun yerine bazı iyi işler yapın ve güvenilirlik kazandıkça yapmak istediğiniz değişiklikler için yavaşça bir durum oluşturun.

  7. Okuma Anahtarı: Değişim Zor Olduğunda Şeyler Nasıl Değiştirilir ? Davanızı etkili bir şekilde nasıl inşa edeceğiniz konusunda size daha iyi fikirler verecektir.


Cevabın özü, UJ'lerin gerçekçi bir şekilde çalıştığını kanıtlıyor. Onlara işe yaradığını göster.
OnesimusUnbound

2
@AvinashR Mesele şu ki, yöneticileri motive eden şey genellikle geliştiricileri motive eden şey değildir. Kodun güzel ve düzenli olmasını, zarif bir şekilde tasarlanmasını vb. Geliştiricileri severiz. Yöneticiler karı maksimize etmek istiyor. Değişikliğiniz daha fazla satışla sonuçlanacaksa, harika. Daha kısa geliştirme süresi veya daha az zamanın yeniden çalışılması veya hataların giderilmesi için harcanmasıyla sonuçlanırsa, harika. Müşterilerin GUI'nizi sevdiğini duyduğuma sevindim, ancak patron bunu UJS'ye veya GUI'nin göründüğü şekilde atfediyor mu? Müşteriler kodunuza bakar ve "kodumuzun böyle görünmesini isteriz!" Davanızı yapmak kolay olmalı.
Caleb,

3
"Switch" e ek olarak, Terrance Ryan tarafından "Driving Technical Change" i de tavsiye ederim: terrenceryan.com/book . Ayrıca, "Merhaba HTML5 ve CSS3" te Rob Crowther basitçe şöyle ifade eder: "İçerik için HTML, sunum için CSS ve davranış için JavaScript." JavaScript’i HTML’nin dışında tutarak, bir davranış kütüphanesi oluşturabilir ve HTML’yi başka bir yerde kodlamaya gerek kalmadan yeniden kullanabilirsiniz. Bu, Caleb'in 4. no'lu noktasına göre zaman ve para tasarrufu sağlar.
Adrian J. Moreno

2
Nokta 3: Tecrübeyi abartmayın. Ekibimde, 32 yaşında, fazladan ödemeli, tembel ve geçici bir Premier Lig oyuncusu yerine süper yetenekli 22 yaşındaki bir Leo Messi istiyorum. Genç, taze, yetenekli kan genellikle çok değerlidir.
Robert Niestroj

1
"Yöneticiler karı maksimize etmek istiyor." - Yöneticiler ayrıca riski azaltmak istiyor; başka bir cadde olabilir.
Roger Lipscombe 30:13

8

Yapabilecekleriniz, onlara FireQuery ve Chrome Query araçlarını kullanarak USJ html hata ayıklama demosu vermektir .

FireQuery bir firebug uzantısıdır ve bu konuda oldukça iyi bir iş çıkarır. Chrome Query'ye gelince, bunun ne kadar iyi olduğu konusunda garanti veremem, ancak kesinlikle bazı aygıtlar ( stackoverflow'ta bir gönderi ) tarafından kullanılıyor.

Ayrıca , jQuery 1.8.0’dan.data bu yana dahili olay verilerini döndürmek için fonksiyonun kaldırıldığını ve bunun yerine değiştirilemeyen resmi değiştirici$._data(element, "events")

Bu şimdi 1.8'de kaldırılmıştır, ancak $ ._ data (element, "events") aracılığıyla hata ayıklama amacıyla olay verisine yine de erişebilirsiniz. Bunun desteklenen bir ortak arayüz olmadığını unutmayın; Gerçek veri yapıları sürümden sürüme uyumsuz olarak değişebilir.

GÜNCELLEME:
Çalışmaya başladığımda aynı ikilemi yaşadım. Ancak, dinamik olarak açılan sekmeleri içeren (çok da yakın), tamamen işlevsel GUI (tek sayfa uygulaması) olan bir demo oluşturulduktan sonra, Akordeon menüsü (db'den dinamik olarak oluşturulmuş), sonunda USJ'yi tamamen kullanmanın daha iyi olduğunu anladılar.

Ayrıca USJ kullanmanın artı bir kısmı da tüm uygulamanızı küçük (okunamayan) bir betiğe küçültebilmenizdir. Ayrıca onlara google.com / github.com (örnek olarak) komut dosyalarını gösterin ve siteyi görüntüleyenlerin güvenlik hatalarını çözmekte zorlanacakları için kodun sıkıştırılmış olduklarına bile dikkat edin. ve sitenizde tam teşekküllü bir saldırı başlatmak için onları kullanın (olasılıkla olmasa da).

GÜNCELLEME 2 :
BT, bu soruyu görene kadar USJ yaptığımı bilmiyordum, bir şekilde teşekkür ederim.


2

Satır içi olay işleyicileri kıyameti çünkü:

  • Hiçbir etkinlik temsilcisi yok - bu, bir sayfadaki öğeleri bir sayfa içinde ve dışında dinamik olarak yeniden birleştirmeye gerek kalmadan kırpabilmek istediğinizde harika.

  • Davranışı, HTML etiketlerinin sınıf / kimlik özellikleri yerine HTML etiketlerine bağladınız. Diyelim ki uygulamanızın tamamında bir "combo_box" sınıfı var. Aniden, eski sayfalarınızın yarısında, açılan kutularda farklı bir kapta olduklarında hafif bir değişiklik istersiniz. Bir sınıfa bağlı olarak, bu davranışı konteyner bağlamına dayalı olarak değiştirebilirsiniz, örn "#special_container .combo_box". Lanet olası HTML'nin içine bağlı olarak, bu işleyici referanslarını tek bir dosya konumundan filtrelemek için birkaç yeni kod satırı ayarlamak veya değiştirmek yerine, her küçük sayfadaki bir .combo_box sınıfı ile her bir seçim kutusunu takip ederek bulabilirsiniz. .

  • Birden fazla işleyici istiyorsanız, bunları bir işleve sarmış ve ardından gereksiz yere belirli HTML dosyalarına bağlamışsınız. Bu ne kadar sürdürülebilir?

  • Daha ince olan nokta ise, daha kontrol paneli zihniyetiyle davranışları ele almanın daha kolay / daha sürdürülebilir / esnek ve sağlam olmasıdır. Merkezi bir konumdan ciltleyerek, sayfada aynı anda gerçekleşen tüm davranışlara genel bir bakış bulabileceğiniz ve belirli sayfaların neden zaman zaman yayınlandığını anlamanız gerektiğinde kullanışlıdır. Anlaşılması zor olan ama başkaları olmayan kesin bir hataya.

  • Bu müşteri tarafı. Ağır karmaşıklığı hesaba katan yorum yapan birden çok tarayıcımız var. Hepsi bir arada toplayın ve IDE'nin sizin için ayırmasına izin verin, zihniyetler burada iyi çalışmaz. Kodunuzu sıkı, minimal, gevşek bir şekilde birleştirilmiş ve temiz tutmak moda değildir, değiştirilmesi ve güncellenmesi kolay bir ön uç oluşturmak için kesinlikle önemlidir ve evet, burası yöneticilerinizin gerçekten öngördüğü varsayımına dayanarak geldiğini gösterir. .

  • Artık! @ # $ İng. Bu argüman sayfa düzeni kadar eskidir. Üstesinden gel ve tecrübeli müşteri tarafı uzmanlığına güvenmeye başla, uzmanlıklarından mahrum kaldığın için kendinden açıkça işe alınmışsın (kişisel deneyimden veya herhangi bir şeyden öfkeye kanallık ettiğimden değil).

Ve patronunuzun argümanını reddetmek için, CTRL + F ile olay delegasyonunda veya işleyicide hangi sınıf veya kimliğin kullanıldığını ve bu sayfadaki tüm JS'yi kendi kişisel utanç verici jquery'im gibi görmenizi sağlayan bir araç olduğunu görmek gerçekten zor değil. / prototype-only bookmarklet version web dev toolbar üzerime çökmeye başladığında aceleyle bir araya toparlandım (kahrolası renk kodlaması). Js kiddle sayfasındaki linkten yer imi yazın veya JS'yi kopyalayıp kendinizinkini yapın.

Sonunda muhtemelen sona erecek bir JS keman bağlantısı


+1 Finaly'de birisi, satır içi JS'nin ana dezavantajlarına dikkat çekti. Bu argümanları patronumla bir sonraki tartışmada kullanacak.
V-Light

@ V-Light Çalışdılar mı?
Erik,

2
Hayır! 'Değişim Organizasyonunuzu' seçeneği çözüm oldu
V-Light

0

Önerilen tekniğinin önemli bir avantajı, etkinlik işleyicisini yalnızca "belge" gibi bir ebeveyne bağlamakla yetinmenizdir ve bu işleyici, "düğme" gibi belirli seçiciyi memnun eden tüm çocuklardan gelen olayları yakalayabilecektir. ". Yalnızca bir düzenleme örneğine ihtiyaç duyan ve tüm öğeleri etkileyecek şekilde bellek ve bakım kolaylığı sağlar.

Sınırlı işlevi bir kerede tanıyamamakla ilgili olarak, ekibiniz bu tür işlevleri muhtemelen sayfanın en alt kısmında ilan etme yöntemini standartlaştırabilir. Bu nedenle, hepiniz nereye bakacağınızı biliyorsunuz, konvansiyonel olarak adlandırmak da çok önemli. Komisyonlar çok faydalı olacak, ancak tarayıcıya yanıt vermeden önce sunucu tarafından çıkarıldığından emin olun.

Ayrıca, javascript'in gizlilik ve küçük düşürülmesini güvenlik amacıyla sağlamak istiyorsanız, ekibiniz hala kullandığınız eski tarzın aksine tekniğinizi mümkün kılar.


-2

Açık cevap, onclick özniteliği ile yalnızca bir işlevi düğmenize bağlayabilmenizdir, oysa JQuery olayı birden çok işlevi bağlamanıza izin verir. Onload olayı ile ilgili yaygın bir sorun: belgeniz birden fazla dosyadan oluşuyorsa, çarpışmalar sıklıkla gerçekleşir.

Hem sizi hem de patronunuzu tatmin edebilecek başka bir çözüm, Knockout veya Angular gibi bir kütüphane ile görüşünüzdeki değişiklikleri izleyen ve olay işleyicilerinin büyük bir kısmına duyulan ihtiyacı bastıracak veri bağlama kullanımıdır.


1
Serin çocuklar için Nakavt, Açısal ve diğer JS çerçeveleri ile ilgili olarak ... ne yazık ki bu bir seçenek değil. Sebep yukarıdakiyle aynı ... "çok fazla" ya da "çok yeni" ya da "çok havalı" ya da sadece "yeni bir şey öğrenmek istemiyoruz, hadi eski yapalım (aptal / aptal)" . "
V-Light

@Niphra: Ayrıca, yalnızca bir bileşene bir işlevi bağlayabilirsiniz.
Bruno Schäpper

3
@ V-Light: "Kuruluşunuzu değiştirebilir ya da kuruluşunuzu değiştirebilirsin." Belki bu sizin için ilginç: jamesshore.com/Change-Diary
Bruno Schäpper

Hey, şirketim Classic ASP'ye bağlı kaldı çünkü ASP.NET "çok yeni", ancak yine de Knockout'u kodumuzda zorlamayı başardım. Kaygılarının gerçekte ne olduğunu görmeye çalışın ve bir değişiklik yapıp yapamayacağınıza bakın.
DistantEcho

1
@Niphra "Şirketim Klasik ASP ile sopa:" Bu .... korkunç.
Michael Paulukonis
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.