{"action":"created","issue":{"url":"https://api.github.com/repos/pubkey/rxdb/issues/17","repository_url":"https://api.github.com/repos/pubkey/rxdb","labels_url":"https://api.github.com/repos/pubkey/rxdb/issues/17/labels{/name}","comments_url":"https://api.github.com/repos/pubkey/rxdb/issues/17/comments","events_url":"https://api.github.com/repos/pubkey/rxdb/issues/17/events","html_url":"https://github.com/pubkey/rxdb/issues/17","id":197221283,"number":17,"title":"what's the pattern for \"connecting\" components?","user":{"login":"faceyspacey","id":154732,"avatar_url":"https://avatars.githubusercontent.com/u/154732?v=3","gravatar_id":"","url":"https://api.github.com/users/faceyspacey","html_url":"https://github.com/faceyspacey","followers_url":"https://api.github.com/users/faceyspacey/followers","following_url":"https://api.github.com/users/faceyspacey/following{/other_user}","gists_url":"https://api.github.com/users/faceyspacey/gists{/gist_id}","starred_url":"https://api.github.com/users/faceyspacey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/faceyspacey/subscriptions","organizations_url":"https://api.github.com/users/faceyspacey/orgs","repos_url":"https://api.github.com/users/faceyspacey/repos","events_url":"https://api.github.com/users/faceyspacey/events{/privacy}","received_events_url":"https://api.github.com/users/faceyspacey/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-12-22T17:07:38Z","updated_at":"2016-12-23T08:26:33Z","closed_at":null,"body":"It seems a redux-style `connect` API will soon come about so you don't have to manually call `subscribe` in `componentDidMount` etc. Are there any thoughts on this already so the wheel doesn't have to be re-invented? I.e. a strategy that you have in mind.\r\n\r\nWhat about possibly a \"transparent reactive programming\" interface similar to what Meteor was originally doing and what MobX does. I.e. that you can can do this:\r\n\r\n```\r\nrender() {\r\n  return (\r\n   <ul>\r\n     {heroCollection\r\n       .find()\r\n       .sort('name')\r\n       .$.map( docs => <li>{doc.name}</li)\r\n      }\r\n   </ul>\r\n )\r\n}\r\n```\r\n\r\nA year ago I built https://github.com/ultimatejs/tracker-react to allow you to transparently reactive functions within your render method and made it so Meteor's `Tracker` tools were aware of any reactive calls within your render method and then called `forceUpdate` any time new data come through. An interface like that might also be attractive. I'm not sure how `render` in this case would be aware of any observable subscription updates. Actually, at least for a react *class* component it could be as simple and explicit as this:\r\n\r\n```\r\nrender() {\r\n  return (\r\n   <ul>\r\n     {heroCollection\r\n       .find()\r\n       .sort('name')\r\n       .$\r\n       .notifyComponent(this) //here's where the magic happens obviously\r\n       .map( docs => <li>{doc.name}</li)\r\n      }\r\n   </ul>\r\n )\r\n}\r\n```\r\n\r\nSo essentially you're passing `rxdb` an instance of the component which it can intelligently call `forceUpdate` on when the subscription updates. \r\n\r\nHaving been a long-time Meteor advocate, i spent the last year completely getting off of it and using Redux instead. I'm not sure I personally would go back to *transparent reactive programming* as easy as it was. But that's mainly because for my projects I need the supreme testability of pure*er* functions. The above obviously has major side-effects. However, that depends on how you look at it. Right now we live in a world where because connections and getting data is so slow, we can't really think of our functions and components as a function of a global database--it's why Redux makes us jump through so many hoops to make your component tree a function of a local database, and then goes farther to impose on you that your components are pure through `connect`. However, you technically could in a reliable/testable way use data from your store in your components in a non-pure way (e.g. with the hypothetical api: `store.get('key')`), so long as the subscriptions notified the component to update similar to above. And then with fixtures for your client-side database you can easily test functions with the above side-effects in a reliable way, allowing you to think of your data as just constants. You won't be dealing with technically correct pure referentially transparent functions, but perhaps it doesn't matter--at least for testing where you can instantly mock your database, especially with rxdb. \r\n\r\nSo that's a case for a \"referentially transparent reactive API\" for rxdb. The major benefit of it all is that it definitely is way faster to at least prototype this code. I loved Meteor's Tracker + Blaze. I now love React + Redux. But I love the latter because of the reliability it gives me, certainly not for the speed of initially building things. It is at least 2x slower, even after mastering the tools. Basically the only case against a referentially transparent reactive interface is that it's not technically pure. There likely will be various testing tools you can't use (which rely on true pure functions), and leaks to the abstraction. I simply didn't want to invest the time to find out. I.e. do a complete comparison of testing essentially meteor's transparent reactive interface for React which I built with `tracker-react` vs. testing pure functions and redux. At the time i decided the best use of my time was just to get going with Redux et al. The ecosystem will definitely benefit the latter. However if I was newer to programming I'd definitely be far better off with the transparent reactive style. It's way way easier to grasp and get off to a running start with. So if you guys wanted to target that audience--which no doubt is large, perhaps larger than more senior programmers--you may have a first class solution. Because you're using observables, you may have already overcome some of the various problems Meteor's `Tracker` had. Here are 2 articles I wrote a year ago highlighting those problems:\r\n\r\nhttps://medium.com/@faceyspacey/the-evolution-of-tracker-solutions-to-its-core-problems-4b9cb90d479a#.1yvdndyq5\r\n\r\nhttps://medium.com/@faceyspacey/tracker-vs-redux-implicit-vs-explicit-df847abcc230#.syas78lpz\r\n\r\nObservables may in fact be the way transparent reactive programming *should* be done. Basically Tracker re-runs your code too much and you have very little control over it. So it's inefficient in how it guarantees your views/subscriptions stay up to date. Observables likely re-runs way less. On the other hand, MobX is known for less component updates compared to Redux (at least prior to the latest react-redux 5.0) because of its spreadsheet-style computations where various dependencies between reactive functions/data is graphed and granularly updates leaves if one of its dependencies update. MobX's depdency graph is also what makes it way better than Tracker, solving many of the problems I highlighted about Tracker in the above articles. So, perhaps MobX is even more suited for the problem than Observables. At least more optimized for react than *standalone* observables, as MobX can take your entire app into consideration, not just ad-hoc observables used throughout your components, which may trigger a child update when the parent already updated. That's a problem that the recent 5.0 update to `react-redux` solves/improves. \r\n\r\nThe react-redux package just released some major changes in their 5.0 release. Basically it makes your connected components aware of its parents, and if it's parent updates, the children won't, whereas before each component was individually subscribe/connected to the redux store and might update even if it's parent was also subscribed and handled the update for both already. I assume that's still probably not as good as MobX, but in reality for 90% of most case is 90% as efficient. So that's one less point for MobX these days. \r\n\r\nAnyway, just thought it might be useful to drop this information for you guys as it could be some good marketing opportunities for you. \r\n\r\nHere's the original article on how MobX works:\r\n\r\nhttps://medium.com/@mweststrate/becoming-fully-reactive-an-in-depth-explanation-of-mobservable-55995262a254#.fgu8gpysi"},"comment":{"url":"https://api.github.com/repos/pubkey/rxdb/issues/comments/268955911","html_url":"https://github.com/pubkey/rxdb/issues/17#issuecomment-268955911","issue_url":"https://api.github.com/repos/pubkey/rxdb/issues/17","id":268955911,"user":{"login":"pubkey","id":8926560,"avatar_url":"https://avatars.githubusercontent.com/u/8926560?v=3","gravatar_id":"","url":"https://api.github.com/users/pubkey","html_url":"https://github.com/pubkey","followers_url":"https://api.github.com/users/pubkey/followers","following_url":"https://api.github.com/users/pubkey/following{/other_user}","gists_url":"https://api.github.com/users/pubkey/gists{/gist_id}","starred_url":"https://api.github.com/users/pubkey/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pubkey/subscriptions","organizations_url":"https://api.github.com/users/pubkey/orgs","repos_url":"https://api.github.com/users/pubkey/repos","events_url":"https://api.github.com/users/pubkey/events{/privacy}","received_events_url":"https://api.github.com/users/pubkey/received_events","type":"User","site_admin":false},"created_at":"2016-12-23T08:26:33Z","updated_at":"2016-12-23T08:26:33Z","body":"Hi @faceyspacey \r\n\r\n1. I dont think RxDB should implement a fancy way to handle reacts component-bindings. When you create a reactive react-app you will need a way to handle your observables, with or without RxDB. So there must be a standard solution to use RxJS in react and we should not invent our own one.\r\n\r\n2. Sry but I neither know the term \"transparent reactive programming\" nor \"referentially transparent reactive API\". I read your medium-posts but could not find out why we need the things described there. Cant we just use our rxjs-\"streams\"? I never had a problem to fit them into redux-stores.\r\n\r\n3. Whats the problem with creating a new observable for every query? I mean its just a very simple javascript-object which does not do anything if not subscribed. If you want to keep the observables you can still store them anywhere outside of the component."}}
{"actor":{"display_login":"pubkey"}}