Rethink all of the two-way data bindings
lastmjs opened this issue · comments
I believe that two-way data bindings are harmful. The unmanaged mutations are dangerous and can lead to unchecked complexity. These issues and the resulting PR are an example of this:
Both of these issues relate to the same problem:
Here is the PR to fix it:
It was hard (not that hard, but indirect) to track down why the __query property in <app-location> was changing, because that property, the query property in <iron-location>, and the paramsString property in <iron-query-params> are all two-way data bound to each other. That means any change in any of those components will change all of the properties.
I've had troubles dealing with these components in the past because of their two-way data binding and the ensuing inability to know when the properties were changing. I think these components should be rethought with events and one-way bindings in mind.
The team agrees with this sentiment as is why our best-practices have changed to use two-way databinding only when absolutely necessary. Our current catalog of elements though are in a general feature freeze; we are only fixing bugs and adding features presented in PRs that address highly-requested features.
For now, we ask that people fork our elements for large breaking changes. 3.0 will likely be a Polymer 3.0 compatibility update in order to help smooth migrations