From d1ad0c3383b72711ad4396534c3dba3f467a87af Mon Sep 17 00:00:00 2001 From: Kevin Schaaf Date: Fri, 23 Jun 2017 10:34:32 -0700 Subject: [PATCH] [ci skip] Fix link closing quotes. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2360063803..81f602b8ab 100644 --- a/README.md +++ b/README.md @@ -475,7 +475,7 @@ Polymer 2.0 will continue to use a [shim](https://github.com/webcomponents/shady 1. property-changed event notification (`notify: true`, including any side-effects on host elements for the bound property changes) * Multi-property observers, computed methods, and computed bindings are now called once at initialization if any arguments are defined (and will see `undefined` for any undefined arguments). As such, the [1.x rule requiring all properties of a multi-property observer to be defined](https://www.polymer-project.org/1.0/docs/devguide/observers#multi-property-observers) no longer applies, as this was a major source of confusion and unintended consequences. Subsequently setting multi-property method arguments will cause the method to be called once for each property changed via accessors, or once per batch of changes via `setProperties({...})`. * Declaring a method name used as an observer or computing function in the `properties` block causes the method property itself to become a dependency for any effects it is used in, meaning the effect for that method will run whenever the method is set, similar to 1.x. However, due to removing the `undefined` rule noted above, in 2.x if such a method exists when the element is created, it will run with initial values of arguments, even in the case some or all arguments are `undefined`. -* ` are no longer supported. In this case you should simply user a `bar` observer in the host. Use cases such as dynamically adding a `property-changed` event listener on for properties bound by an element's host by an actor other than the host are no longer supported. +* ‘notify’ events are no longer fired when value changes _as result of binding from host_, as a major performance optimization over 1.x behavior. Use cases such as `` are no longer supported. In this case you should simply user a `bar` observer in the host. Use cases such as dynamically adding a `property-changed` event listener on for properties bound by an element's host by an actor other than the host are no longer supported. * In order for a property to be deserialized from its attribute, it must be declared in the `properties` metadata object * The `Polymer.Collection` and associated key-based path and splice notification for arrays has been eliminated. See [explanation here](https://github.com/Polymer/polymer/pull/3970#issue-178203286) for more details. * While not a breaking change, Polymer now ships with a `Polymer.MutableData` mixin (and legacy `Polymer.MutableDataBehavior` behavior) to provide more options for managing data. By default, `Polymer.PropertyEffects` performs strict dirty checking on objects, which means that any deep modifications to an object or array will not be propagated unless "immutable" data patterns are used (i.e. all object references from the root to the mutation were changed). Polymer also provides a proprietary data mutation and path notification API (e.g. `notifyPath`, `set`, and array mutation API's) that allow efficient mutation and notification of deep changes in an object graph to all elements bound to the same object graph. In cases where neither immutable patterns or the data mutation API can be used, applying this mixin will cause Polymer to skip dirty checking for objects and arrays and always consider them to be "dirty". This allows a user to make a deep modification to a bound object graph, and then either simply re-set the object (e.g. `this.items = this.items`) or call `notifyPath` (e.g. `this.notifyPath('items')`) to update the tree. Note that all elements that wish to be updated based on deep mutations must apply this mixin or otherwise skip strict dirty checking for objects/arrays.