Forums

Hi,

I find myself writing code such as this all the time:



I seems like a very verbose way to test for the existence of a node and create an onClick. Is there a good shorthand for this?

I would like to write something like
var add2network = Y.one('a.add2network') && add2network.on('click', function() [...]

but I don't know of a way to reference the object on the left hand of the operator as it is not yet assigned to add2network.

Any ideas?

Marc

Hi Marc,

Y.all() will always return a NodeList so you can use that instead.

Y.all('#your-id').on('click', function(e) { /* ... */ });

But both eric's and my solutions only check once so if its added after the fact you will need to check again. Delegate may be a better solution to your problem.

I usually don't check if Y.one returns null or not, so that when it does I get an error. Silent errors are really hard to find afterwards. Don't you find it better to get an exception if something goes wrong?

Heya Luke,
Thanks for listing all of those tradeoffs. I do vaguely remember when Node and NodeList were merged, but I from what I recall, it was during the PR and it was a bit flaky at the time.

To a couple of your points:

1. I don't think Y.all().on is drastically that bad, only because delegation doesn't work for all scenarios. For instance, if the common parent of a set of elements happens to be the body tag, then delegation falls apart (the performance hit of parsing up the dom tree and running through the selector engine gets pretty expensive for every click, given a deep enough DOM and given the browser *cough*IE*cough*).
It comes to a tradeoff between speed up front or speed during interaction.
But as you said, that's why it's there, for cases like that.

2. After so much time with the Node/NodeList paradigm, I will say, the jQuery approach of only providing composite elements is not only easier to explain to new members of a team, but also just more pleasant to write.
Basically, there are 3 factors that make it more enjoyable to work with:
A. Only 1 API to remember (currently, Node and NodeList have different method calls, and trying to remember which one is appropriate, or even having to take the time to look up which type of object I'm working with, more often than not gets in the way).
B. Using one method as a getter/setter (seems like a small thing, but it does make one less thing to fiddle with).
C. Makes 1-off actions much less verbose and easier to write.

Of course, the tradeoff is performance and debugging (though on debugging composite elements, it only *hides* the bugs better, but I haven't found *finding* the bugs any harder).

3. I sometimes wonder if it would be handy to have a wrapping util that is much less fragile than DOM or Node and can work with either a single or multiple objects.
This could just be me preferring terser code over performance/debugging, but I think the dicotomy of the API leads to some thinking over the API and detracts from the goal of the code.

Just my 2 cents, and thanks for going so in depth Luke