@polymer/polymer

v3.4.0 (2020-04-23)

New global settings

This update to Polymer includes some new global settings:

• legacyUndefined / setLegacyUndefined

  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:

  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 / setLegacyWarnings

  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. For example:

  import {PolymerElement, html} from '@polymer/polymer/polymer-element.js';
  
  class SomeElement extends PolymerElement {
    static get template() {
      return html`<span>[[someProperty]] is used here</span>`;
    }
  
    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 and update when that attribute changes. 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 / setOrderedComputed

  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:

  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 + 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.

  If your component's computed property graph contains cycles, the order in which they are run when using orderedComputed is still undefined.

  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 / setFastDomIf

  What does it do? This setting enables a different implementation of <dom-if> 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 <dom-if> is in the shadow root of a Polymer element: you can't use a <dom-if> directly in the main document or inside a shadow root of an element that doesn't extend PolymerElement.

  • Second, because the fastDomIf implementation of <dom-if> 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 <dom-if> will no longer 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 <dom-if> as described in the section above.

• removeNestedTemplates / setRemoveNestedTemplates

  What does it do? This setting causes Polymer to remove the child <template> elements used by <dom-if> and <dom-repeat> from the their containing templates. This can improve the performance of cloning your component's template when new instances are created.

  Should I use it? This setting is generally recommended.

• suppressTemplateNotifications / setSuppressTemplateNotifications

  What does it do? This setting causes <dom-if> and <dom-repeat> not to dispatch dom-change events when their rendered content is updated. If you're using lots of <dom-if> and <dom-repeat> but not listening for these events, this setting lets you disable them and their associated dispatch work.

  You can override the global setting for an individual <dom-if> or <dom-repeat> by setting its notify-dom-change boolean attribute:

  import {PolymerElement, html} from '@polymer/polymer/polymer-element.js';
  
  class SomeElement extends PolymerElement {
    static get properties() {
      return {
        visible: {type: Boolean, value: false},
      };
    }
  
    static get template() {
      return html`
        <button on-click="_toggle">Toggle</button>
        <!-- Set notify-dom-change to enable dom-change events for this particular <dom-if>. -->
        <dom-if if="[[visible]]" notify-dom-change on-dom-change="_onDomChange">
          <template>
            Hello!
          </template>
        </dom-if>
      `;
    }
  
    _toggle() {
      this.visible = !this.visible;
    }
  
    _onDomChange(e) {
      console.log("Received 'dom-change' event.");
    }
  }
  
  customElements.define('some-element', SomeElement);
  

  Should I use it? This setting is generally recommended.

• legacyNoObservedAttributes / setLegacyNoObservedAttributes

  What does it do? This setting causes LegacyElementMixin not to use the browser's built-in mechanism for informing elements of attribute changes (i.e. observedAttributes and attributeChangedCallback), which lets Polymer skip computing the list of attributes it tells the browser to observe. Instead, LegacyElementMixin simulates this behavior by overriding attribute APIs on the element and calling attributeChangedCallback itself.

  This setting has similar API restrictions to those of the custom elements polyfill. You should only use the element's setAttribute and removeAttribute methods to modify attributes: using (e.g.) the element's attributes property to modify its attributes is not supported with legacyNoObservedAttributes and won't properly trigger attributeChangedCallback or any property effects.

  Components can override the global setting by setting their _legacyForceObservedAttributes property to true. This property's effects occur at startup; it won't have any effect if modified at runtime and should be set in the class definition.

  Should I use it? This setting should only be used if startup time is significantly affected by Polymer's class initialization work - for example, if you have a large number of components being loaded but are only instantiating a small subset of them. Otherwise, this setting is not recommended.

• useAdoptedStyleSheetsWithBuiltCSS / setUseAdoptedStyleSheetsWithBuiltCSS

  What does it do? If your application is uses pre-built Shady CSS styles and your browser supports constructable stylesheet objects, this setting will cause Polymer to extract all <style> elements from your components' templates, join them into a single stylesheet, and share this stylesheet with all instances of the component using their shadow roots' adoptedStyleSheets array. This setting may improve your components' memory usage and performance depending on how many instances you create and how large their style sheets are.

  Should I use it? Consider using this setting if your app already uses pre-built Shady CSS styles. Note that position-dependent CSS selectors (e.g. containing :nth-child()) may become unreliable for siblings of your components' styles as a result of runtime-detected browser support determining if styles are removed from your components' shadow roots.

Other new features

<dom-repeat>

• reuseChunkedInstances

  What does it do? This boolean property causes <dom-repeat> to reuse template instances even when items is replaced with a new array, matching the Polymer 1 behavior.

  By default, a <dom-repeat> with chunking enabled (i.e. initialCount >= 0) will drop all previously rendered template instances and create new ones whenever the items array is replaced. With reuseChunkedInstances set, any previously rendered template instances will instead be repopulated with data from the new array before new instances are created.

  Should I use it? This flag is generally recommended and can improve rendering performance of chunked <dom-repeat> instances with live data.

LegacyElementMixin

• disable-upgrade

  What does it do? LegacyElementMixin now has built-in support for the disable-upgrade attribute (usually provided by DisableUpgradeMixin) that becomes active when the global legacyOptimizations setting is enabled, matching the Polymer 1 behavior.

  Should I use it? Consider using this setting if you are already using the legacyOptimizations setting and migrating older components that depend on disable-upgrade without explicit application of DisableUpgradeMixin.

Bug fixes

<dom-repeat>

• Chunking behavior

  <dom-repeat> no longer resets the number of rendered instances to initialCount when modifying items with PolymerElement's array modification methods (splice, push, etc.). The number of rendered instances will only be reset to initialCount if the items array itself is replaced with a new array object.

  See #5631 for more information.

All commits

• [ci skip] bump to 3.4.0 (commit)

• shareBuiltCSSWithAdoptedStyleSheets -> useAdoptedStyleSheetsWithBuiltCSS (commit)

• formatting (commit)

• Fix incorrect JSDoc param name. (commit)

• Gate feature behind shareBuiltCSSWithAdoptedStyleSheets; update tests. (commit)

• Add shareBuiltCSSWithAdoptedStyleSheets global setting (commit)

• Add stalebot config (commit)

• Annotate more return types as !defined (#5642) (commit)

• Ensure any previously enqueued rAF is canceled when re-rendering. Also, use instances length instead of renderedItemCount since it will be undefined on first render. (commit)

• Improve comment. (commit)

• Remove obsolete tests. (commit)

• Simplify by making limit a derived value from existing state. This centralizes the calculation of limit based on changes to other state variables. (commit)

• Update Sauce config to drop Safari 9, add 12 & 13. Safari 9 is now very old, and has micro task ordering bugs issues that make testing flaky. (commit)

• Remove accidental commit of test.only (commit)

• When re-enabling, ensure __limit is at a good starting point and add a test for that. Also: * Ensure __itemsArrayChanged is cleared after every render. * Enqueue __continueChunkingAfterRaf before notifying renderedItemCount for safety (commit)

• Remove accidental commit of suite.only (commit)

• Ensure limit is reset when initialCount is disabled. Note that any falsey value for initialCount (including 0) is interpreted as "chunking disabled". This is consistent with 1.x logic, and follows from the logic of "starting chunking by rendering zero items" doesn't really make sense. (commit)

• Updates from review. * Refactoring __render for readability * Removing __pool; this was never used in v2: since we reset the pool every update and items are only ever pushed at detach time and we only detach at the end of updates (as opposed to v1 which had more sophisticated splicing) (commit)

• Store syncInfo on the dom-if, but null it in teardown. (same as invalidProps for non-fastDomIf) (commit)

• Fixes for several related dom-repeat chunking issues. Fixes #5631. * Only restart chunking (resetting the list to the initialCount) if the items array itself changed (and not splices to the array), to match Polymer 1 behavior. * Add reuseChunkedInstances option to allow reusing instances even when items changes; this is likely the more common optimal case when using immutable data, but making it optional for backward compatibility. * Only measure render time and throttle the chunk size if we rendered a full chunk of new items. Ensures that fast re-renders of existing items don't cause the chunk size to scale up dramatically, subsequently causing too many new items to be created in one chunk. * Increase the limit by the chunk size as part of any render if there are new items to render, rather than only as a result of rendering. * Continue chunking by comparing the filtered item count to the limit (not the unfiltered item count). (commit)

• Update comment. (commit)

• Store syncInfo on instance and don't sync paths. Fixes #5629 (commit)

• Avoid Array.find (doesn't exist in IE) (commit)

• Add comment to skip. (commit)

• Skip test when custom elements polyfill is in use (commit)

• Copy flag to a single location rather than two. (commit)

• Lint fix. (commit)

• Update test name. (commit)

• Introduce opt-out per class for legacyNoObservedAttributes (commit)

• Ensure telemetry system works with legacyNoObservedAttributes setting (commit)

• Update package-lock.json (commit)

• Update test/unit/inheritance.html (commit)

• Fix testing issues with latest webcomponentsjs (commit)

• Allow undefined in legacy _template field to fall-through to normal lookup path. (commit)

• re-add npm cache (commit)

• regen package-lock (commit)

• mispelled services, node 10 for consistency (commit)

• modernize travis (commit)

• Adds support for imperatively created elements to legacyNoObservedAttributes (commit)

• Rebase sanitize dom value getter onto legacy-undefined-noBatch (#5618) (commit)

• Add getSanitizeDOMValue to settings API (#5617) (commit)

• FIx closure annotation (commit)

• Fix closure annotation. (commit)

• legacyNoObservedAttributes: Ensure user created runs before attributesChanged (commit)

• Enable tests for legacyNoObservedAttributes (commit)

• Only auto-use disable-upgrade if legacyOptimizations is set. (commit)

• Adds disable-upgrade functionality directly to LegacyElementMixin (commit)

• Add doc comment (commit)

• Lint fixes. (commit)

• Update externs. (commit)

• Update extern format. (commit)

• Address review feedback. (commit)

• Address review feedback (commit)

• Lint fixes. (commit)

• Adds legacyNoAttributes setting (commit)

• [ci skip] update changelog (commit)

• Update polymer externs for new settings. (commit)

• Update lib/utils/settings.js (commit)

• Changes based on review. (commit)

• Add basic support for adoptedStyleSheets (commit)

• [ci skip] Add/fix comments per review. (commit)

• Add missing externs for global settings. (commit)

• Revert optimization to not wrap change notifications. This was causing a number of rendering tests to fail. Needs investigation, but possibly because wrapping calls ShadyDOM.flush, and this alters distribution timing which some tests may have inadvertently relied on. (commit)

• Reintroduce suppressTemplateNotifications and gate Dom-change & renderedItemCount on that. Matches Polymer 1 setting for better backward compatibility. (commit)

• Add notifyDomChange back to dom-if & dom-repeat to match P1. (commit)

• Simplify host stack, set __dataHost unconditionally, and make _registerHost patchable. (commit)

• Move @private annotation to decorate class definition. (commit)

• Add type for _overrideLegacyUndefined. (commit)

• Attempt to fix travis issues (commit)

• Revert isAttached change based on review feedback. Deemed a breaking change. (commit)

• Update travis to use xenial distro and, latest Firefox, and node 10 (commit)

• Applies micro-optimizations and removes obsolete settings (commit)

• Work around Closure Compiler bug to avoid upcoming type error (commit)

• Only import each file once (#5588) (commit)

• Avoid Array.from on Set. (commit)

• Update nested template names. (commit)

• Add runtime stamping tests around linking & unlinking effects. (commit)

• Ensure parent is linked to child templateInfo. Fixes fastDomIf unstopping issue. (commit)

• Remove unused TemplateInfo properties from types. (commit)

• Add other used TemplateInfo property types. (commit)

• Add type for TemplateInfo#parent. (commit)

• [ci-skip] Add comment explaining confusing check in _addPropertyToAttributeMap (commit)

• Ensure clients are flushed when runtime stamping via _stampTemplate. Maintains flush semantics with Templatizer stamping (relevant to fastDomIf, which is a switch between Templatizer-based stamping and runtime _stampTemplate-based stamping). Works around an issue with noPatch where nested undistributed dom-if's won't stamp. The changes to the tests are to remove testing that the full host tree is correct since the host doing the runtime stamping will no longer be the DOM getRootNode().host at ready time (this is exactly the case with Templatizer, whose semantics we intend to match). (commit)

• Fix template-finding issue with DisableUpgrade mixin. The existing rules are that prototype._template is first priority and dom-module via is is second priority for a given class. A subclass has a new shot at overriding the previous template either by defining a new prototype._template or a new is resulting in a dom-module lookup. However, trivially subclassing a Polymer legacy element breaks these rules, since if there is no own prototype._template on the current class, it will lookup a dom-module using is from up the entire prototype chain. This defeats the rule that a prototype._template on the superclass should have taken priority over its dom-module. This change ensures that we only lookup dom-module if the class has an own is property. (commit)

• Fix issue with camel cased properties and disable-upgrade (commit)

• More closure fixes. (commit)

• closure fixes (commit)

• lint fixes (commit)

• Fix issue with defaults overriding bound values when disable-upgrade is used. (commit)

• Add closure types (commit)

• Use DisbleUpgradeMixin in legacy class generation (commit)

• Add comment about why code is duplicated. (commit)

• Add tests for connected/disconnected while disabled (commit)

• Improve comments. (commit)

• Added comments. (commit)

• Fix typo and improve readbility (commit)

• Enable disable-upgrade when legacyOptimizations is set to true (commit)

• Remove use of Object.create on template info (significant perf impact). (commit)

• Attempt to sync host properties on every call to _showHideChildren. Fixes an issue where a dom-if that is toggled synchronously true-false-true could fail to sync properties invalidated while false, since the hidden state is only checked at render timing, and the newly added dirty-check could fail if the hidden state has been changed back to its initial value. (commit)

• Add tests for extension and dom-if/repeat (commit)

• Update stand alone disable-upgrade mixin. (commit)

• Remove cruft from test (commit)

• Simplify logic for disable-upgrade (commit)

• Use a safer flag, based on internal testing. (commit)

• Reorder based on review feedback. (commit)

• Fix closure type. (commit)

• Updated comment. (commit)

• Ensure hasPaths is also accumulated as part of info necessary to sync. (commit)

• Fix one more closure annotation. (commit)

• Simplify algorithm; we already have list of computed deps in effect list. (commit)

• Build computed graph from dependencies, rather than properties. (commit)

• Fix closure annotations for dom-if. (commit)

• Avoid lint warnings. (commit)

• Minor simplifications/comments. (commit)

• Updates from review. (commit)

• Closure type fixes. (commit)

• Initialize all settings from Polymer object when available. (commit)

• Fix host prop merging. (commit)

• Updates based on review. (commit)

• Fix defaults back to false for new settings. (commit)

• Add a dirty check to showHideChildren (commit)

• Fix host property syncing (commit)

• Adds disable-upgrade directly into legacy Polymer elements (commit)

• Refactor DomIf into separate subclasses. (commit)

• Runtime stamped dom-if (commit)

• dom-if/dom-repeat bind-to-parent (commit)

• Fix a few closure compiler issues (commit)

• [ci skip] Add comment (commit)

• Fix typo in comment (commit)

• Cleanup, add tests. * remove old implementation * add API docs * rename some API * add dynamicFn to dep count * add test for method as dependency (commit)

• [wip] Add additional topo-sort based algorithm. (commit)

• Dedupe against a single turn on only under orderedComputed (commit)

• Fix closure issues (commit)

• Add hasPaths optimziation (commit)

• Minor comment updates (commit)

• Evaluate computed property dependencies first. Fixes #5143 (commit)

• Add more externs (commit)

• Fix lint warnings (commit)

• Add comments per review feedback (commit)

• Add legacyNotifyOrder. Improve comments. (commit)

• Add test for literal-only static function. (commit)

• Remove unnecessary literal check (commit)

• Simplify (commit)

• Add templatizer warnings. Move to legacyWarnings flag. (commit)

• Add legacyUndefined and legacyNoBatch to externs (commit)

• NOOP has to be an array for closure compiler (commit)

• Add comments on warning limitations. (commit)

• Ensure properties are set one-by-one at startup. (commit)

• Remove unnecessary qualification. (commit)

• Avoid over-warning on templatizer props and "static" dynamicFns. (commit)

• Store splices directly on array when legacyUndefined is set (commit)

• Fix test (commit)

• Add arg length check (commit)

• Adds legacyNoBatch setting (commit)

• Add tests for legacyUndefined setting (commit)

• Adds legacyUndefined setting (commit)