3 ms·

I agree: I have just started using Redux and the new 1.0 API and documentation are great. However, I am very curious about the long-term* future of Redux now t

I agree: I have just started using Redux and the new 1.0 API and documentation are great. However, I am very curious about the long-term* future of Redux now that FB's Relay has landed... (*) long-term in JavaScript-parlance, meaning more than 2 months ;-)

quicksnap 11y ago
I'm curious too; I had the same concern when looking at Relay and hearing it as an eventual replacement for Flux. However, Relay seems too heavyweight for some projects, and incurs a lot buy-in to GraphQL.
- Matthias247 11y ago
  I'm not really in the webdev-world, but I took a look at those things too because they also seem to have interesting concepts for my work. From my point of view flux is pretty much a general architecture pattern. Relay and GraphQL seem much more tied to how facebook works and what there requirements are. It requires that you change your server-side code, which might not be possible for most parties.
  - grayrest 11y ago
    You're more or less correct. One of the not-immediately-obvious problems with the React pattern of passing data in via attrs and actions via callbacks is that the parent component needs to accept all the data/callbacks that all its child components require and its parent in turn needs to do the same. In many projects you wind up needing an additional chunk of data on a child component and that change requiring edits in 8 additional components to pipe around the data. The Realy/GraphQL (also Falcor from Netflix) idea is that an individual component knows what data it needs and having it describe the data it needs and those requirements being aggregated into a hiearchical query over the graph of data present on the server. Structuring your data requirements this way solves both client side (the problem I mention above) and server side problems (supporting multiple client apps with similar but not the same data requirements, only having to write the code to expose a table as part of a query instead of having to shape it to various endpoints). At least that's the idea. I find Relay as released to be unpleasant just like I found Flux as originally released to be unpleasant. Now that the code is out there expect a million Relay re-implementations before a rough consensus winner emerges. I expect the winner to look something like a combination of react-resolver with some redux middleware.

quicksnap 11y ago

I'm curious too; I had the same concern when looking at Relay and hearing it as an eventual replacement for Flux. However, Relay seems too heavyweight for some projects, and incurs a lot buy-in to GraphQL.

Matthias247 11y ago
I'm not really in the webdev-world, but I took a look at those things too because they also seem to have interesting concepts for my work. From my point of view flux is pretty much a general architecture pattern. Relay and GraphQL seem much more tied to how facebook works and what there requirements are. It requires that you change your server-side code, which might not be possible for most parties.
- grayrest 11y ago
  You're more or less correct. One of the not-immediately-obvious problems with the React pattern of passing data in via attrs and actions via callbacks is that the parent component needs to accept all the data/callbacks that all its child components require and its parent in turn needs to do the same. In many projects you wind up needing an additional chunk of data on a child component and that change requiring edits in 8 additional components to pipe around the data. The Realy/GraphQL (also Falcor from Netflix) idea is that an individual component knows what data it needs and having it describe the data it needs and those requirements being aggregated into a hiearchical query over the graph of data present on the server. Structuring your data requirements this way solves both client side (the problem I mention above) and server side problems (supporting multiple client apps with similar but not the same data requirements, only having to write the code to expose a table as part of a query instead of having to shape it to various endpoints). At least that's the idea. I find Relay as released to be unpleasant just like I found Flux as originally released to be unpleasant. Now that the code is out there expect a million Relay re-implementations before a rough consensus winner emerges. I expect the winner to look something like a combination of react-resolver with some redux middleware.