Difference to redux-observable

[timjacobi]

Hi,

I've just done a comparison between this library and https://github.com/redux-observable/redux-observable
The code is almost similar (surprise, both are based on rx :D) but I was wondering if it made sense to join forces between the two libraries.

[BerkeleyTrue]

Hey @timjacobi thanks for opening this issue.

Initially redux-observable was very different from redux-epic. They took the same path as redux-thunk, redux-promise, and others where the observable (or promise, or function, or whatever) goes through the dispatch. This was distasteful to me, which is why I went the same route as redux-saga and redux-saga-rxjs, using middleware to intercept and dispatch actions in a fashion that fits the idioms of both Redux and Rx.

It looks like they independently came to the same conclusion in redux-observable/redux-observable#55 and redux-observable/redux-observable#67 and switched to an identical model as mine, even the same name! It's great that we both came to the same conclusions and validates my initial thoughts.

So, what is still different between this library and redux-observable?

From what I can tell, there are a couple of differences:

• First class support for SSR
• Universal (read: isomorphic) JavaScript First Design
• Ability to inject dependencies
• Use of Rx instead of RxJS
• Disposable Epics
• React Centric

First Class Support for Server Side Rendering

There doesn't seem to be a way for the user to tell the epic (which manages observables internally) to end, which is a requirement if you have a long-lived saga. If a long-lived saga does not complete it's hard to determine if all my data fetching sagas have completed.

When you can tell if all saga's are completed, you can create a simple observable for server side rendering that knows when all the data is fetched, the store is hydrated, and the app is ready to be rendered to a string.

Then you leave it up to the user to call onCompleted on the epic so that there is a proper cleanup happening.

Universal JavaScript First Design

This is an issue with most libraries built around React/Redux. The library may not be build with the idea of Universal JavaScript. What does that mean in the context of this library? Mainly that there are methods that mirror each other both server and client side.

These are the render and renderToString functions. While you don't need to use these functions to use redux-epic, it was created with the idea that you would want to use them to support SSR'ing.

This is not to say that redux-observable does not support SSR, but that it just was not built initially with that idea. I'm not actually sure you can, though. I'd be happy to be proven wrong. According to this issue redux-observable/redux-observable#47 it is still a question to be solved.

This library also has a contain function (creates a HOC) that allows a user to declare data fetching actions for a given component. These actions then automatically called to fetch data when the component is rendered.

Dependency injection

This is another requirement I have for a library like this. I want to be able to create a dependency per server request, not just once the library is created on the client. createEpic allows you to pass in an object that is then passed to each individual saga.

This gives me the option to pass in a fully contextualized object on the client and a mock on the server and not have to worry about detecting my environment in the individual sagas.

Rx instead of RxJS

This is not that big of a deal, but there are difference in operators and how the library is built. I'm concerned that RxJS (Rx@5) might never actually be released as Rx (Rx@4) and we end up with a Python 2/3 situation. I build this library to use at @freeCodeCamp and it's being used there today with Rx. I can't really justify switching to RxJS until I know what's going to happen to Rx.

Once RxJS is out of beta and has fully replaced Rx then this library will move over.

I am also willing to make this library compatible with all Observable libraries in the same way that CycleJs is now. I want to do it in such a way that wouldn't disrupt FreeCodeCamp's codebase significantly.

Disposable Epics

I don't see this in their codebase and this goes back to Universal JavaScript First design. Disposable epics don't matter much if you are only designing for the client, but if you are server side rendering, you want to know that a proper cleanup is happening.

React Centric

I intentionally built this library around React. That's not to say you couldn't use this library without React, you can still use the createEpic function without importing anything React specific. Redux-observable seems to be build with the idea of being used with any UI library.

I will at some point extract the React specific stuff, like I did with ThunderCat.JS, but decided it would be a premature optimization doing it now.

Joining Forces

I'm open to it. I can't say I'm not bummed that they essentially have become the same library as this one. I don't know if the above goals are something they would also support, though.

[timjacobi]

Wow. Thank you for this comprehensive answer. I will definitely have a closer look at the things you've mentioned. I'm working on a blog post comparing the different options for redux async so this will be super helpful. Thanks!

[jayphelps]

@timjacobi tomorrow we're also discussing ways we might collaborate between the two projects or possibly merge. Some initial discussion has started here: redux-observable/redux-observable#84

[BerkeleyTrue]

@timjacobi I'm working on a talk on the same topic!

[timjacobi]

@BerkeleyTrue Awesome! Let me know if you want to collaborate.

[VasilioRuzanni]

@BerkeleyTrue Any news on redux-epic and redux-observable convergence? Both seem to have a relatively small footprint and indeed trying to implement the same thing so hopefully you've advanced in some sort of cooperation.

The redux-observable is all good and supports rxjs@5.x (which is Release Candidate as of now) but redux-epic seems to have much better SSR story and this contain thing that seems to be addressing some of the "component data requirements" concerns. Would definitely like these to converge.

[jayphelps]

@VasilioRuzanni we're still collaborating with that goal, but no news at this point.

[BerkeleyTrue]

@VasilioRuzanni Yes we are still working towards that goal.

Unfortunately I have been extremeley busy these last few months and have not written as much code as I'd like.

I do have some initial work here but it is completely untested.

You can tune into that repo for updates. I'll post here once I feel like SSR with RO is in a reasonable state.

[VasilioRuzanni]

@jayphelps @BerkeleyTrue Alright, guys. Just curious if that collaboration is in effect. I guess no particular milestones are set, so just hoping for the better :)

@BerkeleyTrue Will be checking react-redux-epic, despite being untested and raw, it's already got a direction and looks promising.

[dawidvdh]

@VasilioRuzanni have you had any luck with react-redux-epic? Been trying to implement via the documentation with out much success.

[BerkeleyTrue]

@dawidvdh feel free to ping me on gitter in the redux-observable channel if you are having issues with react-redux-epic.

[VasilioRuzanni]

@dawidvdh What exactly are you trying to achieve? Are you trying to beat the SSR beast or just have any issues using it in general? Both redux-epic and redux-observable (and react-redux-epic as well) are very simple.

P.S. I gave up on using any of these (doesn't mean they're bad or something), just ended up using Cycle.js to run my effects in a (subjectively) much more elegant way (effects themselves are completely isolated by the "drivers"). Similar to redux-cycles but I'm also using Cycle.js at component level (though, this is a different concern).

[dawidvdh]

@VasilioRuzanni got good clarity from @BerkeleyTrue, but yes I am trying to beat the SSR beast currently... and yes it was rather simple after some explanation, just very new to the observable world man.

Do you have any examples of your approach? Gathering as many examples of implementations as I can get at the moment. will definitely checkout redux-cycles though thanks for the heads up.