Skip to main content
added 334 characters in body
Source Link
Joseph
  • 25.4k
  • 2
  • 26
  • 37

I was expecting this to be hard as, from what I've read, most people don't create their own

Actually, there are more people who create event emitters than you thinkmore people who create event emitters than you think. I'm one of them, and here's my implementation. It'sAside from Event Emitter, it's also called "pub-sub", and here's one of the same nature under that label.

It's a basic practice of the concept of managing async and decoupled code. It also makes for a good practice in code performance, coding style and sample code when learning GIT.

It's far simpler than most libraries I've seen.

Because it is very simple. Collect callbacks, and when someone looks for themtriggered, you look for themthe right collection and executefire. That's about it.

Is there a flaw in this method?

Yes, and that's what I haven't fixed in mine. The following code in trigger is the problem:

events[evtName].forEach(function(callback) {
  callback(evtObj);
});

In your trigger, you fire the callbacks one after the other. That's fine for sequential code. But what if each of the callbacks contained operations that are synonymous to looping 100k times? And imagine if every callback listening to that fired event did that? That would freeze up the browser.

A solution to that wasis using timers. Timers can be "set aside" when JS is busy. They don't "block the thread", as they usually call it. That way, you have these "gaps" when executing the callbacks, allowing the browser to breathe and do something else, like render the page perhaps.

var length = events[evtName].length;
var i = 0;
var timer = setInterval(function(){       // Execute whenever possible
  events[evtName][i].call(); // I usually use call, in case I want to place context  // Nothing special about the call()
  if(++i == length) clearInterval(timer); // Clear when done
},0);

What are the benefits of using something like EventEmitter.js?

If you mean the concept of pub-sub, then you have decouplingdecoupled of code, async event handling which means it's easier to put in and pull out code without breaking the rest of the app. You also have a basic facility for managing asynchronous events.

If you meant the library itself, then you just saved your time maintaining, writing and, testing thatand maintaining a pub-sub library. Not to mention, it's all free. All you need to do is grab and usego (and maybe give credits where it's due).

I was expecting this to be hard as, from what I've read, most people don't create their own

Actually, there are more people who create event emitters than you think. I'm one of them, and here's my implementation. It's also called "pub-sub", and here's one of the same nature under that label.

It's a basic practice of the concept of managing async and decoupled code. It also makes for a good practice in performance, coding style and sample code when learning GIT.

It's far simpler than most libraries I've seen.

Because it is very simple. Collect callbacks, and when someone looks for them, you look for them and execute. That's about it.

Is there a flaw in this method?

Yes, and that's what I haven't fixed in mine. The following code is the problem:

events[evtName].forEach(function(callback) {
  callback(evtObj);
});

In your trigger, you fire the callbacks one after the other. That's fine for sequential code. But what if the callbacks contained operations that are synonymous to looping 100k times? And imagine if every callback listening to that fired event did that? That would freeze up the browser.

A solution to that was using timers. Timers can be "set aside" when JS is busy. That way, you have these "gaps" when executing the callbacks, allowing the browser to breathe and do something else, like render the page perhaps.

var length = events[evtName].length;
var i = 0;
var timer = setInterval(function(){
  events[evtName][i].call(); // I usually use call, in case I want to place context
  if(++i == length) clearInterval(timer); // Clear when done
},0);

What are the benefits of using something like EventEmitter.js?

If you mean the concept of pub-sub, then you have decoupling of code, async event handling.

If you meant the library itself, then you just saved your time maintaining, writing and testing that pub-sub library. Not to mention, it's all free. All you need to do is grab and use (and maybe give credits where it's due).

I was expecting this to be hard as, from what I've read, most people don't create their own

Actually, there are more people who create event emitters than you think. I'm one of them, and here's my implementation. Aside from Event Emitter, it's also called "pub-sub", and here's one of the same nature under that label.

It's a basic practice of the concept of managing async and decoupled code. It also makes for a good practice in code performance, coding style and sample code when learning GIT.

It's far simpler than most libraries I've seen.

Because it is very simple. Collect callbacks, and when triggered, you look for the right collection and fire. That's about it.

Is there a flaw in this method?

Yes, and that's what I haven't fixed in mine. The following code in trigger is the problem:

events[evtName].forEach(function(callback) {
  callback(evtObj);
});

In your trigger, you fire the callbacks one after the other. That's fine for sequential code. But what if each of the callbacks contained operations that are synonymous to looping 100k times? And imagine if every callback listening to that fired event did that? That would freeze up the browser.

A solution to that is using timers. Timers can be "set aside" when JS is busy. They don't "block the thread", as they usually call it. That way, you have these "gaps" when executing the callbacks, allowing the browser to breathe and do something else, like render the page perhaps.

var length = events[evtName].length;
var i = 0;
var timer = setInterval(function(){       // Execute whenever possible
  events[evtName][i].call();              // Nothing special about the call()
  if(++i == length) clearInterval(timer); // Clear when done
},0);

What are the benefits of using something like EventEmitter.js?

If you mean the concept of pub-sub, then you have decoupled of code which means it's easier to put in and pull out code without breaking the rest of the app. You also have a basic facility for managing asynchronous events.

If you meant the library itself, then you just saved your time writing, testing and maintaining a pub-sub library. Not to mention, it's all free. All you need to do is grab and go (and maybe give credits where it's due).

Source Link
Joseph
  • 25.4k
  • 2
  • 26
  • 37

I was expecting this to be hard as, from what I've read, most people don't create their own

Actually, there are more people who create event emitters than you think. I'm one of them, and here's my implementation. It's also called "pub-sub", and here's one of the same nature under that label.

It's a basic practice of the concept of managing async and decoupled code. It also makes for a good practice in performance, coding style and sample code when learning GIT.

It's far simpler than most libraries I've seen.

Because it is very simple. Collect callbacks, and when someone looks for them, you look for them and execute. That's about it.

Is there a flaw in this method?

Yes, and that's what I haven't fixed in mine. The following code is the problem:

events[evtName].forEach(function(callback) {
  callback(evtObj);
});

In your trigger, you fire the callbacks one after the other. That's fine for sequential code. But what if the callbacks contained operations that are synonymous to looping 100k times? And imagine if every callback listening to that fired event did that? That would freeze up the browser.

A solution to that was using timers. Timers can be "set aside" when JS is busy. That way, you have these "gaps" when executing the callbacks, allowing the browser to breathe and do something else, like render the page perhaps.

var length = events[evtName].length;
var i = 0;
var timer = setInterval(function(){
  events[evtName][i].call(); // I usually use call, in case I want to place context
  if(++i == length) clearInterval(timer); // Clear when done
},0);

What are the benefits of using something like EventEmitter.js?

If you mean the concept of pub-sub, then you have decoupling of code, async event handling.

If you meant the library itself, then you just saved your time maintaining, writing and testing that pub-sub library. Not to mention, it's all free. All you need to do is grab and use (and maybe give credits where it's due).