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

Application Architecture with React: Rethinking Flux

dialelo.github.io

Post reply on HN
Print view View original

11–20 of 53 posts

Re: Application Architecture with React: Rethinking Flux

#11

Post by btown »

alexro wrote: post #6
bvm wrote: post #4

Earlier quoted context omitted.

so, Meteor?

This front-end db should be separate of the UI/navigation. So, not Meteor

To be very fair to Meteor, they're trying hard to separate their UI/rendering layer from their front-end data layer [1]. There are prototypes where you can build an entire frontend in React from the top down, taking Meteor collections as stores and passing them down your hierarchy or just including them [2]. Still rough around the edges, but Meteor's going in the right direction here.

[1] http://info.meteor.com/blog/meteor-the-missing-infrastructur...

[2] https://github.com/jedwards1211/meteor-webpack-react

Re: Application Architecture with React: Rethinking Flux

#13

Post by Cshelton »

I've been using a flux architecture with Immutable Stores and cursor like things that only give the state to the components that need it. I'm using Facebook's dispatcher as well. Maybe I missed it or the author is just describing an alternative, I don't see the advantage of using js-csp over FB's dispatcher?

Re: Application Architecture with React: Rethinking Flux

#14

Post by davedx »

marcofiset wrote: post #12

If you're going to borrow every idea from ClojureScript and Om, why not simply switch to these technologies instead of relying on so many libraries?

Many companies will simply not use ClojureScript, it's too niche and too hard to find developers for at the moment.

It's much easier to find JavaScript developers.

Re: Application Architecture with React: Rethinking Flux

#15

Post by collyw »

davedx wrote: post #14
marcofiset wrote: post #12

If you're going to borrow every idea from ClojureScript and Om, why not simply switch to these technologies instead of relying on so many libraries?

Many companies will simply not use ClojureScript, it's too niche and too hard to find developers for at the moment. It's much easier to find JavaScript developers.

Many developers are capable of learning a second language. If they are stupid about hiring they will insist on experience with ClojusreScript. And lets face it most companies will do that.

Re: Application Architecture with React: Rethinking Flux

#16

Post by foxhedgehog »

davedx wrote: post #9

Always good to see alternatives to "Flux classic" [1]. We have just started using Redux [2] with ImmutableJS. It's a nice way of expressing how different actions mutate the store, but I do feel like there's some leaky abstractions in there - e.g. ImmutableJS is usually used for performance reasons, yet you see your entire app filled with getter boilerplate to get the data from the immutable structures. I have to say…

I thought that the reason for immutability wasn't so much for performance as much as for getting predictable state to enable time-travel, etc.

Re: Application Architecture with React: Rethinking Flux

#17

Post by feedjoelpie »

foxhedgehog wrote: post #16
davedx wrote: post #9

Always good to see alternatives to "Flux classic" [1]. We have just started using Redux [2] with ImmutableJS. It's a nice way of expressing how different actions mutate the store, but I do feel like there's some leaky abstractions in there - e.g. ImmutableJS is usually used for performance reasons, yet you see your entire app filled with getter boilerplate to get the data from the immutable structures. I have to say…

I thought that the reason for immutability wasn't so much for performance as much as for getting predictable state to enable time-travel, etc.

As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get a new object, but not everything in the object is new, which is what keeps things fast.

Re: Application Architecture with React: Rethinking Flux

#18

Post by Cshelton »

feedjoelpie wrote: post #17
foxhedgehog wrote: post #16

Earlier quoted context omitted.

I thought that the reason for immutability wasn't so much for performance as much as for getting predictable state to enable time-travel, etc.

As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get…

When you use Immutable JS, you are taking a slight performance hit. You are creating a new object every time you change anything and returning it. But the benefit of not having to worry about unexpected changed or sometimes referencing something you didn't mean too is great.

The added performance can come from the equality checks. Like, do not do anything if newState === oldState. This has added benefit with something like React where you can use shouldCOmponentUpdate, which we returned false, will not call the render function. It can increase performance drastically on complicated things.

Re: Application Architecture with React: Rethinking Flux

#19

Post by rakoo »

alexro wrote: post #2

With each next article about React (and more generally javascript) it's more apparent that the final result is a mongo/rethink like db in the front-end with a transparent sync to the server

Maybe something like PouchDB, lazily synced with a CouchDB instance on the server ? I'd love to see a better integration, where for example global state would be automatically saved in PouchDB. You'd get pub/sub, history and synchronization for free, at the cost of PouchDB's performance (last I tried, it wasn't transparent enough)

Re: Application Architecture with React: Rethinking Flux

#20

Post by jeswin »

btown wrote: post #11
alexro wrote: post #6

Earlier quoted context omitted.

This front-end db should be separate of the UI/navigation. So, not Meteor

To be very fair to Meteor, they're trying hard to separate their UI/rendering layer from their front-end data layer [1]. There are prototypes where you can build an entire frontend in React from the top down, taking Meteor collections as stores and passing them down your hierarchy or just including them [2]. Still rough around the edges, but Meteor's going in the right direction here. [1] http://info.meteor.com/blog/…

I wish Meteor nothing but the best, but React is no longer just a UI framework. Relay encroaches significantly on Meteor turf; and its optimistic update mechanism is arguably more flexible that Meteor's syncing protocol. In addition, there's React native and deep integration with tools such as Flow and Include.

There should be space for Meteor and I don't mean to be discouraging, but this is generally a good time for framework authors to internally debate how the competitive landscape has changed and the best path forward.

Post reply on HN