Structuring a Client-Side App

Editor's Notes

• #2: We’ve called this lecture “Structuring a Client-Side App” not because the lessons here only apply to the client-side portion of an app, but because we’ll be going through an example that’s entirely client-side.
• #4: Show what the app does. Point out that this is all client-side. http://www.mit.edu/~ebakke/misc/6170_gradebook_example http://www.mit.edu/~ebakke/misc/6170_gradebook_example/08_pivot/index.html
• #5: Give the class 5 minutes to think about how they would structure this app, then discuss possible architectures on the board. http://www.mit.edu/~ebakke/misc/6170_gradebook_example
• #8: Spaghetti code originally refered to programs with tangled control structures (e.g. using GOTO everywhere). I’ll use it to denote software with tangled dependencies. This list is not exhaustive.
• #9: This is just the classic MVC.
• #10: This will not be on the test. I’m just showing you a couple of architectures people have proposed.
• #11: This one adds another layer. The thing called “View” here is actually the DOM in this model.
• #12: Explain clearly what is meant by “view” and “model”. The model is the data underlying your app. The view is the user interface. The view may have some state of its own (e.g. the pressed state of buttons, or the immediate content of text boxes), but the core state of your application, which may potentially be shared among multiple user interface components or even users, should be stored in a separate “model” part of your application that is independently testable and does not depend on anything else.
• #13: Give the class 5 minutes to think about how they would structure this app, then discuss possible architectures on the board. http://www.mit.edu/~ebakke/misc/6170_gradebook_example
• #15: Actually, I lied when I said there were only two modules. There is another tiny little module which actually makes use of the GradeWidget and the GradeBook. You can consider it part of the view, but none of the other modules depend on it. Note that the model can be tested entirely independently of the view. On this chart, the arrows mean dependencies.
• #16: There’s also the HTML and CSS files, but they’re not too interesting in this example. Note, though, that the gradewidget has a CSS file that logically belongs in its module together with gradewidget.js.
• #17: http://www.mit.edu/~ebakke/misc/6170_gradebook_example https://github.com/eirikbakke/6170_gradebook_example/commits/master
• #19: Runtime checks. Repeat what DNJ said before: you shouldn’t be checking for types and constraints everywhere, but you should absolutely check them at API boundaries. Especially when supplied objects go into the model state and errors may not otherwise be discovered until much later.
• #20: Mention Object.freeze here.
• #21: Go and show these unit tests in action. https://www.mit.edu/~ebakke/misc/6170_gradebook_example/02_robust/tests.html Spend about 10 minutes on QUnit tests. Point out the “unit” part of unit tests. They’re testing a unit, that is to say, they are only testing a small piece of the program in isolation. Unit tests are most valuable when written early in the development process; that’s when they will best help you catch bugs, especially as you make a lot of changes to your application.
• #22: Point out that I’m using the JSDoc format, with the caveat that it doesn’t quite understand the this = that idiom (with some more annotations it would work). Spend no more than 5 minutes on this.
• #25: Note here how the GradeWidget takes a domContainer and a model object. It does not install itself arbitrarily on the page.
• #26: The main point here is that we are building DOM elements from a model object. There also exists client-side templating libraries that help with this. Point out where we get the grade from—it comes from the model. Constructing DOM “behind the scenes” (good practice). Also discuss the technique of regenerating the entire view every time there is an update (less complexity in code, but can upset UI state such as scroll position, focus, and tooltip state).
• #27: Don’t go into too much detail here; just point out that as part of our refresh, we assign a click handler to each grade, and put an input field in the right position if any grade has previously been clicked. About detach(): jQuery will automatically detach any listeners when an element is removed from the DOM. Use detach() to remove gradeInputElm without removing its listeners, since we'll be reusing it.
• #29: The most important point here is that the setting of the grade is done on the model, not somewhere in the view. The view gets updated in turn when rebuild_table() is called.
• #30: There’s also a little bit of CSS here.
• #31: Ask the class what is wrong. Get a good answer before moving on.
• #32: Tell students not to look at the solution yet. http://www.mit.edu/~ebakke/misc/6170_gradebook_example/challenge.zip http://tinyurl.com/pq9gm8v Might need more than 5 minutes on this one; though students can continue to try to implement the solution as I move along.
• #34: Stress that we are able to avoid making the model dependent on the view. Compare subscribers to event handlers.
• #37: We can generalize the GradeWidget a bit so that grades can be displayed either by assignment or by student. That way we can show off a useful reason why you might want two widgets based on the same model. (The exact logic in this part of the example is not so important.)
• #40: A Game of Life solution organized like this can be done in less than 300 lines of JavaScript (+tests).