I am going to be honest.

It’s all about relations. But not just any relations. It’s about what we have and how we pass it further. It’s about information and how it will return to us. Finally, it’s just about that in programming world we cannot stop communicating. Maybe it sounds silly, especially in stereotypical thinking about programmers closed in basements, but the truth is that every application is built from many layers, which are sharing data in continuous mode.

Why do these layers need to communicate? It's because sometimes data needs to be written in one layer and read by another, or one layer needs to be informed about an update in another layer so that it can react appropriately.

What is Data Binding?

Data binding is a programming mechanism, which is responsible for connecting and synchronizing data from at least two different sources.

We can found it in many places. Most classic example is connection between view of an app (User Interface) with data that has to be displayed. Important and valuable is that data change in one place automatically updates data in another place.

Before we focus on different types of bindings, I would like to point that we shouldn’t connect that technique only with Javascript world. We can find Data Binding in web apps (built with Angular or React), mobile apps or in backend technologies (it’s worth to enumerate JavaFX, Java Spring, ASP.NET or Windows Presentation Foundation). Every mentioned technology uses Data Binding for creating dynamic interactions between data models and view layer.

One way or two ways?

As I mentioned above, data can be passed in different way. Basically everything is about who can communicate with who and who has an impact on who. We can highlight one-way data binding and two-way data binding.

One-way bindings are a relatively simple form of binding where data flows only in one direction. Typically, this involves displaying data from a model on a view. A good example from Angular ecosystem would be a component where we have a separation between the view file (HTML) and the component file with logic (TS). The Typescript file, in this case, serves as the data model which passes data to the view. The view is responsible for displaying this data. Let’s look at the example:

In the AppComponent class, there is a public field named „title”, which contains the text „Hello!”. Note that in the html file associated with this component, the „title” variable is used in a notation with double curly brackets. The data will be displayed on the view, but the view cannot make any changes in the data model, which is the component file.

The architecture of React assumes that flow of data is unidirectional by default. The data are passed between components through props (component properties) only in one direction.

The Button component is displaying label based on data, which are passed from top from component App. As you can see it works only in one direction. The Button component cannot influence on the shape of data in parent component.

Bananas in the Box

There may be situations where we want to pass data to the view and update the model accordingly. Basically two-way binding allows us reflect changes on the view when the data in the model changes, but also update the model when the changes occur on the view, for example when user triggered it.

For example: let’s say we have a form in our application. The data from it should be transformed on our component level in order to make them usable for next steps that are connected with user choices. Usually we would create an event handler that takes the passed data and sends them to the model, which finally will work with them.

The famous "bananas in the box” syntax isn’t nothing different than standard notation, which allows us to create two-way directional communication between model and view.

The above syntax replaces two attributes: event handling - (which is typically denoted with parentheses „()”, namely bananas) and binding data - „[]” namely box.

From children to parent

React, by default, assumes unidirectional data flow. This assumption stems from the way how component architecture is organized in React applications. However, it doesn’t mean that we cannot create different type of binding data where the flow would be reversed from the default one (not from parent to children, but from children to parent).

To achieve that, we need to use the same mechanism that we use for preparing unidirectional connections, specifically props. Instead of passing a value to the child component, we need to pass a callback function, which will be executed in the child component with the proper data. Then, the change would be passed to the top of the components tree.

Note the above example. The child component (in this case, „ActionButton”) executes a function that it received from the top, with data that it wants pass to the parent component level.

Other types of bindings

It’s worth to add that besides from two previously mentioned binding, we can enumerate two another: one-way-to-source binding and one-time binding. First of them is reverse version of one-way binding. It lies in the fact that it works from view to the model, not from model to the view.

One-time binding is characterized by the fact that data on the view aren’t automatically updated. This approach is useful, when we need only snapshot of data and the data are static.

Summary

Data binding is common technique. It’s typically used in every app. I cited few examples from modern frontend applications. Probably I could extend above examples with code in other languages, but I believe these examples are interesting and provide a fairly comprehensive view of what data binding is.

Remember to take care of the relationships not only the private ones, but also those between each part of your application.