Closed
Description
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
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
kevinpschaaf commentedon Jul 9, 2015
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.Don't create private setter for computed properties. Fixes #2016.
Don't create private setter for computed properties. Fixes #2016.
jlg7 commentedon Jul 9, 2015
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.
Merge pull request #2056 from Polymer/2016-kschaaf-computed-setter