Skrócenie kodu jq

Question

Witam

Nie znam się na jquery. Mam taki kod:

jQuery(document).ready(function( $ ){
  
    
    jQuery('#test1')
    .on('pumBeforeOpen', function () {
        var $iframe = jQuery('iframe', jQuery(this)),
            src = $iframe.prop('src');
        $iframe.prop('src', '').prop('src', src + '?autoplay=1');
    });
  
 
jQuery('#test2')
    .on('pumBeforeOpen', function () {
        var $iframe = jQuery('iframe', jQuery(this)),
            src = $iframe.prop('src');
        $iframe.prop('src', '').prop('src', src + '?autoplay=1');
    });

jQuery('#test3')
    .on('pumBeforeOpen', function () {
        var $iframe = jQuery('iframe', jQuery(this)),
            src = $iframe.prop('src');
        $iframe.prop('src', '').prop('src', src + '?autoplay=1');
    });

});

Jak go skrócić, żeby nie powtarzać za każdym razem wszystkiego podając inne id.

Jest to kod do wtyczki wordpress, który dodaje automatyczne włączenie filmiku po kliknięciu w ikonę, film wyświetla się w lightboxie. Nie mogę dodać bezpośrednio autoplay do adresu z youtube, bo wtedy film włącza się po załadowaniu strony przed kliknięciem (słychać dźwięk, sam film jest nadal schowany).

Answer 1

Spróbuj w ten sposób:

jQuery(document).ready(function ($) {
  jQuery('[id^="test]').on('pumBeforeOpen', function () {
    var $iframe = jQuery('iframe', jQuery(this)),
            src = $iframe.prop('src');
    $iframe.prop('src', '').prop('src', src + '?autoplay=1');
  });
});

P.S.

Po co jako argument funkcji przekazujesz "$", jeżeli nigdzie go nie używasz?

Comments

jQuery('[id^="test]')

mocno bym tutaj dyskutowal czy jest to faktycznie szybsze i lepsze rozwiązanie... Takie selektory są dość wolne i moim zdaniem już lepsze jest rozwiązanie np. dodaniem dla tych elementów jakiegoś atrybutu czy klasy i dodaniu event listenera dla rodzica, z analizą, który z dzieci został kliknięty.

---

Prośba była o skrócenie kodu, a nie optymalizację ;) Na pewno da się to w lepszy sposób wykonać.

---

Prośba była o skrócenie kodu, a nie optymalizację

I w pracy też masz takie podejście w CR :( ?

Skrócenie kodu to nie wszystko i to tylko jedna ze składowych wpływających na ogólną wydajność aplikacji. I tak kod zanim trafi na proda jest minifikowany, więc te kilka linijek więcej nie robi wielkiej różnicy, jeśli całkowity build miałby się zwiększyć nieznacznie, ale kosztem szybszej pracy to lepiej zostać czasami przy tym większym. Czasami warto szukać rozwiązań gdzie indziej, np. w buildach cząstkowych, w jakiś rozwiązaniach reaktywnych itp. itd.

---

Tomek Sochacki imo takie mikro-optymalizacje kompletnie nie mają znaczenia. Szczególnie dodawanie event delegation dla 3 elementów, jeśli mamy jQuery.

---

@Tomek Sochacki, ile zyskasz na optymalizacji Twoim sposobem? Nie sądzę, żeby w obrębie całej strony miało to jakieś duże znaczenie. Tym bardziej, że strona jest na WP, który sam w sobie jest dosyć "ciężki".

---

@arces,

Zgubiłeś cudzysłów , a poza tym jeżeli pobierasz kolekcję to chyba musisz ją przepuścić przez jakąś pętlę np. each() I dopiero na każdym elemencie $(this) wykonać jakieś działanie.

---

I tak i nie. Myśląc tylko i wyłącznie tym jednym ficzerem to owszem, macie rację. Ale moim zdaniem warto myśleć kompleksowo, dzisiaj robimy jeden ficzer, jutro drugi, i za chwilę okaże się, że w miesiąc wypuszczamy na proda 30 nowych wersji jakieś usługi... Jak weźmiemy pod uwagę skalę np. roku to już można wg mnie faktycznie myśleć co nie co o takich mikrooptymalizacjach.

To jest błąd, który jest zauważalny u wielu osób początkujących... patrzenie wyłącznie na swój feature, na swoją drobną zmianę... i właśnie takie argumentacje jak ktoś w CR wytknie kwestię optymalizacji...

Argento piszesz o niepotrzebnym omijaniu jQuery skoro i tak jest... oki, racja, ale czy nie warto może sprawdzić czy naprawdę to jQuery jest niezbędne i czy nie lepiej powoli zacząć wychodzić z niego aby zmniejszyć całkowity build itp.? Myśląc ponownie tylko swoją, obecną zmianą to takie coś nigdy nie nastąpi, ale jeśli stopniowo będziemy wychodzić z jQuery to z czasem okaże się, że starych ficzerów jest garstka i może warto naprawdę to zaorać i zyskać ładnych parę kb?

To jest zawsze oczywiście sprawa indywidualna, ale ja jestem zdania, aby jednak starać się zawsze myśleć bardziej przyszłościowo i otwierać sobie drogę do przyszłych migracji technologii itp.

---

I tak i nie. Myśląc tylko i wyłącznie tym jednym ficzerem to owszem, macie rację. Ale moim zdaniem warto myśleć kompleksowo, dzisiaj robimy jeden ficzer, jutro drugi, i za chwilę okaże się, że w miesiąc wypuszczamy na proda 30 nowych wersji jakieś usługi... Jak weźmiemy pod uwagę skalę np. roku to już można wg mnie faktycznie myśleć co nie co o takich mikrooptymalizacjach

Milionowe części sekundy pomnożone nawet przez setki przypadków - nadal nie zmieniają ux i naprawdę daleko im do tego.

To jest błąd, który jest zauważalny u wielu osób początkujących... patrzenie wyłącznie na swój feature, na swoją drobną zmianę... i właśnie takie argumentacje jak ktoś w CR wytknie kwestię optymalizacji...

To nie jest optymalizacja, optymalizacja to by była gdyby zaoszczędzono 300ms. To jest niepotrzebne czepialstwo i pisanie nadmiernych ilości kodu.

Argento piszesz o niepotrzebnym omijaniu <<< wstaw dowolny framework /bibliotekę >>> skoro i tak jest... oki, racja, ale czy nie warto może sprawdzić czy naprawdę to <<< wstaw dowolny framework /bibliotekę >>> jest niezbędne i czy nie lepiej powoli zacząć wychodzić z niego aby zmniejszyć całkowity build itp.? Myśląc ponownie tylko swoją, obecną zmianą to takie coś nigdy nie nastąpi, ale jeśli stopniowo będziemy wychodzić z <<< wstaw dowolny framework /bibliotekę >>> to z czasem okaże się, że starych ficzerów jest garstka i może warto naprawdę to zaorać i zyskać ładnych parę kb?

Narzędzia są po to, żeby z nich korzystać. Inna sprawa, że w tym konkretnym przypadku jQuery raczej nigdzie się nie wybiera.