4 ms·

I'm very happy to see that one-way binding is now supported within templates, with syntax that sets it apart from two-way binding: https://www.polymer-project.

I'm very happy to see that one-way binding is now supported within templates, with syntax that sets it apart from two-way binding: https://www.polymer-project.org/1.0/docs/devguide/data-bindi.. https://www.polymer-project.org/1.0/docs/devguide/data-bindi.... That option may have become available some time ago, but I haven't looked at Polymer in quite awhile. Two-way binding can be a great and convenient thing, but having it as the only option, in the early days of Polymer, led to many headaches (for me, at least). The reason is that two-way binding can make it practically impossible to reason deterministically about data flow when several or more bindings come into play.

spankalee 11y ago
I like the one-way bindings myself, but one thing I've never reconciled with the one-way is the one-true-way view is that in a one-way only world you tend to wire up more event listeners to deal with data changes and inputs, and those listeners can be all over the place with arbitrary side-effects. A two-way binding ends up being shorthand for a specific type of event handler with a known side-effect, making them easier to find and reason about. Maybe I'm missing some other aspect to the one-way-only view though.
- michaelsbradley 11y ago
  Arbitrary side-effects can be a recipe for problems, definitely. One-way flow is, to my mind, best used in conjunction with persistent data structures and some tangible mechanism to coordinate state changes under a single reference, or a small set of references.