Facebook Flux – Application Architecture for Building User Interfaces
1–10 of 59 posts
Re: Facebook Flux – Application Architecture for Building User Interfaces
#2We'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 React/Flux and we find ourselves having to question ourselves a lot more than we'd like.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#3It'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 satisfied with our server syncing strategy. Seems like actions are the best place to sync data, but how do you deal with interdependent actions?
Re: Facebook Flux – Application Architecture for Building User Interfaces
#4It 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.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#5I'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 couple of directories to find out how it's all wired up.
I just cut out the middlemen and directly interfaced my Stores from my components. My Store then emits a change event as usual and other components that are subscribed to the change event than refetch their state. That part of Flux makes perfect sense to me. The need for Dispatchers and Actions don't.
To be fair, I didn't start looking into Flux until my app starting growing large enough that I started feeling the pain of my lack of architecture. The Stores and the event emitter solved my immediate problems. Perhaps if my app grows even larger, the Dispatcher may come in handy.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#6It'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.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#7I'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 :)
Re: Facebook Flux – Application Architecture for Building User Interfaces
#8It'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…
The React docs talk about this a bit [1]. Have you already tried this? What kind of problems are you encountering?
[1] http://facebook.github.io/react/docs/flux-todo-list.html#add...
Re: Facebook Flux – Application Architecture for Building User Interfaces
#9I'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…
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-play MIDI keyboard and simultaneously adding a new audio plugin that reacts to any MIDI input. The Dispatcher removes any dependencies between these components; everything just needs to know about the Dispatcher.
Re: Facebook Flux – Application Architecture for Building User Interfaces
#10It'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?