What is Angular's "unidirectional data flow rule"?

Question

Angular's "unidirectional data flow rule" is mentioned several times in the docs but nowhere do the Angular docs ever clearly (emphasis on clearly) define the unidirectional data flow rule.

Here are the closest things I could find to a clear definition of the unidirectional data flow rule:

From this page:

Angular's unidirectional data flow rule forbids updates to the view after it has been composed.

Fair enough, but what exactly does it mean for a view to have been composed? What constitutes an update to the view? Aren't we updating views all the time?

From this page:

One important assertion [enableProdMode] disables verifies that a change detection pass does not result in additional changes to any bindings (also known as unidirectional data flow).

I had to read this sentence about 8 times very slowly and I still don't get it. When it says "also known as unidirectional data flow", I'm assuming the thing that's also known as unidirectional data flow is "that a change detection pass does not result in additional changes to any bindings". Okay, maybe we're getting closer. Pretty abstract though. How about an example or something?

---

These two fairly opaque blurbs are all the Angular docs apparently give us to go off of regarding the unidirectional data flow rule. Seems insufficient.

Can anyone explain it to me more clearly, preferably as if I'm very stupid?

---

Edit: I found what might be a third clue, on this page:

A template expression should not change any application state other than the value of the target property.

This rule is essential to Angular's "unidirectional data flow" policy. You should never worry that reading a component value might change some other displayed value. The view should be stable throughout a single rendering pass.

Okay. You should never worry that reading a component value might change some other displayed value. Is that Angular's unidirectional data flow rule? I wouldn't think so because it doesn't seem to agree with the other mentions of the rule. I'm still confused.

Answer 1

In Angular pre v1.5, two way binding was the norm, so if you created a child object in a component, the parent maintained a reference to it, so if you updated the object in the parent, it updated the child, and if you updated the object in the child, it updated the parent. This incurred a lot of overhead, and you'd see significant performance impact with a large number of child components maintaining two way bindings to the parent, for example, a parent container component loading a list of passenger data and displaying a child component for each passenger with the specific attributes for that passenger. The parent is watched for changes, and every child is watched for changes, and they're constantly being re-evaluted.

One way data binding was introduced in Angular1.5, but is a big part of Angular2's performance gains. Data flows from the parent to the child, but not the other way round. If the parent data changes, those changes are pushed down to the child, but if the child changes, those changes are not auto-magically propagated back to the parent. You manage updates from the child to the parent by explicitly sending an event back up to the parent with the changed data, and instructing the parent to update the specific data that's changed. One way data flow then takes over and the parent, with updated data, updates the children as appropriate.