Response title
This is preview!
Move this topic
Revert to old $.fn.add() behaviour, but provide a $.fn.sort()
Implemented
- Maybe later
- Under review
- In-progress
- Implemented
- Will not implement
in Developing jQuery Core
•
13 years ago
The backwards incompatible change to $.fn.add() in jQuery 1.4 is bugging me.
First of all, it's breaking some old code, and second of all it bugs me because I don't get *why* it was changed to return a source-order sorted collection.
Consider this bit of code:
In 1.3.2 and earlier `newElm == elm.prev()`, whereas as of version 1.4 `newElm == elm.parent()`.
Questions:
respectfully,
--
Már
First of all, it's breaking some old code, and second of all it bugs me because I don't get *why* it was changed to return a source-order sorted collection.
Consider this bit of code:
- var newElm = elm.prevAll().add( elm.parent() ).eq(0);
In 1.3.2 and earlier `newElm == elm.prev()`, whereas as of version 1.4 `newElm == elm.parent()`.
Questions:
- Could someone help me understand why this change to `.add()` was a) beneficial and b) neccessary?
- Wouldn't it make sense to add a `$.fn.sort()` method (or `$.fn.order()` if you will) to perform this action more generally?
- Would it be too late to revert `.add()` back to its old first-in-first-out behaviour, and save us all the trouble of patching/reworking our old code?
respectfully,
--
Már
1
Replies(26)
The reason this result changed was that .add() now ensures that the resulting set is in document order. Previously it just tacked the element on the end of the collection. For consistency I believe that all manipulation methods now return the set in document order, unless one was missed.
uhm... could you point out to me any other method that modifies the collection (i.e. `.pushStack`) and reorders the new collection?
`$.fn.slice()` doesn't reorder the returned collection.
Neither do `$.fn.filter()` nor `$.fn.not()`.
Not even the `jQuery()` method itself reorders the elements to pass into it (in an array).
Furthermore, there is a handful of methods that willfully return elements in reverse source order (e.g. `$.fn.prevAll`, `$.fn.prevUntil`, '$.fn.parents').
As far as I can tell, `.add()` is the only method that reorders a returned collection.
...and from where I'm standing, it's breaking existing code - pretty badly in places.
BTW, don't get me wrong, I think this feature of quickly sorting a collection by document-source order is pretty neat - It just seems odd that the only way to access it, is to `.add()` a redundant element to the collection.
IMO `$.fn.order()` should be made available, and then those who wish could use it every time they run `.add()`.
--
Már
`$.fn.slice()` doesn't reorder the returned collection.
Neither do `$.fn.filter()` nor `$.fn.not()`.
Not even the `jQuery()` method itself reorders the elements to pass into it (in an array).
Furthermore, there is a handful of methods that willfully return elements in reverse source order (e.g. `$.fn.prevAll`, `$.fn.prevUntil`, '$.fn.parents').
As far as I can tell, `.add()` is the only method that reorders a returned collection.
...and from where I'm standing, it's breaking existing code - pretty badly in places.
BTW, don't get me wrong, I think this feature of quickly sorting a collection by document-source order is pretty neat - It just seems odd that the only way to access it, is to `.add()` a redundant element to the collection.
IMO `$.fn.order()` should be made available, and then those who wish could use it every time they run `.add()`.
--
Már
Sure: prevAll, nextAll, parents, add, find -- all of these modify the jQuery set and are returned in document order (or in reversed document order), it is now consistent across all of these methods.
Having some methods return elements in a non-document-order based sorting is simply wrong and breaks the consistentcy of the API, hence why it's now been fixed.
Having some methods return elements in a non-document-order based sorting is simply wrong and breaks the consistentcy of the API, hence why it's now been fixed.
Leave a comment on dave.methvin's reply
John,
There's a subtle but very important difference between those methods.
In case of `prevAll`, `nextAll`, `parents` and `find`, they reach out and compile a new set of completely new elements that weren't part of the previous one. As a developer you feel like you're getting a whole new collection.
`add` is much more closely related to `slice`, `filter`, and `not` methods, in the way that they take an existing collection of elements and add/remove a few. As a developer you feel like you're still working with almost the same collection, only slightly modified.
(Similarly `jQuery(arrayOfElements)` does not sort the array before returning a collection.)
Since `slice`, `filter` and `not` (thankfully!) maintain the original order of elements in the collection, I argue that making `.add` do the same would be the most logical and least surprising thing to do.
Please, don't brush this idea off too quickly ... think about it for a bit.
Reverting back to the old `.add` behavior would arguably be much "cheaper" change than carrying on with this new backwards-incompatible behavior, and should make `.add` super-fast again.
And if there was a generic `$.fn.order` method, developers could simply choose to sort their collections whenever need - be they result of `add`, `slice`, `filter`, `not` or a direct call to `jQuery`.
--
Már
There's a subtle but very important difference between those methods.
In case of `prevAll`, `nextAll`, `parents` and `find`, they reach out and compile a new set of completely new elements that weren't part of the previous one. As a developer you feel like you're getting a whole new collection.
`add` is much more closely related to `slice`, `filter`, and `not` methods, in the way that they take an existing collection of elements and add/remove a few. As a developer you feel like you're still working with almost the same collection, only slightly modified.
(Similarly `jQuery(arrayOfElements)` does not sort the array before returning a collection.)
Since `slice`, `filter` and `not` (thankfully!) maintain the original order of elements in the collection, I argue that making `.add` do the same would be the most logical and least surprising thing to do.
Please, don't brush this idea off too quickly ... think about it for a bit.
Reverting back to the old `.add` behavior would arguably be much "cheaper" change than carrying on with this new backwards-incompatible behavior, and should make `.add` super-fast again.
And if there was a generic `$.fn.order` method, developers could simply choose to sort their collections whenever need - be they result of `add`, `slice`, `filter`, `not` or a direct call to `jQuery`.
--
Már
I guess it makes sense, if you look at `.add` as a counterpart to `$.fn.andSelf`, instead of counterpart to `Array.prototype.push` (which is the way it has always worked until now).
Would you perhaps consider then adding some `Array.prototype`-like methods to jQuery, say, `.splice`, `.reverse', `.sort`, `.push`, `.unshift`?
They would be easy to implement and would definitely prove very useful.
--
Már
Would you perhaps consider then adding some `Array.prototype`-like methods to jQuery, say, `.splice`, `.reverse', `.sort`, `.push`, `.unshift`?
They would be easy to implement and would definitely prove very useful.
--
Már
The problem with the array methods is that they're all destructive (which is the opposite of what jQuery does - it returns a completely new collection after every operation). Moving away from push-like behavior is a good thing since add doesn't behave like a push (or more accurately, concact).
In the examples I've seen of regressions concerning this the vast majority have been cases where something really inefficient has been done. The one legitimate case that I've seen was solved for 1.4.1 when we made it possible to do:
In the examples I've seen of regressions concerning this the vast majority have been cases where something really inefficient has been done. The one legitimate case that I've seen was solved for 1.4.1 when we made it possible to do:
- $("<div/>").add("div").appendTo("#foo");
- var newElm = elm.parent();
Leave a comment on mar.orlygsson's reply
of course my example was contrived, the point was that the same code returns different elements in 1.3.2 and 1.4 respectively.
Regarding the destructive nature of the native Array methods, that was why I said "-like" because they'd need to be reimplemented in a jQuery like fashion.
Actually I've found a weird behaviour in the 1.4.1 version of `.add`:
If `otherElm` has a `.parentNode` then `collection` is in source-order, else if `otherElm` is an orphan then `collection` is in reverse source-order.
Also consider this case:
Here `newCollection` will be in source order if, and only if, all the elements in the `firstCollection` have a `.parentNode`. Otherwise `newCollection` will be in the original order.
So in jQuery 1.4.1 `.add()` returns a sorted collection ... except when it doesn't. ;-)
This is confusing and difficult to work around, especially given the lack of explicit .sort()/.order() methods.
I can only assume this is something you'd like to fix.
...sometimes a little less magic is more.
--
Már
Regarding the destructive nature of the native Array methods, that was why I said "-like" because they'd need to be reimplemented in a jQuery like fashion.
Actually I've found a weird behaviour in the 1.4.1 version of `.add`:
- var collection = elm.prevAll().add( otherElm );
If `otherElm` has a `.parentNode` then `collection` is in source-order, else if `otherElm` is an orphan then `collection` is in reverse source-order.
Also consider this case:
- var firstCollection = $([ elmB, elmC, elmA ]);
- var newCollection = firstCollection.add( elmWithParent );
Here `newCollection` will be in source order if, and only if, all the elements in the `firstCollection` have a `.parentNode`. Otherwise `newCollection` will be in the original order.
So in jQuery 1.4.1 `.add()` returns a sorted collection ... except when it doesn't. ;-)
This is confusing and difficult to work around, especially given the lack of explicit .sort()/.order() methods.
I can only assume this is something you'd like to fix.
...sometimes a little less magic is more.
--
Már
The same applies, it seems, to `$.fn.andSelf()`.So in jQuery 1.4.1 `.add()` returns a sorted collection ... except when it doesn't.
--
Már
So to clarify on the behavior here: It's not possible to sort disconnected DOM nodes together with connected DOM nodes - they're in different DOM tress and will be, inherently, separated. Until the browsers work to provide a generic way for getting sorted lists of DOM nodes we have to make-do with a half-baked solution - and the solution is to simply pass when a disconnected node comes into the equation.
We could do even more pre-processing on the elements to enforce that they don't have any sort of disconnected DOM nodes mixed in (and if so, split them off into a separate collection that will be added in at the end). I was hesitant to land that in 1.4 because it would mean even more overhead for what is, decidedly, an edge case already.
I will continue to espouse that consistently making sure that the results of every jQuery collection are returned in document order is a good thing.
As it stands you've outlined three problems with the existing setup that should be resolved:
We could do even more pre-processing on the elements to enforce that they don't have any sort of disconnected DOM nodes mixed in (and if so, split them off into a separate collection that will be added in at the end). I was hesitant to land that in 1.4 because it would mean even more overhead for what is, decidedly, an edge case already.
I will continue to espouse that consistently making sure that the results of every jQuery collection are returned in document order is a good thing.
As it stands you've outlined three problems with the existing setup that should be resolved:
- jQuery(arrayOfElements) can be returned in not document order. Filed: http://dev.jquery.com/ticket/5992
- Calling .add() when there's a disconnected node won't attempt to sort any of the other nodes, even though there may be some mixed in (although, this will only happen in the case of .add(Element) or .add(arrayOfElements)). When the sort occurs it should go further and push all disconnected nodes to an end collection. Filed: http://dev.jquery.com/ticket/5993
- prevAll and parents currently return elements in reverse document order - this was done for convenience back in the day but should be brought inline with the style of the other jQuery methods. Filed: http://dev.jquery.com/ticket/5994
Changing prevAll and parents (#3 above) to return elements in document order seems counter-intuitive to me. It'll also break an enormous amount of code out there that uses .prevAll(':first') and .parents('first'). I'm all for API consistency, but I think user expectation should trump it.
I wouldn't want to assume that my expectations are representative of all (or even most) jQuery users', but maybe more investigation into how people actually think about and use these methods is warranted before making a change with such implications.
--Karl
I wouldn't want to assume that my expectations are representative of all (or even most) jQuery users', but maybe more investigation into how people actually think about and use these methods is warranted before making a change with such implications.
--Karl
.prevAll() and .parents() should remain to return in reverse order. I couldn't think about any need for parents() to be in document order.
Having said that, I got myself thinking, what would happen when you do whatever.prevall().appendTo(something). Am I right that this actually does something we wouldn't intuitively expect?
Try yourself:
- $('body').append('<div class="foo">1</div><div class="foo">2</div><div class="bar"></div>');
- $('.bar').prevAll('.foo').appendTo('body');
Wouldn't you expect them to be in the same order as before?
Same thoughts go for .prevUntil() and .parentsUntil(), of course.
So, it is still an open case, I suppose. I can't really give a very clear answer if I'm with John or Karl on this one.
Would love to hear some more thoughts.
-- Aivo --
Leave a comment on mar.orlygsson's reply
Actually, I'd prefer if jQuery didn't question my motives too much, thank you. :-)Good point about `jQuery(arrayOfElements)` not being sorted [...] that could definitely be something that we enforce.
Order of elements matters tremendously, and a lot of operations will become mindbogglingly difficult if all jQuery methods automatically sort every collection they return. (Let's not forget `.slice`, `.filter` and `.not`, shall we.)
I say, skip the overt auto-sorting of every returned element, because 9 times out of 10 the source order is either correct, intentionally "wrong", or doesn't matter. For the few cases where correct source-order is vitally important, let them perform an explicit `.sort()` and forget about it.
--
Már
I agree that it matters tremendously - which is why we should work to be perfectly consistent about the return results: They will always be returned in document order. This will serve us well as all DOM specifications require that returned sets of nodes are also returned in document order.
All the filter methods (like slick, filter, and not are already returned in document order - since they're only manipulating the results of sets that are already in document order).
All the filter methods (like slick, filter, and not are already returned in document order - since they're only manipulating the results of sets that are already in document order).
Már,
I believe you also need some kind of ordering maybe just different from the chosen one in jQuery !
I hardly believe you need them unordered however in that case you can always add a shuffle() method using sort() and random() ;-)
I believe you also need some kind of ordering maybe just different from the chosen one in jQuery !
I hardly believe you need them unordered however in that case you can always add a shuffle() method using sort() and random() ;-)
Leave a comment on mar.orlygsson's reply
I am getting really curious..
Which are the use cases where you so urgently need jQuery not to sort elements? Isn't it easier to use a plain array if you like to have so much control over things? As I understand, jQuery is meant to do things a lot easier for developers. And as I know, it 99% of the time does things A LOT easier.
Please, show how are you using jQuery so that you explicitly need to dictate its inner working. Without seeing a good example, I would like to say that you must be doing something wrong, or jQuery is not the right choice for your problem. Please, prove me wrong.
-- Aivo --
-- Aivo --
I agree with Aivo, having an actual example will help to quantify a problem better. Right now only theoreticals are being debated which makes it hard to take these concerns seriously. I say that a consistent API is more important than both implicit performance and explicit attempts at manipulation by the user.
This basic premise "every jquery collection should be returned in soure-order" may always have been obvious goal for the core jQuery design team, but I think it never was for us mere users.
What was a bug for you guys, was a feature for us (i.e. certain methods consistently return unsorted collections).
So while you are happily closing bugs (enforcing source-order on yet another method), some of us feel like the rules are being changed in mid-game.
Such is life.
...
I need to know one thing, to help me figure out ways to future-proof my existing code that relies on certain collections being unsorted:
Right now, if I `.detach()` all elements in a collection, jQuery won't attempt to sort them at all.
Can you promise that won't change some time in the future?
--
Már
What was a bug for you guys, was a feature for us (i.e. certain methods consistently return unsorted collections).
So while you are happily closing bugs (enforcing source-order on yet another method), some of us feel like the rules are being changed in mid-game.
Such is life.
...
I need to know one thing, to help me figure out ways to future-proof my existing code that relies on certain collections being unsorted:
Right now, if I `.detach()` all elements in a collection, jQuery won't attempt to sort them at all.
Can you promise that won't change some time in the future?
--
Már
If you detach everything in a collection then there's no need to sort anything - they're already in document order (or, more accurately, in no particular order since they're not in a document).
Leave a comment on aivopaas's reply
I think we have to distinguish methods like .add() from other more advanced features like jQuery(array) and jQuery.unique.
All methods shuld garanty document order, but jQuery(array) shuldn't.
It is clear that jQuery(array) is not there for beginners, but for "advanced users".
You certenly will not sort on jQuery(nodeList) becouse elements are already sorted. Also doing jQuery(array), elements are normally already sorted - sorting it twice is not nice.
PS: jQuery.unique sorts arrays in-place (without returning new array). You shuld correct documentation at http://api.jquery.com/jQuery.unique/ (also see comment at http://api.jquery.com/jQuery.merge/).
All methods shuld garanty document order, but jQuery(array) shuldn't.
It is clear that jQuery(array) is not there for beginners, but for "advanced users".
You certenly will not sort on jQuery(nodeList) becouse elements are already sorted. Also doing jQuery(array), elements are normally already sorted - sorting it twice is not nice.
PS: jQuery.unique sorts arrays in-place (without returning new array). You shuld correct documentation at http://api.jquery.com/jQuery.unique/ (also see comment at http://api.jquery.com/jQuery.merge/).
I've updated the .unique() docs to represent that.
I don't think we can guarantee that we won't sort jQuery(array) - I fully expect that it might be something that we would do in the future.
I don't think we can guarantee that we won't sort jQuery(array) - I fully expect that it might be something that we would do in the future.
Leave a comment on rkatic's reply
Array.prototype.sort and Array.prototype.slice are exposed right on every jQuery object, so the idea that there ISN'T a .sort and one ought to be added is somewhat misleading/wrong. Furthermore, I'm not sure what made the *old* sort order anything other than arbitrary, so relying on the order things were returned in 1.3.2 as representative of something at all doesn't quite make sense to me.
Actually, if you read the souce, you'll see that the `Array.prototype` methods are explicitly marked "for internal use only". This means they're not part of the public API and could be changed/removed at a moments notice.
If we view every part of a javascript library with suspicion like that, we wouldn't get much done at all. :-)
jQuery is a beautifully designed library, developed to be used by hundreds of thousands of developers - so backwards compatibility is a huge thing for a library like that, and should be assumed by default.
I only assumed wrong in this particular case.
--
Már
If we go down this philosophical route, pretty much everything is aribtrary and shouldn't be relied on.I'm not sure what made the *old* sort order anything other than arbitrary,
If we view every part of a javascript library with suspicion like that, we wouldn't get much done at all. :-)
jQuery is a beautifully designed library, developed to be used by hundreds of thousands of developers - so backwards compatibility is a huge thing for a library like that, and should be assumed by default.
I only assumed wrong in this particular case.
--
Már
Leave a comment on ajpiano's reply
The old way of add not returning in document order was a real PITA. For example, if you were wanted to combine an element and its siblings into one set
- $("#someTableRow td:nth-child(5)").siblings().andSelf()
using .index(), :even, :odd, etc, became a pretty ugly scenario.
Actually, if you read the souce,
How do you think I knew they were there in the first place? :)
I think that expecting people to explicitly call some method if they want to order the elements in the set in document order is a pretty onerous burden to shift to EVERYONE just in the name of achieving backwards compatibility with something not that many people relied on in the first place.
a) You're talking about the `.andSelf()` method and I agree completely, It has always been a real pain.
b) I don't get it: If you read the source and new that the `Array.prototype` methods were marked for internal use only - why did you suggest I was wrong or misleading when I didn't bring them up? BTW, applying Array.sort to a jQuery collection will not sort it in source order, so I can't see how bringing them up would have been helpful at all.
But nit picking aside...
Asking whether enough people rely on .add() being unsorted to justify not changing it is a very valid question - and exactly the one I was trying to bring up. I think "yes", while others disagree.
John was kind enough to explain quite clearly his (past and future) goals for this sorting behaviour, in a way that helps me (and hopefully others) make the neccessary arrangements to prepare for future versions of jQuery.
I might personally have preferred jQuery to limit it's sorting magic to only a select few methods (`.andSelf()` included of course), and let the rest continue to be a little more plain and `Array`ish -- but if I can accomplish that same effect with a few extra .detach()es or .clone(true)s I'm happy enough.
--
Már
b) I don't get it: If you read the source and new that the `Array.prototype` methods were marked for internal use only - why did you suggest I was wrong or misleading when I didn't bring them up? BTW, applying Array.sort to a jQuery collection will not sort it in source order, so I can't see how bringing them up would have been helpful at all.
But nit picking aside...
Asking whether enough people rely on .add() being unsorted to justify not changing it is a very valid question - and exactly the one I was trying to bring up. I think "yes", while others disagree.
John was kind enough to explain quite clearly his (past and future) goals for this sorting behaviour, in a way that helps me (and hopefully others) make the neccessary arrangements to prepare for future versions of jQuery.
I might personally have preferred jQuery to limit it's sorting magic to only a select few methods (`.andSelf()` included of course), and let the rest continue to be a little more plain and `Array`ish -- but if I can accomplish that same effect with a few extra .detach()es or .clone(true)s I'm happy enough.
--
Már
Leave a comment on ajpiano's reply
jQuery is a beautifully designed library, developed to be used by hundreds of thousands of developers - so backwards compatibility is a huge thing for a library like that, and should be assumed by default.You think jQuery would still be so beautiful and useful if backwards compatibility was managed all time? Sometimes little things have to be broken to improve the overall quality.
-- Aivo --
Aivo, I don't understand where you're going with this question...
The fact that I dared question this one specific change to the jQuery API, doesn't automatically imply I'm against all such changes.
...or do you disagree with me that backwards-compatibility should be assumed to be "the default" way forwards - and breaking it should be the (informed and calculated) exception?
I think we must agree.
--
Már
The fact that I dared question this one specific change to the jQuery API, doesn't automatically imply I'm against all such changes.
...or do you disagree with me that backwards-compatibility should be assumed to be "the default" way forwards - and breaking it should be the (informed and calculated) exception?
I think we must agree.
--
Már
Leave a comment on aivopaas's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to mar.orlygsson's idea
{"z2944156":[14737000000675752],"z2877445":[14737000000681716],"z2566198":[14737000000676592,14737000000674912,14737000000676937,14737000000676939,14737000000676941,14737000000677471,14737000000680976],"z957804":[14737000000682348,14737000000681983],"z3030785":[14737000000679203,14737000000677179,14737000000687003],"z2950914":[14737000000675642,14737000000676568,14737000000676608,14737000000675957,14737000000677165,14737000000677173,14737000000677167,14737000000679053,14737000000681981,14737000000687403,14737000000687405],"z464496":[14737000000679201],"z-1":[14737000000681886]}