Why we needed Knockout
How we chose to use Knockout
We chose Knockout due to limitations of Office 365, and prior experience with the system. Knockout also has the added benefit of allowing you to very easily JSONify the view model.
How we used Knockout
The primary view model for knockout is actually a collection of view models which are re-used all over the place. This allows code re-use and simplicity in modifying code.
The code for saving the view model to local storage takes the view model and wholesale serializes it into JSON, which it then saves into local storage. We can later retrieve that JSON string and move it back into the view model. If we then initialize the page, the user is put exactly where they left off.
We heavily utilized the knockout templating engine, which takes all of the data in the view model that’s bound to the UI and renders the UI with the data.
Knockout’s templating engine works in both directions: If you update the view model, it will automatically update the UI, and if you update the UI it will automatically update the view model. This allows us to control the DOM using only the view model, and separate UI concerns from data concerns.
Knockout does not handle rest requests by itself. As such, the code for retrieving and saving data to SharePoint is completely separate from the actual view model. This was not problematic however, because the SharePoint rest is much more complicated than what our current backbone stack would allow. This meant that we could make updates to the data access without endangering the UI code.
We also set a variable in the view model for going offline. Because we use this variable in the templates, it automatically updates the UI to disable all functions that are impossible to use when offline (such as file uploads).