{"action":"closed","issue":{"url":"https://api.github.com/repos/leeoniya/domvm/issues/60","repository_url":"https://api.github.com/repos/leeoniya/domvm","labels_url":"https://api.github.com/repos/leeoniya/domvm/issues/60/labels{/name}","comments_url":"https://api.github.com/repos/leeoniya/domvm/issues/60/comments","events_url":"https://api.github.com/repos/leeoniya/domvm/issues/60/events","html_url":"https://github.com/leeoniya/domvm/issues/60","id":151524076,"number":60,"title":"Redraws should always be, async, queued and coalesced.","user":{"login":"lawrence-dol","id":8662551,"avatar_url":"https://avatars.githubusercontent.com/u/8662551?v=3","gravatar_id":"","url":"https://api.github.com/users/lawrence-dol","html_url":"https://github.com/lawrence-dol","followers_url":"https://api.github.com/users/lawrence-dol/followers","following_url":"https://api.github.com/users/lawrence-dol/following{/other_user}","gists_url":"https://api.github.com/users/lawrence-dol/gists{/gist_id}","starred_url":"https://api.github.com/users/lawrence-dol/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lawrence-dol/subscriptions","organizations_url":"https://api.github.com/users/lawrence-dol/orgs","repos_url":"https://api.github.com/users/lawrence-dol/repos","events_url":"https://api.github.com/users/lawrence-dol/events{/privacy}","received_events_url":"https://api.github.com/users/lawrence-dol/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":21,"created_at":"2016-04-28T00:42:46Z","updated_at":"2016-04-29T19:30:32Z","closed_at":"2016-04-29T19:30:32Z","body":"I want to make the argument that telling a DOMVM vm to \"redraw\" is really telling it that one of the models on which it depends has been updated and that it needs to redraw at the end of the current event cycle. It is nothing more than an indication that the view is now out of step with the model.\r\n\r\nIf it lies within DOMVM's power to make it easy to request a redraw instead of redrawing inline it absolutely should do so, rather than have every application reinvent some kind of coalescing/deferred-redraw logic.\r\n\r\nFor example, if an event causes 17 different model properties to change, it should not execute the redraw code 17 within that even handler; it is necessary only to do it once. \r\n\r\nAs well, immediately changing the view often results in counter-intuitive behavior per below.\r\n\r\nHere is a fiddle based on the test branch for #57 that doesn't crash with an exception but does loose input on the two properties that don't use `domvm.watch` because of the counter-intuitive action of updating the views inline.\r\n\r\nhttps://jsfiddle.net/LawrenceDol/yjyhm9se/\r\n\r\nIn this case it happens because the built-in \"change function\" is invoked before the value is actually updated internally because one of the purposes of the change function is to override, even suppress the change under some conditions. So during view rendering, the property value is refetched before it's been updated. \r\n\r\nNote the console output of:\r\n\r\n````\r\n17:34:49.049 Property: new value 2 new value 2a _display:104:13\r\n17:34:49.050 Property: new value 2 undefined _display:104:13\r\n17:34:49.051 Property Value: new value 2 _display:112:13\r\n17:34:49.051 Property: new value 3 undefined _display:104:13\r\n17:34:49.051 Property Value: new value 3 _display:112:13\r\n17:34:49.053 Property Value: new value 2a _display:112:13\r\n````\r\n\r\nWhere the property starts to change, is accessed for read, and then the change completes. The access for read is due to the `redraw`.\r\n\r\nIf there is some reason why redraw cannot always coalesce within the same event, then there should be a separate function that never executes in line, such as `modelUpdated` or `update`, similar to what all GUI toolkits offer. Ideally, such a function should only set a flag that a redraw is required, and that flag would be checked (if this is possible) at the end of every event handled by the application. It would be less desirable to simply queue a new event (though that would be better than nothing), since that, in turn, will result in possible event queuing race conditions.\r\n\r\nThis is not intended to describe how the end-result is achieved, but rather, the semantics of that end-result. It is possible that this might be, of necessity, an application-level construction, though that would be unfortunate. Such a feature would mitigate or eliminate #57.\r\n\r\nPS: Since `update` is already used, perhaps `remodel`."}}