From 0da4e63f264e26dd1919d2f3043bf7661c20e03a Mon Sep 17 00:00:00 2001 From: Russell Bicknell Date: Thu, 26 Mar 2020 13:38:47 -0700 Subject: [PATCH 01/12] Remove unused externs. --- externs/polymer-externs.js | 6 ------ 1 file changed, 6 deletions(-) diff --git a/externs/polymer-externs.js b/externs/polymer-externs.js index f49bf21e0a..0413192d4b 100644 --- a/externs/polymer-externs.js +++ b/externs/polymer-externs.js @@ -138,15 +138,9 @@ Polymer.syncInitialRender; /** @type {boolean} */ Polymer.legacyUndefined; -/** @type {boolean} */ -Polymer.legacyNoBatch; - /** @type {boolean} */ Polymer.legacyWarnings; -/** @type {boolean} */ -Polymer.legacyNotifyOrder; - /** @type {boolean} */ Polymer.orderedComputed; From d80fdca088dfcd87657234d0684e68ac00819c10 Mon Sep 17 00:00:00 2001 From: Russell Bicknell Date: Fri, 27 Mar 2020 16:12:37 -0700 Subject: [PATCH 02/12] Started on release notes for `legacyUndefined`, `legacyWarnings`, `orderedComputed`. (...) These might be too large for release notes and may be better off moved to the docs site. --- CHANGELOG.md | 91 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 144757faa4..50c5767fe0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,96 @@ # Change Log +## Unreleased + +### New settings + +This update to Polymer includes some new [global settings](https://polymer-library.polymer-project.org/3.0/docs/devguide/settings): + +- `legacyUndefined` + + **What does it do?** This setting reverts how computed properties handle `undefined` values to the Polymer 1 behavior: when enabled, computed properties will only be recomputed if none of their dependencies are `undefined`. + + Components can override the global setting by setting their `_overrideLegacyUndefined` property to `true`. This is useful for reenabling the default behavior as you migrate individual components: + + ```js + import {PolymerElement, html} from '@polymer/polymer/polymer-element.js'; + + class MigratedElement extends PolymerElement { /* ... */ } + + // All MigratedElement instances will use the default behavior. + MigratedElement.prototype._overrideLegacyUndefined = true; + + customElements.define('migrated-element', SomeElement); + ``` + + **Should I use it?** This setting should only be used for migrating legacy codebases that depend on this behavior and is otherwise **not recommended**. + +- `legacyWarnings` + + **What does it do?** This setting causes Polymer to warn if a component's template contains bindings to properties that are not listed in that element's [`properties` block](https://polymer-library.polymer-project.org/3.0/docs/devguide/properties). For example: + + ```js + import {PolymerElement, html} from '@polymer/polymer/polymer-element.js'; + + class SomeElement extends PolymerElement { + static get template() { + return html`[[someProperty]] is used here`; + } + + static get properties() { + return { /* but `someProperty` is not declared here */ }; + } + } + + customElements.define('some-element', SomeElement); + ``` + + Only properties explicitly declared in the `properties` block are [associated with an attribute](https://polymer-library.polymer-project.org/3.0/docs/devguide/properties#property-name-mapping) and [update when that attribute changes](https://polymer-library.polymer-project.org/3.0/docs/devguide/properties#attribute-deserialization). Enabling this setting will show you where you might have forgotten to declare properties. + + **Should I use it?** Consider using this feature during development but don't enable it in production. + +- `orderedComputed` + + **What does it do?** This setting causes Polymer to topologically sort each component's computed properties graph when the class is initialized and uses that order whenever computed properties are run. + + For example: + + ```js + import {PolymerElement, html} from '@polymer/polymer/polymer-element.js'; + + class SomeElement extends PolymerElement { + static get properties() { + return { + a: {type: Number, value: 0}, + b: {type: Number, computed: 'computeB(a)'}, + c: {type: Number, computed: 'computeC(a, b)'}, + }; + } + + computeB(a) { + console.log('Computing b...'); + return a + 1; + } + + computeC(a, b) { + console.log('Computing c...'); + return a * 2 + b * 2; + } + } + + customElements.define('some-element', SomeElement); + ``` + + When `a` changes, Polymer's default behavior does not specify the order in which its dependents will run. Given that both `b` and `c` depend directly on `a`, one of two possible orders could occur: [`computeB`, `computeC`] or [`computeC`, `computeB`]. + + - In the first case - [`computeB`, `computeC`] - `computeB` is run with the new value of `a` and produces a new value for `b`. Then, `computeC` is run with both the new values of `a` and `b` to produce `c`. + + - In the second case - [`computeC`, `computeB`] - `computeC` is run first with the new value of `a` and the _current_ value of `b` to produce `c`. Then, `computeB` is run with the new value of `a` to produce `b`. If `computeB` changed the value of `b` then `computeC` will be run again, with the new values of both `a` and `b` to produce the final value of `c`. + + However, with `orderedComputed` enabled, the computed properties would have been previously sorted into [`computeB`, `computeC`], so updating `a` would cause them to run specifically in that order. + + **Should I use it?** The value of this setting depends on how your computed property functions are implemented. If they are pure and relatively inexpensive, you shouldn't need to enable this feature. If they have side effects that would make the order in which they are run important or are expensive enough that it would be a problem to run them multiple times for a property update, consider enabling it. + ## [v3.3.1](https://github.com/Polymer/polymer/tree/v3.3.1) (2019-11-08) - [ci skip] bump to 3.3.1 ([commit](https://github.com/Polymer/polymer/commit/11f1f139)) From 3b6494bf0fd44f390cc6da6b371dc0d7c077dd51 Mon Sep 17 00:00:00 2001 From: Russell Bicknell Date: Mon, 30 Mar 2020 14:33:35 -0700 Subject: [PATCH 03/12] Added notes for `fastDomIf`, `removeNestedTemplates`, `suppressNestedTemplates`, and `suppressTemplateNotifications`. --- CHANGELOG.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 50c5767fe0..36f42184a9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -91,6 +91,40 @@ This update to Polymer includes some new [global settings](https://polymer-libra **Should I use it?** The value of this setting depends on how your computed property functions are implemented. If they are pure and relatively inexpensive, you shouldn't need to enable this feature. If they have side effects that would make the order in which they are run important or are expensive enough that it would be a problem to run them multiple times for a property update, consider enabling it. +- `fastDomIf` + + **What does it do?** This setting enables a different implementation of `` that uses its host element's template stamping facilities (provided as part of `PolymerElement`) rather than including its own. This setting can help with performance but comes with a few caveats: + + - First, `fastDomIf` requires that every `` is in the shadow root of a Polymer element: you can't use a `` directly in the main document or inside a shadow root of an element that doesn't extend `PolymerElement`. + + - Second, because the `fastDomIf` implementation of `` doesn't include its own template stamping features, it doesn't create its own scope for property effects. This means that any properties you were previously setting on the `` will no longr be applied within its template, only properties of the host element are available. + + **Should I use it?** This setting is recommended as long as your app doesn't use `` as described in the section above. + +- `removeNestedTemplates` + + **What does it do?** This setting causes Polymer to remove the child `