McFly – Flux Architecture Made Easy | Hacker News Reader

McFly – Flux Architecture Made Easy

github.com

86 pointsdanso38 comments

I wish someone would create a large Flux/Reflux demo app. I love the "one-way data flow" model and the patterns established by Flux/Reflux, but I feel like I would really benefit from seeing a large, complex application where stores depend on stores (or keep state independently?) etc. The example ToDo apps everyone publishes are too trivial to really gain an understanding of how to apply the patterns.

I don't know if it's "large", but I wrote an article and supplied a demo that is a bit more complex than the usual examples you might see are.

http://scotch.io/tutorials/javascript/creating-a-simple-shop...

Facebook came out with a flux chat example: https://github.com/facebook/flux/tree/master/examples/flux-c...

Yahoo has a good take on making it isomorphic here: https://github.com/yahoo/flux-examples

This was posted today on the React forums asking the same question: How should you structure a large Flux project? https://groups.google.com/forum/#!topic/reactjs/d33IinfVI0o

We were in a similar spot. Our startup is building a relatively large flux app. We interviewed Ian Obermiller of FB on a lot of the concerns of a large app. You can find a lot of answers to tough questions in our transcript: http://ianobermiller.com/blog/2014/09/15/react-and-flux-inte...

Awesome, thank you so much for this.

How is this different from reflux? https://github.com/spoike/refluxjs

So McFly is basically pure Facebook Flux. I even use their Dispatcher. What I'm doing is creating a helper factory to DRY-up some of the Stores and Actions boilerplate code, because in the examples they are freeform and not instances of any object. So the answer to the question is essentially:

https://github.com/spoike/refluxjs#differences-with-flux

Did you use reflux before writing McFly?

I like reflux but I'm worried it may be leading me astray from the core principles that make the flux architecture so useful. It's one of those things you can't be sure of until the app grows complex enough to start running into edge cases (such as waitFor and the single dispatcher, separation of actions from action creators, keeping async code out of stores, etc).

I did, and it's really cool, but I felt the same way. So I wanted to bridge the gap.

Question about the Flux pattern in general, why is a dispatcher/store more desirable than an observable model? The biggest difference I see is a component can add or delete an object with no knowledge of a store just the global dispatcher, but why not just have a static method on a traditional model for adding and deleting?

I think the biggest difference is that Stores don't necessarily contain just one object. They are state containers, so where with a Model you would have singular object based static methods, in a Store you could have methods to manipulate or return any of the objects it contains.

Fair enough, but why coordinate Store actions through a Dispatcher? Is there much to gain over just calling a method on the Store?

The Dispatcher is helpful because, using the waitFor method, you can marshall the callbacks to enforce an explicit update order in the event that there are dependencies.

For me, the gain is that you can track all interactions in a single spot. If stores trigger updates on each other, you end up with a web of dependencies that take a long time to trace through when making changes or debugging.

I'm liking how there are new projects popping up who all implement the flux pattern, but do so in different ways. I haven't looked into how this differs from something like fluxxor, but the example looks simple and easy to use. My one grip with the jsfiddle is a nitpicky one: that the McFly object is being given the Flux name... that could be confusing for people who are looking at this and also using the flux library from facebook (which has a different API).

Sorry about that. I was kind of at a loss for what to call the new instance.

How about mcfly? :D

Hah. In my own projects I've been cameling it like var mcFly = new McFly()

I still don't understand why developers want this over something more simplistic like this: http://jsfiddle.net/quje39qa/1/ - Am I alone in thiking JS frameworks are not the future?

The to-do app is just an example, an over-simplistic one, but if you ever try to write any large-ish app using the jQuery approach you'll get your answer.

Especially if you write it on a team with other people.

I agree with you, but to be fair it is possible to build a large jQuery-only application and be successful. You'd just end up re-inventing a lot of things that a framework could have given you, or writing a lot more code. You'd also have to impose strict guidelines for your developers, since there'd be no "established" way of doing certain things (the first time round).

That's why React is brilliant, since it's really simple and scales well.

In association with Flux I assume you mean?

React can be used without a Flux-like architecture. It can also be integrated in a MV* application, see Backbone React Component[1] for example that uses Backbone Model for rendering React components.

[1] https://github.com/magalhas/backbone-react-component

Couldn't we say any view layer "scales well" when integrated other architectures?

No. Some view layers require you to specify a lot more of the state transition code and may be more heavily integrated with the rest of your architecture (like the way you do data binding, etc). Because React transparently updates state by simply re-rendering components, you can keep it very cleanly decoupled from the rest of your architecture. There are other frameworks that accomplish similar tasks, but I've found that none come quite so close to having zero lines of state transition code as React. (In React, most of my state transition code involves visual animations.)

the biggest problem with plain React (without Flux) is that the parent components have to pass event handlers to the child components, which gets really messy if you have multiple (>3, say) levels of nesting. It's much cleaner to have the child component trigger an event, and the data for the parent component to be updated accordingly.

This is something Ractive.js provides out of the box (child components fire events, that parent can be listening for), and what Flux (and its implementations) provide.

Yes, I do realise that. It's just that React on its own is only a small part of what people would normally use to build an app. People will therefore use React + <something> and I would expect a lot of people are using Flux as that something.

Yes, you could write a large jQuery-only application. But it won't be as "simple" as the fiddle provided above.

1. Stop using frameworks

2. Build project from scratch with well structured JS.

3. Build another project, but first extract the generalizable bits from the first project into a module that solves common problems.

4. Open source this module because it could be useful for other people writing single page apps.

5. Go back to step 1?

And suddenly you've given yourself, and the community, a nice present called "A Library Framework" :)

This example is missing a lot of features :-)

Yeah, I kept it as minimal as possible so that people could focus on the actual architecture. I'll be releasing an article in the near future that will show it in use in a more complex application.

No project like this ever amounted to anything in the history of The Valley!

Its not the project, but the ease in which it enables you to understand the concept

Yeah, well, history is gonna change.

Reply on news.ycombinator.com