Actual site for the project:
http://facebook.github.io/flux/
Seems to still be in flux.
Facebook Flux – Application Architecture for Building User Interfaces
21–30 of 59 posts
Re: Facebook Flux – Application Architecture for Building User Interfaces
#22I'm still somewhat unclear on the point of the Dispatcher and Actions and they simply feel like needless indirection to me. For instance, in the flux-chat app within the linked repo, the MessageComposer component calls `ChatMessageActionCreators.createMessage(text);` when the user press the enter key to submit a message. To find out how that ends up affecting the application, you need to jump around more than a coupl…
Because I didn't want to add so many layers at once, I just implemented Stores -> ControllerView -> View -> direct Store call.
As far as my understanding goes that should be fine for most use-cases. The only reason that really requires a Dispatcher would be synchronization of the incoming Store mutations.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#23Earlier quoted context omitted.
You can imagine that a key command, a click on a button, or even a command originated from a remote control that arrives proxied over a WebSocket - all of these could create the same Action. Each Store shouldn't care, or have any interest in, what component created that Action. And you should be able to add new Stores and new interaction types at runtime, as if (in music production) you were plugging in a plug-and-pl…
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
Re: Facebook Flux – Application Architecture for Building User Interfaces
#24It'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…
Usually I have an action call out to some DAO class which encapsulates an HTTP request and returns a promise, then just firing off a different action in the done and fail callbacks.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#25How does this compare with FRP? I've been thinking about this and concluding that React wouldn't benefit even a little from those FRP libraries and architecture, it is already quite functional reactive. Am I wrong?
[deleted]
Re: Facebook Flux – Application Architecture for Building User Interfaces
#26I'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 think this is the best combination of libraries I've ever used, but given how impressive React truly is, I'm sure I'll see the Flux light soon enough too.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#27I 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.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#28I 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.
Google did it as well with Go![1]
[1] http://en.wikipedia.org/wiki/Go!_%28programming_language%29
Re: Facebook Flux – Application Architecture for Building User Interfaces
#29It'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…
Could you describe what you mean by interdependent actions? As in, chains of actions?
Yes, a chain of actions (for example, a sequence of AJAX requests that need to be fired)
Re: Facebook Flux – Application Architecture for Building User Interfaces
#30I'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 view states. Re-rendering the view on any data change can result in very abrupt changes. For instance, my app displays multiple lists of items. When the user edits an item, that can result in the item suddenly disappearing from underneath their cursor to reappear somewhere else in that list, in a different list, or nowhere within view.
I've been able to handle each issue of this nature as it arises in an ad-hoc fashion, but I'd really like a more formalized way in React to say, "when attribute X changes, use transition Y to change from the old view state to the new one".
Does anyone know of an existing solution to this problem?