41–50 of 59 posts
I know is stylized as "f.lux" but fuck man... Why does big companies do that? Just recently Apple's Swift and now Facebook's Flux.
Yes, you don't absolutely need the ActionCreator helper methods. You could call AppDispatcher.handleViewAction() or even AppDispatcher.dispatch() directly in the View. But keeping these things separated out keeps the code nicely organized and keeps application logic out of the View. Additionally, I find it helps to maintain a mental model where the only way into the data flow is through the creation of an action, codified in the library of ActionCreators.
It has a fine explanation of the pattern: http://facebook.github.io/react/docs/flux-overview.html but what isthe reasoning in using this architecture? Or in pattern speak, what are the forces that this pattern is considering? I can't find a clear explanation about which problems is it trying to solve.
I've been using React quite a bit but haven't had a need for Flux. Using React to implement all of my UI concerns, combined with Backbone for easy to use persistence and modeling, has worked wonderfully for me. YMMV :)
I agree. The combination of Backbone models/collections and React views bound together by React.Backbone[1] so that the views automatically re-render after any changes to the models/collections has made the data-heavy application I'm working on surprisingly easy to develop. The real issue I've been having React -- that I'd I like to see dealt with by a library/design pattern -- is dealing with transitions between vie…
Not simply react but you can get the idea.
It's easy to integrate with Backbone if you want for this kind of architecture, as it already implements events and stores. I've found it requires less boilerplate than the example in the repo.
I just wrapped up the initial version of a medium-size app using React. It was my first use of the library in production. I had originally used Backbone.Model and Backbone.Collection in conjunction with React. But after reading about Flux on the React blog and watching the video explanation back in May, it only took me a week to replace all of my Backbone models and collections with Flux singleton-stores. Coupled wit…
At least Andrey add his reasoning for the latest deprecation in rrouter's documentation. Although the page regarding server-side regarding in the rrouter docs is empty :(
According to the docs "RRouter was developed to replace react-router-component and fix design flaws introduced by it." Maybe I'm just unfamiliar with the npm community but is it typical to just rename projects once they introduce breaking changes?
We've been playing with this architecture. It makes testing a lot easier - you just shove data in where needed and things pop out the other end. It also forces us into splitting things up in a more sensible manner. Along with easier testing is easier reasoning. That said, like most new architectures/frameworks finding a big example (not just a TODO app) is really hard. We are currently prototyping a big app using Rea…
Earlier quoted context omitted.
Just trying to understand here: What's the practical difference between the dependency on knowing the right action to call to the dispatcher vs. the dependency on calling the Singleton Store method?
I haven't used flux yet, but I'm assuming a single action might call on multiple stores? Eliminates having to handle that in a dependency
It's great to see Facebook releasing code for Flux. Hope to see more in the future. Here are some other implementations of Flux for anyone who's interested: https://github.com/BinaryMuse/fluxxor https://github.com/jmreidy/fluxy https://github.com/yahoo/flux-example We recently adopted this architecture for a medium-scale project. The unidirectional data flow has greatly reduced code complexity for us. We're still not…
I'm the author of Fluxy and would be happy to answer any questions here. The big benefits of Fluxy vs other Flux approaches is that 1) Stores are built on top of immutable data structures (via ClojureScript / mori) 2) Server side rendering is baked in (or will be as of 0.4) I'd also mention https://github.com/spoike/reflux as an implementation.
I initially thought that the suggested implementation by Facebook was a bit weird because it requires a lot of boiler plate code.
For the longest time I disliked using magic strings for type checking since it breaks the concept of polymorphism. In Javascript it is even more weird considering it is a dynamic language. So I fixed that by moving the type specifics (which in Flux's case is mostly about handling events) into the actions and stores themselves.
Thanks to a contributor we also provide a mixin for React components that adds automatic unsubscription on componentWillUnmount and provides a listenTo method in the components to subscribe to actions and stores.
It works both server-side (available at npm) and client-side (available as bower package or can be built in browserify from npm package).
They write "Flux eschews MVC in favor of a unidirectional data flow", but MVC already has a unidirectional data flow (Controller -> Model -> View). Is this just a case of those who don't understand MVC are compelled to reinvent it?
EDIT: Actually, the main addition over MVC seems to be that the Stores declaratively specify their relationships between one another (which are then resolved by the dispatcher), rather than the developer writing a specific Model implementation that explicitly orders the changes to related elements of the model. I'm a bit suspicious that this would be less explicit, and so harder to maintain, but maybe I'm wrong.