Roadmap for Future Development

From a comment by @chicoxyzzy in #18 - a chance for those actively using this library to weigh in on what gets done next.

My thoughts are (reprinted/modified from #18):
- [ ] Publish the latest version with the fix for the Redux Middleware API to NPM
- somehow `npm install redux-rx` installs version `0.5.0` but the latest Release for the repo is tagged as `0.4.0`, neither of which have the fix for the Middleware API
- [ ] close several issues which have been resolved
- [ ] Improve the examples that are provided by including `import` statements at the top and an example of how to use it with `react-redux`, specifically:
- [ ] finish the `createConnector` example by showing how it is used with the `Todo` component
- [ ] _personally_ an example of passing props down from parent containers to child components, e.g. what does the binding statement look like?
- [ ] Provide examples of the other parts of the API, e.g. the current example for `observableMiddleware` doesn't even include `observableMiddleware` in the example
- [ ] Make `rx` and `redux` peer dependencies
- [ ] Update [react-component-rx](https://github.com/acdlite/react-rx-component) dependency => [rx-recompose](https://github.com/acdlite/recompose/tree/master/src/packages/rx-recompose)
- **OR should we be using that completely instead of this package?**
- [ ] Document what other packages are necessary ( [rx-react](https://github.com/fdecampredon/rx-react) ?) or useful ( [recompose](https://github.com/acdlite/recompose) - another one of yours ) in order to understand the examples or make it easier to use this library
- [ ] Have an ability **not** to use FSA compliant actions - this appears to be an arbitrary dependency but I could be wrong

Not necessarily in that order.

Also some comments from @acdlite in that issue thread that modify the list above:

> In addition to the sensible steps you've listed like pushing the changes to the middleware API, my suggestion is that `createConnector()` should be removed in favor of using rx-recompose (or similar) directly. That project + `observableFromStore()` + `.flatMap()` gives you all the power you need, and would allow the library to be view framework agnostic.

_In response to my example which is_

> ``` javascript
> import Redux from 'redux';
> import { Observable } from 'rx';
> import { observableFromStore } from 'redux-rx';
> import { observeProps } from 'rx-recompose';
>
> const storeState$ = observableFromStore(store);
> const fooState$ = storeState$.map(state => state.fooKey).distinctUntilChanged(fstate => fstate.id);
> const FooCtor = observeProps(props$ => {
> return Observable.combineLatest(props$, fooState$, (props, fooState) => Object.assign(props, fooState);
> });
>
> const Foo = FooCtor(

);
> ```
> - **I'm not sure where to use `.flatMap(…)` above and could use some assistance on that**
> - **I'm not sure if I'm implementing it right using `Object.assign(…)`**

_he also wrote_

> Yeah, if you do it like that you don't need `.flatMap()`. I was thinking about a situation like this, where you grab the store from the stream of props:
>
> ``` js
> const enhance = compose(
> getContext({ store: PropTypes.object }),
> observeProps(props$ => {
> const storeState$ = props$.flatMap(props => observableFromStore(props.store))
> // ...
> })
> )
> ```
>
> `observableFromStore()` already supports disposal because the function passed to `Observable.create()` returns an unsubscribe function. Admittedly, this isn't exactly clear from the source, but here's the longer version:
>
> ``` js
> export default function observableFromStore(store) {
> return Observable.create(observer => {
> const unsubscribe = store.subscribe(() => observer.onNext(store.getState()));
> // By returning unsubscribe, the observable can be disposed
> return unsubscribe;
> });
> }
> ```

Is there anything else you'd like to see?
What's immediately needed for your project?
What do you want longer term?