javascript event emitter aka decoupling javascript modules 

why? aka was machen sachen Sometimes modules are dependent on other modules but we still want to be able to keep them loosely coupled. *loosely coupled 

wait ... “If you've ever listened for a click event in a browser you've used an emitter.” - yes. but no. but yes. => decouples dom from js => You'll see this type of pattern a lot in node.js. 

Page (has xhr model; aka makes requests and holds list data) List (gets data from page, shows list) Pagination (gets data from page, has dom event handler, updates page request on click) Sorting (gets data from page, has dom event handler, updates page request on click) a job list x-ample 

current implementaion - page makes model - filter constructor: request - searchform constructor: request & filter - listing constructor: request - so much broken code …. later =======> 

Page (loads xhr data, renders list with data) List (gets data from page, shows list) Pagination (gets data list) Sorting (gets data from list) a job list x-ample - data down 

Page (gets event from list - makes xhr - then data down again) List (listens to events from childen - sends event on request change) Pagination (gets dom event - sends event to list) Sorting (gets dom event - sends event to list) a job list x-ample - events up 

code ... https://github.com/HenrikJoreteg/wildemitter 

wins - more re-usable - less brainfuck - more clean code