Application Architecture with React: Rethinking Flux • Hacker News Board

Re: Application Architecture with React: Rethinking Flux

#41

Post by guscost » Mon, Sep 14, 2015, 5:44 PM UTC

masklinn wrote: post #21

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.

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 specif…

I've actually used a plain state object with UUID version tags saved at each node that needs to be optimized. Whenever the store updates that node, it also updates the version tag with a new UUID. Then shouldComponentUpdate just checks whether the version tag is different before rendering.

For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated library. However it does require extra boilerplate and manual updates to version tags each time something changes, and it can cause confusion if you forget to update a version tag or accidentally update the wrong one. Anyway, it is one alternative, but if you don't have a compelling reason not to use ImmutableJS for optimization I'd probably go with that. Of course it is perfect for undo/redo functionality too if that is a requirement.

Re: Application Architecture with React: Rethinking Flux

#42

Post by dustingetz » Mon, Sep 14, 2015, 6:06 PM UTC

drcode wrote: post #37

dustingetz wrote: post #24

Earlier quoted context omitted.

> 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 coordinat…

Both cursors and Relay involve syncing a "database" to a declarative view object- In Om Next, there will be a new query language that maps the database to the views, so it can be used both for in-browser data (like cursors) and server data (like Relay). What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the q…

> Both cursors and Relay involve syncing a "database" to a declarative view object

A cursor is something that implements the atom interface, and refine [1]. What does this have to do with databases and declarative view objects?

It would make sense if GraphQL/Relay were used to sync backend state to browser state, and then cursors are used to sync browser state to a view, but here, cursors are still part of the picture! Or is it that components will directly sync with the server, so no mechanism to sync browser-state to a view is necessary? What about application/UI state that doesn't exist on a server?

[1] From the OM wiki:

"In Om, you keep all your application state in a single atom (the root atom). Components, however, generally do not care about the entire scope of the application state, but focus on specific parts of it.

"Cursors are Om's way to manage a component's focus on just the state data that it needs to operate. Cursors split one big mutable atom into smaller sub-atoms that remain in-sync with the state held in the root atom. Cursors keep a path to the data within the root atom that the component needs to deal with. Sub-cursors are produced by refining the path."

Re: Application Architecture with React: Rethinking Flux

#43

Post by tajano » Mon, Sep 14, 2015, 6:20 PM UTC

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.

I'm curious to know how complex your React app is.

I'm just starting to integrate Redux (and possibly Immutable) into my app, and initially I'm a bit surprised by how Redux can make simple things much more complex. I'm hoping it will pay off by end up simplifying complex things down the road.

In any case, it feels like we're currently at the "peak of inflated expectations" with respect to React and Flux/Redux.

Re: Application Architecture with React: Rethinking Flux

#44

Post by masklinn » Mon, Sep 14, 2015, 6:22 PM UTC

dustingetz wrote: post #42

drcode wrote: post #37

Earlier quoted context omitted.

Both cursors and Relay involve syncing a "database" to a declarative view object- In Om Next, there will be a new query language that maps the database to the views, so it can be used both for in-browser data (like cursors) and server data (like Relay). What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the q…

> Both cursors and Relay involve syncing a "database" to a declarative view object A cursor is something that implements the atom interface, and refine [1]. What does this have to do with databases and declarative view objects? It would make sense if GraphQL/Relay were used to sync backend state to browser state, and then cursors are used to sync browser state to a view, but here, cursors are still part of the pictur…

GraphQL/Relay are not fundamentally bound to server state, they can be used to map client application state (from the "big atom") to components as well.

Re: Application Architecture with React: Rethinking Flux

#45

Post by tajano » Mon, Sep 14, 2015, 6:24 PM UTC

iLoch wrote: post #30

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.

Slightly off topic, but what library do you use for networking with React? Almost every code sample or tutorial uses jQuery's AJAX methods. Bundling jQuery seems excessive when just using those methods, but is there not a reliable alternative?

Re: Application Architecture with React: Rethinking Flux

#46

Post by drcode » Mon, Sep 14, 2015, 8:05 PM UTC

dustingetz wrote: post #42

drcode wrote: post #37

Earlier quoted context omitted.

Both cursors and Relay involve syncing a "database" to a declarative view object- In Om Next, there will be a new query language that maps the database to the views, so it can be used both for in-browser data (like cursors) and server data (like Relay). What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the q…

> Both cursors and Relay involve syncing a "database" to a declarative view object A cursor is something that implements the atom interface, and refine [1]. What does this have to do with databases and declarative view objects? It would make sense if GraphQL/Relay were used to sync backend state to browser state, and then cursors are used to sync browser state to a view, but here, cursors are still part of the pictur…

> What does this have to do with databases and declarative view objects?

Well, you can think of a cursor as a query into the state, with support for dependency tracking. I think your confusion is that you're asking "How is what you're describing like a cursor?" when I'm saying "Om Next is going to replace cursors with something very different."

...so you're right, it isn't the same as a cursor anymore, because swannodette is moving away from the cursor paradigm into more of a "querying" approach.

Re: Application Architecture with React: Rethinking Flux

#47

Post by rymohr » Mon, Sep 14, 2015, 9:38 PM UTC

guscost wrote: post #41

masklinn wrote: post #21

Earlier quoted context omitted.

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 specif…

I've actually used a plain state object with UUID version tags saved at each node that needs to be optimized. Whenever the store updates that node, it also updates the version tag with a new UUID. Then shouldComponentUpdate just checks whether the version tag is different before rendering. For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated libra…

Your approach sounds interesting. Ever write about it?

The undo / redo gains of ImmutableJS quickly vanish when you're working with remote data and the leaked getters aren't fun. A little UUID juggling is worth it if it allows my components/reducers to work with plain old javascript objects and still get fast shouldComponentUpdates.

Re: Application Architecture with React: Rethinking Flux

#48

Post by sotojuan » Mon, Sep 14, 2015, 10:37 PM UTC

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.

I agree about react-router and Immutable.js, but redux is tiny and the cognitive load is minimal.

Re: Application Architecture with React: Rethinking Flux

#49

Post by sotojuan » Mon, Sep 14, 2015, 10:42 PM UTC

tajano wrote: post #45

iLoch wrote: post #30

Earlier quoted context omitted.

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.

Slightly off topic, but what library do you use for networking with React? Almost every code sample or tutorial uses jQuery's AJAX methods. Bundling jQuery seems excessive when just using those methods, but is there not a reliable alternative?

There's tons, but the common one is fetch: https://github.com/matthew-andrews/isomorphic-fetch

Re: Application Architecture with React: Rethinking Flux

#50

Post by btown » Tue, Sep 15, 2015, 5:25 AM UTC

jeswin wrote: post #20

btown wrote: post #11

Earlier quoted context omitted.

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…

Unfortunately, Relay is significantly further from "just working" with push and write-once-run-everywhere-including-your-database query language, than Meteor is from "just working" with React. If you want a realtime immediate-mode-rendered web application without writing tons of boilerplate for data handling, and duplicating business logic in your server (i.e. GraphQL implementation) and client, Meteor+React has the edge today. You're right, though, that frameworks built on Relay+React will eventually catch up. I'm also looking forward to that day.