Skip to content

#1.0.5 computed property function name limitations? #2016

Closed
@jlg7

Description

@jlg7

Hey Guys,

I upgraded from 1.0.4 and 1.0.5 and noticed there are new limitations for naming computed property functions.

Example:

<link rel="import" href="bower_components/polymer/polymer.html">
<link rel="import" href="bower_components/layout/layout.html">


<dom-module id="sample-element">
  <template>
    <h1>#1</h1>
    <div>{{_computeJonsFavorite(GestaltGroupingLaws)}}</div>
    <h1>#2 (doesn't work)</h1>
    <div>{{nextMostFavorite}}</div>
    <h1>#2 (for real)</h1>
    <div>{{nextMostFavoriteThatWorks}}</div>
  </template>
</dom-module>

<script>
  Polymer({
    is:'sample-element',
    behaviors:[],
    properties:{
        gestaltGroupings:{
          type:Array,
          value: function(){
            return [
             "Proximity",
             "Similarity",
             "Closure",
             "Symmetry",
             "Common_Fate",
             "Continuity",
             "Good_Gestalt",
             "Past_Experience"
           ];
          }
        },
        GestaltGroupingLaws:{
          type:Object,
          computed:'toKeys(gestaltGroupings)'
        },
        nextMostFavorite:{
          type:String,
          computed:'_setNextMostFavorite(GestaltGroupingLaws)'
        },
        nextMostFavoriteThatWorks:{
          type:String,
          computed:'_nextMostFavorite(GestaltGroupingLaws)'
        }
    },

    _computeJonsFavorite:function(gestaltKeys){
      if(gestaltKeys)
          return gestaltKeys.Symmetry;
      return "";  
    }, 
     _setNextMostFavorite:function(gestaltKeys){
      if(gestaltKeys)
          return gestaltKeys.Proximity;
      return "";  
    }, 
    _nextMostFavorite:function(gestaltKeys){
         if(gestaltKeys)
          return gestaltKeys.Proximity;
      return "";
    },
    toKeys: function(gestaltGroupings){
         if(gestaltGroupings){  
          var obj = {};
          for(var i=0; i < gestaltGroupings.length; i++)
            obj[gestaltGroupings[i]] = gestaltGroupings[i];
          return obj;   
         }
         return {};
    }
});
</script>

What is the preferred means for staying current on limitations of function and property names? I poked around in the docs and primer but was unable to locate this. I can definitely use "_", "_compute" or "_update"; however, more concerned about keeping up with limitations.

Let me know if the example or question is not clear!

Best

@jongeho1

Activity

kevinpschaaf

kevinpschaaf commented on Jul 9, 2015

@kevinpschaaf
Member

In v1.0.5 we made computed properties implicitly read-only, since users should never set computed properties directly. That had a side effect of computed properties getting the conventional private setter created (e.g. _setNextMostFavorite), by virtue of it being treated as a read-only property.

This was probably an oversight; the computed property logic does not actually use that named setter, so it need not create it. We'll fix that in the next release.

The only thing you should be aware of for naming conflicts going forward is that readOnly: true properties will get a setter named _set<PropertyName> on the prototype.

added 2 commits that reference this issue on Jul 9, 2015
b98b847
980f22e
self-assigned this
on Jul 9, 2015
jlg7

jlg7 commented on Jul 9, 2015

@jlg7
Author

Thank you, the "0.5" label for version may not apply. Would something like this be candid for hydrolysis? I don't know how volatile this may be but can be observed via static analysis.

added a commit that references this issue on Jul 9, 2015

Merge pull request #2056 from Polymer/2016-kschaaf-computed-setter

58eaa8f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @jlg7@kevinpschaaf

      Issue actions

        #1.0.5 computed property function name limitations? · Issue #2016 · Polymer/polymer