Fully support ES6 Getters with Class Syntax

[ChadKillingsworth]

ES6 getters provide an excellent (and standardized) alternative to computed properties. While the change notification is no longer automatic, static analysis and refactoring tools are supported.

Currently to properly support ES6 getters you have to modify internal private properties:

function enableGetters(Superclass) {
  return class extends Superclass {
    /**
     * Overrides the default `Polymer.PropertyEffects` to ensure
     * ES6 getter properties are supported 
     *
     * @override
     */
    _initializeProperties() {
      const proto = Object.getPrototypeOf(this);
      proto['__dataHasAccessor'] = this['__dataHasAccessor'] || {};
      const getterProps = new Set();

      // Mark any getters on the prototype so that Polymer doesn't add it's own
      // This has to be done before calling super
      const propNames = Object.getOwnPropertyNames(proto);
      propNames.forEach(propName => {
        const descriptor = Object.getOwnPropertyDescriptor(proto, propName);
        if (!(descriptor && descriptor.get)) {
          return;
        }

        // Indicate to Polymer that this property already has an accessor function
        // so that Polymer doesn't add another one.
        proto['__dataHasAccessor'][propName] = true;
        getterProps.add(propName);
      });

      super._initializeProperties();

      // For every getter, add a propagate effect
      getterProps.forEach(propName => {
        this._addPropertyEffect(
          propName,
          this.PROPERTY_EFFECT_TYPES.PROPAGATE,
          {
            'fn': (elem, propName) => {
                elem['__data'][propName] = elem[propName];
            }
          });
      });
    }
  }
}

[jfrazzano]

Thank you. That might have been the best thing I got on any electronic device In 6 months I was asking one variety or another of that question since September. I never thought I would get answer. I was going just delete my way through dom object prototype chain and then the window object to at least understand some of the seeming mass of infinite repeating property references was actually necessary . Still curious Thanks . Thanks really so much. I had the idea that events weren't really needed save a few it I already had turned all my click mouse focus and taps to string composition; then gonna try and implement selective interception ala a 2010 talk by Brendan eich it's minute 24. I was the just going to use a property mirror in what remaindow I frame or window. And take care of rest with js. Use nose side to take everything apart before a first load. Hold a seed on the used side that could be live or require a match set for auth. Let's just say the idea was the result of heavy frustration and a no adding and changing set of new restrictions. It's figured no one would expect a systematic recordederasure of everything And since a lot of impossible and less of impossible seemed like the sane thing Aside: why not use the wrapped return of an unnamed object in ur getter you can stack properties in this object and while they can be enumerator and configurable. You can't see them in an inspection it says no properties I thought that was awesome. Sub getter takes args if needed to and can be used with setter to dynamically add to proxy objects Although controlling dom was like impossible with proxy. So just used an object it was fine Sorry for going on but You guys taught me so much. You can't say anything about above I know Opinion is divided. it's complicated Will send any code or results that are interesting or leave them open pen Sincerely, Jason

…

On Fri, May 12, 2017 at 12:08 PM Jason Frazzano ***@***.***> wrote: On Fri, May 12, 2017 at 12:07 PM Jason Frazzano ***@***.***> wrote: > > On Fri, May 12, 2017 at 12:06 PM Jason Frazzano ***@***.***> > wrote: > >> >> On Fri, May 12, 2017 at 7:40 AM Jason Frazzano ***@***.***> >> wrote: >> >>> >>> On May 12, 2017, at 7:15 AM, Chad Killingsworth < >>> ***@***.***> wrote: >>> >>> ES6 getters provide an excellent (and standardized) alternative to >>> computed properties. While the change notification is no longer automatic, >>> static analysis and refactoring tools are supported. >>> >>> Currently to properly support ES6 getters you have to modify internal >>> private properties: >>> >>> function enableGetters(Superclass) { >>> return class extends Superclass { >>> /** * Overrides the default `Polymer.PropertyEffects` to ensure * ES6 getter properties are supported * * @OverRide */ >>> _initializeProperties() { >>> const proto = Object.getPrototypeOf(this); >>> proto['__dataHasAccessor'] = this['__dataHasAccessor'] || {}; >>> const getterProps = new Set(); >>> >>> // Mark any getters on the prototype so that Polymer doesn't add it's own >>> // This has to be done before calling super >>> const propNames = Object.getOwnPropertyNames(proto); >>> propNames.forEach(propName => { >>> const descriptor = Object.getOwnPropertyDescriptor(proto, propName); >>> if (!(descriptor && descriptor.get)) { >>> return; >>> } >>> >>> // Indicate to Polymer that this property already has an accessor function >>> // so that Polymer doesn't add another one. >>> proto['__dataHasAccessor'][propName] = true; >>> getterProps.add(propName); >>> }); >>> >>> super._initializeProperties(); >>> >>> // For every getter, add a propagate effect >>> getterProps.forEach(propName => { >>> this._addPropertyEffect( >>> propName, >>> this.PROPERTY_EFFECT_TYPES.PROPAGATE, >>> { >>> 'fn': (elem, propName) => { >>> elem['__data'][propName] = elem[propName]; >>> } >>> }); >>> }); >>> } >>> } >>> } >>> >>> — >>> You are receiving this because you are subscribed to this thread. >>> Reply to this email directly, view it on GitHub >>> <#4595>, or mute the thread >>> <https://github.com/notifications/unsubscribe-auth/AHxnvl5Rv1NxVJ4J4h2ftCrDjqyI5iJVks5r5D9BgaJpZM4NZJ71> >>> . >>> >>> >>> -- >> _________________________________ >> Jason C. Frazzano Esq. >> Founder and Master Coach, Focused Coaching >> Stanford University, B.A. M.A., with honors and distinction >> Columbia Law School, J.D., Stone Scholar >> www.focusedcoaching.com >> ***@***.*** >> ***@***.*** >> office: 732-671-1834 >> >> -- > _________________________________ > Jason C. Frazzano Esq. > Founder and Master Coach, Focused Coaching > Stanford University, B.A. M.A., with honors and distinction > Columbia Law School, J.D., Stone Scholar > www.focusedcoaching.com > ***@***.*** > ***@***.*** > office: 732-671-1834 > > -- _________________________________ Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com ***@***.*** ***@***.*** office: 732-671-1834 --

_________________________________ Jason C. Frazzano Esq. Founder and Master Coach, Focused Coaching Stanford University, B.A. M.A., with honors and distinction Columbia Law School, J.D., Stone Scholar www.focusedcoaching.com [email protected] [email protected] office: 732-671-1834

[sorvell]

Sorry for the delay on this. We'd really like to address this issue but think it may not make sense to layer on top of the current data binding system. There are a number of issues:

1. the getter is not always used in the data-binding system. Instead the code often just looks for data in the private __data storage.

2. the setter is not always used in the data-binding system. API like setProperties and _setPendingProperty, for example, do not directly call the property setter.

3. For computed properties, polymer relies on the dependencies if finds in the computed property section to know when the computed "getter" should be called and any properties bound to that updated.

4. The contract in _propertiesChanged is that all property values are available in the first argument. This would not be the case for any manually defined getters. While probably not fatal, this is something to contemplate.

That said, if these issues can be addressed via a PR in a way that makes sense, we would consider it.

[TimvdLippe]

Closing per #4815 (comment)