API 设计和 jQuery [英] API design and jQuery

问题描述

我经常听说 jQuery 做出了一些糟糕的 API 决策.虽然 jQuery 不是我最喜欢的库，但它是我最常使用的库，我发现很难指出 API 设计中的具体错误或如何改进它.

I have often heard that jQuery has made some poor API decisions. Although jQuery is not my favourite library it's the library I've used most often and I find it hard to point out specific mistakes in the API design or how it could have been improved.

jQuery API 的哪些部分可以做得更好，如何实现不同，为什么不同的实现会更好?

What parts of jQuery's API could have been done better, how could it have been implemented different and why would that different implementation be better?

问题扩展到 API 的低级个人详细信息和 API 的高级详细信息.我们只讨论 API 中的缺陷，而不是库的高级设计/目的中的缺陷，jQuery 仍然是一个以选择器引擎为中心的 DOM 操作库.

The question extends to both low level individual details of the API and high level details of the API. We are only talking about flaws in the API rather then flaws in the high level design / purpose of the library, jQuery is still a DOM manipulation library centred around a selector engine.

由于流行库中 API 冻结的必要性，jQuery 停留在当前状态，开发人员做得很好.从最近的 .attr 与 .prop 变化可以看出，开发人员没有灵活性来改变他们的任何设计决策(这是一种耻辱！).

Because of the necessity of API freezing in popular libraries, jQuery is stuck in it's current state and the developers are doing a great job. As can be seen by the recent .attr vs .prop change the developers do not have the flexibility to change any of their design decisions (which is a shame!).

我能想到的一个具体例子是

One specific example I can think of would be

$.each(function(key, val) { })

对比

$.grep(function(val, key) { })

这太令人困惑了，我必须经常仔细检查参数是什么.

which is confusing enough that I have to double check what the parameters are frequently.

请不要将 jQuery 库与成熟的框架(如 dojo 和 YUI)进行比较，并抱怨缺乏功能.

Please do not compare the jQuery library to full fledged frameworks like dojo and YUI and complain about lack of features.

推荐答案

• .load() 根据传递的参数重载完全不同的行为

  • .load() is overloaded with entirely different behavior depending on the arguments passed

    .toggle() 根据传递的参数重载完全不同的行为

    .toggle() is overloaded with entirely different behavior depending on the arguments passed

    可能是 jQuery() 函数的过多重载.

    too much overloading of the jQuery() function perhaps.

    你提到的.attr().与财产的区别应该是直接的 IMO.

    the .attr() you mentioned. The distinction from properties should have been immediate IMO.

    .map( key,val ) 但是$.map( val,key )，和this的值不同.

    非标准选择器应该被排除在 Sizzle IMO 之外.基于 Javascript 的选择器引擎应该会在多年后过时，而迷恋专有选择器的人将面临更困难的过渡

    non-standard selectors ought to have been kept out of Sizzle IMO. Javascript based selector engines should become obsolete in a number of years, and people hooked on the proprietary selectors will have a more difficult transition

    .closest() 或 .live() 等方法的方法命名不佳.他们究竟是做什么的?

    poor method naming of methods like .closest() or .live(). What exactly do they do?

    我最近发现在创建新文件时无法通过 props 参数设置标准的 width 和 height 属性元素.jQuery 运行它自己的 width 和 height 方法.IMO，应该优先考虑规范属性，特别是因为 width 和 height 可以通过 css 设置.

    I recently discovered that you can't set the standard width and height attributes via the props argument when creating a new element. jQuery runs its own width and height methods instead. IMO, the spec attributes should have been given priority, especially since width and height can be set via css.

    $('<img/>', { 
        css:{width:100, height:100},
        width:100, // <-- calls method, why?
        height:100, // <-- calls method, why?
    });
    

    • $.get() 和 .get() 完全不同.

      .get() 和 .toArray() 在不传递参数时是相同的

      .get() and .toArray() are identical when passing no arguments

      toArray() 和 $.makeArray() 有效地做同样的事情.为什么他们不给它们起与 .each() 和 $.each() 相同的名字?

      toArray() and $.makeArray() do effectively the same thing. Why didn't they give them the same name like .each() and $.each()?

      两种不同的事件委托方法..delegate() 是明智的，而 .live() 是神奇的 哇，它真的有效！" 一个.

      two different event delegation methods. .delegate() the sensible one, and .live() the magical "wow, it just works!" one.

      .index() 重载了 3 种行为，但它们的差异可能令人困惑

      .index() is overloaded with 3 behaviors, but their differences can be confusing

       // v---get index   v---from collection (siblings is implied)
      $('selector').index();
       // v---from collection   v---get index
      $('selector').index(element);
       // v---get index      v---from collection
      $('selector').index('selector');
      

      第一个是可以理解的，如果你记得它只对第一个元素进行操作

      The first one is understandable if you remember that it only operates on the first element

      第二个最有意义，因为 jQuery 方法通常对整个集合进行操作.

      The second one makes the most sense since jQuery methods usually operate on an entire collection.

      第三个完全令人困惑.该方法没有指明哪个选择器是集合，哪个选择器代表您希望从集合中获取其索引的元素.

      The third one is entirely confusing. The method gives no indication of which selector is the collection and which selector represents the element whose index you want from the collection.

      为什么不干脆去掉第三个，让人们像这样使用第二个:

      Why not just eliminate the third one, and have people use the second one like this:

       // v---from collection      v---get index
      $('selector').index( $('selector') );
      

      通过这种方式，它更接近于 jQuery 的其余部分，其中 .index() 对整个集合进行操作.

      This way it fits more closely with the rest of jQuery where .index() operates on the entire collection.

      或者至少颠倒选择器的含义以更好地适应:

      Or at least reverse the meaning of the selectors to fit in better:

       // v---from collection   v---get index
      $('selector').index('selector');
      

      <小时>

      无论如何，这是另一个需要考虑的问题.

      ---

      Here's another to think about anyway.

      我对 jQuery 的事件处理/数据存储系统有些担忧.它之所以受到称赞，是因为它没有向 on[event] 属性添加可以关闭其他元素的函数，从而在 IE 中造成内存泄漏.相反，它放置了一个轻量级的 expando 属性，该属性映射到 jQuery.cache 中的一个条目，该条目保存处理程序和其他数据.

      I have some concerns with jQuery's event handling/data storage system. It is praised because it doesn't add functions to on[event] properties that can close around other elements, creating memory leaks in IE. Instead it places a lightweight expando property, which maps to an entry in jQuery.cache, which holds handlers and other data.

      我相信它会附加一个处理程序，并依次调用您分配的处理程序.或者类似的东西.

      I believe it then attaches a handler with in turn invokes the handler that you assigned. Or something like that.

      无论系统是什么都无关紧要.关键是元素和jQuery.cache 之间的连接就是expando.

      Whatever the system is doesn't really matter. The point is that the connection between the element(s) and the jQuery.cache is that expando.

      这有什么大不了的?从哲学上讲，jQuery 不是一个框架；这是一个图书馆.看起来，作为一个库，您应该能够使用或不使用 jQuery 函数而不必担心负面影响.然而，如果您在从 DOM 中删除元素时脱离了 jQuery，您就会通过 expando 孤立与这些元素相关的任何处理程序和其他数据，从而造成良好且完全跨浏览器的内存泄漏.

      Why is that a big deal? Well philosophically jQuery is not a framework; it is a library. It would seem that as a library you should be able to use or not use the jQuery functions without concern for negative effects. Yet if you go outside jQuery when removing elements from the DOM, you've orphaned any handlers and other data associated with those elements via the expando, creating a nice and fully cross-browser memory leak.

      例如，像 el.innerHTML = '' 这样简单的东西可能非常危险.

      So for example, something as simple as el.innerHTML = '' could be very dangerous.

      将其与 jQuery.noConflict() 功能结合起来.这使开发人员能够将 jQuery 与其他利用 $ 全局命名空间的库一起使用.那么，如果这些库之一删除了一些元素怎么办?同样的问题.我有一种感觉，需要在 jQuery 旁边使用像 Prototypejs 这样的库的开发人员可能不知道足够的 JavaScript 来做出好的设计决策，并且会遇到像我这样的问题描述.

      Couple this with the jQuery.noConflict() feature. This enables developers to use jQuery with other libraries that utilize the $ global namespace. Well what if one of those libraries deletes some elements? Same problem. I have a feeling that the developer that needs to use a library like Prototypejs along side jQuery probably doesn't know enough JavaScript to make good design decisions, and will be subject to such a problem as I've described.

      就图书馆预期哲学的改进而言，据我所知，他们的哲学是多做，少写"之类的.我认为他们很好地做到了这一点.您可以编写一些非常简洁但富有表现力的代码来完成大量工作.

      In terms of improvements within the intended philosophy of the library, as far as I know, their philosophy is "Do more, write less" or something. I think they accomplish that very well. You can write some very concise yet expressive code that will do an enormous amount of work.

      虽然这很好，但在某种程度上我认为它是负面的.你可以做这么多，那么容易，初学者很容易写出一些非常糟糕的代码.我认为如果有一个开发人员构建"记录滥用库的警告，那就太好了.

      While this is very good, in a way I think of it as something of a negative. You can do so much, so easily, it is very easy for beginners to write some very bad code. It would be good I think if there was a "developer build" that logged warnings of misuse of the library.

      一个常见的例子是在循环中运行选择器.DOM 选择很容易做到，看起来你每次需要一个元素时都可以运行一个选择器，即使你只是运行了那个选择器.我认为一个改进是 jQuery() 函数记录选择器的重复使用，并给出一个控制台注释，选择器可以被缓存.

      A common example is running a selector in a loop. DOM selection is very easy to do, that it seems like you can just run a selector every time you need an element, even if you just ran that selector. An improvement I think would be for the jQuery() function to log repeated uses of a selector, and give a console note that a selector can be cached.

      因为 jQuery 如此占主导地位，我认为如果它们不仅使成为 JavaScript/DOM 程序员变得容易，而且还帮助您成为更好的程序员，那就太好了.

      Because jQuery is so dominant, I think it would be good if they not only made it easy to be a JavaScript/DOM programmer, but also helped you be a better one.

      这篇关于API 设计和 jQuery的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！