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

21–30 of 53 posts

Re: Application Architecture with React: Rethinking Flux

#21

Post by masklinn »

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.

It's performance wrt state invalidation for work skipping. The library can check the state tree, and if the tree (or subtree) has not changed skip rendering entirely. With mutable state limited assumptions can be made so by default you have to render to vdom and diff that.

With immutable state you can do an identity check on the current state node (pretty much free), and only perform the render if it fails. On specific components you may want to go further and do a deeper equality check if the identity check fails (if rendering is expensive) but immutable collections generally give a lot of bang for your buck when it comes to skipping state -> vdom.

Re: Application Architecture with React: Rethinking Flux

#23

Post by bpicolo »

I feel like every new architecture for flux lately comes at the cost of a lot of code complexity. The global state is becoming extremely common too, and it feels like a big anti-pattern. Not really a fan. I do like the more pure-flux Alt at the moment. I felt quickly put off from Redux after going through docs for a while.

Re: Application Architecture with React: Rethinking Flux

#24

Post by dustingetz »

masklinn wrote: post #5

> Om solves this problem with an abstraction called Cursor, which lets us focus on a path of the global atom and offer the same API as atoms. This allows views to treat the substructure as their data source and even modify it with the same operations as the Atom. I wrote a simple implementation of this concept for using it with atoms and immutable data. FWIW Om Next moves away from cursors and towards something close…

> Om Next moves away from cursors and towards something closer to GraphQL/Relay queries.

Can you elaborate, I watched the Om Next talk i think you're referencing and recall David saying this, but I do not really understand why or what Cursors have to do with GraphQL/Relay as they are separate concerns. (Cursors are a way to update deeply nested data structures and don't do I/O, GraphQL and Relay are ways to coordinate/sync state from backend to frontend and involve I/O.

Re: Application Architecture with React: Rethinking Flux

#25

Post by dustingetz »

bpicolo wrote: post #23

I feel like every new architecture for flux lately comes at the cost of a lot of code complexity. The global state is becoming extremely common too, and it feels like a big anti-pattern. Not really a fan. I do like the more pure-flux Alt at the moment. I felt quickly put off from Redux after going through docs for a while.

databases are global state

(The design pattern here is separation of code from state. OOP couples code (methods) and state (members))

Re: Application Architecture with React: Rethinking Flux

#27

Post by reustle »

collyw wrote: post #15
davedx wrote: post #14

Earlier quoted context omitted.

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.

Really? Good luck convincing good JS developers that they should actually be doing Clojurescript at work instead. Maybe you'll have better luck at a local frequent clojurescript meetups (probably doesn't exist).

Re: Application Architecture with React: Rethinking Flux

#28

Post by LePetitDev »

dominotw wrote: post #26

I recently got rid of redux, react-router, immutablejs ect from my reactjs app. I can't believe how much simpler my app got. There is a lot of architecture astronautism going on in js world right now. Just be skeptical of it.

After getting rid of redux, what did you end up using for your data-model needs?

Re: Application Architecture with React: Rethinking Flux

#29

Post by iLoch »

dominotw wrote: post #26

I recently got rid of redux, react-router, immutablejs ect from my reactjs app. I can't believe how much simpler my app got. There is a lot of architecture astronautism going on in js world right now. Just be skeptical of it.

That sounds like a ton of work for any moderately sized application. It also seems like it would have diminishing returns as your app gets bigger, as that's when these architectures start to get useful. I have to be skeptical that your app has gotten simpler. If you've decided to drop the Flux pattern entirely then I can see your argument, because if you can do that then you probably didn't need to be using it in the first place. However I don't see this as a shortcoming of Redux or Flux. It just means they don't need to be used in every scenario, which should be implied.

Re: Application Architecture with React: Rethinking Flux

#30

Post by iLoch »

Void_ wrote: post #7

It feels so complicated. Every one of these "React architectures" does. And it doesn't even include any networking. Compare all that to Meteor.

Networking is a nearly trivial layer on top of the Flux pattern. I've found this especially true with Redux with the ability to easily wait on promises to mute state.

Meteor has its own problems too. The nice thing about Flux architecture is that you're not married to the network. Take my comparison with a grain of salt because I haven't given Meteor a try.

Post reply on HN