Describe differences between rx-flux and thundercats

[ivan-kleshnin]

What motivates you to fork, what are you going to add / remove, etc?

[BerkeleyTrue]

Biggest reason was the slow pace at which rx-flux was moving. At the moment there is no real difference as far as api is concerned (well actually I have removed a feature, so there is a minor difference). That may change with rx-flux upcoming rewrite which might re-introduce the concept of a dispatcher, which is something I am against.

I can already see some avenues that I wish to go down that might not be in the interest of rx-flux but that I require in for my use cases.

The biggest reason is that I want to focus on Isomorphic javascript, use of RxJS, and minimizing the number of new concepts introduced in this project. Simpler is better.

Another Idea I am toying with is composable flux. In the way you can create isolated react components that can function and exist outside of the app/view they were created in, I want to be able to do the same with ThunderCats. This is just something rattling around in my brain but the idea is growing on me.

@ivan-kleshnin Is there anything you would like to see? I am open to suggestion or features.

[ivan-kleshnin]

Thank you, @BerkeleyTrue

Biggest reason was the slow pace at which rx-flux was moving

Yeah, I have the same feeling, they kinda stop at the API stage.

Is there anything you would like to see? I am open to suggestion or features.

I won't talk of docs, which is a pain point for all newer libs... :)
I laid out my frustration about current state of things here:
acdlite/flummox#63

I tried Flux, Reflux, Flummox... I think they all suffer from bad abstractions. Dispatcher is kinda worthless, I can agree with you here. I looked through flummox code which is good but does essentially nothing through hundreds of lines. Just transport event further and further. That's awful. Store is the second from the end. Actions are also blurry. So we don't have anything "good" right now except of Virtual DOM and RxJS. That's the problem.

I'm not sure about LINQ. Are they really enough to create complex business-level stuff (I still think we'll be happy to have DSL for DB-like queries at some point) but, at least, it's much better than custom helper accessor methods.

There is also Cycle.js which drops React completely and keeps only Virtual DOM. But it's API is really "strange", I can't wrap my head around it for now. The main difference is how Cycle.js inverses dependencies.

Flux:

Actions <- Stores <- Components
Actions <- Components

Cycle:

View <- Intent <- Model <- View (circual deps here, solved by dep injection)

[BerkeleyTrue]

I still think we'll be happy to have DSL for DB-like queries at some point

I guess that is what Relay is for :) I'm hoping to find someway to integrate GraphQL with ThunderCats (probably as ThunderCats-GraphQL)

View <- Intent <- Model <- View (circual deps here, solved by dep injection)

This is essentially where we are now with ThunderCats, except actions are not declaratively tied to React views.

View <- Store <- Action <- View(imperative)

I've removed react components from ThunderCats and moved them to ThunderCats-React (with the idea that later on I could make a v-dom implementation and not have to import react everywhere).

I think Cycle.js is pretty cool but I think sticking with React is a winning formula.

So how is ThunderCats.js different from Rx-Flux

• Universal JavaScript by default (no singletons)
• Render to Observable, server side data pre-fetching, client side re-fetching, declarative Higher Order Container (in ThunderCats-React).
• Stores, Actions, Cats create Stampit Stamps!
• Soon Actions will be compostable (ref)
• Soon... I promise... Actions/Stores/Cats will be able to take in an object that conforms to stamp descriptor and create stamps accordingly.