Z witryny z dokumentacją jQuery API dlaready
Wszystkie trzy z następujących składni są równoważne:
- $ (document) .ready (handler)
- $ (). ready (handler) (nie jest to zalecane)
- $ (handler)
Po odrabianiu lekcji - czytaniu i zabawie z kodem źródłowym nie mam pojęcia dlaczego
$().ready(handler)
nie jest zalecane. Pierwszy i trzeci sposób są dokładnie takie same, trzecia opcja wywołuje funkcję ready na zbuforowanym obiekcie jQuery z document
:
rootjQuery = jQuery(document);
...
...
// HANDLE: $(function)
// Shortcut for document ready
} else if ( jQuery.isFunction( selector ) ) {
return rootjQuery.ready( selector );
}
Ale gotowa funkcja nie ma interakcji z selektorem wybranych elementów węzła, ready
Kod źródłowy:
ready: function( fn ) {
// Attach the listeners
jQuery.bindReady();
// Add the callback
readyList.add( fn );
return this;
},
Jak widać, po prostu dodaje wywołanie zwrotne do wewnętrznej kolejki ( readyList
) i nie zmienia ani nie używa elementów w zestawie. Pozwala to wywołać ready
funkcję na każdym obiekcie jQuery.
Lubić:
- zwykły selektor:
$('a').ready(handler)
DEMO - Selektor bzdur :
$('fdhjhjkdafdsjkjriohfjdnfj').ready(handler)
DEMO - Niezdefiniowany selektor:
$().ready(handler)
DEMO
Wreszcie ... na moje pytanie: dlaczego $().ready(handler)
nie jest zalecane?
javascript
jquery
callback
document-ready
gdoron wspiera Monikę
źródło
źródło
$.ready
na przykład) i nie wymagać w pierwszej kolejności konstruowania obiektu jQuery..ready()
możliwości dla poszczególnych elementów, nie powinno być powodu do konstruowania obiektu jQuery.$.ready
jest już zajęte przez wewnętrzną funkcję jQuery, wyszukaj kod źródłowyready:
.Odpowiedzi:
Otrzymałem oficjalną odpowiedź od jednego z programistów jQuery:
$().ready(fn)
działa tylko dlatego,$()
że był skrótem do$(document)
(jQuery <1.4)Więc
$().ready(fn)
był czytelny kod.Ale ludzie robili takie rzeczy jak
$().mouseover()
i wszelkiego rodzaju inne szaleństwa.i ludzie musieli zrobić,
$([])
aby uzyskać pusty obiekt jQueryWięc w 1.4 zmieniliśmy to tak, że
$()
daje puste jQuery i po prostu wykonaliśmy$().ready(fn)
pracę, aby nie zepsuć dużo kodu$().ready(fn)
jest teraz dosłownie załatany w jądrze, aby działał poprawnie w przypadku starszej wersji.Najlepsze miejsce na tę
ready
funkcję jest$.ready(fn)
, ale to naprawdę stara decyzja projektowa i to jest to, co mamy teraz.Zapytałem go:
Jego odpowiedź brzmiała:
źródło
$()
w pierwszej kolejności (tak głupkowate, jak mogło być to zachowanie) . Z drugiej strony masz rację. Nie zawsze są tak skłonni do dokonywania przełomowych zmian, jak pokazano, gdy próbowali to zmienić.attr()
, a kilka dni później dokonali szybkiego powrotu. To wiąże ich z niektórymi z ich niefortunnych decyzji projektowych we wczesnym (i średnim wieku).$(selector[, context])
i$(html[, ownerDocument])
. W rzeczywistości równie dobrze możesz po prostu użyćjQuery()
zamiast,$()
jeśli problemem jest wiedza, że to działa. Albo po co w ogóle używać jQuery?Ponieważ różne opcje działają prawie tak samo, jak wskazałeś, nadszedł czas, aby założyć kapelusz pisarza bibliotecznego i zrobić kilka domysłów.
Być może ludzie z jQuery chcieliby mieć
$()
dostęp do przyszłego użytku (wątpliwe, ponieważ$().ready
udokumentowano, że działa, nawet jeśli nie jest to zalecane; zanieczyściłoby to również semantykę,$
jeśli ma specjalne wielkości ).O wiele bardziej praktyczny powód: druga wersja jest jedyną, która nie kończy się zawijaniem
document
, więc łatwiej jest zepsuć podczas obsługi kodu. Przykład:// BEFORE $(document).ready(foo); // AFTER: works $(document).ready(foo).on("click", "a", function() {});
Porównaj to z
// BEFORE $().ready(foo); // AFTER: breaks $().ready(foo).on("click", "a", function() {});
W związku z powyższym:
ready
jest dziwadłem w tym sensie, że jest to (jedyna?) Metoda, która będzie działać tak samo bez względu na to, co zawija obiekt jQuery (nawet jeśli nie zawija niczego, jak ma to miejsce w tym przypadku). Jest to zasadnicza różnica w stosunku do semantyki innych metod jQuery, więc szczególne poleganie na tym jest słusznie odradzane.Aktualizacja: Jak podkreśla komentarz Esailiji, z inżynieryjnego punktu widzenia
ready
naprawdę powinna to być metoda statyczna, dokładnie dlatego, że tak działa.Aktualizacja # 2: Kopiąc u źródła, wydaje się, że w pewnym momencie gałąź 1.4
$()
została zmieniona, aby pasowała$([])
, podczas gdy w 1.3 zachowywała się podobnie$(document)
. Zmiana ta wzmocni powyższe uzasadnienia.źródło
$(document).ready( function(){ //your code here } );
selector = selector || document
naif(!selector) return this
.Powiedziałbym, że jest to po prostu fakt, że
$()
zwraca pusty obiekt, podczas gdy$(document)
nie oznacza to, że stosujesz sięready()
do różnych rzeczy; nadal działa, ale powiedziałbym, że nie jest intuicyjny.$(document).ready(function(){}).prop("title") // the title $().ready(function(){}).prop("title") //null - no backing document
źródło
$()
.ready
ponieważ jest to dobrze ugruntowany idiom, którego nie wolno. Oczywiście, istnieje teoretyczna szansa, że ktoś to zrobi, ale nigdy nie widziałem kodu, który to robi (co nie jest dobrym argumentem, ale wiesz: D).Najprawdopodobniej jest to tylko błąd dokumentacji i powinien zostać naprawiony, jedyną wadą używania
$().ready(handler)
jest jego czytelność. Jasne, argumentuj, że$(handler)
jest to równie nieczytelne. Zgadzam się, dlatego go nie używam .Możesz również argumentować, że jedna metoda jest szybsza niż inna. Jednak jak często wywołujesz tę metodę wystarczająco dużo razy z rzędu na jednej stronie, aby zauważyć różnicę?
Ostatecznie sprowadza się to do osobistych preferencji. Nie ma żadnych wad używania
$().ready(handler)
innego argumentu niż argument czytelności. Myślę, że w tym przypadku dokumentacja jest chybiona.źródło
Aby było wyraźnie oczywiste, że w tych trzech jest pewna niespójność, dodałem też czwartą często używaną formę:
(function($) {}(jQuery));
Z tym znacznikiem:
<div >one</div> <div>two</div> <div id='t'/>
i ten kod:
var howmanyEmpty = $().ready().find('*').length; var howmanyHandler = $(function() {}).find('*').length; var howmanyDoc = $(document).ready().find('*').length; var howmanyPassed = (function($) { return $('*').length; }(jQuery)); var howmanyYuck = (function($) {}(jQuery)); var howmanyYuckType = (typeof howmanyYuck); $(document).ready(function() { $('#t').text(howmanyEmpty + ":" + howmanyHandler + ":" + howmanyDoc + ":" + howmanyPassed + ":" + howmanyYuckType); });
Wyświetlane wyniki div z ostatniej instrukcji to: 0: 9: 9: 9: undefined
WIĘC, tylko wersje Handler i Doc są zgodne z konwencją jQuery polegającą na zwracaniu czegoś użytecznego, gdy dostają selektor dokumentu, a z formularzem Passed musisz coś zwrócić (myślę, że nie zrobiłbym tego, ale wstawiłem to po prostu pokazać „w środku”, że coś ma).
Oto skrzypcowa wersja tego dla ciekawskich: http://jsfiddle.net/az85G/
źródło
null
taki, że.find('*').length
zwraca 0 . Czy widzisz coś złego w tym (oczywistym) zachowaniu?if(!selector) return this
taki, że jeśli dasz coś innego, sąregex
i inne rzeczy ... Dzięki za miłe słowa ... Myślę, że mógłbym poprosić zespół jQuery o odpowiedz na to (do diabła, to nie moja biblioteka:-)
).jQuery(document).ready(function(){});
formularz w naszej bazie kodu, ponieważ istnieją różne poziomy wiedzy na temat jQuery i dla nowych ludzi jest "najbardziej oczywiste", że JEST to funkcja obsługi zdarzeń dla jQuery.Myślę, że jest to bardziej czytelne niż cokolwiek innego.
Ten nie jest tak wyrazisty
tak jak
$(document).ready(handler)
Być może próbują promować jakąś formę idiomatycznego jQuery.
źródło
$(document).ready(handler)
jest bardziej czytelny niż$(handler)
zalecany ...