It was my understanding after reading this www.polymer-project.org/docs/polymer/polymer.html#attrreflection (sorry, not allowed to include more than two links), that Property values are reflected back into their attribute counterpart
That doesn't look to be the case in 37.0.2007.2 canary with experimental Web Platform features enabled.
For instance, have a look at the console http://jsbin.com/fihan/2/edit
Another example is in Eric's Bidelman video at 19min 58s:
I would expect the Element panel to update <demo-tab selected="0"> to <demo-tab selected="1">
Thanks !
This is a recent change on the Polymer side (not Chrome) where property values are no longer reflected back to their attribute value. It's now opt-in for perf. You need to use the publish block with reflect: true:
publish: {
foo: {value: 'foo', reflect: true}
}
http://jsbin.com/qavavina/1/edit
We have yet to get the documented :( https://github.com/Polymer/docs/issues/402
Related
Where can I find a full API reference for PolymerElements?
For example, the description for PaperDialogBehavior says
Use the dialog-dismiss and dialog-confirm attributes on interactive controls to close the dialog. If the user dismisses the dialog with dialog-confirm, the closingReason will update to include confirmed: true.
But I can't find any further information anywhere about what closingReason actually is (a property? a parameter passed to some callback?) and how it "includes" confirmed: true.
Instead of wasting time on guessing how to do every single little thing when using Polymer, it would be nice to have an actual API reference. Is there one?
There isn't any further information. Documentation isn't well written and you have to find many things on your own. Just remember that everything in Polymer is about properties. So closingReson is property that you can access on paper-dialog (or any other elements using paperDialogBehavior).
This property contains object {confirmed: true|false}
Truly said, behaviors has extremely badly written documentations. It is very confusing. For example:
modal: boolean = false
If modal is true, this implies no-cancel-on-outside-click, no-cancel-on-esc-key and with-backdrop.
but none of those properties are specified in paperDialogBehavior, because it is inherited from iron-overlay-behavior. And these inheritences are not documented (mostly).
I'm a bit amazed I haven't been able to find an explanation for how to do this as it seems like it's fairly elemental to debugging, but I can't find anywhere how to print the attributes of an object in Polymer.
I'm learning Polymer and I keep running into situations where I have an object, but I have no idea what the attributes are of the object. (Ex. I print to the window, and I get [object Object]. I've found some explanations for how to print a list of the keys/attributes of an object (I know how to print the values for those keys if I know what they are), but I have no idea how to get the keys if I don't already know the format of my data. Every example presumes you already know what the attributes are.
I've seen solutions recommending adding a script like:
getKeys : function(o){
return Object.keys(o);
}
And then they recommend something like this:
<template is="dom-repeat" items="{{ item in obj | getKeys}}">
{{item}}
</template>
But I think they must work off maybe an earlier version of polymer. Most are from 2014-ish and I know the library has changed a lot since then.
This is the closest thing I get to an error with this code:
Polymer::Attributes: couldn`t decode Array as JSON
Here's an example post recommending this strategy. I understand I could dig deeper into the documentation and try to understand what response is supposed to be coming back, but I'm more curious what the general strategy is for this situation - I've multiple times wanted to check to see how polymer was modeling something vs how I thought it was.
The post you mention recommends a method that is no longer possible with post-1.0 Polymer, which does not support that syntax of filtering/pipes (as of the current release, 1.5.0).
You could use DevTools to select the Polymer element and then run console.dir($0). This works in the following browsers (and maybe older versions):
Chrome 50
Firefox 45
Safari 9.1
Opera 39
Chrome and Opera display all keys (even inherited ones from HTMLElement) in sorted order, so it can be tedious to scan through the long list of keys for a Polymer-specific property. However, Firefox and Safari list Polymer-specific keys first and then the inherited ones.
One workaround for Chrome/Opera is to use this snippet:
((o) => {
let obj = {};
Object.keys(o).sort().forEach((x) => {
obj[x] = o[x];
});
console.dir(obj);
})($0);
Here's a codepen that logs the attributes of a paper-button. You don't need to click the button. Open the browser's console log (not the Codepen console) to see something like the screenshot below. You can expand the fields in the console log to see the attributes of the Polymer object.
The solution I have been using is the following:
Place a button somewhere on the visible page.
When that button is tapped, print the object to the console.
my-element.html
<button on-tap="show">Click here to see user</button>
...
show: function() {
console.log('user', this.user);
},
...
You can also use console.dir() as follows.
<my-element id="foo"></my-element>
...
bar: function() {
console.dir( this.$.foo );
}
In Polymer 1.0 you can drop {{localPropFoo.bar}} and bar will be observed for changes if you use this.set('localPropFoo.bar', 'new value'); to update its value.
But what to do if you want to bind template to an external object which is out of your control? E.g., this {{window.globalFoo.bar}} won't be bound to bar changes because external code doesn't depend on Polymer and doesn't call this.set.
Demo on codepen
Using Object.observe manually requires extra code and doesn't work in FireFox (dirty checks of observe.js to the rescue).
I want to know what is the idiomatic way of data binding to external objects out of your control.
Polymer doesn't do observation out of the box, because:
Object.observe support is not ubiquitous and dirty checks are expensive.
Object.observe may be expensive on itself.
Supposed Solution
Catch changes yourself, call notifyPath, this.fire('global-foo-changed', {path: 'globalFoo.bar', value:...}, this.set and this.push.
They all dispatch corresponding non-bubbling (capturing) globalFoo-changed custom events (only when needed).
Why my global-foo-changed events affect only this element?
global-foo-changed events are capturing (non-bubbling).
Polymer elements listen for bubbling events by default.
For some reason these capturing listeners capture bubble events dispatched from the same element (not from its children). Demo on codepen.
You may patch polymer with this behavior (I don't understand how it works):
SharedGlobalsBehavior = {
properties: {
globalFoo: {
type: Object,
notify: true,
value: globalFoo
}
},
created: function() {
window.addEventListener('global-foo-changed', () => {
if (!event.detail || !event.detail.path)
return; // Property initialization.
this.notifyPath(event.detail.path, event.detail.value);
},/* if capturing */ true);
}
};
Why No Observation Out of the Box
...sometimes imperative code needs to change an object’s sub- properties directly. As we avoid more sophisticated observation mechanisms such as Object.observe or dirty-checking in order to achieve the best startup and runtime performance cross-platform for the most common use cases, changing an object’s sub-properties directly requires cooperation from the user.
Specifically, Polymer provides two methods that allow such changes to be notified to the system: notifyPath(path, value) and set(path, value), where path is a string identifying the path (relative to the host element).
I can get my <iron-meta> instance to work properly when using a static value. But when I bind the value to a dynamic variable (using {{}}) it <iron-meta> no longer behaves as expected.
Does <iron-meta> support binding its value to dynamic variables?
<iron-meta id="meta" key="info" value="foo/bar"></iron-meta> // works
<iron-meta id="meta" key="info" value="{{str}}"></iron-meta> // fails
Previous work
This question is a refinement of this question in order to clarify that the ONLY thing causing the problem is the change from a static string value to a dynamic string value binding. I was getting a lot of other suggesting that had nothing to do with the change from static to dynamic so I thought it might be best to rewrite the question to clarify that. But the entire code context is contained in the links there if that would help.
Alternative solutions
There has been some recent chatter about using <iron-localstorage>. Perhaps that is the best way to go for dynamic binding essentially creating global variables?
Yes, <iron-meta> does support binding to variables, but perhaps not in the way you think.
Example: http://plnkr.co/edit/QdNepDrg9b3eCTWF6oRO?p=preview
I looked through your code here, here, and here but I'm not entirely clear what your expectations are. Hopefully my attached repro might shed some light. I see you have declaratively bound <iron-meta id="meta" key="route" xvalue="foo-bar" value="{{route}}"></iron-meta> which is fine - when route changes, iron-meta's key="route" will update accordingly.
However, be aware that in Polymer 1.0, <iron-meta> is in essence a one-way bind from parent to child in the sense that you set a meta key value dynamically by binding to a property; but to get that value, you'll have to get it imperatively via iron-meta's byKey() method.
<iron-meta> is just a simple monostate pattern implementation without an in-built path notification mechanism. What this means is value changes do not propagate upwards. Therefore, doing something like
<!-- this does not work like the way you think -->
<iron-meta id="meta" key="foo" value="{{bar}}">
in order to get the value of foo, or listen to changes to foo, does not work. This behaves more like a setter, where you set the value of foo based on your data-bound property bar.
From what I gather, it seems that you're trying to implement some sort of global variable functionality. A monostate implementation used to work in Polymer 0.5, but not in 1.0. Unfortunately, until Google endorses a "best-practice" pattern for this, suggestions till-date seems a bit speculative to me. You might find this (Polymer 1.0 Global Variables) helpful.
I have had success using <iron-signals> to communicate global information. I know there is a warning in the <iron-signals> documentation that discourages its use for related elements, but when broadcasting a shared resource it seems just the thing. For example:
// source element
var db = SomeDB.init();
this.fire('iron-signal', { name: 'database', data: db });
<-- sink element -->
<iron-signals on-iron-signal-database="dbChange"></iron-signals>
class SinkElement {
dbChange(e, detail) {
this.db = detail;
this.db.getSomeData();
}
}
Given an element instance, how do I see how many observers it's maintaining?
I'm trying to figure if either of these implementations is more expensive.
Polymer({
fooChanged: function() {
this.bar = foo.baz;
}
}
Polymer({
computed: {
'bar': 'foo.baz'
}
}
I suspect they're equivalent (except that one is watching foo, the other is watching the path) but I want to be sure.
Internally, Polymer uses uses Node.bind() to bind the property changes.
It will use PathObserver to watch 'foo.baz' and of course, it's slower to watch a computed object like that versus a single attribute.
https://www.polymer-project.org/docs/polymer/node_bind.html
You can check all the event listeners in the chrome dev tools. Select the ID in the console and on the right you have the "event listeners" tab.
See:
Using Chrome, how to find who's binded to an event?
But I doubt this will show you anything performance wise. I think it is better to use the CPU profile in the profiles tab in the chrome dev tools.