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

51–59 of 59 posts

Re: Facebook Flux – Application Architecture for Building User Interfaces

#51

Post by augustl »

voyou wrote: post #50

A lot of this seems like it's just MVC, except what they call the "View" is a traditional MVC Controller (the UI element that handles user interactions and sends these to the Model), what they call the "Controller-View" is a traditional MVC View (something that gets notified when the Model changes and displays that change to the user), and what they call the Dispatcher is what traditional MVC calls the Model. They wr…

The main difference between Flux and MVC is the unidirectional data flow. In MVC, a controller updates a model which updates a view which again talks directly to a model that might invoke another view which again might cause a model update, and so on. In Flux, the only thing a view can do is to invoke actions on the top-level dispatcher. Furthermore, views are never partially updated, they are always re-rendered from scratch every time (like you typically do in the back-end).

Re: Facebook Flux – Application Architecture for Building User Interfaces

#52

Post by voyou »

augustl wrote: post #51
voyou wrote: post #50

A lot of this seems like it's just MVC, except what they call the "View" is a traditional MVC Controller (the UI element that handles user interactions and sends these to the Model), what they call the "Controller-View" is a traditional MVC View (something that gets notified when the Model changes and displays that change to the user), and what they call the Dispatcher is what traditional MVC calls the Model. They wr…

The main difference between Flux and MVC is the unidirectional data flow. In MVC, a controller updates a model which updates a view which again talks directly to a model that might invoke another view which again might cause a model update, and so on. In Flux, the only thing a view can do is to invoke actions on the top-level dispatcher. Furthermore, views are never partially updated, they are always re-rendered from…

But as I said, MVC already has unidirectional data flow. An MVC View doesn't make changes to the Model, so can't lead to cascading updates of other Views.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#53

Post by couchand »

e1g wrote: post #37
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 are absolutely right that actions are just another level of abstraction that come with their own pain, and if the pain they bring does not relieve an even greater pain of not having them then there is no reason to introduce them yet. In our app, we started feeling the growing pain of a laissez faire approach to internal comms. For us, a user interaction can generate multiple logical state changes in the app, and…

I'd be very interested in seeing some Crossfilter-based filtering store code. I've been working on a business application that needs to do quite a bit of filtering and hierarchical rollups, and I'd really like to start using Crossfilter for it so we can chuck the much more limited tool I whipped up when we started the project and get that speed boost you mention.

We're also starting to see a lot of the many-to-many relationships in actions you mentioned, which convinces me we need to work towards more of a Flux architecture (it wasn't out yet when we started this lo those many months ago).

Re: Facebook Flux – Application Architecture for Building User Interfaces

#54

Post by e1g »

couchand wrote: post #53
e1g wrote: post #37

Earlier quoted context omitted.

You are absolutely right that actions are just another level of abstraction that come with their own pain, and if the pain they bring does not relieve an even greater pain of not having them then there is no reason to introduce them yet. In our app, we started feeling the growing pain of a laissez faire approach to internal comms. For us, a user interaction can generate multiple logical state changes in the app, and…

I'd be very interested in seeing some Crossfilter-based filtering store code. I've been working on a business application that needs to do quite a bit of filtering and hierarchical rollups, and I'd really like to start using Crossfilter for it so we can chuck the much more limited tool I whipped up when we started the project and get that speed boost you mention. We're also starting to see a lot of the many-to-many r…

I'd be happy to have a chat over Skype and share what we've done - just drop me a line to [redacted]

Re: Facebook Flux – Application Architecture for Building User Interfaces

#55

Post by joekrill »

Excellent! Been waiting to see an "official" implementation of this. There's a lot of different information floating around about how Flux architecture "should be done", but I've been waiting anxiously to see how Facebook actually implements it/suggests it be implemented.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#56

Post by stereosteve »

Spoike wrote: post #48
jmreidy wrote: post #19

Earlier quoted context omitted.

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.

Thanks for mentioning my project, Reflux. 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…

Thanks for posting - I'm glad to learn about reflux here. I started adding flux to an application as prescribed and thought there were many strange and unnecessary steps. All the flux libraries seemed equally complicated. Instead I went with a simple event emitter approach, which is basically Reflux without the nice API. I will certainly give it a try.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#57

Post by fiatjaf »

lightblade wrote: post #16
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.

Well, I know that.

Re: Facebook Flux – Application Architecture for Building User Interfaces

#59

Post by zubairq »

xiaoma wrote: post #33
jmreidy wrote: post #19

Earlier quoted context omitted.

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've been reading about ClojureScript/OM and mori. What example apps are online using either of them? This is what I've found so far. ClojureScrpt/OM: https://github.com/swannodette/om (several examples linked) http://rigsomelight.com/2014/05/01/interactive-programming-f... (flappy bird clone) React+Mori: ???

http://connecttous.co/connecttous/connecttous.html?livedebug...
Post reply on HN