[JQuery] (load clik toggle) Czy da się to uprościć? Opcje

[KotWButach]

Witam
Mam kod i zastanawiam się czy i jak można by go skrócić czy możecie pomóc?

[PHP] pobierz, plaintext 
    $('.table-component').on('click', '.filters', function() {
        $('.menu-filters').load('load/test.html'); // menu
    });
 
    // ukrycie
    $('.menu-filters').hide();
 
    // Obsłużenie kliknięcia
    $('.table-component').on('click', '.filters', function(event) {
        event.stopPropagation();
        $('.menu-filters').toggle();
    });
 
    // schowanie
    $(document).click(function() {
        $('.menu-filters').hide();
    });
[PHP] pobierz, plaintext 

Ten post edytował KotWButach 3.07.2014, 14:51:58

[SmokAnalog]

Czy zawartość pliku test.html jest jakaś wybitnie długa? Jeśli nie, to niech będzie normalnie w źródle.

Ukrycie .menu-filters załatwiłbym w CSS (display: none), a nie jQuery.

[proszek]

Wszystko co da się zrobić za pomocą CSSa powinno się nim robić - to tak na przyszłość. Optymalnie w JS dodajesz tylko albo odejmujesz odpowiednie klasy.

[SmokAnalog]

Wszystko co da się zrobić za pomocą CSSa powinno się nim robić - to tak na przyszłość. Optymalnie w JS dodajesz tylko albo odejmujesz odpowiednie klasy.

W tym przypadku mam inne zdanie. Po co bałaganić CSS kolejnymi klasami, kiedy jedyną różnicą jest widoczność elementu? To jest jedna (a może jedyna?) z tych właściwości, które lepiej zdają egzamin jako inline style.

Ten post edytował SmokAnalog 4.07.2014, 23:23:14

[pedro84]

W tym przypadku mam inne zdanie. Po co bałaganić CSS kolejnymi klasami, kiedy jedyną różnicą jest widoczność elementu? To jest jedna (a może jedyna?) z tych właściwości, które lepiej zdają egzamin jako inline style.

I wtedy zaśmiecisz HTML. Struktura dokumentu CSS naprawdę nie ucierpi jeśli dodasz do niej dwie klasy: .hidden, .visible. A style inline są zawsze "be".

[SmokAnalog]

A style inline są zawsze "be".

To twoje zdanie Ja trzymam się swojego zdania na temat display: none. Nie podobają mi się klasy typu "hidden", bo to tylko prosty tymczasowy stan, a nie jakaś rodzina właściwości. Ale to już dyskusja filozoficzna, każdy ma swoje zdanie.

[pedro84]

To twoje zdanie Ja trzymam się swojego zdania na temat display: none. Nie podobają mi się klasy typu "hidden", bo to tylko prosty tymczasowy stan, a nie jakaś rodzina właściwości. Ale to już dyskusja filozoficzna, każdy ma swoje zdanie.

Klasa ma zasadniczy jeden argument "za". Co w przypadku n elementów? Wstawiasz wszędzie style inline?

Poza tym, to nie odnosi się tylko do tymczasowego stanu - to zwykła klasa helpera i tyle.

[SmokAnalog]

Klasa ma zasadniczy jeden argument "za". Co w przypadku n elementów? Wstawiasz wszędzie style inline?

Tak, dokładnie to. Nie widzę problemu.

[Pyton_000]

Ap porem zmiana pierdyliard styli inline doprowadza kolejnych programistów do szału.

Jedynym miejscem gdzie akceptuję inline są newslettery.

[SmokAnalog]

Ap porem zmiana pierdyliard styli inline doprowadza kolejnych programistów do szału.

Przecież mówimy o przypisywaniu stylów z jQuery, więc co chcesz ręcznie zamieniać?

[KotWButach]

Dziękuje wam za te porpowiedzi, staram się własnie nie używać Jquery ale w tym przypadku uznałem że trzeba bo ten kod odpowiedzialny jest za każdą kolumnę których jest bardzo wiele:(.

[proszek]

Nie chodzi o zaśmiecanie kodu bądź nie ale o wydajność. Aczkolwiek oczywiście w tym przypadku wydajność nie ma wielkiego znaczenia bo kwestia jest tylko ukrycia lub odkrycia jednego elementu.

[SmokAnalog]

Trzeba by sprawdzić z ciekawości co jest wydajniejsze, bo coś podejrzewam, że .hide() szybciej zadziała niż dodanie klasy

[pedro84]

Trzeba by sprawdzić z ciekawości co jest wydajniejsze, bo coś podejrzewam, że .hide() szybciej zadziała niż dodanie klasy

Zdecydowanie klasa: http://jsperf.com/show-vs-addclass.

[proszek]

W przypadku animacji jeżeli robisz to za pomocą jquery przy każdej najmniejszej zmianie renderowana jest cala strona, css przelicza tylko jeden element. Sam odpowiedz sobie co jest szybsze

[KotWButach]

Cóz mogę powiedzieć Fajnie że wywiązała się ciekawa rozmowa Ale czy prócz wydajności nie jest również ważna czytelność kodu?

[SmokAnalog]

Zadałeś mądre pytanie. W dzisiejszych czasach czytelność rzeczywiście jest ważniejsza, zwłaszcza po stronie klienta. O ile oczywiście nie mówimy o odczuwalnych różnicach. Ale śmiać mi się chce, gdy ktoś pisze kod na 10 linii zamiast na 3, bo skrypt działa 0.03 sekundy zamiast 0.08.

[proszek]

Czytelność kodu po stronie klienta? A po co mu to? Kod ma się wykonywać. I powinieneś go dzielić na dwa rodzaje:
1. Kod dla "człowieka" (w domyśle programisty)
2. Kod dla maszyny (w domyśle serwera/przeglądarki)

Kod dla człowieka powinien być maksymalnie przejrzysty, łatwo edytowalny i skalowalny. A po przekompilowaniu powinien być maksymalnie wydajny. I tyle. Dlatego używa się SASSa, Lessa, CoffeeScript, HAMLa i podobnych, żeby ułatwić pracę człowiekowi a potem dla maszyny wygenerować maksymalnie wydajny kod.

Pewnie, że nie ma różnicy w przypadku prostej strony gdzie jest kilkaset linii css i kilka hide(), show(). Ale po co wyrabiać sobie złe nawyki? Po co męczyć się potem skoro i tak trzeba będzie się tego oduczyć w momencie gdy przyjdzie nam pracować nad czymś dużym i konkretnym.

[SmokAnalog]

Miałem na myśli kod, który się wykonuje po stronie klienta. Wspomniałem o tym dlatego, że to są w znacznej większości przypadków różnice totalnie nieważne. Wyjątkiem są strony, które wyświetlają wiele elementów jednocześnie lub zaawansowane animacje. Strona serwera to już inna bajka, bo serwer musi obsługiwać wiele żądań.

[pedro84]

Miałem na myśli kod, który się wykonuje po stronie klienta. Wspomniałem o tym dlatego, że to są w znacznej większości przypadków różnice totalnie nieważne. Wyjątkiem są strony, które wyświetlają wiele elementów jednocześnie lub zaawansowane animacje. Strona serwera to już inna bajka, bo serwer musi obsługiwać wiele żądań.

Nawet przy prostych stronach, CSS/JS powinno się łączyć i minimalizować - w szczególności w przypadku kiedy strona ma sensownie działać na mobilkach.