{"action":"created","issue":{"url":"https://api.github.com/repos/webcomponents/gold-standard/issues/1","repository_url":"https://api.github.com/repos/webcomponents/gold-standard","labels_url":"https://api.github.com/repos/webcomponents/gold-standard/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/webcomponents/gold-standard/issues/1/comments","events_url":"https://api.github.com/repos/webcomponents/gold-standard/issues/1/events","html_url":"https://github.com/webcomponents/gold-standard/issues/1","id":60590621,"number":1,"title":"Recommendations for generating change events when an attribute has updated?","user":{"login":"JanMiksovsky","id":86139,"avatar_url":"https://avatars.githubusercontent.com/u/86139?v=3","gravatar_id":"","url":"https://api.github.com/users/JanMiksovsky","html_url":"https://github.com/JanMiksovsky","followers_url":"https://api.github.com/users/JanMiksovsky/followers","following_url":"https://api.github.com/users/JanMiksovsky/following{/other_user}","gists_url":"https://api.github.com/users/JanMiksovsky/gists{/gist_id}","starred_url":"https://api.github.com/users/JanMiksovsky/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JanMiksovsky/subscriptions","organizations_url":"https://api.github.com/users/JanMiksovsky/orgs","repos_url":"https://api.github.com/users/JanMiksovsky/repos","events_url":"https://api.github.com/users/JanMiksovsky/events{/privacy}","received_events_url":"https://api.github.com/users/JanMiksovsky/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2015-03-11T00:11:49Z","updated_at":"2016-12-13T23:50:03Z","closed_at":null,"body":"From @RobDodson:\n\n> Before I forget, I'm not sure if the checklist includes well behaved components firing change events when an attribute has updated, but I think this is important for data binding systems like Angular 2.\n\nI assume the idea here is that if you create an instance of <my-element>, then change the foo attribute, you may be expecting the element to raise a “change” event.\n\nI'm not sure whether there's any behavior here that's recognized as good by enough people that we can craft a checklist item for it, but I'm open to the idea.\n"},"comment":{"url":"https://api.github.com/repos/webcomponents/gold-standard/issues/comments/266899262","html_url":"https://github.com/webcomponents/gold-standard/issues/1#issuecomment-266899262","issue_url":"https://api.github.com/repos/webcomponents/gold-standard/issues/1","id":266899262,"user":{"login":"robdodson","id":1066253,"avatar_url":"https://avatars.githubusercontent.com/u/1066253?v=3","gravatar_id":"","url":"https://api.github.com/users/robdodson","html_url":"https://github.com/robdodson","followers_url":"https://api.github.com/users/robdodson/followers","following_url":"https://api.github.com/users/robdodson/following{/other_user}","gists_url":"https://api.github.com/users/robdodson/gists{/gist_id}","starred_url":"https://api.github.com/users/robdodson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/robdodson/subscriptions","organizations_url":"https://api.github.com/users/robdodson/orgs","repos_url":"https://api.github.com/users/robdodson/repos","events_url":"https://api.github.com/users/robdodson/events{/privacy}","received_events_url":"https://api.github.com/users/robdodson/received_events","type":"User","site_admin":false},"created_at":"2016-12-13T23:50:03Z","updated_at":"2016-12-13T23:50:03Z","body":"I spoke with some Blink engineers about this. Let me try to answer the above points in order.\r\n\r\n> So the first question is: do we want to treat those differently? That is, do we want component authors to raise events when an attribute changes, or when a property changes, or both? Those options are related, because most authors will have an attributedChangedCallback set the corresponding property.\r\n\r\nAs a general rule of thumb, I don't think we want every property/attribute to dispatch an event. To quote one of the Blink engineers: \"In the platform today most 'property changed' events don't fire if you manually set the property because it's assumed that you were the one setting it.\" It would also be quite spammy and possibly expensive if every property change dispatched an event.\r\n\r\nHaving said that, there may be exceptions because the platform is not consistent here. Apparently setting the `src` property of an `img` dispatches a `load` event.\r\n\r\n> Does the standard HTML behavior make sense globally for an essentially infinite number of custom elements?\r\n\r\nI think it's a good model to follow and it's what frameworks and libraries are already written to understand.\r\n\r\n> A third, related question is: Is the standard HTML behavior really obvious?\r\n\r\nI guess for me it's non-obvious only because prior to Custom Elements I didn't spend much time building components to exactly model what the DOM does today. But I think it's a teachable pattern. Again, saying every property should dispatch an event will probably get very expensive/spammy.\r\n\r\n> Fourth question: How would data binding systems (Polymer, Ember, etc.) work without change events for properties?\r\n\r\nThe same way it listens to native checkbox today. Polymer's `notify` stuff is primarily for two-way data binding but two-way bindings are an opinionated, framework-specific pattern. It's not something the platform natively supports and it's not even something that all frameworks universally support or favor.\r\n\r\n> Fifth question: I’m not completely certain of this, but given the above issue, I’m concerned that people composing complex UI components from multiple, smaller components will have to carefully keep track of which things are happening in direct response to user interactions and which are happening because of changes imposed by the outer application.\r\n\r\nThis is how native HTML works today and I don't think we have major issues there. Each element I'm composing is essentially a black box to me, so I can ignore why it's dispatching its change event and just listen for it.\r\n\r\n> Sixth question: How can component behavior be properly factored if there is a direct relationship between user interactions and property effects?\r\n\r\nI think this becomes less of an issue if we remove the `mixin` from the equation. Personally I question the value of behavior mixins. I realize not having mixins leads to code duplication in elements but I've seen first hand how elaborate and confusing mixins have made some Polymer Elements. I'm not a big fan but that's just my personal opinion :)\r\n\r\nDoes the `mixin` have to use an event dispatch? Could it use a callback instead? Maybe override the setter and whenever it gets called, at the very end do `callback(this.selectedItem)`. \r\n\r\n> Seventh question: How should components handle situations in which they update multiple properties in response to a single user event?\r\n\r\nDoes removing the `mixin` make this easier to reason about?\r\n\r\n> Eighth question: Should the prevention of the infinite loop be the dominant concern here?\r\n\r\nIt seems fair to want the frameworks out there watch out for this. But I think another reason to avoid having every property fire an event would be to avoid spamminess.\r\n\r\nI'm curious what @treshugart thinks about all this :D"}}
{"actor":{"display_login":"robdodson"}}