![\"reflux](\"/static/d3e5d0171e6314fdff557935cd5529ae/e03bf/reflux-flux.png\")
\n \n \n \nThis round-up is a special edition on Flux. If you expect to see diagrams showing arrows that all point in the same direction, you won’t be disappointed!
\nFacebook engineers Jing Chen and Bill Fisher gave a talk about Flux and React at ForwardJS, and how using an application architecture with a unidirectional data flow helped solve recurring bugs.
\nYahoo is converting Yahoo Mail to React and Flux and in the process, they open sourced several components. This will help you get an isomorphic application up and running.
\n\nMikael Brassman wrote Reflux, a library that implements Flux concepts. Note that it diverges significantly from the way we use Flux at Facebook. He explains the reasons why in a blog post.
\n\n \n \n \nIan Obermiller, engineer at Facebook, made a lengthy interview on the experience of using React and Flux in order to build probably the biggest React application ever written so far.
\n\n\nI’ve actually said this many times to my team too, I love React. It’s really great for making these complex applications. One thing that really surprised me with it is that React combined with a sane module system like CommonJS, and making sure that you actually modulize your stuff properly has scaled really well to a team of almost 10 developers working on hundreds of files and tens of thousands of lines of code.
\nReally, a fairly large code base… stuff just works. You don’t have to worry about mutating, and the state of the DOM just really makes stuff easy. Just conceptually it’s easier just to think about here’s what I have, here’s my data, here’s how it renders, I don’t care about anything else. For most cases that is really simplifying and makes it really fast to do stuff.
\n\n
Kevin Dangoor is converting the project tree of Adobe’s Bracket text editor to React and Flux. He wrote about his experience using Flux.
\n![\"flux](\"/static/b4643456a3de61c8352415a6fc171876/1e088/flux-diagram.png\")
\n \n \n \nReto Schläpfer came back to a Flux project he hasn’t worked on for a month and saw many ways to improve the way he implemented Flux. He summarized his learnings in a blog post.
\n\n\nThe smarter way is to call the Web Api directly from an Action Creator and then make the Api dispatch an event with the request result as a payload. The Store(s) can choose to listen on those request actions and change their state accordingly.
\nBefore I show some updated code snippets, let me explain why this is superior:
\n\n
\n\n- There should be only one channel for all state changes: The Dispatcher. This makes debugging easy because it just requires a single console.log in the dispatcher to observe every single state change trigger.
\n- Asynchronously executed callbacks should not leak into Stores. The consequences of it are just too hard to fully foresee. This leads to elusive bugs. Stores should only execute synchronous code. Otherwise they are too hard to understand.
\n- Avoiding actions firing other actions makes your app simple. We use the newest Dispatcher implementation from Facebook that does not allow a new dispatch while dispatching. It forces you to do things right.
\n
Ameya Karve explained how to use Mori, a library that provides immutable data structures, in order to implement undo-redo. This usually very challenging feature only takes a few lines of code with Flux!
\nundo: function() {\n this.redoStates = Mori.conj(this.redoStates, Mori.first(this.undoStates));\n this.undoStates = Mori.drop(1, this.undoStates);\n this.todosState = Mori.first(this.undoStates);\n this.canUndo = Mori.count(this.undoStates) > 1;\n this.canRedo = true;\n if (Mori.count(this.undoStates) > 1) {\n this.todos = JSON.parse(this.todosState);\n } else {\n this.todos = [];\n }\n this.emit('change');\n},Gary Chambers wrote a guide to get started with Flux. This is a very practical introduction to Flux.
\n\n\nSo, what does it actually mean to write an application in the Flux way? At that moment of inspiration, when faced with an empty text editor, how should you begin? This post follows the process of building a Flux-compliant application from scratch.
\n\n
Dan Abramov working at Stampsy made a talk about React and Flux. It’s a very good overview of the concepts at play.
\n\nChristian Alfoni wrote an article where he compares Backbone, Angular and Flux on a simple example that’s representative of a real project he worked on.
\n\n\nWow, that was a bit more code! Well, try to think of it like this. In the above examples, if we were to do any changes to the application we would probably have to move things around. In the FLUX example we have considered that from the start.
\nAny changes to the application is adding, not moving things around. If you need a new store, just add it and make components dependant of it. If you need more views, create a component and use it inside any other component without affecting their current “parent controller or models”.
\n\n
Nicola Paolucci from Atlassian wrote a great guide to help your getting understand Flux step by step.
\n![\"flux](\"/static/2d495afb05a28c237d0dfc5c9133f4be/1e088/flux-chart.png\")
\n \n \n \nDeLorean is a tiny Flux pattern implementation developed by Fatih Kadir Akin.
\n\n\n\n
\n- Unidirectional data flow, it makes your app logic simpler than MVC
\n- Automatically listens to data changes and keeps your data updated
\n- Makes data more consistent across your whole application
\n- It’s framework agnostic, completely. There’s no view framework dependency
\n- Very small, just 4K gzipped
\n- Built-in React.js integration, easy to use with Flight.js and Ractive.js and probably all others
\n- Improve your UI/data consistency using rollbacks
\n
Last but not least, Flux and React ideas are not limited to JavaScript inside of the browser. The iOS team at Facebook re-implemented Newsfeed using very similar patterns.
\nIf you build your app with flux, you can swap out React for a canvas or svg view layer and keep 85% of your code. (or the thing after React)
— Ryan Florence (@ryanflorence) September 3, 2014