Step One: Watch Writing Testable JavaScript - Rebecca Murphey from Full Frontal 2012 (award for worst conference name ever?)
Step Two: Fork this gist.
Step Three: Respond to this question in your fork: Consider the four responsibilities that Rebecca lists for client side code (hint: they're color coded). Respond below with your thoughts. Did any of the responsibilities that she lists surprise you? Do you feel like you mentally split your client side code in IdeaBox and other past projects into these responsibilities?
- Data/server communication
- Setup
- Application state
- Presentation & interaction
I would say that I began thinking of a framework something like the one Rebecca describes when I began to grasp the general MVC concept. There is definitely a similarity between the MVC structure and the four responsibilities she describes. It does surprise me that Setup and Application State are listed separately, as I would often think of those responsibilities being carried out by the same entity (as in the case of a controller or "runner" file perhaps).
While working on Idea Box I did notice (at least in my setup) that there were various presentation/interaction functions being called by what could be considered a "runner" function. Looking back it doesn't seem that responsibilities in my code were clearly in line with the breakdown Rebecca discusses, which suggests to me that I may have functions with too many responsibilities.
Step Four: Totally Optional: take a look at some of the other forks and comment if the spirit moves you.
Good observations! I think the Setup and Application State distinction takes a little while to make sense.