Javascript – What does “initialize event handler” mean in this context

eventinitializationjavascript

In file1.js I read:

// NOTE: initialize your app event handlers here, see file2.js for a simple event handler example

// TODO: configure following to work with both touch and click events (mouse + touch)
// see http://msopentech.com/blog/2013/09/16/add-pinch-pointer-events-apache-cordova-phonegap-app/

//...overly simple example...
//    var el, evt ;
//
//    if( navigator.msPointerEnabled || !('ontouchend' in window))    // if on Win 8 machine or no touch
//        evt = "click" ;                                             // let touch become a click event
//    else                                                            // else, assume touch events available
//        evt = "touchend" ;                                          // not optimum, but works
//
//    el = document.getElementById("id_btnHello") ;
//    el.addEventListener(evt, myEventHandler, false) ;

in file2.js I read:

// This file contains your event handlers, the center of your application.
// NOTE: see file1.js for event handler initialization code.

// example event handler
function myEventHandler() {
  // event handler code
};

What "initialize event handlers here" in file1.js is supposed to mean?

What should I do there?

Is it a place for defining additional event handlers, like the one in file2.js ?

Or could it be that by "initialize" they mean that file1.js is the place where I should make use of an even handler (i.e. using it within an event listener, like in the example that comes after, in file1.js) ?

I've googled the expression "event handler initialization", or "initialize event handler" and I found almost nothing, so I am confused…

Update: In code above, in file2.js, I had forgotten to include the beginning comments. Added them. Hopefully this can help further understand the different roles of the two files?

Best Answer

Definition

An event handler is just a piece of code (function in the case of Javascript) that does something when a specific event occurs.

An Example

One example would be the mouseover event that occurs when the mouse (any pointing device really) moves over an element on the page.

<ul id="test">
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3</li>
</ul>

<script>
  var test = document.getElementById("test");

  // ... //

  // this handler will be executed every time the cursor is 
  // moved over a different list item
  test.addEventListener("mouseover", function( event ) {   
    // highlight the mouseover target
    event.target.style.color = "orange";

    // reset the color after a short delay
    setTimeout(function() {
      event.target.style.color = "";
    }, 500);
  }, false);
</script>

Example code "borrowed from" MDN.

Example Explanation

The example above shows adding an event listener (or event handler) during the initialization process for the script. The event handler is defined inline (the part where function( event ) { starts). The inline function is called every time our event occurs.

What this means is that when you move your mouse over one of the list items, the color of the text for that list item will turn orange for about half a second.

Some Answers

Now that the definitions are out of the way, let's talk about answering your questions.

What "initialize event handlers here" in file1.js is supposed to mean?

It means that you should build your event handling functions immediately following the comment. You will also need to add code to add the event handler to the object on which the event occurs (the test.addEventListener("mouseover",... part).

Is it a place for defining additional event handlers, like the one in file2.js?

You can include code in that spot or you could reference an external file, that is your choice which way you want to handle it.

Or could it be that by "initialize" they mean that file1.js is the place where I should make use of an even handler (i.e. using it within an event listener, like in the example that comes after, in file1.js)?

Same answer as the last question.

Related Solutions

JavaScript – What Does Bubbling Mean in This Context?

Bubbling is an event flow mechanism in the DOM where events that are designated as "bubbling" (such as your click event), after being dispatched to their target, follow the target's parent chain upwards, checking for and triggering any event listeners registered on each successive target.

In other words, given a DOM like this:

<div id="foo">
  <div id="bar">
    <a href="/something">Click Target!</a>
  </div>
</div>

The click event that is triggered when the anchor is clicked will bubble up through the chain, triggering any click handlers on div#bar and div#foo on the way up.

CQRS+ES Object Initialization – Constructor vs First Event

When doing CQRS+ES I prefer not having public constructors at all. Creating my aggregate roots should be done via a factory (for simple enough constructions such as this) or a builder (for more complicated aggregate roots).

How to then actually initialize the object is an implementation detail. The OOP "Don't use initialize"-advice is imho about public interfaces. You should not expect that anyone that uses your code knows that they must call SecretInitializeMethod42(bool,int,string) - that's bad public API design. However if your class does not provide any public constructor but instead there is a ShoppingCartFactory with the method CreateNewShoppingCart(string) then the implementation of that factory may very well hide any kind of initialization/constructor magic which your user then don't need to know about (thus providing a nice public API, but allowing you to do more advanced object creation behind the scenes).

Factories get a bad rep from people thinking there's too many of them, but used correctly they can hide away a lot of complexity behind a nice easy-to-understand public API. Don't be afraid to use them, they're a powerful tool which can help you make complex object construction much easier - as long as you can live with some more lines of code.

It's not a race to see who can solve the problem with the least lines of code - it is however an ongoing competition as to who can make the nicest public API's! ;)

Edit: Adding some examples on how applying these patterns could look

If you just have an "easy" aggregate constructor that has a couple of required parameters you can go with just a very basic factory implementation, something along these lines

public class FooAggregate {
     internal FooAggregate() { }

     public int A { get; private set; }
     public int B { get; private set; }

     internal Handle(FooCreatedEvent evt) {
         this.A = a;
         this.B = b;
     }
}

public class FooFactory {
    public FooAggregate Create(int a, int b) {
        var evt = new FooCreatedEvent(a, b);
        var result = new FooAggregate();
        result.Handle(evt);
        DomainEvents.Register(result, evt);
        return result;
    }
}

Of course, exactly how you divide creating the FooCreatedEvent is in this case up to you. One could also make a case for having a FooAggregate(FooCreatedEvent) constructor, or having a FooAggregate(int, int) constructor that creates the event. Exactly how you choose to divide the responsibility here is up to what you think is the cleanest and how you have implemented your domain event registration. I often choose to have the factory create the event - but it's up to you since event creation is now an internal implementation detail that you can change and refactor at any time without changing your external interface. An important detail here is that the aggregate does not have a public constructor and that all the setters are private. You don't want anyone to use them externally.

This pattern works fine when you're just more or less replacing constructors, but if you have more advanced object construction this may become way too complex to use. In this case I usually forego the factory pattern and turn to a builder pattern instead - often with a more fluent syntax.

This example is a bit forced since the class it builds isn't very complex, but you can hopefully grasp the idea and see how it would ease more complex construction tasks

public class FooBuilder {
    private int a;
    private int b;   

    public FooBuilder WithA(int a) {
         this.a = a;
         return this;
    }

    public FooBuilder WithB(int b) {
         this.b = b;
         return this;
    }

    public FooAggregate Build() {
         if(!someChecksThatWeHaveAllState()) {
              throw new OmgException();
         }

         // Some hairy logic on how to create a FooAggregate and the creation events from our state
         var foo = new FooAggregate(....);
         foo.PlentyOfHairyInitialization(...);
         DomainEvents.Register(....);

         return foo;
    }
}

And then you use it like

var foo = new FooBuilder().WithA(1).Build();

And of course, generally when I turn to the builder pattern it's not just two ints, it may contain lists of some value objects or dictionaries of some kind of maybe some other more hairy things. It is however also quite useful if you have many combinations of optional parameters.

The important takeaways for going this way is:

Your main objective is being able to abstract object construction so that the external user doesn't have to know about your event system.
It's not that important where or who registers the creation event, the important part is that it gets registered and that you can guarantee that - apart from that, it's an internal implementation detail. Do what fits your code the best, don't follow my example as some sort of "this is the right way"-thing.
If you want to, by going this way you could have your factories/repositories return interfaces instead of concrete classes - making them easier to mock for unit tests!
This is a lot of extra code sometimes, which makes many people shy away from it. But it's often quite easy code compared to the alternatives and it does provide value when you do sooner or later need to change stuff. There's a reason that Eric Evans talks about factories/repositories in his DDD-book as important parts of DDD - they are necessary abstractions to not leak certain implementation details to the user. And leaky abstractions are bad.

Hope that helps a bit more, just ask for clarifications in comments otherwise :)