Hacker News Reader

Comment by themgt | Hacker News Reader

One of the things I didn't realize at first was the degree to which Relay/GraphQL appear to effectively replace a lot of Flux: http://facebook.github.io/react/blog/2015/02/20/introducing-...

Learning Flux sort of seems like learning how to drive stick shift on an '97 Civic while we wait for the new Tesla to arrive - useful, also a bit annoying. A central store architecture does seem a better match to what Relay will look like though.

View on HN

I think one thing that's misunderstood about Flux is the store <-> model distinction. Coming from MVC, it's a pretty easy mistake to make, but stores _are_ effectively global state objects: You can access a store's state from any component -- whether that's good practice is doubtful, but it can be done -- and even though you have to call that store's getter in particular, it's not really that different from requesting state from a global object. (As the article hints at, Om makes it even clearer that stores handle global state in the app-state atom.)

All of that is to say that I think Flux-y architectures can help with reasoning about GraphQL's and Relay's data handling, which I think is seconding your opinion, even if it's quibbling a bit with how annoying driving stick (or working in Flux) is. :)

That was my initial thoughts when Relay/GraphQL were announced, but it seems that though Relay is inspired by Flux it is somewhat different. Facebook's most recent post on Relay and GraphQL (http://facebook.github.io/react/blog/2015/02/20/introducing-... - February 20) addresses Relay's relation to Flux at the end and mentions that Facebook actually has apps using Flux and Relay.

Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.

Exactly -- nobody (yet) has written any kind of general purpose mapping from rest concepts to relay endpoints. Relay appears to leverage graph db functionality/semantics pretty heavily.

Pete hunt said it should be relatively easy to wire up a RESTful api to flux relay. And since mapping data to complex front ends is hard, but defining restful endpoints is easy, I'd rather design my database to be optimized for the complex front end scenarios. I imagine that you would be able to make a standard REST api from graphql.

I still think Flux will be handy for holding global UI state. Such as visible notifications, sidebar state, etc.

Reply on news.ycombinator.com