Transitioning to Flux Architecture | Hacker News Reader

Transitioning to Flux Architecture

engineering.kapost.com

As far as I understand Flux (I'm wondering if "understanding Flux" is becoming 2015's "understanding Monads"), in its pure form it is based on the idea that state is an aggregate of past actions. In other words, the database becomes more of a message queue (or event log) and the "models" are simply cached aggregates.

This structure is great if you're mostly concerned with letting data flow through your application and less with transactional guarantees. It's easy to imagine how this architecture can apply to a chat or a Facebook-style wall or river of user-provided content.

I'm not convinced that this is a useful architecture for applications that aren't primarily about streams of user-created content. React's idea of unidirectional data flow and a strictly linear hierarchy (which is frequently subverted by "Flux" libraries via global stores) is powerful and IMO far more widely applicable than the Flux architecture in which it is frequently used.

I think a cross-breed of Flux's concept of actions and stores and the traditional MVC style collections and models might be worth exploring. This is where our internal React code seems to be heading, anyway.

Shameless plug/disclosure: I'm the author of Fynx (http://foss-haas.github.io/fynx/) which started out as yet another Flux library and is currently undergoing a rewrite in our internal code which will become the 2.0 release once it has stabilised.

There is a funny (somewhat related) thing I've been trying recently, which is just using pouchdb to hold the application state and using pouchdb change listeners to propagate database content straight into views.

For smallish amounts of content, re-querying the entire dataset out of pouch every time a change happens works fine.

For tables with e.g. several thousand rows, I started to need an explicit cache however, and update it with only the changed documents.

As you explain it, I understand it as event sourcing, as used in CQRS and event sourcing.

http://martinfowler.com/eaaDev/EventSourcing.html https://msdn.microsoft.com/en-us/library/jj554200.aspx

Negative points? Really? I expected a constructive discussion about the respective merits of Flux vs MVC or at least an explanation of how my understanding of Flux is horribly wrong.

Looking at my comment history there is a disturbing trend: off-the-cuff sarcastic quips get upvoted to the double digits (with a few sub-zero exceptions depending on who else is reading the comments), serious attempts of having a discussion get downvoted or not voted on at best. So much for "HN is not Reddit".

From my initial readings and implementations of flux, it seems that actions should only really interact with stores through the dispatcher. To achieve uni directional data flow here, you could pass the DataSTore.loadingState from the component to the action.

Maybe I should ask before stating: What was the intention of coupling your store and action in this scenario?

Reply on news.ycombinator.com