Element#at about opal-jquery HOT 5 CLOSED

Element#[] has been chosen to access attributes and treat the element(s) as a kind of hash.

Element#at takes indexes starting from 0 like Array#at and I think its better to stay consistent with Array.

I did the same mistake a bunch of times realizing that #[] was for attributes and switching to #at.
If it were the opposite I think I would have ended trying to use #[] for attributes…

(just my 2 cents)

from opal-jquery.

This works in JQuery:

$("a")[2]["href"]

This works too:

$("a")[2].attributes["href"].value

This works in Nokogiri:

doc.css('a')[2]['href']

This is OK too:

doc.css('a')[2].attribute('href').value

from opal-jquery.

Good point, still the problem with jquery is that when we're dealing with it's "power array" we're both operating on a collection and on an element…

when you do

$("a")[2]

you have no more a jquery object, you're accessing the original HTMLElement, opal jquery on the contrary always returns jquery objects (#at) so I think the confusion is sitll, there…

The matter is:

“we want opal-jquery to treat its object primarily as html elements or as arrays?”

I find myself using the mostly as elements, so I'm content with the current behavior

from opal-jquery.

We could have Element#[] work with both ... if a string is passed in, then treat it as an attribute reference/assignment, or if it is a numeric, then treat it as an index like #at does.

Personally, I think Element#[] for attributes is a must, as its a lot nicer/shorter, but there is no reason for not using it for these indexes as well. Thoughts?

from opal-jquery.

Keeping them separate feels better to me, String#[] and Array#[] accept different formats (ranges, regexps, index+length) as well but always (AFAIK) to extract elements

said this that solution can surely work… and could be the least surprising

from opal-jquery.