Step 3 - which is better?


Background: I've only seen making an object out of the document, $(document)..., jQuery syntax in this course. And previous examples utilized it once while creating it outside of other functions.

After noodling around on this board and in the blogosphere, it appears that one can utilize the 'document' selector in other places. Which leads to the solution I've worked out here (after much side learning and experimentation).

Below, is the simplified code that utilizes the document selector in TWO places. One within the 'main' function and the other outside of that function. Both seem to do what is desired in this step (with the other example omitted, of course). But which placement of the on() method would be considered best practices.

var template = function(text) {
  // do stuff...

var main = function() {
	$('form').submit(function() {
		// do stuff...
        // step 3. Add the $(document).on() event within the main function as in the next few lines
	$(document).on("click", '.glyphicon-star', function() {



// step 3. Or add the $(document).on() event at a higher level as in the next few lines
$(document).on("click", '.glyphicon-star', function() {

Why return false, the sequel?

Still hoping to receive some feedback on the question posed earlier


Means anywhere in the document. You'll need to read up on bubbling... All events bubble upwards to the their highest level parent, in this case the document object, itself. Any click, anywhere in the page will be detected, and if that click took place in the delegated type or class indicated, it will trigger the handler, else nothing happens.

The advantage is very obvious once we bring into play dynamically inserted or removed elements. We don't even have to have any child elements yet and we can still register the listener on an existing parent. As we add new type or class elements indicated in the delegation, they automatically have listeners already attached (sort of). The todo list exercise is a good example, as well.

Indentation (a form of white space) is ignored in JavaScript. We only write the indentation for readability, and to indicate nesting levels. So there is no real difference in how we write it. However, we should consider whether deferral is needed or not. I suspect that since your example is bound to the document, it won't need a .ready() wrapper. Test this out and see if it is true. Have your JS load in the HEAD for this test.


Will read about "bubbling", thanks for the suggestion.

If I understand you correctly, it does not matter whether the .on("click") method is placed within the example's main function or if it's placed outside of the main function. Correct?

If that is the case, which is best practice in the field; i.e. where would most seasoned programmers put the .on("click") method?

Aside: I did get back in the Javascript course through CC that indentation or white space is not relevant to how js gets interrupted. Though, thanks for the reminder.


Forgive me, you've caused me to rethink my question...

Since, in this instance above, we're calling the .on("click") method, which is listening anytime and anywhere on the page. So perhaps, where on puts this event is almost irrelevant. If I understand the scope of the .on() method, that is.

Then after reading about the bubbling concept, it seems if one were to utilize a class as a selector, a class that is utilized a few times on a page, and one utilizes an event handler {different from .on() method} on that class, where the event is called can be relevant.


It does, depending where the script is loaded, HEAD or BODY.

Some testing would be needed to determine the edge cases. The document exists immediately at run time, as I understand it, so can have bindings attached to that object before the DOM content is loaded. Any other element would need to defer attachment of listeners until the HTML is downloaded.

I cannot stress enough how unimportant best practices are at this stage learning. It is subjective thinking when there are way to many missing pieces. Learn the keywords, their constructs, the programming concepts associated with varying constructs, and as you go, syntax. Toss the 'best practices' idea for now. It will evolve into your writing over time.


Ok. Don't stress about best practices at this point.

Thanks for the terms to read up on.


As mentioned above, the biggest advantage of .on() is that it only needs to be bound to a single object, which object will be at or near the top bubble layer.

Aside ~~~

Each layer derives from the context of its declared container.


Since these are not functions, but objects, they are all in the same scope, with differing context. It's a slight different take from scope. Scope is environment related, while context is object related. As we can see, all three levels above exist in the same memory namespace, the same scope.


From your reading you will have learned that a click in the third layer bubbles up to the body layer eventually. Each layer gets a look at the event, and the first handler to be triggered follows up the event with actions. Read up on this aspect to determine if just the one handler executes, or if the event is handled further up the chain, as well.

When we register a binding on a top level parent, none of the children need to be present with the listener is attached. Only the parent needs to be present. The children can stream in afterward and not even be aware that they are the delegated objects of the attached event listener. They can be inserted and removed at will and always be hot spots for the registerd event(s).

When we attach a listener to a selector, such as a click event, That binding is created only on that object, if it exists, and only at load time. If we somehow later insert a new element and want it to have the same event profile we have to attach the listener at the time we create the new object. This gets very messy and uses a tonne of memory.

The usage is case by case. Simple static cases can use simple listeners. More complex cases almost always yearn for delegation as a demand of dynamic DOM insertion and deletion.

Now as to where an event handler is called, more or less relates back to the above. It depends on whether an event is one-off or persistent. If an interaction causes a new element to overlay a section of the page, it may have events associated with it. Depending how frequently, if at all this feature would be called upon might be a determining factor into whether it gets registered at load time, or at event time (opening the overlay).

Memory is always a factor, and lots of registered event bindings uses lots of memory. It may also introduce conflicts, another big picture to study up on. When we register events on elements individually, and those elements happen to be removed, the bindings are still in place, but doing nothing but using space. Therefore our program needs to be aware of these deletions and track down any bindings the elements may have and turn them off. This is the messy part.

Case by case. We can explore any that you may come up with over in the corner bar, if you ever want to.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.