{"action":"created","issue":{"url":"https://api.github.com/repos/dojo/parser/issues/3","labels_url":"https://api.github.com/repos/dojo/parser/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/dojo/parser/issues/3/comments","events_url":"https://api.github.com/repos/dojo/parser/issues/3/events","html_url":"https://github.com/dojo/parser/issues/3","id":111358674,"number":3,"title":"Parser Objects versus Compose Objects","user":{"login":"kitsonk","id":1282577,"avatar_url":"https://avatars.githubusercontent.com/u/1282577?v=3","gravatar_id":"","url":"https://api.github.com/users/kitsonk","html_url":"https://github.com/kitsonk","followers_url":"https://api.github.com/users/kitsonk/followers","following_url":"https://api.github.com/users/kitsonk/following{/other_user}","gists_url":"https://api.github.com/users/kitsonk/gists{/gist_id}","starred_url":"https://api.github.com/users/kitsonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kitsonk/subscriptions","organizations_url":"https://api.github.com/users/kitsonk/orgs","repos_url":"https://api.github.com/users/kitsonk/repos","events_url":"https://api.github.com/users/kitsonk/events{/privacy}","received_events_url":"https://api.github.com/users/kitsonk/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/dojo/parser/labels/discussion","name":"discussion","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-10-14T09:29:45Z","updated_at":"2015-10-30T14:19:16Z","closed_at":null,"body":"The parser proposal indicates that the API signature of a parser class would be something like this:\r\n\r\n```typescript\r\ninterface ParserObject {\r\n    node: HTMLElement;\r\n    id: string;\r\n    [name: string]: any;\r\n}\r\n\r\ninterface ParserConstructor<T extends ParserObject, O> {\r\n    new (node: HTMLElement, options?: O): T;\r\n}\r\n```\r\n\r\nWhile the compose proposal follows the following:\r\n\r\n```typescript\r\ninterface ComposeConstructor {\r\n  new (options?: any): any;\r\n}\r\n```\r\n\r\nIn order to make the API consistent, it maybe better to change the parser proposal to something like this:\r\n\r\n```typescript\r\ninterface ParserConstructorOptions {\r\n    node: HTMLElement;\r\n    [option: string]: any;\r\n}\r\n\r\ninterface ParserObject {\r\n    node: HTMLElement;\r\n    id: string;\r\n    [name: string]: any;\r\n}\r\n\r\ninterface ParserConstructor<T extends ParserObject, O extends ParserConstructorOptions> {\r\n    new (options?: O): T;\r\n}\r\n```\r\n\r\nIn this case only a single `options` argument is passed on object instantiation, which would have a mandatory `node` property."},"comment":{"url":"https://api.github.com/repos/dojo/parser/issues/comments/152538615","html_url":"https://github.com/dojo/parser/issues/3#issuecomment-152538615","issue_url":"https://api.github.com/repos/dojo/parser/issues/3","id":152538615,"user":{"login":"jdonaghue","id":78551,"avatar_url":"https://avatars.githubusercontent.com/u/78551?v=3","gravatar_id":"","url":"https://api.github.com/users/jdonaghue","html_url":"https://github.com/jdonaghue","followers_url":"https://api.github.com/users/jdonaghue/followers","following_url":"https://api.github.com/users/jdonaghue/following{/other_user}","gists_url":"https://api.github.com/users/jdonaghue/gists{/gist_id}","starred_url":"https://api.github.com/users/jdonaghue/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdonaghue/subscriptions","organizations_url":"https://api.github.com/users/jdonaghue/orgs","repos_url":"https://api.github.com/users/jdonaghue/repos","events_url":"https://api.github.com/users/jdonaghue/events{/privacy}","received_events_url":"https://api.github.com/users/jdonaghue/received_events","type":"User","site_admin":false},"created_at":"2015-10-30T14:19:16Z","updated_at":"2015-10-30T14:19:16Z","body":"The only issue that I see is that in the original definition a ```node``` is required to be passed into the constructor but with the modification that you are presenting a ```node``` is only required if ```options``` were to be passed in. ```options``` are optional in the interface definition so one could get away without passing in anything. If we removed the '?' on ```options``` your intentions should be satisfied though. Besides that I think this makes a lot of sense in terms of api consistency.\r\n\r\nThe only other downside that I can see is that if someone were to not want to pass in any options, this still requires them to construct an object that contains the node, whereas with the old definition they could simply pass the node in as a single argument. This seems to be a relatively trivial point though and the benefits of api consistency probably outweigh it. "}}