Redux: Has Redux's Time Come and Gone

https://github.com/rackt/redux/issues/464

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.

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?

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.

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.

@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!

@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!

:100:

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

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?

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!

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

@gyzerok i've meant client side application state

@oriSomething Yes, I'm talking about client-side application state

@gyzerok i've must missed it. can you give me a link about this?

@oriSomething there is no special link because Relay manage it implicitly. Maybe you can try to watch FB talks about Relay. They talking about how Relay solves cache problem. Client-side application cache = state. I do not remember definite talk, sorry.

@oriSomething the only place developer should do some explicit state management is here.

@gyzerok ok, so in that case, is there a state management that isn't related to the server that relay does? as far as i understand it doesn't, or is it?

@oriSomething If I understood you correctly Relay do all things about data normalization on the client and merging data from queries into single store.

@oriSomething yes, it does=> https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
Check: https://facebook.github.io/relay/docs/guides-ready-state.html#content

Only if there's insufficient data on the client, Relay sends a request to the server for more data.

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.

So I made slim-redux.js just for fun—a version of Redux without comments, developer warnings and sanity checks. It passes all the essential Redux tests (except the sanity check tests), and it's 99 lines :wink: . This should seal my point that Relay and Redux are tools with wildly different scopes.

@IwanKaramazow i think i wasn't clear enough, what i'm trying to say, is not all data is about the server, there is a data which is not related to the server to manage, and i truly don't think relay is the go to "tool" even if it can to manage this data

@oriSomething can you give an example?

Fully agree @mattapperson . Everything comes down to the definition of complex, or better, to where each individual recognize a "complex thing"

@IwanKaramazow I think @oriSomething talks about client side form state for example

I moved from Redux => Relay because of GraphQL. Mostly all the resources in my application were hierarchical. They naturally made sense to be nested entities. Keeping a cache of these models in Redux was amazing. I had a sane view of my data and could quickly iterate with the awesome redux-devtools.

But without GraphQL, I had to do several round trips to map remote resources to the redux tree.

1. /resource1-list
2. /resource2-list?resource1=
3. /resource3-list?resource2=

Obviously this is a problem with REST, not Redux. Had I seen some Redux-GraphQL bindings earlier, perhaps I would be using those. Adopting Relay changed very little in my application. Instead of @connect I am using Relay.createContainer. Both products have the same vision of architecture with differing APIs. I wrote a quick post on this.

I am currently using both redux and relay/graphql and although relay is amazing for data fetching, i can see myself always using redux. I currently use redux for 2 reasons and I can see myself finding more reasons in the future

1) Miscellaneous state that needs to be shared between components that do not live in the database
2) Form prep. I actually have one part of my application where I have a toolbar component that has a submit button, and a panel component that holds all my input fields. When I type in the form, I debounce my input into a "form reducer" stored in redux so that my toolbar can have access to the data before I submit.

Also, redux devtools is awesome.

Man oh man. I have been reading up on Relay today, and I have to admit the code is not easy to read nor is it easy to understand. I looked at a few examples of Redux and I was able to grasp the core concepts by just reading the code.

The tutorial or the Todo example seem anything but elegant. I think React and FLUX pride themselves on being simple. I don't get that feeling from Relay as of yet.

Given Relay's heavy ties to React and relative overkill in complexity for most apps, I've been more keen on Falcor lately. In fact, because of its promise-based interface, it fits in really nicely with how you do most async behavior in Redux. And because its decoupled from React, I can use it everywhere in my app more easily. Also, server-side rendering isn't fully baked yet, which is a non-starter for me.

I'm also liking react-resolver, which is _sort of_ akin to a "Relay Lite". That one may end up being best for very simple projects or ones that rely on third-party REST APIs.

@timdorr Have you tried storing all of your state in Falcor? Having your reducers use a Falcor object, for example.

Not yet. I'm still in experimental mode with it and I've got bigger fish to fry on my projects, so I haven't given it enough attention yet.

I've played around with Falcor, and I'd highly recommend it. In fact, I'm working on integrating a Redux app with a Falcor backend right now. It doesn't give you the query aggregation of Relay, but it has a very sophisticated cache layer in its client library that prevents overfetching. I think that might be good enough, but time will tell.

@gaearon how does writing a React web app with declarative data fetching compare to writing the same app in Elm?

Seems to me like the chief difference is that data fetching is more declarative with Relay & GraphQL (Elm asks you to specify a URL, and it's up to you to sort through the data that comes back), and everything else is more declarative in Elm.

Actually, it seems like the Elm ecosystem could benefit from a port of Relay/GraphQL.

In regards to query aggregation, there's the Model.batch method. It takes either an interval (in milliseconds) or a scheduler but, I'm not finding much documentation on schedulers.

If you don't mind me asking, how are you integrating Redux and Falcor? All my attempts have left me frustrated.

I'd also be interested in seeing a redux Falcor example. I've read all the Falor docs and agree it's much simpler than relay/graphql. Albeit less powerful.

For anyone wondering about the relationship of Redux with Relay, and whether it makes sense to use them together, see: https://github.com/facebook/relay/issues/114

The gist is that Relay will eventually handle data from multiple sources (backend, local ephemeral data, etc.), so it replaces other Flux implementations you may be using.

https://github.com/facebook/relay/issues/168#issuecomment-135169255:

Note that Relay is an implementation of the Flux pattern (can Flux replace itself? ;-).

We're using both Redux and Relay heavily at OpenGov. It's true that since moving to Relay, our reducers/ folder has gotten far smaller. However, we've found that Redux is still quite useful for application-level, local state management. Perhaps one day Relay will supplant it in that area, too. But as @josephsavona put it once, the "Redux architecture" is really just... functions :) Even if one day you move on from Redux the library, you'll likely continue to use immutable state updates, reactive data flow, reducer functions, etc. for the forseeable future. That's the valuable part of Redux IMO, not necessarily the <100-line library that exists in this repo. (Oh, and the community, of course.)

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.

Agreed, but I'd argue GraphQL + Relay is a good investment even for modestly-sized apps, especially for new projects that are starting from scratch.

What do you guys think of https://github.com/gyzerok/adrenaline?

Not exactly fitting, because it doesn't use Relay, but what do you think of this opinionated full-stack approach out of the Meteor Community? https://github.com/mattkrick/meatier

Only a deep architecture like GraphQL/Relay or Datomic/Om.Next can solve the object/relational impedance problem... Here are my thoughts -- feedback appreciated.

GraphQL/Relay: The End of Redux? (Perhaps?)

Looks like there are a lot of people interested in this topic (Relay/Redux, GraphQL, and reducing complexity) I'm working on a design for a simple yet functional GraphQL client that will play very nicely with the Redux approach to app state.

Curious what people think about this set of design principles: https://github.com/apollostack/apollo-client/pull/7/files?short_path=83772ba

Just adding my 2cents here: I don't think there is an end to Redux. It's simple and beautiful, and sufficient in many cases. The JS ecosystem is so fast and hard to keep up, and Redux, like React in some way, is a milestone on which we can rely for some time. We just cannot evolve our workflow every month (or at least, I can't), and I think Redux is a really a good option right now. Relay (and data fetching in general) is just not required on many projects…

@gaearon it has been a few months since you made this post, and you just gave a talk on Redux at a React conference. Where would you say we are now in terms of GraphQL integration with Redux compared to Relay/, or perhaps a combination of all three?

@likeabbas if you're looking for GraphQL-Redux integration, try Apollo Client: http://docs.apollostack.com/apollo-client/index.html

We don't have 100% feature parity with Relay yet, but we are getting close.

@gaearon to echo the question from @likeabbas : "Where would you say we are now in terms of GraphQL integration with Redux compared to Relay/, or perhaps a combination of all three?"

A couple brief thoughts. Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware. That use case doesn't seem likely to go away, so rather than "has Redux's time come and gone", perhaps a more interesting question would be: if you are building a GraphQL client, does it make sense to build on Redux?

To which I would answer that it isn't clear that there is one right answer. Building on Redux may benefit from integration (shared tooling, shared data), while building a custom approach is more work but allows more domain-specific tooling and may enable better performance. As with many things in software development, it depends on the use case!

@josephsavona : that is a _great_ summary of Redux! We may have to steal that for the docs somewhere :)

Yeah the title of this thread is not optimal, and it seems like the question has been kind of exhausted. Perhaps it's time to move the discussion somewhere else.

>.> lock the issue

I'll just close this out. Not sure if any resolution is to be had anyways. Redux works for some people and that's good enough for me.

Whoops, wrong button. Sorry about that 😄