I will be honest.

This is about relationships. But not just any relationships. It is about what we have and how we pass it further. It is also about how that information comes back to us. In the end, it is simply about the fact that in programming, you cannot not communicate. It sounds silly, especially in a reality filled with stereotypes about programmers locked away in basements. The truth is that every application consists of different layers that continuously exchange data with each other.

Why do they do that? Because sometimes data has to be saved somewhere, sometimes it has to be updated somewhere else, and sometimes one layer simply needs to be informed about new data so it can react properly.

What Is Data Binding?

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

We can meet it in many places. The most classic example is connecting an application's view, or user interface, with the data that should appear in that view. What is important and valuable here is that changing data in one place automatically refreshes that data in another place.

Before we focus on the different kinds of bindings we can create, I would like to point out that we should not associate this technique only with the world of JavaScript. We can find data binding in web applications, both in Angular and React, in mobile applications, and also in backend technologies. Here it is worth mentioning JavaFX, Java Spring, ASP.NET, or Windows Presentation Foundation. Each of these technologies uses data binding to create dynamic interactions between data models and the view.

One Way or Two Ways?

I have already mentioned that data can be passed in different ways. In practice, this comes down to who can communicate with whom and who can affect whom. We can distinguish one-way data binding and two-way data binding.

One-way bindings are relatively simple. The point is that data flows in only one direction. Most often, this will mean displaying data from the model in the view. In Angular, a good example would be a component where we have a split between a view file (HTML) and a logic/component file (TS). In our case, the TypeScript file will be the data model that passes data to the view, where it will be displayed. Let us look at the example below:

<h1>{{ title }}</h1>

@Component({
  selector: 'app-component',
  templateUrl: './app.component.html'
})
export class AppComponent {
  title = "Hello!"
}

The AppComponent class has a public title field containing the text "Hello!". Notice that in the HTML file connected with this component, the title variable is used in double curly brace notation. The data will be displayed in the view, but the view cannot make any changes to the model, meaning the component file.

React's architecture, on the other hand, assumes one-way data flow by default. Notice that data is passed between components through props, or component properties, in only one direction.

const Button = ({ label }) => {
  return <button>{label}</button>
}

const App = () => {
  const value = "Hello!";
  
  return (
    <Button label={value} />
  )
}

The Button component will display a label based on the data it receives "from above", from the App component. As we can see, this works only one way. The Button component cannot affect the shape of the data in the parent component.

Bananas in a Box

There may, however, be a situation where we want to pass data to the view and modify the model accordingly. In general, two-way binding lets us reflect a change in the view when data in the model changes, but also update the model when a change happens on the view side, for example through a user action.

For example: we use a form in our application, and we want to process the data from that form further from inside our component, so we can perform the next steps connected with the user's choices. Usually, we will create an event that uses the entered data in order to send it to the model and handle it there.

The famous bananas in a box syntax is nothing more than a writing convention that allows two-way communication between the model and the view.

<input [(value)]="value" >

The syntax above replaces the separation of the event binding attribute, meaning () - the bananas, and the data from the model, meaning [] - the box.

From Child to Parent

As a rule, React assumes one-way data flow. This assumption comes from the way component architecture is organized in React applications. It does not mean, however, that we cannot create another kind of data binding where the flow is the opposite of the default one, so not from parent to child, but from child to parent.

To achieve this, we will use the same mechanism that we use to create a one-way connection, namely props. It is enough that instead of passing a value to the child component, we pass a callback that will be handled appropriately on the child side. Then the change will be passed up the tree.

const ActionButton = ({ handleClick }) => {

	return <button onClick={() => handleClick('clicked!')}>Action!</button>
}

const App = () => {
  const [value, setValue] = useState();

	return <ActionButton handleClick={(value) => setValue(value)} />
}

Pay attention to the construction above. The child component, in this case ActionButton, calls a function it receives from above with the data it wants to introduce at the parent component level.

Other Types of Binding

It is worth adding that apart from the two types mentioned above, we can distinguish two more ways of binding data: one-way-to-source and one-time. The first one is actually the reverse of one-way binding. It consists of creating a one-way binding that works from the view to the model, but not the other way around.

One-time binding is characterized by the fact that data in the view, or in the receiving application, is not automatically updated. This approach is useful when we only need a snapshot of the data and the data itself is static.

Summary

Data binding is a fairly common technique. In fact, it is used at almost every step. I have shown a few examples from modern frontend applications. I could probably expand the examples above with other languages, but it seems to me that these are interesting enough and give a fairly broad view of what data binding is.

Remember: take care of relationships, not only the private ones, but also the ones between the individual parts of your application.