Thinking of using Knockout? Here’s why we did.

JohnWhat is Knockout?

Knockout is an open source JavaScript Model-View-View Model (MVVM) library. MVVM differs from Model View Controller by not having a controller, as well as directly linking the model to the UI. Another example of MVVM is the binding used in Windows Presentation Foundation.

Why we needed Knockout

We needed the user to have the ability to work offline, but also have the ability to get back online later to sync. This required us to do nearly all of our interaction code in JavaScript. Thus, a JavaScript view model was needed.

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).

Each physical page has separate JavaScript backing. This way, users do not need to have their JavaScript polluted with code that is not needed on that page.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s