Javascript Event Emitter

Transcript

1. javascript event emitter aka decoupling javascript modules
2. 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
3. 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.
4. 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
5. current implementaion - page makes model - filter constructor: request - searchform constructor: request & filter - listing constructor: request - so much broken code …. later =======>
6. 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
7. 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
8. code ... https://github.com/HenrikJoreteg/wildemitter
9. wins - more re-usable - less brainfuck - more clean code