The View layer of a single page application goes far beyond statically displaying HTML and data through JavaScript templating engines or other means. A modern JavaScript application must handle real-time updates and be imbued with reactivity. Some of the protocols described in Chapter 4, REST is Best - Interacting with the Server Side of Your App such as WebSockets, MQPP, and DDP can be used to actively retrieve updates to data for an application, but the ability to bind those changes to the DOM and display them in the View must be handled on the frontend of the application. This is where data binding comes into play.
In this chapter, you will learn:
- What data binding is?
- The differences between one-way and two-way data binding
- The AngularJS implementation of data binding
- Other popular implementations of data binding
- How to implement data binding with native JavaScript?
- What some use cases of data binding are?
At a high level, data binding is a software design pattern specifying the ability to directly tie changes to your underlying application data, or Model, to the View by visually reflecting those changes automatically. This can be done by any number of means using JavaScript, and it is really dependent upon what version of JavaScript you are using and its abilities and limitations. In the case of a web application, those abilities and limitations are governed by the user's browser, of course, and this is why there are so many implementations of data binding in the JavaScript community.
If you have worked with any popular JavaScript frameworks, or at least have read about any of them, you have probably heard of data binding. You also have probably never attempted to implement it on your own, considering the number of libraries and frameworks out there that provide this capability. The advantage that some of these implementations give you is cross-browser compatibility by using multiple methods and feature detection in the browser for the delegation of those methods. Other frameworks, such as Ember.js and Knockout.js, use their own proprietary implementation of data binding that works across most browsers, but requires loading a potentially large library when all you want is the data binding feature.
Using a library or framework for complex data observation is often more desirable than writing custom JavaScript to do it yourself, which speaks to the popularity of frameworks such as AngularJS - often touted for its data binding features. Leveraging these features is one thing, but understanding how they work and what is going on under the hood of a framework is quite another. First, let's break down the concept of data binding a bit more.
One-way, or unidirectional, data binding is when a change to an application's data model is updated and subsequently reflected in the View. The initial change to the data model can come from anywhere, be it the submission of a form from the current user, the edit of a post of a different user on another computer, or a change in current data pushed directly from the application's host server. When the change in that data is automatically merged with a dynamic template and updated in the View without intervention from the user, it is known as one-way data binding:
One-way data binding is visualized in a View from the merging of a ViewModel with a Template.
Here, you can see a simple representation of the one-way data binding design pattern. The manner in which the update to the View ultimately takes place relies entirely on how the application's frontend JavaScript is written, and can be done in any number of ways, but the conceptual pattern itself remains unvarying.
Using a JavaScript templating engine, like the ones discussed in Chapter 5, Its All About the View provides one-way data binding at the template level when expressions in the compiled templates are bound to dynamic data. Updating the view to reflect real-time changes to that data, however, must be handled with additional code that observes for model changes and triggers updates to the view accordingly.
Two-way, or bidirectional, data binding includes the one-way data binding pattern but additionally allows changes to the representation of data in the View by the user to be reflected in the underlying Model itself. With this pattern in place, the data displayed in the View is always a representation of the current state of the Model, even when the user makes changes to that data in the View without explicitly submitting it via forms or other means:
This diagram shows the two-way data binding design pattern. In order for this pattern to work, there must be some type of observer in place that is continuously watching for changes to the data and syncing it in both directions. This naturally requires a more complex frontend architecture, and popular frameworks such as AngularJS can be leveraged to take the reins.