Pourquoi jQuery n'explose-t-il pas si votre objet sélecteur n'est pas valide ?

Question

J'ai récemment utilisé un code du type

$("#divMenuContainer:visible").hide("explode");

Cependant, après un certain temps passé à essayer de le faire fonctionner, j'ai réalisé que mon sélecteur faisait référence à une division qui n'existait pas.

Le résultat de la requête était simplement qu'elle ne s'exécutait pas.

Il est évident qu'il s'agit d'un choix délibéré. Quelqu'un pourrait-il expliquer la logique de ce choix plutôt que de soulever une sorte d'exception ?

Je ne cherche pas à critiquer, mais à comprendre.

Answer 1

Pensez-y comme un requête ce qui est le cas. Vous demandez tous les "enregistrements" (éléments du DOM) qui correspondent à vos critères. Le résultat est un ensemble de zéro enregistrement.

Il passe ensuite en boucle sur vos enregistrements zéro et leur applique l'action. :)

Si vous faisiez la même chose avec SQL, ou un tableau, cela se comporterait de la même manière dans la plupart des langages. Une collection d'enregistrements nuls n'est pas un état d'erreur.

var things = $("invalid selector");
$("p").text("The object is valid: " + things + " but has " + things.length + " elements.")

<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<p></p>

Answer 2

Il y a quelques bonnes raisons à cela, la "chaînabilité" est le moteur principal, la capacité d'écrire du code très laconique par chaînage ne doit pas produire d'erreurs pour fonctionner sans problème, par exemple :

$("#divMenuContainer:visible").hide("explode").add("#another").fadeIn();

Chaque objet de la chaîne, même s'il ne fait référence à aucun élément du DOM, peut en avoir d'autres ajoutés ultérieurement, ou prenons un autre exemple :

$("#divMenuContainer:visible").live("click", function() { ... });

Dans ce cas, nous ne nous soucions pas des éléments que le sélecteur a trouvés, mais du sélecteur lui-même. En voici un autre :

$("#divMenuContainer:visible").find(".child").hide("explode").end().fadeOut();

Même s'il n'y a pas d'enfants, nous pouvons vouloir revenir en arrière dans la chaîne par la suite, en continuant à utiliser l'élément .prevObject référence pour remonter la chaîne.

Il y a des dizaines de cas distincts comme celui-ci qui montrent les avantages de la bibliothèque telle qu'elle est. Quant à la pourquoi à partir d'interviews de John Resig qui est le créateur de jQuery, il déclare que c'est comme ça que ça s'est passé. Il cherchait un code aussi concis que possible, et le modèle de chaînage est ce qui en est ressorti. Il se trouve qu'il présente également de nombreux avantages, dont l'exemple ci-dessus.

Pour être clair, je ne dis pas chaque L'attribut de l'enchaînement est bon, il y a juste beaucoup d'avantages à cela.

---

Prenons cette page comme exemple, et si nous avions quelque chose comme ceci :

$(".comment").click(replyToFunction);

Devrait qui échoue parce qu'il n'y a pas encore de commentaires ? Eh bien non, pas vraiment, c'est prévu, je ne voudrais pas qu'une erreur se produise ici... si l'élément existe, faites-le, sinon, ne le faites pas. Ce que je veux dire, c'est que, du moins d'après mon expérience, no Lancer une erreur à cause d'un élément manquant est énormément plus utile que d'en lancer une.

Le sélecteur dans votre question, le #ID sélecteur est un cas très particulier où l'on ne s'attend qu'à un seul élément, donc on pourrait peut-être argumenter qu'il devrait échouer là... mais cela ne serait pas cohérent avec les autres sélecteurs, et on veut qu'une bibliothèque soit cohérente.

Avec à peu près n'importe quel autre sélecteur vous vous attendez à des éléments 0-many, donc échouer lorsque vous ne trouvez aucun élément serait nettement moins souhaitable dans la plupart des situations, et encore plus dans les cas tels que .live() ci-dessus.

Answer 3

C'est une question de flexibilité. Moi-même, j'aimerais les mêmes protections que vous demandez, vous pouvez toujours le faire vous-même. Utilisez :

jQuery.fn.single = function() {
    if (this.length != 1) {
        throw new Error("Expected 1 matching element, found " + this.length);
    }

    return this;
};

et utilisez maintenant $("input:checked").single() avec l'assurance qu'il renvoie un seul élément ou qu'il vous donne une erreur.

Answer 4

JQuery() retournera toujours un objet jQuery, d'une part pour éviter les erreurs, mais surtout :

Vous pouvez donc écrire du code réactif.

do X if Y is present

Si Y n'est pas présent, X n'est pas calculé.

Cela signifie que vous pouvez avoir un init global pour toutes les pages et juste init pour les plugins, qu'ils trouvent quelque chose ou pas.

$(function(){
    // does nothing if the page contains no element with className 'accordion'
    $('.accordion').implementAccordion();
    // usually on a single page, but we can add it to a global js file nontheless.
    $('.validate-form').implementFormValidator();
});

Mais bien sûr, certains plugins sont très mal écrits et provoquent une erreur.

Answer 5

Cela fait partie de la philosophie de jQuerys (en fait John Resigs, je suppose) concernant la bibliothèque.

Il essaie d'être "gentil" avec vous et vos clients, ce qui signifie qu'il ne fait que rarement des exceptions.
(comme très rarement)

Mais comme toujours, vous pouvez facilement l'étendre :

(function(_jQuery){
    jQuery = function(){
        var ret = _jQuery.apply(this, arguments);
        if(!ret.length) throw new Error('empty selector');
        return ret;
    };
}(jQuery));

Mais comme Nick dit dans un commentaire, la plupart du temps c'est no un comportement souhaité. Si vous voulez quand même l'avoir pour une raison quelconque, un extrait de code comme celui ci-dessus devrait le faire.