Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook Flux – Application Architecture for Building User Interfaces

github.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Facebook Flux – Application Architecture for Building User Interfaces

#11

Post by alec_heif »

xtrumanx wrote: post #5

I'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…

Another benefit is that the Dispatcher handles all the ordering of updates for you. If you have complex relationships between your stores or even if they just must handle updates in a certain order, by sending all updates through the dispatcher you can also force a partial ordering of store updates through dispatcher.waitFor()

Re: Facebook Flux – Application Architecture for Building User Interfaces

#12

Post by tracker1 »

neves wrote: post #4

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.

In larger web based applications, tracking down side effects becomes increasingly difficult with patterns that implement two-way data binding (observables) or ad-hoc injection. This also in part takes into account part of why React renders the way it does. With the flux pattern(s) along with React's rendering pipelines, you can have heavy data flows, with minimal side effects and a slightly easier time in terms of tracing the flow of data.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#14

Post by nchuhoai »

btown wrote: post #9
xtrumanx wrote: post #5

I'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-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?

Re: Facebook Flux – Application Architecture for Building User Interfaces

#15

Post by HeyImAlex »

xtrumanx wrote: post #5

I'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…

Came to write the exact same thing. I chatted with some other people on the react irc channel about it and interfacing with stores directly seems to be pretty common. It's been working well for me so far in the smallish app I'm writing now.

To expand a little, I have trouble identifying what the difference between these two flows are;

    (something) -> store method -> change event
    (something) -> "action" -> store method -> change event
Feels like actions on the dispatcher are an unnecessary level of indirection when I have to know that I'm calling a store method under the hood just by virtue of knowing the action to call. I understand batching events and things like that, but manually wiring seems like a really boilerplate heavy solution to the problem.

Now that I'm writing this, I can kind of see the usefulness in making reusable components that can interact with stores. I guess I just felt like reusable components would never interacted with stores (as that's handled by controller-views which are pretty much application specific). But even then they need access to the dispatcher, and if you can inject that dependency then you can inject the store itself...

Sorry for the stream of consciousness, it's my lunch break...

Re: Facebook Flux – Application Architecture for Building User Interfaces

#16

Post by lightblade »

fiatjaf wrote: post #13

How 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?

React is not functional reactive by itself. Although there's no stopping people from integrating it with other FRP libraries.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#19

Post by jmreidy »

jefftchan wrote: post #3

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.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#20

Post by geetee »

HeyImAlex wrote: post #15
xtrumanx wrote: post #5

I'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…

Came to write the exact same thing. I chatted with some other people on the react irc channel about it and interfacing with stores directly seems to be pretty common. It's been working well for me so far in the smallish app I'm writing now. To expand a little, I have trouble identifying what the difference between these two flows are; (something) -> store method -> change event (something) -> "action" -> store method…

Probably more reasons, but a few off the top of my head: 1) Multiple stores can respond to a single action 2) Single action listener may call multiple store methods 2) Can reduce the number of places a store is modified from
Post reply on HN