{"action":"created","issue":{"url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/51","repository_url":"https://api.github.com/repos/GuillaumeSalles/redux.NET","labels_url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/51/labels{/name}","comments_url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/51/comments","events_url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/51/events","html_url":"https://github.com/GuillaumeSalles/redux.NET/issues/51","id":217106883,"number":51,"title":"Future of Redux.NET / version 3.0","user":{"login":"GuillaumeSalles","id":7273466,"avatar_url":"https://avatars2.githubusercontent.com/u/7273466?v=3","gravatar_id":"","url":"https://api.github.com/users/GuillaumeSalles","html_url":"https://github.com/GuillaumeSalles","followers_url":"https://api.github.com/users/GuillaumeSalles/followers","following_url":"https://api.github.com/users/GuillaumeSalles/following{/other_user}","gists_url":"https://api.github.com/users/GuillaumeSalles/gists{/gist_id}","starred_url":"https://api.github.com/users/GuillaumeSalles/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GuillaumeSalles/subscriptions","organizations_url":"https://api.github.com/users/GuillaumeSalles/orgs","repos_url":"https://api.github.com/users/GuillaumeSalles/repos","events_url":"https://api.github.com/users/GuillaumeSalles/events{/privacy}","received_events_url":"https://api.github.com/users/GuillaumeSalles/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":9,"created_at":"2017-03-27T00:35:55Z","updated_at":"2017-03-30T06:31:43Z","closed_at":null,"body":"I open this issue to know what kind of features people would want in a v3.\r\n\r\nI don't currently use Redux.NET in my day to day job so I can't really build something useful without feedback.\r\n\r\nWhat improvements I currently have in mind : \r\n\r\n- [ ] Remove dependencies on IObservable. I find observable useful to build [selectors](http://redux.js.org/docs/recipes/ComputingDerivedData.html), to improve [performance](https://github.com/GuillaumeSalles/redux.NET#performance-optimization) or execute subscribtion callback on a specific thread thanks to ObserveOn, I think it bring too much confusion for people who don't know Rx. \r\n- [ ] Useful way to extends store like middleware or enhancer without drawbacks. See #48 \r\n- [ ] Remove the IAction interface\r\n- [ ] Basic helper to merge ItemsSource. See #46 \r\n- [ ] CombineReducer? Not sure about this one since it will be build with reflexion and can introduce error at runtime. \r\n- [ ] Samples\r\n\r\ncc @cmeeren, @lilasquared, @dcolthorp :\r\n\r\nYou definitely put a lot of time to think about Redux or even use it in production. I think we can benefit from our different experiences to shape a new version of Redux that we will help everyone. Your feedback is more than welcome and I'm looking for some people that want to become core contributors of Redux.NET since I don't always have the time to work on it anymore.\r\n"},"comment":{"url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/comments/290315369","html_url":"https://github.com/GuillaumeSalles/redux.NET/issues/51#issuecomment-290315369","issue_url":"https://api.github.com/repos/GuillaumeSalles/redux.NET/issues/51","id":290315369,"user":{"login":"cmeeren","id":7766733,"avatar_url":"https://avatars3.githubusercontent.com/u/7766733?v=3","gravatar_id":"","url":"https://api.github.com/users/cmeeren","html_url":"https://github.com/cmeeren","followers_url":"https://api.github.com/users/cmeeren/followers","following_url":"https://api.github.com/users/cmeeren/following{/other_user}","gists_url":"https://api.github.com/users/cmeeren/gists{/gist_id}","starred_url":"https://api.github.com/users/cmeeren/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cmeeren/subscriptions","organizations_url":"https://api.github.com/users/cmeeren/orgs","repos_url":"https://api.github.com/users/cmeeren/repos","events_url":"https://api.github.com/users/cmeeren/events{/privacy}","received_events_url":"https://api.github.com/users/cmeeren/received_events","type":"User","site_admin":false},"created_at":"2017-03-30T06:31:43Z","updated_at":"2017-03-30T06:31:43Z","body":"> 1 and 2 introduce breaking changes, 3 increase the surface API and force store enhancers to implement the Subscribe method.\r\n\r\nSince this is a major upgrade, I don't think we should shy away from breaking changes. See also [SemVer](http://semver.org/) if you're not familiar with it. I think all libraries should adhere to semantic versioning.\r\n\r\n> Store enhancers are definitely a great extension point. However, if we want to lower the entry barrier for C# developers, I'm not sure supporting the store enhancers exactly like redux.js does is a good idea. IMO, even if C# has more and more functional features, a store enhancer could be replaced by an OO decorator. What do you think about it?\r\n\r\nNo strong feelings on my part, but that's mostly because I lack the experience/knowledge to fully grasp the implications (I'm not that familiar with functional concepts, and while I know of the decorator pattern, I haven't used it myself yet). Whichever solution we arrive at should be robust, extensible, and simple to use.\r\n\r\n> One example is the discussion about not returning the state in the subscriber callback. They thought about doing it at one point until this comment:\r\n\r\nInteresting, thanks. I'm leaning towards making the \"raw\" store low-level/orthogonal and having separate higher-level extensions (whether as functional store enhancers or OO decorators) to e.g. serve the current (and possibly previous) state to subscribers. I would prefer the most important of these extensions to be included with Redux.NET according to what @dcolthorp said about a _a batteries-included, prepackaged \"starter kit\"_.\r\n\r\nRegarding the UI thread stuff: I haven't done anything such with Yarni, yet everything works perfectly. Under which circumstances would this be a problem? (In my app, all subscribers are defined in the view codebehind and update the view directly; I don't use bindings. Perhaps that's why things work for me?)\r\n\r\nRegarding the \"awaiting completion\" stuff: What about middleware? Middleware may dispatch actions forward (ultimately reaching the store) and then do other stuff that the store can't possibly know about. See e.g. my [ListenerMiddleware](https://github.com/cmeeren/yarni/blob/master/src/Yarni/ListenerMiddleware.cs) which sends the action down and then calls all listeners (subscribers), which will perform necessary async tasks and often dispatch actions of their own. So again, I'm not sure what exactly @dcolthorp intends to be awaited."}}
{"actor":{"display_login":"cmeeren"}}