javascript - body - jquery ready vs load

¿Por qué no se recomienda "$(). Ready(handler)"?

Question

Desde el sitio de documentos de jQuery API para ready

Las tres sintaxis siguientes son equivalentes:

• $ (documento) .ready (controlador)
• $ (). ready (controlador) (esto no se recomienda)
• $ (manejador)

Después de hacer la tarea, leer y jugar con el código fuente , no tengo idea de por qué

$().ready(handler)

no es recomendado. La primera y la tercera formas son exactamente iguales, la tercera opción llama a la función lista en un objeto jQuery almacenado en caché con el document :

rootjQuery = jQuery(document);
...
...
// HANDLE: $(function)
// Shortcut for document ready
} else if ( jQuery.isFunction( selector ) ) {
return rootjQuery.ready( selector );
}

Pero la función lista no tiene interacción con el selector de los elementos del nodo seleccionado, El código fuente ready :

ready: function( fn ) {
// Attach the listeners
jQuery.bindReady();
// Add the callback
readyList.add( fn );
return this;
},

Como puede ver, solo agrega la devolución de llamada a una cola interna ( readyList ) y no cambia ni usa los elementos en el conjunto. Esto le permite llamar a la función ready en cada objeto jQuery.

Me gusta:

• selector regular : $(''a'').ready(handler) DEMO
• Selector de tonterías : $(''fdhjhjkdafdsjkjriohfjdnfj'').ready(handler) DEMO
• Selector no definido : $().ready(handler) DEMO

Finalmente ... a mi pregunta: ¿Por qué no se recomienda $().ready(handler) ?

Answer 1

Creo que esto es más para legibilidad que otra cosa.

Este no es tan expresivo

$().ready(handler);

como

$(document).ready(handler)

Tal vez están tratando de promover alguna forma de jQuery idiomática.

Answer 2

Dado que las diferentes opciones hacen casi lo mismo que usted señala, es hora de ponerse el sombrero de escritor de la biblioteca y hacer algunas conjeturas.

1. Quizás las personas de jQuery deseen tener $() disponible para uso futuro (dudoso ya que $().ready está documentado para funcionar, incluso si no se recomienda, sino que también contaminaría la semántica de $ if special-cased).

2. Una razón mucho más práctica: la segunda versión es la única que no termina envolviendo el document , por lo que es más fácil romperla cuando se mantiene el código. Ejemplo:

   // BEFORE
   $(document).ready(foo);
   // AFTER: works
   $(document).ready(foo).on("click", "a", function() {});

   Contraste esto con

   // BEFORE
   $().ready(foo);
   // AFTER: breaks
   $().ready(foo).on("click", "a", function() {});

3. Relacionado con lo anterior: ready es un bicho raro en el sentido de que es (¿el único?) Método que funcionará igual sin importar lo que el objeto jQuery ajuste (incluso si no ajusta nada como es el caso aquí). Esta es una diferencia importante con respecto a la semántica de otros métodos de jQuery, por lo que confiar en esto específicamente es desaconsejado.

   Actualización: Como señala el comentario de Esailija, desde una perspectiva de ingeniería, realmente debería ser un método estático exactamente porque funciona así.

Actualización n. ° 2: al cavar en la fuente, parece que en algún punto de la rama 1.4 $() se cambió para que coincida con $([]) , mientras que en 1.3 se comportó como $(document) . Este cambio reforzaría las justificaciones anteriores.

Answer 3

Diría que es simplemente el hecho de que $() devuelve un objeto vacío, mientras que $(document) no lo hace, por lo que su aplicación ready() aplica a cosas diferentes; todavía funciona, pero yo diría que no es intuitivo.

$(document).ready(function(){}).prop("title") // the title
$().ready(function(){}).prop("title") //null - no backing document

Answer 4

Es muy probable que esto sea solo un error de documentación y deba corregirse, el único inconveniente de usar $().ready(handler) es su legibilidad. Claro, argumenta que $(handler) es igual de ilegible. Estoy de acuerdo, es por eso que no lo uso .

También puede argumentar que un método es más rápido que otro. Sin embargo, ¿con qué frecuencia llama a este método bastantes veces seguidas en una sola página para notar una diferencia?

En definitiva, se trata de preferencia personal. No hay inconveniente en usar $().ready(handler) no sea el argumento de legibilidad. Creo que la documentación no es líder en este caso.

Answer 5

Simplemente para que quede claramente obvio que hay una cierta incoherencia en los tres, además, agregué la cuarta forma que se usa con frecuencia: (function($) {}(jQuery));

Con este marcado:

<div >one</div>
<div>two</div>
<div id=''t''/>

y este código:

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

Los resultados mostrados del div de la última instrucción son: 0: 9: 9: 9: indefinido

ASÍ, solo las versiones de Handler y Doc son consistentes con la convención de jQuery de devolver algo de uso, ya que obtienen el selector de documentos y con el formulario Passed debes devolver algo (no haría esto, pensaría, pero póngalo solo para mostrar "adentro" tiene algo).

Aquí hay una versión fiddle de esto para los curiosos: http://jsfiddle.net/az85G/

Answer 6

Recibí una respuesta oficial de uno de los desarrolladores de jQuery:

$().ready(fn) solo funciona porque $() solía ser un acceso directo a $(document) _{(jQuery <1.4)}
Entonces $().ready(fn) era un código legible.

Pero la gente solía hacer cosas como $().mouseover() y todo tipo de otras locuras.
y la gente tenía que hacer $([]) para obtener un objeto jQuery vacío

Entonces en 1.4 lo cambiamos así que $() da un jQuery vacío y acabamos de hacer que $().ready(fn) funcione para no romper un montón de código

$().ready(fn) literalmente ahora está parcheado en el núcleo para que funcione correctamente para el caso heredado.

El mejor lugar para la función de ready es $.ready(fn) , pero es una decisión de diseño realmente antigua y eso es lo que tenemos ahora.

Le pregunté:

¿Crees que $ (fn) es más legible que $ (). Ready (fn)?

Su respuesta fue:

Siempre hago $ (document) .ready (fn) en aplicaciones reales y generalmente solo hay un bloque de doc ready en la aplicación, no es exactamente como algo de mantenimiento.

Creo que $ (fn) es bastante ilegible también , es solo una cosa que debes saber Works ™ ...