[Aleman360]

So... a global message bus? That will quickly become spaghetti in a large code base.

[mcjiggerlog]

The whole point of it is to eliminate spaghetti code. Traditional large frontend apps often end up with very complex chains of information dependency and it can become unclear as to what changing a piece of code will affect. Flux tries to prevent this by enforcing a uni-directional data flow, meaning working out what a certain component affects/is affected by is much simpler.

In short

Traditional MVC: http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux...

vs

Flux: http://www.infoq.com/resource/news/2014/05/facebook-mvc-flux...

edit: or a more complex flux example - http://fluxxor.com/images/flux-complex.png

[illicium]

Hey, it has a cool name and it's made by Facebook. It must be state of the art tech, right?

Trolling aside, Flux really doesn't bring much to the table. It's trying to solve the pain caused by two-way-binding by forcing state to flow in one direction through an event bus, reinventing MVwhatever along the way.

You can already do this stuff in Angular (et al) if you stick to a few firm rules for how to structure your app.

[istorical]

Don't blame you if you don't have time nor motivation to respond, but care to share a 2 min. description of those rules?

I'm a fairly new developer working in my first post-uni role and we're starting to rack up a lot of Angular code and I'm not sure if I'm structuring things right as far as events vs $watches etc.

[illicium]

A few off the top of my head:

* Use ui-router. Build your app with nested views.

* Any duplicate page elements should be directives. Use isolated scope when you can and pass state into directives explicitly

* Keep model state in services. Controllers handle binding data to $scope (one way, from model to view) and handling events from the view