Remove RxJava as a dependency

[brianegan]

After working with this code a bit, I think it makes sense to remove RxJava as a dependency. Why you might ask? Let's break it down.

RxJava Pros Broken Down

• Allows for threading! What if we want to run reducers in the background for example? Well, with the great work done by @clemp6r, we moved away from a model where the reducer work could be done on a background thread, and made the entire process synchronous. This is a fairly fundamental part of the way Redux works, and it has some very nice advantages. Therefore, RxJava isn't needed for this type of threading anymore!
• Solid Subscriber and Observer interfaces in place. Fortunately, it's very easy to create a small interface of our own that's
• Has some very helpful abstractions for testing. So, let's continue using it for testing!

Reasons it makes sense to move away

• In the context of Android, RxJava eats up about 4200 methods. If we really don't need it, I'd prefer to keep this library lean and mean.
• For folks who don't have experience with RxJava, the requirement might add too much of a learning curve
• If you still want to work with state changes as an observable, it's completely possible to wrap this smaller core in that type of interface!
• The code is far simpler and easier to reason about. The main store is now about 20 lines.

[beyondeye]

Sounds good. But I will leave the option of RxJava based store

[brianegan]

@beyondeye Thanks for the feedback!

Yah, I was thinking of how to achieve this. What do you think of providing 2 modules: Bansa and BansaRx? BansaRx could simply act as a wrapper around the Bansa implementation, and would simply extend the core interface with the stateChanges observable we provided in the previous implementation.

/cc @clemp6r would love your feedback as well if you have time :)

Thanks again to both of you for contributing and helping make this a better library!

[clemp6r]

Hi,

I agree with the reasons you provided, and I like the idea of providing an Rx-based store as an optional dependency, because (for me) the ideal framework provides state changes as Rx observables. So no problem for me.

[brianegan]

@clemp6r Cool! I'll go ahead and create a separate module on this PR that includes BansaRx so the transition should be pretty close to seamless for folks!

Thanks again for the reviews :)

[beyondeye]

I think that it is time to create a separate repository, Bansa Addons or something like that, where to aggregate all optional modules, like RxStore, Reselect, etc...

[clemp6r]

It's also possible to put all modules in the same repo (see https://github.com/square/retrofit)

It may be easier to manage.

Le dim. 10 avr. 2016 06:40, beyondeye notifications@github.com a écrit :

I think that it is time to create a separate repository, Bansa Addons or something like that, where to aggregate all optional modules, like RxStore, Reselect, etc...

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/brianegan/bansa/pull/8#issuecomment-207917364

[LalitMaganti]

I agree with the aim here and also creating a new module for Rx. I feel they should actually be in different repos similar to how Redux/Reselect etc are structured. Multi-module builds should be used when a release in one project should trigger a release in all projects wheras multi-repo would allow, for example, a release for reselect if a bug/feature was created, without requiring a release of Bansa too.

I've also been experimenting with the ideas of selectors and how actions should look on the JVM (a class hierarchy, JSON tree, Map of String to Objects). I have some interesting ideas but nothing that feels quite correct. Will continue to see what fits :)

[brianegan]

This branch has now been merged! Gonna work on making this lib more Java friendly at this point :)