{"action":"created","issue":{"url":"https://api.github.com/repos/barneycarroll/mattr/issues/2","labels_url":"https://api.github.com/repos/barneycarroll/mattr/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/barneycarroll/mattr/issues/2/comments","events_url":"https://api.github.com/repos/barneycarroll/mattr/issues/2/events","html_url":"https://github.com/barneycarroll/mattr/issues/2","id":96525562,"number":2,"title":"Why allow transformers to replace the vElm node?","user":{"login":"maranomynet","id":86827,"avatar_url":"https://avatars.githubusercontent.com/u/86827?v=3","gravatar_id":"","url":"https://api.github.com/users/maranomynet","html_url":"https://github.com/maranomynet","followers_url":"https://api.github.com/users/maranomynet/followers","following_url":"https://api.github.com/users/maranomynet/following{/other_user}","gists_url":"https://api.github.com/users/maranomynet/gists{/gist_id}","starred_url":"https://api.github.com/users/maranomynet/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/maranomynet/subscriptions","organizations_url":"https://api.github.com/users/maranomynet/orgs","repos_url":"https://api.github.com/users/maranomynet/repos","events_url":"https://api.github.com/users/maranomynet/events{/privacy}","received_events_url":"https://api.github.com/users/maranomynet/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-07-22T09:58:17Z","updated_at":"2015-07-22T14:00:26Z","closed_at":null,"body":"Hi. I'm curious why you allow transformer functions to replace the virtual element node:\r\nhttps://github.com/barneycarroll/mattr/blob/master/index.js#L33\r\n\r\nIt looks to me like this leads to unpredictable behaviour - as the for-loop is already fixed on, and half-way through, the property names of the original vElm. And if the transformer returns a node made by a `mattr` enhanced function, you might even end up with double transformations on some attributes.\r\n\r\nThe safest/sanest option might be to simply exit the for-loop when a transformer returns something other than `undefined`, like so:\r\n\r\n```js\r\nif ( transformed !== undefined ) {\r\n    node = transformed;\r\n    break;\r\n}\r\n```\r\n\r\nOr am I missing something obvious?"},"comment":{"url":"https://api.github.com/repos/barneycarroll/mattr/issues/comments/123731738","html_url":"https://github.com/barneycarroll/mattr/issues/2#issuecomment-123731738","issue_url":"https://api.github.com/repos/barneycarroll/mattr/issues/2","id":123731738,"user":{"login":"barneycarroll","id":83627,"avatar_url":"https://avatars.githubusercontent.com/u/83627?v=3","gravatar_id":"","url":"https://api.github.com/users/barneycarroll","html_url":"https://github.com/barneycarroll","followers_url":"https://api.github.com/users/barneycarroll/followers","following_url":"https://api.github.com/users/barneycarroll/following{/other_user}","gists_url":"https://api.github.com/users/barneycarroll/gists{/gist_id}","starred_url":"https://api.github.com/users/barneycarroll/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/barneycarroll/subscriptions","organizations_url":"https://api.github.com/users/barneycarroll/orgs","repos_url":"https://api.github.com/users/barneycarroll/repos","events_url":"https://api.github.com/users/barneycarroll/events{/privacy}","received_events_url":"https://api.github.com/users/barneycarroll/received_events","type":"User","site_admin":false},"created_at":"2015-07-22T14:00:26Z","updated_at":"2015-07-22T14:00:26Z","body":"Yeah to be honest when I read your proposal it made immediate obvious sense — I was going to ask you to file a pull request, but then by talking through the root of the problem I realised it adds code without solving any problems.\r\n\r\nThe truth is there's no clear user expectation for a transform not to run: if anything, breaking the loop is a violation of user expectation. The scenario where the user puts several custom attributes on a node and one returns a new node does not necessarily mean the others shouldn't run (in fact object iteration order differs between Javascript engines, so in one browser the replacing transform may occur 1st, cancelling further transforms, while in another it could run last). So adding this behaviour would only add more possibilities for confusion.\r\n\r\nI guess this minefield should be documented, with the advice that users should take care to avoid composing nodes with potentially contradictory custom attributes — and, where they really do want the behaviour of several custom attributes which could lead to different outcomes depending on what order they execute in, to compose new attributes that invoke the others in the desired order…"}}