{"action":"created","issue":{"url":"https://api.github.com/repos/omniscientjs/omniscient/issues/67","labels_url":"https://api.github.com/repos/omniscientjs/omniscient/issues/67/labels{/name}","comments_url":"https://api.github.com/repos/omniscientjs/omniscient/issues/67/comments","events_url":"https://api.github.com/repos/omniscientjs/omniscient/issues/67/events","html_url":"https://github.com/omniscientjs/omniscient/issues/67","id":58656551,"number":67,"title":"Parent to child communication without mixins","user":{"login":"Gozala","id":21236,"avatar_url":"https://avatars.githubusercontent.com/u/21236?v=3","gravatar_id":"","url":"https://api.github.com/users/Gozala","html_url":"https://github.com/Gozala","followers_url":"https://api.github.com/users/Gozala/followers","following_url":"https://api.github.com/users/Gozala/following{/other_user}","gists_url":"https://api.github.com/users/Gozala/gists{/gist_id}","starred_url":"https://api.github.com/users/Gozala/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Gozala/subscriptions","organizations_url":"https://api.github.com/users/Gozala/orgs","repos_url":"https://api.github.com/users/Gozala/repos","events_url":"https://api.github.com/users/Gozala/events{/privacy}","received_events_url":"https://api.github.com/users/Gozala/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-02-23T22:03:13Z","updated_at":"2015-02-23T22:36:03Z","closed_at":null,"body":"One of the biggest challenges I found with omniscient, is to use it in a referentially transparent way without destroying performance. Let me elaborate exactly what I mean:\r\n\r\nThe way we use omniscient is without `this` or mixins, as both imply mutable `this.props` and there for are not referentially transparent & there for not much better than use of plain react.\r\n\r\nUsing omniscient this way poses a challenge, of how could children perform a task that changes state larger than what they render. Here is a practical example:\r\n\r\n\r\n```js\r\nconst Tab = Component({items, item}) => DOM.div({\r\n  className: 'tab'\r\n  /* ... */\r\n}, [\r\n  DOM.button({\r\n     onClick: event => items.remove(item)\r\n  })\r\n])\r\n\r\nconst TabDeck = Component(items => DOM.div({\r\n  className: 'tabs'\r\n  /* .... */\r\n}, items.map(item => Tab({items, item}));\r\n```\r\n\r\nThe problem with that is that any change to any tab will re-trigger `Tab` component for every tab & generate virtual DOM that will be mostly equal, but still it's linear.\r\n\r\n\r\nThe other solution one could think of is:\r\n\r\n```js\r\nconst Tab = Component({onRemove, item}) => DOM.div({\r\n  className: 'tab'\r\n  /* ... */\r\n}, [\r\n  DOM.button({onClick: onRemove})\r\n])\r\n\r\nconst TabDeck = Component(items => DOM.div({\r\n  className: 'tabs'\r\n  /* .... */\r\n}, items.map(item => Tab({item, onRemove: () => items.remove(item)}));\r\n```\r\n\r\nBut unfortunately it has exact same issue. Although I believe we could make some changes to omniscient to fix the later case."},"comment":{"url":"https://api.github.com/repos/omniscientjs/omniscient/issues/comments/75652820","html_url":"https://github.com/omniscientjs/omniscient/issues/67#issuecomment-75652820","issue_url":"https://api.github.com/repos/omniscientjs/omniscient/issues/67","id":75652820,"user":{"login":"Gozala","id":21236,"avatar_url":"https://avatars.githubusercontent.com/u/21236?v=3","gravatar_id":"","url":"https://api.github.com/users/Gozala","html_url":"https://github.com/Gozala","followers_url":"https://api.github.com/users/Gozala/followers","following_url":"https://api.github.com/users/Gozala/following{/other_user}","gists_url":"https://api.github.com/users/Gozala/gists{/gist_id}","starred_url":"https://api.github.com/users/Gozala/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Gozala/subscriptions","organizations_url":"https://api.github.com/users/Gozala/orgs","repos_url":"https://api.github.com/users/Gozala/repos","events_url":"https://api.github.com/users/Gozala/events{/privacy}","received_events_url":"https://api.github.com/users/Gozala/received_events","type":"User","site_admin":false},"created_at":"2015-02-23T22:36:03Z","updated_at":"2015-02-23T22:36:03Z","body":"So one solution is to use \"cursor reference\" to pass in pointer to \"additional state\" required to perform an action but short circuit an update (meaning do not trigger components on \"additional state\" state changes). That will work indeed, but it implies:\r\n\r\n1. Use of immustruct that is additional dependency that we have being avoiding so far.\r\n2. More importantly it's yet another new concept that in my experience happen to be very difficult to explain. Or put it differently it requires deep understanding of the issue and a solution from a contributor to get all things right.\r\n3. At the end of the day reference cursor is not much better than passing a mutable object, meaning that it destroys referential transparency.\r\n\r\nThose are the reasons why we find it to not work for us."}}