Code on the Go - Architecture
Version 1.x of Code on the Go was really architecture-less. For 2.0 I wanted to have an architecture, and in the end, two primary types were used.
The first is the module design pattern. In the module pattern, you do not define things on the global. Instead, you use a library (Almond in my case) to give you two functions: define and require. You use the define method to define new modules. The function typically takes in the name of the module, an array of modules that the module depends on, and a function that has the dependencies passed in to as parameters. In the function, you create the object that you want the module to represent. It can be a simple object or a constructor function. It can even be as simple as a string, number, or Boolean value. The function is called the first time the module is request, either by the dependencies array or define a or by using the require function that passes the requested module. The library then stores the result of the function and passes it along as the result of all future calls to the module. The basic idea here is that a module only knows about modules it needs, cannot change those modules, and does not need global objects to cross-files.
The second is the Model-View-ViewModel (MVVM) pattern. The MVVM pattern is a spin on the classic Mode-View-Controller (MVC) pattern. The breakdown of MVVM is
Model: The data passed around that you display to the end user. For example the file that you are editing.
View: The code that contains User Interface (UI) objects like buttons. Important is that it does not know about the Model. For example the HTML in Code on the Go.
ViewModel: The glue between View and Model. It knows how to convert the Model into data and functions that the View can use. It contains properties that the UI links to and methods that the UI calls to change the Model.
The idea behind MVVM is that the Model and the View are completely independent of one another. This allows you to tweak your View without needing to worry about the model or to have more than one view of the data. A good example of different views would be in a stocks application. The Model consistently has the same information about the stocks but you can have many ways to look at it, graphs and tables for example.
Code on the Go consists of a small Model, "one" View and many ViewModels. The reason I say one in quotes is because technically there is only one HTML file so one view, BUT because of the way I have split it into multiple ViewModels it is like having more than one View. The ViewModels break code up into parts like one for controlling the Tabs, one for the Editor View, one for the Debug View, one for the Home View, etc. The ViewModels are intertwined, containing one another. There are some standalone, self-executing function style files too. One manages the CSS styles for instance; another is the entry point for the application.
That covers the overall architecture of Code on the Go. Next time I will talk about individual tricks I did to make things easier, like the CSS style manager class.