{"action":"created","issue":{"url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/11","labels_url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/11/labels{/name}","comments_url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/11/comments","events_url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/11/events","html_url":"https://github.com/economist-components/component-articletemplate/pull/11","id":110698811,"number":11,"title":"[Not ready to merge] Variant Styling","user":{"login":"sebinsua","id":152098,"avatar_url":"https://avatars.githubusercontent.com/u/152098?v=3","gravatar_id":"","url":"https://api.github.com/users/sebinsua","html_url":"https://github.com/sebinsua","followers_url":"https://api.github.com/users/sebinsua/followers","following_url":"https://api.github.com/users/sebinsua/following{/other_user}","gists_url":"https://api.github.com/users/sebinsua/gists{/gist_id}","starred_url":"https://api.github.com/users/sebinsua/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sebinsua/subscriptions","organizations_url":"https://api.github.com/users/sebinsua/orgs","repos_url":"https://api.github.com/users/sebinsua/repos","events_url":"https://api.github.com/users/sebinsua/events{/privacy}","received_events_url":"https://api.github.com/users/sebinsua/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-10-09T17:00:34Z","updated_at":"2015-10-12T10:58:47Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/economist-components/component-articletemplate/pulls/11","html_url":"https://github.com/economist-components/component-articletemplate/pull/11","diff_url":"https://github.com/economist-components/component-articletemplate/pull/11.diff","patch_url":"https://github.com/economist-components/component-articletemplate/pull/11.patch"},"body":"I want to get your thoughts on how we should be doing this, within this component (and others going forth.)\r\n\r\n**This is not ready to merge (and does not have my changes from within #10 rebased into it.)**\r\n\r\n___\r\n\r\n## The problem\r\n\r\n`component-articletemplate` already contained the styling from world-if. I do not want to get rid of the styling for that project but want it to be possible to choose world-in styling.\r\n\r\n## An approach\r\n\r\nWith these changes you can pass in a `variantType` and if it is supported it will use this to generate variant-related versions of the classes that it applies to its elements. The extra styling has also been moved into `variants/world-if` and `variants/world-in` (and presumably these would either be imported in by the `index.css` or imported in via the App component itself.)\r\n\r\nThere are other ways of doing this - and I guess it will depend on the use case which is best."},"comment":{"url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/comments/147365611","html_url":"https://github.com/economist-components/component-articletemplate/pull/11#issuecomment-147365611","issue_url":"https://api.github.com/repos/economist-components/component-articletemplate/issues/11","id":147365611,"user":{"login":"sebinsua","id":152098,"avatar_url":"https://avatars.githubusercontent.com/u/152098?v=3","gravatar_id":"","url":"https://api.github.com/users/sebinsua","html_url":"https://github.com/sebinsua","followers_url":"https://api.github.com/users/sebinsua/followers","following_url":"https://api.github.com/users/sebinsua/following{/other_user}","gists_url":"https://api.github.com/users/sebinsua/gists{/gist_id}","starred_url":"https://api.github.com/users/sebinsua/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sebinsua/subscriptions","organizations_url":"https://api.github.com/users/sebinsua/orgs","repos_url":"https://api.github.com/users/sebinsua/repos","events_url":"https://api.github.com/users/sebinsua/events{/privacy}","received_events_url":"https://api.github.com/users/sebinsua/received_events","type":"User","site_admin":false},"created_at":"2015-10-12T10:58:47Z","updated_at":"2015-10-12T10:58:47Z","body":"> Personally I don't like BEM, and would argue against using it should we ever decide to.\r\n\r\nWell whether or not you like BEM or not, the principle always points the same way: avoid deep selectors, CSS cascades and polluting the global namespace.\r\n\r\n> You raise a good point here, and I think this point supports the idea of HOCs (higher order components) for ArticleTemplate variations. If we use ArticleTemplate in WIN, we shouldn't have users download the variation code for WIF (e.g. the tabs). While it may be small here, it could certainly add up to be large, unused blocks of code when distributed in other microsites. This, to me, is a compelling justification for generalizing this component, and having HOC variants.\r\n\r\nYes, pretty much.\r\n\r\nI was just speaking to @russEco who was currently having trouble placing the title and section headers in the correct place since the HTML structure of world if article template is different from what would be required for our style. He was having to use absolute positioning to get them into the right place...! Not very nice.\r\n\r\n> Once again, HOC variants would support this architecture nicely - the HOC variant could supply subcomponents (like the Gobbet, or headings) that were tuned to its variant, so ArticleTemplate would come with some basic components, like a heading (let's call it ArticleHeading) - but WIF-ArticleTemplate could be a HOC that overrides the base components with WIF variants (like WIF-ArticleHeading - another HOC variant). Again, I feel this is a compelling reason to use HOC variants for the ArticleTemplate.\r\n\r\nThat seems reasonable to me. However creating higher-order components for so many inner components is gonna be super time-consuming.\r\n\r\nTempted to let Russ work in this codebase now with `if-else` statements around large render code-blocks, and then to work out how to split it up and generalises as time progresses."}}