Going with the flow - abukhalil-LTUC-ASAC/amman-401d4 GitHub Wiki

Or making flow your way

Event driven programming is just like that, define a flow to be in, and build a boat that will sail through it! Which you might have guessed, it mostly revolves around how what users can interact with, and a very basic UI/UX course could do wonders in terms of doing in depth into the know how's. The programming side uses two main functionalities which you might have used heavily without thinking about it:

  • One is a callback that is triggered with every fired event.
  • The other is a main loop that maintains the listener to events through the different means and actions.

Source flow: The EventEmitter

The Victoria lake of the Nile river. From a static web point of view, it seems like an overkill to have a whole module several MB's of size to just add a few onclick listeners here and there, but as you scale and add app like functionalities on concurrent events and streaming data, along with best UI/UX practices things would get really large and unmaintainable quickly.

Usage

The methods looks really simple, with on and emit where on sets the method to execute and action to listen to, and emit is the action that is going to be listened to, defined inside another function. This allows scalability by adding actions as you define it anywhere and simply trigger it as you need to.

Don't forget to remove listeners as well when objects they refer to don't exist anymore, this is mostly for performance concerns and is done using the method removeListener

OOP + EDP

The way to implement proper scalability is seems to emit through object calls separately when you need them to, and whatever object that listens to each actions deals with it as it is programmed to. All of that is to decrease the need to write and rewrite the same emitters and listeners in the hope that it works out at scale.