Meerdere $(document).ready() op een pagina
Als ik her en der op internet lees dan zie ik aan de ene kant dat het niet uit zou moeten maken, anderzijds dat het performance kost. Volgens deze benchmark zou het ook echt trager zijn: http://jsperf.com/docready/3
Om zelf te kunnen bepalen of het ook echt zo is dacht ik in de broncode van JQuery te duiken om te zien hoe het werkt, maar daar wordt ik in elk geval niet wijzer van. Het is mij niet duidelijk of elke document ready afzonderlijk de status blijft controleren, of dat er een queue wordt gevormd waarna alle callbacks achter elkaar worden gedaan.
Hier de JQuery sourcecode, vanaf regel 815: https://github.com/jquery/jquery/blob/master/src/core.js
Iemand die meer kennis heeft over hoe document ready nu echt werkt (en dus kan onderbouwen of je het bij een zou moeten houden of niet)?
Overigens heb ik ook mijn eigen queue gebouwd zodat ik met een standard scriptje het altijd bij een document ready kan houden:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var register = new Array();
function register_startup(func){
register.push(func);
}
$(document).ready(function(){
for(i=0; i<register.length; i++){
if (typeof register[i] == "function"){
register[i]();
}
}
});
//in plaats van alle events in een document ready te plaatsen kan ik nu dit doen:
register_startup(function(){
$("#test_button").click(function(){
alert("clicked!");
});
});
function register_startup(func){
register.push(func);
}
$(document).ready(function(){
for(i=0; i<register.length; i++){
if (typeof register[i] == "function"){
register[i]();
}
}
});
//in plaats van alle events in een document ready te plaatsen kan ik nu dit doen:
register_startup(function(){
$("#test_button").click(function(){
alert("clicked!");
});
});
Gewijzigd op 06/07/2012 17:27:04 door Erwin H
.ready() is niets anders dan een functie die test of het laden van voorgaande variabele klaar is. Hier dus of het document geladen is.
Wanneer je meerdere van dit soort testen hebt, zal elke keer de hele pagina worden aangevraagd en opgeslagen, en er wordt een functie uitgevoerd. Dat kost gewoon geheugen. Dat kun je optimaliseren door $(document) op te slaan in een variabele, en daar die ready() method op uit te voeren. Dat kost alsnog meer geheugen dan eenmalig, maar minder dan niet cashen, zoals dat heet.
PS. ik denk dat je bedoelt cachen trouwens, cashen is wat ik later met mijn website wil gaan doen :-D
zo weet je zeker dat hele pagina geladen is alvoren je JS in werking gaat en hoef je geen .Ready te gebruiken
en ik vind ook dat je ongeacht hoeveel snelheid je ermee bespaart je dit altijd moet doen.
De callbacks die je in de ready functie meegeeft (let op de jQuery.fn.ready functie) worden opgeslagen in jQuery.readyList (dit is een jQuery.Deferred object). Deze readyList wordt vervolgens geretourneerd en aangeroepen. Dan zal jQuery.Deferred deze lijst afgaan en de callbacks aanroepen.
Het lijkt er dus niet op dat dit enige tijdverlies is, behalve dan dat je een loop nodig hebt die door alle callbacks moet gaan.
PS: Video's die je wel leuk gaat vinden: http://www.youtube.com/watch?v=i_qE1iAmjFg en http://www.youtube.com/watch?v=ARnp9Y8xgR4 (in 1 van die 2 wordt ook over ready gesproken)
Gewijzigd op 06/07/2012 17:51:44 door Wouter J
Reshad F op 06/07/2012 17:49:51:
en ik vind ook dat je ongeacht hoeveel snelheid je ermee bespaart je dit altijd moet doen.
Kan je hier ook de nadelen van opsommen? Pas dan kan je zo'n absolute waarheid verkondigen.
Tevens is het argument van Jeroen niet echt waar. Dat $(document) dat ervoor staat is omdat je in jQuery eenmaal een element moet meegeven in de constructor. Ik zie in de code in elk geval nergens terug dat dat element gebruikt wordt. Tevens heeft jQuery ook een shorthand versie (die ik altijd gebruik):
Code (php)
1
2
3
2
3
$(function() {
// ...
});
// ...
});
Daar wordt dus helemaal geen element in gebruikt.
Als laatst, mocht het element toch gebruikt worden, is het gewoon een referentie naar de document variabele. Het hoeft dus niet te gaan zoeken in de DOM, maar slaat gewoon een referentie van een van de hoofd objecten in JS op in een eigen variabele. Dit zal een verwaarloosbare traagheid opleveren.
Wouter J op 06/07/2012 18:28:45:
Tevens is het argument van Jeroen niet echt waar. Dat $(document) dat ervoor staat is omdat je in jQuery eenmaal een element moet meegeven in de constructor. Ik zie in de code in elk geval nergens terug dat dat element gebruikt wordt. Tevens heeft jQuery ook een shorthand versie (die ik altijd gebruik):
Daar wordt dus helemaal geen element in gebruikt.
Code (php)
1
2
3
2
3
$(function() {
// ...
});
// ...
});
Daar wordt dus helemaal geen element in gebruikt.
wat jij daar hebt is een SIAF (self invoking anonymous function), toch? dat heeft toch helemaal niets te maken met jQuery.fm.ready()? jQuery.fn.ready() is niets anders dan een functie die bekijkt of voorgaand element klaar is. met wat? ligt er maar net aan. een SIAF voert zichzelf uit wanneer die de kans krijgt, en dat is vrijwel altijd wanneer de pagina klaar is met laden, maar bekijkt totaal niet of de pagina al klaar is.
of heb ik het nu mis?
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
(function() {
})();
// of
!function() {
}();
// of
(function() {
}());
})();
// of
!function() {
}();
// of
(function() {
}());
Dit is:
Code (php)
1
2
2
$(function() {
});
});
Dat is dus een jQuery constructor: $() met daarin een callback function() { ... }
Het verhaal over wat de IFFI doet is wel waar.
Erwin, ja. Ik denk dat het enige tijdverschil zit in de loop.
Reshad F op 06/07/2012 17:49:51:
en ik vind ook dat je ongeacht hoeveel snelheid je ermee bespaart je dit altijd moet doen.
Kan je hier ook de nadelen van opsommen? Pas dan kan je zo'n absolute waarheid verkondigen.
[/quote]
Erwin. een groot voordeel naar mijn mening om je javascript onderop te plaatsen zijn
- je geeft de prioriteit aan de HTTP request en niet aan de logica waardoor laden sneller gaat en de gebruiker eerder een pagina ziet. ( we weten allemaal hoe irritant een trage pagina is)
- je weet 100% zeker dat de DOM al geladen is alvoren je JS aan het werk gaat.
echte nadelen weet ik niet en ben ik ook niet echt tegengekomen tot nu toe. ik heb er even naar gegoogled en heb niet echt veel nadelen gevonden maar als jij deze weet hoor ik het graag. :)