Application Architecture with React: Rethinking Flux
dialelo.github.io
Application Architecture with React: Rethinking Flux
1–10 of 53 posts
Re: Application Architecture with React: Rethinking Flux
#2With 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
Re: Application Architecture with React: Rethinking Flux
#3Very interesting, thanks!
Re: Application Architecture with React: Rethinking Flux
#4With 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
so, Meteor?
Re: Application Architecture with React: Rethinking Flux
#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 closer to GraphQL/Relay queries.
Re: Application Architecture with React: Rethinking Flux
#6Re: Application Architecture with React: Rethinking Flux
#7It feels so complicated. Every one of these "React architectures" does. And it doesn't even include any networking.
Compare all that to Meteor.
Re: Application Architecture with React: Rethinking Flux
#8There is also the excellent Redux which is similar
Re: Application Architecture with React: Rethinking Flux
#9Always 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 don't quite see the difference between CSP used here and normal eventemitter style code. Can someone explain the difference?
Re: Application Architecture with React: Rethinking Flux
#10This feels similar to NuclearJS[1], which I've yet to use in anger, but seems like a pretty nice wrapper on top of using one big immutable data store.