Opened 10 years ago

Closed 10 years ago

#9359 closed defect (duplicate)

NodeList.closest: unclear functionality

Reported by: mschuerig Owned by: James Burke
Priority: high Milestone: 1.4
Component: Core Version: 1.3.0
Keywords: Cc:
Blocked By: Blocking:


I'm not sure what exactly NodeList?.closest(query) is supposed to do, however, it does not do what I had expected.

To recap, it does work as demonstrated by the DOH test, on a single part query. It does not work on selectors describing a path, such as ".third .classy span". In that case, only the first component is taken into account.

If this functionality is not supposed to be supported, the query parameter has a misguiding name. If this functionality is meant to be there, the docs ought to specify the direction in which the selector is matched, i.e. from the root or from the node being checked, and which node is returned.

My preference is to specify the path in the usual direction, from general to specific, and return the node matching the specific end.

Also, I think closest() should follow dojo.query() in taking an optional root node as the second argument for limiting the search from above.

Change History (3)

comment:1 Changed 10 years ago by James Burke

(In [17641]) Refs #9359: clarify what kinds of queries can be used with the traverse methods, basically simple ones, no decent operations. May modify it later if found to be too restricting. Opting for speed in this case until viable use cases otherwise are identified.

comment:2 Changed 10 years ago by James Burke

Component: GeneralCore
Milestone: tbd1.4
Owner: changed from anonymous to James Burke

mschuerig: thanks for the feedback: this is a new module still under final construction.

The queries supported by the -traverse NodeList? methods are just simple queries, the same ones that are allowed on the normal NodeList?.filter calls. This is because a quicker, simplified test is used to identify matching nodes. From the (just updated) docs:

single-expression CSS rule. For example, ".thinger" or "#someId[attrName='value']" but not "div > span". In short, anything which does not invoke a descent to evaluate but can instead be used to test a single node is acceptable.

I think in the case of closest, this in particular is applicable since you are trying to find the closest parent. It seems like simple query checks are mostly what is needed.

However, I could be wrong. I'm opting for speed in this case, but if you can describe some real world scenarios where descent operations make sense in the context of closest(), maybe we can make the code more feature rich at the expense of speed.

Note that I will probably critique any example given, so hopefully it will come from a real world situation. I want to make sure we do not take a big performance hit for a very uncommon use case that might work with a query readjustment. All that said, I want this to still be useful. Again, thanks for the feedback.

comment:3 Changed 10 years ago by James Burke

Resolution: duplicate
Status: newclosed

Closing this in favor of #9665 even though this ticket came first. If #9665 is fixed, this one will be fixed too.

Note: See TracTickets for help on using tickets.