RESOLVED FIXED 42758
Web Inspector: consider jQuery object to be of 'array' nature.
https://bugs.webkit.org/show_bug.cgi?id=42758
Summary Web Inspector: consider jQuery object to be of 'array' nature.
Pavel Feldman
Reported 2010-07-21 09:05:59 PDT
- Go to the specified url - Open console - See a bunch of "> Object" entries there. Do similar with Firebug+FireQuery, see nice output there. Considering jQuery object an array we get pretty much same results. I think jQuery is big enough to do it for them.
Attachments
[PATCH] Proposed change. (1.11 KB, patch)
2010-07-21 09:08 PDT, Pavel Feldman
no flags
[IMAGE] Firebug looks (59.90 KB, image/png)
2010-07-21 09:12 PDT, Pavel Feldman
no flags
[IMAGE] Web Inspector today. (82.86 KB, image/png)
2010-07-21 09:13 PDT, Pavel Feldman
no flags
[IMAGE] Web Inspector with patch applied. (110.56 KB, image/png)
2010-07-21 09:13 PDT, Pavel Feldman
no flags
Pavel Feldman
Comment 1 2010-07-21 09:08:22 PDT
Created attachment 62189 [details] [PATCH] Proposed change.
Pavel Feldman
Comment 2 2010-07-21 09:12:58 PDT
Created attachment 62190 [details] [IMAGE] Firebug looks
Pavel Feldman
Comment 3 2010-07-21 09:13:27 PDT
Created attachment 62191 [details] [IMAGE] Web Inspector today.
Pavel Feldman
Comment 4 2010-07-21 09:13:53 PDT
Created attachment 62192 [details] [IMAGE] Web Inspector with patch applied.
Joseph Pecoraro
Comment 5 2010-07-21 10:14:43 PDT
This sounds like what bug 30974 was opened for: https://bugs.webkit.org/show_bug.cgi?id=30974 Any new comments on that?
WebKit Commit Bot
Comment 6 2010-07-21 10:26:36 PDT
Comment on attachment 62189 [details] [PATCH] Proposed change. Clearing flags on attachment: 62189 Committed r63837: <http://trac.webkit.org/changeset/63837>
WebKit Commit Bot
Comment 7 2010-07-21 10:26:41 PDT
All reviewed patches have been landed. Closing bug.
John-David Dalton
Comment 8 2010-08-12 14:14:27 PDT
Why is a browser giving special treatment to a specific JS lib? Why not extend the same functionality to any array-like object say that has a `length` property and `index` properties? Maybe the devs using console.log() were just doing it wrong as: [].slice.call($('div')) would produce an output like an array without a lib specific patch.
kangax
Comment 9 2010-08-12 14:20:29 PDT
I'll second John-David. It would make more sense to extend this functionality for any array-like object. This will display similar array-like abstractions from other libraries in similar, descriptive way. It would also make sense to indicate that an object is not a real array (where "real array" could be considered, for example, anything with [[Class]] of "Array"). Perhaps prepend returning value with "ArrayLike: " or something along those lines.
Kyle Simpson
Comment 10 2010-08-12 14:26:04 PDT
i concur with dalton and kangax. it's a bad pattern to specifically tie features to one lib and not the others.
Angus Croll
Comment 11 2010-08-12 14:29:12 PDT
Agree with previous 3. Basing logic on knowledge of 3rd party library objects is analogous to browser sniffing. Just check for length etc. regardless of type
Guillermo Rauch
Comment 12 2010-08-12 14:31:26 PDT
Agree with previous comments.
Mathias Bynens
Comment 13 2010-08-12 14:32:49 PDT
I agree with comments #8 and up. Why tie features to specific libraries when it can just as easily be done for all of them, as John-David Dalton proposed: > Why not extend the same functionality to any array-like object say that has `length` and `index` properties?
Nick Carter
Comment 14 2010-08-12 14:33:32 PDT
Definitely think if this functionality is going to be available to jQuery it should be available to everything, and if we can apply it to all array-likes that'd be great! Just need to be sure it's presented clearly enough that it's NOT an array.
Pavel Feldman
Comment 15 2010-08-12 14:35:47 PDT
I agree that "tie features to one lib and not the others" is a bad pattern, we've just had too many requests for this specific one. I am sure many users will benefit from this suboptimal solution. While we are thinking about a more generic one, could we get the use cases where other libraries would benefit from the array-alike output as well? It is just that 'length + index' requirement seems to be to loose, so we might add more.
Mike Taylor
Comment 16 2010-08-12 14:39:31 PDT
+1 for adding this capability for all array-like objects, agnostic of library.
John-David Dalton
Comment 17 2010-08-12 14:44:33 PDT
MooTools 1.3beta, MooTools' next release, returns an array-like object for its DOM query method. http://dl.dropbox.com/u/513327/log_array_like.html Note that in Firebug it displays like an array because it is array-like.
kangax
Comment 18 2010-08-12 14:50:44 PDT
(In reply to comment #15) > I agree that "tie features to one lib and not the others" is a bad pattern, we've just had too many requests for this specific one. I am sure many users will benefit from this suboptimal solution. While we are thinking about a more generic one, could we get the use cases where other libraries would benefit from the array-alike output as well? It is just that 'length + index' requirement seems to be to loose, so we might add more. Well, detecting length + index properties would cover: 1) real arrays 2) nodelists (already displayed as arrays) 5) arguments object 3) jquery objects 4) any other array-like abstractions from other scripts/libraries I could see how this could be "too loose", which is why some kind of indication of array-like nature of an object seems reasonable here (e.g.: #Arguments: ['foo', 'bar', 'baz'], #ArrayLike: ['foo', 'bar', 'baz'], etc.)
Ryan Grove
Comment 19 2010-08-12 14:56:19 PDT
(In reply to comment #15) > It is just that 'length + index' requirement seems to be to loose, so we might add more. I agree with kangax that it seems reasonable to assume that an object with both "length" and "index" properties wants to be treated as an array-like object, or at least that it would not be surprising for such an object to be treated as array-like (as long as the distinction between "array" and "array-like" is clear). This also provides a simple convention for library developers. Want your object to be considered array-like? Give it "length" and "index" properties. Don't want that? Call them "size" and "indexOf" (or something else) instead.
Kit Cambridge
Comment 20 2010-08-12 14:58:41 PDT
I agree with all of the above comments as well; however, I think that checking for the existence of the `length` property is not enough, as an object like `{"title": "Commentaries", "length": 25, "content": [...]}` would be incorrectly represented as an array. A more robust (though certainly not foolproof) check might be `(obj.length === obj.length >>> 0) && "0" in obj`, or even iterating over the object's properties until a numeric one is encountered. I also like kangax's proposal for a separate representation for array-like objects, maybe something akin to `<List: [...]>`. I would, however, also like to propose using that representation for NodeLists and HTMLCollections as well, reserving `[...]` for arrays only.
Timothy Hatcher
Comment 21 2010-08-12 15:05:56 PDT
Looking from "0" in obj would not work for sparse arrays.
Kit Cambridge
Comment 22 2010-08-12 15:16:32 PDT
(In reply to comment #21) > Looking from "0" in obj would not work for sparse arrays. Good point. The alternative method I mentioned above (looping over the object's properties using a `for..in` loop, breaking as soon as a numeric key is encountered) should be more effective in that regard, although performance might be an issue.
Kyle Simpson
Comment 23 2010-08-12 15:18:12 PDT
for-in loops have *vastly* worse performance. http://jsperf.com/for-loop-vs-for-in-loop
Joseph Pecoraro
Comment 24 2010-08-12 15:19:14 PDT
Hey Guys! Thanks for the comments. As I mentioned in comment #5, we opened a bug for this already, and had some discussion on it. I'd recommend the discussion move over to that bug if possible. I'll duplicate this comment on that bug as well: <http://webkit.org/b/30974> Web Inspector: Pretty print array-like objects (In reply to comment #20) > A more robust (though certainly not foolproof) check might be `(obj.length === > obj.length >>> 0) && "0" in obj`, or even iterating over the object's properties > until a numeric one is encountered. I think this check is pretty sufficient. > I also like kangax's proposal for a separate representation for array-like > objects, maybe something akin to `<List: [...]>`. I would, however, also like > to propose using that representation for NodeLists and HTMLCollections as well, > reserving `[...]` for arrays only. I also like this idea. Currently we treat NodeLists and Collections as arrays, and I think they deserve some differentiation. http://trac.webkit.org/browser/trunk/WebCore/inspector/front-end/InjectedScript.js > if (obj instanceof inspectedWindow.Array) > return "array"; > if (obj instanceof inspectedWindow.NodeList) > return "array"; > if (obj instanceof inspectedWindow.HTMLCollection) > return "array"; ------ It seems the major issue is: JavaScript libraries have "array like" collections which would be useful to display like arrays in the console! But, sometimes this could go wrong, or sometimes this could hide information. For those "sometimes" cases, like was mentioned above, I think it would be good enough to indicate that this is in fact not an array, but an "array like" object. As a user, if I saw this indicator it be helpful, and I might want to display this as an object instead. So, if that indicator was clickable, and could toggle between the array-like quick view and the complete object view that sounds best to me. Does that sound good? Is there a use case I'm missing?
Pavel Feldman
Comment 25 2010-08-12 15:25:53 PDT
You just made "window" render as [undefined] in the console :P
kangax
Comment 26 2010-08-12 15:26:27 PDT
Welcome to the can of worms :) Detecting by both indices and length will not work with `arguments` object, since arguments object could well have `length` of 0 and no indices. One possible workaround for that is to consider objects with length === 0 to be array-like even if no indices are present. Another workaround is to catch `arguments` object before testing for array-like'ness — for example, by checking if [[Class]] of object is "Arguments" (as per ES5), or that it has `callee` property of function value, besides `length` (as per ES3), or maybe even checking `length` and `callee` properties' non-enumerability if we want to be really paranoid. But since webkit already sets arguments's [[Class]] to "Arguments", the other — more complex — versions could probably be avoided. I like second solution better, as it's both more robust and goes in line with detecting not just array-like objects, but arguments, nodelists, and "the rest" (e.g. jQuery) separately. It's also less confusing that way.
Joseph Pecoraro
Comment 27 2010-08-12 15:34:19 PDT
(In reply to comment #25) > You just made "window" render as [undefined] in the console :P Yah, I guess more have a "length" than I thought. Functions do too, but they have good instanceof and typeof semantics. > But since webkit already sets arguments's [[Class]] to "Arguments", the other > — more complex — versions could probably be avoided. "Arguments" is one of my major use-cases. I would like to see that arraylike. And you're right, this can be special cased differently.
John-David Dalton
Comment 28 2010-08-12 15:42:13 PDT
For reference this is how Firebug detects array-like: http://code.google.com/p/fbug/source/browse/branches/firebug1.6/content/firebug/reps.js#560 This allows jQuery results, MooTools 1.3 results and anything with a length property and splice method to be displayed as an array. It covers the arguments object too.
Joseph Pecoraro
Comment 29 2010-08-12 15:58:41 PDT
(In reply to comment #28) > For reference this is how Firebug detects array-like: > http://code.google.com/p/fbug/source/browse/branches/firebug1.6/content/firebug/reps.js#560 > > This allows jQuery results, MooTools 1.3 results and anything with a > length property and splice method to be displayed as an array. It covers the arguments object too. Pavel just put a patch to this affect up on bug 30974.
Note You need to log in before you can comment on or make changes to this bug.