Has Redux's Time Come and Gone

My team and I have spent a lot of time learning redux and have started to build a new application with it. I was listening to @gaearon on The Software Engineering Podcast found here http://softwareengineeringdaily.com/2015/09/18/flux-redux-and-react-hot-loader-with-dan-abramov/. At the 50 minute mark @gaearon said "but of course declarative data fetching is the future and redux does not offer you declarative data fetching so redux has past".

Should I build anything with Redux or should I be moving on to Relay / GraphQL?

[ronag]

#464

[gaearon]

Many people are pretty happy with Redux. You should ask around—I'm not really qualified to answer this question. I'd say if your app is very data-heavy a la Facebook (many nested entities with complex relationships) it's a good idea to invest in a GraphQL backend and learn Relay. I've only heard good things about it.

Redux of course is more explicit and doesn't solve declarative data fetching for you. There are attempts to integrate Redux and GraphQL but I can't evaluate them against Relay—I know too little about it.

Redux is much lower level than Relay, and is no more “past” than plain JS objects and functions are “past”. Relay is a framework, and Redux, sans the sanity checks, is ten 10-liner functions, so it shouldn't be a surprise that they have different scopes. Pick what works best for you and let us know.

[RickWong]

Declarative fetching of GraphQL is amazing, top-notch. However Relay still has a HoC API mainly, which isn't declarative per se. If Relay would offer a more flexible API, uncoupled from the component tree, then a proper Redux-binding could be written?

[mattapperson]

I think they are 2 types of systems that solve 2 distinct issues.
This ticket is like carpenters asking if the time of the hammer has passed.
graphql based systems I would argue are an over engineered solution for many apps, conversely apps with complex data structures are most likely under engineered if built using redux.

[gaearon]

graphql based systems I would argue are an over engineered solution for many apps, conversely apps with complex data structures are most likely under engineered if built using redux.

Good way to put it; that's how I feel about it too.

[mattapperson]

@gaearon keep up the good work with redux! One of the best tools going! I am using it in 5 large apps and 2 small ones at my company and loving it!

[vojtech-dobes]

@gaearon keep up the good work with redux! One of the best tools going! I am using it in 5 large apps and 2 small ones at my company and loving it!

💯

[oriSomething]

i think their not the same:

• relay - for solving data fetching management from the server
• redux - for solving state management of application

many complex applications contains state which is not related to the server that you'll need to manage. i'll argue that if you'll use relay, you'll see yourself in the end need redux as well. according to the opposite, relay seems like a very nice boost but only for server related stuff

[IwanKaramazow]

Question is how does Relay relate to flux inspired design patterns? Where does Relay end, when do we need Redux? Is Relay Flux 2.0?

The Todo Relay example: does it render redux obsolete?

[aphillipo]

Maybe there is a way to tell your reducer how to map itself to and from GraphQL and when? Not saything that isn't complex but what is the simplest way to make that make sense.

Need to learn more about what Relay is. It's not a couple of hundred lines of code that's for sure!

[gyzerok]

@oriSomething You are not quite right. Relay solves a lot of state management too.

[oriSomething]

@gyzerok i've meant client side application state