change .selector property into .selectors array

[cowboy]

I'm just throwing this out there, but based on questions I've received from people in the past and ticket #6754, I think it's potentially problematic for the .selector property to be a concatenated string of all previous selector strings / derived selectors, because people might think it's supposed to be a valid selector they can use to actually select elements.

In fact, other than for events, I don't see the value in the current .selector property's value, and even then, it's useless once any kind of complex traversing/filtering has taken place.

I propose that the .selector string property be changed to a .selectors array property, with the .selector property reflecting the last *actual* selector string used. For example:

var elems = $('div').children('p');

elems.selector // 'p'
elems.prevObject.selector // 'div'

elems.selectors // [ 'div', '.children(p)' ]
elems.prevObject.selectors // [ 'div' ]

This way, the array could just be joined if someone wants the old (current) behavior, but because it's an array it would allow a more robust programmatic after-the-fact selector parsing logic.

The .selectors array could even be an array of hashes, like so:

var elems = $('div').children('p');

elems.selector // 'p'
elems.prevObject.selector // 'div'

elems.selectors // [ { name: 'jQuery', selector: 'div' }, { name: 'children', selector: 'p' } ]
elems.prevObject.selectors // [ { name: 'jQuery', selector: 'div' } ]

Of course, at this point, since you already have the simple .selector property, you could forgo the array altogether and just add a .methodname property:

var elems = $('div').children('p');

elems.selector // 'p'
elems.prevObject.selector // 'div'

elems.methodname // 'children'
elems.prevObject.methodname // 'jQuery'

Either way, a non-string-property-approach might help avoid possible confusion from people who think that the .selector property is always a valid selector string they can use in a new selection, and might add some value to being able to better programmatically derive selectors from sequential complex/filtering operations.

[snover]

Other than avoiding any more confusion from people that ignore the documentation (which states “if DOM traversal methods have been called on the object, the string may not be a valid jQuery selector expression”), what sort of use cases are there for providing this?

[cowboy]

Benefits:

• a slightly smaller and simpler jQuery
• less end-user confusion (around both the .selector value and .live method behavior, or even the very simple but unexpected behavior in #6754)
• with the array of hashes / .methodname property approach, the traversal/filtering methods and selectors used could be programmatically derived without complex string parsing

[SlexAxton]

I think it's pretty fair to say that the current behavior doesn't make sense in a lot of common cases. In the case of just string concatenated dom traversal stuff, it's completely useless. I think, while this is largely unimportant since no one should be relying on the .selector property, that it couldn't hurt to consider it in a future build, just so we have something that can at least be consistent.

[dmethvin]

Hmmm, I didn't even think we documented .selector publicly, but why the heck are people trying to look at it? We know it doesn't survive complex traversal or filtering methods. Saying "don't touch that" in the docs saves us the code of trying to fix it and still falling short.

[cowboy]

The .selector property is  documented here and has been for quite some time, IIRC.

[john]

Let's look at this for 1.7.

[john]

Nominating ticket for 1.7 discussion.

[rwaldron]

-1, A huge burden that will require managing entries to the array... which means all existing methods would have to bear the addition of at least one function being added to their call stack. -9001

[jaubourg]

-1, sounds like a cheap and horrible way to construct selection... and a means to actually do terribly wrong things in general

[timmywil]

-1, might make selector more useful, but entirely unnecessary.

[dmethvin]

-1, Not a fan of .selector at all.

[john]

+1, I like this - it makes what we originally wanted to do with .selector actually possible (do all sorts of after-the-fact stack manipulation). This would be a very easy change given that we already handle all of this in pushStack.

[cowboy]

I'd encourage everyone to look at #9469 and then from there, continue discussion of the .selector property. I think combining the ideas from that ticket with this one might be the best approach.

[scott.gonzalez]

+0, no opinion, this is all internal, right?

[ajpiano]

-1, I like the idea of dropping this in #9469 and I definitely don't think we should spend our cycles working on getting this "right" if it's impossible.

[jzaefferer]

+0

[dmethvin]

Per the 1.7 vote this isn't going to be implemented.