An example of using custom events

Probably many people know that jQuery has a set of standard events, such as Click or MouseDown and others, to which handlers can be hung or thrown using click () mousedown () and others functions. Slightly fewer people know that the same actions can be done using the bind () and trigger () functions:

$( document ).bind( 'click' , function (){
alert( 'It works!' );
});

$( document ).trigger( 'click' );

* This source code was highlighted with Source Code Highlighter .

And probably few people know that you can use your own events in bind () and trigger () functions. Why this is needed, I want to tell you by example.

Formulation of the problem

Imagine that our site is full of all kinds of pop-up windows, and they are called from different places, some pop up with information about the product, some with a login form, some else somewhere. The first thought about how to implement it will probably be like this:

$( '#products .item .info' ).bind( 'click' , function (){
$( this ).parents( '.item' ).eq(0).find( '.float' ).fadeIn(500);
});

$( '#login-link' ).bind( 'click' , function (){
$( '#login-form' ).fadeIn(500);
});

* This source code was highlighted with Source Code Highlighter .

This thought is obviously wrong, and you will understand it as soon as the designer says “it seems to me that it would be better if they appeared not in 0.5 seconds, but in 2” or “I meant that it should fly out to the left, not to the right” and you will have to search and edit all the places, you have this damn window.

The second option, how to implement it, will probably be something like this:

function ShowMe(el) {
el.fadeIn(500);
}

$( '#products .item .info' ).bind( 'click' , function (){
ShowMe($( this ).parents( '.item' ).eq(0).find( '.float' ));
});

$( '#login-link' ).bind( 'click' , function (){
ShowMe($( '#login-form' ));
});

* This source code was highlighted with Source Code Highlighter .

Already better, but here, not without problems. The fact is that the element itself, which you have chosen, does not carry any information about which function you need to transfer, so you will have to remember what to shove yourself and constantly look into the code. By the way, I, for example, like to wrap all the code in a function, limiting the scope and if you need to put a pop-up window somewhere in the content, you have to bring functions like ShowMe into the global scope.
')
Both methods have an additional common problem: in addition to the appearance of the window, you need to take care of hiding it, which, firstly, can also be animated, and secondly, very often after closing the window, you need to do some additional actions that you also have to somehow take into account with each method of closing the window (and you can think up as many as you want, cross, close button, close link in the text of the window, click outside the window).

Experienced programmers will probably say that you need to create a class and inherit it for each type of pop-up window, overriding the methods of hiding and showing. But I would like to suggest another way how to structure all this and avoid porridge in the code and in the head. If you read the heading and the text before the habrakat (and there are those who did not read it?), You probably already guessed what exactly I want to offer.

Use custom events

I prepared a small example in which 2 approaches are presented. The code of the first, without using events, is in the <div id = "not-envents"> block. The second, respectively, in <div id = "envents">.
What I wanted to show the first example:

1. What is called “logic” and “representation” is mixed, in one place it is determined what should happen and how it should be done.
2. When it was necessary to do .another-link1 (which is hypothetically in general in another file, it just has to open the same window), I had to repeat all the code responsible for showing
3. When it was necessary to make a link in "Window 2", closing the window directly in the text, I had to repeat the code responsible for the hide. And this is the simplest case, everything could be much worse.

In the second example, I use the custom events "hidefloat" and "showfloat". What I wanted to show with a second example:

1. You can select some common elements for all pop-up windows and write their logic in one place, as shown by the example of the .close button
2. The "view" (the part that says exactly how the window should be hidden) is completely separate from the logic. And, of course, the name "presentation" here is more than conditional. Very often, it may be necessary to show some additional elements when the window appears, and hide when hiding.
3. All events hung on the elements (.link1, .link2, .link3) clearly say what needs to be done, but they do not say anything about how to do it.
4. The link code in the text in Window 2 also says only that the window should be hidden. If the way in which it is supposed to hide will change, we will not have to edit the link in “Window 2”.
5. Finally, it becomes possible to make a “.closeall” link, which also knows nothing about how windows will be hidden. Even on such a simple page, it is clear that creating the “.closeall” button for the first option is something from the category of fiction.

Naturally, all that I have described is only an example of what problems user events can solve; in fact, their scope is not limited to one pop-up window.