keen
Modularize
One of the big design goals of an open source project should be modularization. This has a bunch of benefits, such as readability, ownership of modules, testability, less brittle for contributions.
This will likely feel overkill for the size of the project right now, but I think if we start a modular theme now it will be easy to keep that going as CommonWeb grows.
Anyways, I'd like to break CommonWeb apart in to 3 different components/types.
Trackers
Trackers are essentially just tools that bind to events. So, for instance, the trackClicks method would use a click tracker. In most scenarios, these trackers will be very tiny functions - the base of each tracker will likely just be tying to a specific event using the event system.
However, some trackers (actually all, to some extent) will have a bit of logic in them. The logic is for doing things like deciding if we want to track clicks on ALL elements, or just a subset that was passed. It decides if/when those events should be unbound, etc.
Parsers
could also be called enrichers, or enhancers... thoughts?
Parsers take a thing, and make it better. The thing here is pretty broad - right now I think the things we might parse would be JS events, DOM nodes, cookies, POJOs (like user objects), times, dates, etc.
For instance, if a button gets sent to the DOM node parser, the parser will return an object with information like the button text, XPath, classes, ID, etc.
Dispatchers
I hate naming. Better name, anyone?
Dispatchers are the things that actually take a CW event object and shoot it off to an analytics service. A dispatcher is responsible for taking in a standard CW formatted event object, molding it to match the required structure of the analytics service, and actually dispatching the event.
I actually think that eventually we will remove dispatchers from the CommonWeb project. As the list gets longer, it will probably make more sense for dispatchers to live in their own repos. That will remove the necessity of the CW lib containing a massive amount of dispatcher code by default, and also let orgs control their own dispatcher (ie: mixpanel would own/run/manage the mixpanel dispatcher).
If you ignore the fancy names, you will probably notice that these are just things that we already have in CommonWeb, but separated. Nothing here is new - actually, most of the code should just be copy and pasted. The value of doing it this way is that it makes it quicker for potential contributors to figure out what lives where, and it's less scary to make changes. Also, if CW ever gets big enough to justify it, it will be easier for people to "own" certain portions of CW if it is broken apart like this.
This is part of The Refactor.
