[w3c/webcomponents] missing guidance on implementing an 'refresh' option. (#562)

A lot of custom elements are build to encapsulate some form of data-entry.  Have a look at the date-pickers and sliders and so on.
What I miss is a default way to tell an custom element that I provided new data to it, and I want it to update its view to reflect this change.
For attributes this is possible with the `attributeChangedCallback()`. However as attributes only support strings, a lot of elements expose a property in stead of a attribute.
if an property gets updates like this:

```
querySelector('my-custom-element').myProperty = new Date()
```
It will not get picked up by `attributeChangedCallback()`. 

Due to missing guidance on this, every custom element builder solves this on their own way. One likes setter methods. Other listen for some-property-changed events.  And yet another exposes an callback on the custom element. 

I thinks this is a severe oversight. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/562

Received on Tuesday, 6 September 2016 16:21:23 UTC