4 ms·

Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny

Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny and very simple. It pushes you towards keeping a lot of your business logic as pure JS, so testing your code tends to be really easy (and it means your code is re-usable, it's not tied super tightly to X or Y framework!). If you use it with React it's also a joy to test. Something that Redux doesn't solve is data fetching, caching, and mutations. If you have a reasonably sized application, you'll end up having to implement a lot of logic surrounding data fetching and caching by yourself. The suggested solution is to store your resources normalized, indexed by id, and create selectors to get the data in the shape you want. This works out alright, but it's tedious and during your first few iterations on it you'll probably find yourself with a lot of boilerplate code. Facebook released Relay [1], which gives you the solution for data fetching and caching. If you give it a try, you'll be amazed by how much mental overhead simply disappears. You want data? You get it, that's it! But then your new problem is that you need a GraphQL server, and since it's a new technology that's not very mature (outside of Facebook at least), it means you'll have to do a reasonable amount of exploring. (I should really clarify that this is in no way the fault of the Facebook teams that put out Relay and GraphQL, both tools are amazing! It's simply that the ecosystems needs time to evolve and adapt.) I'd say that in one or two years from now a formidable amount of frontend app will be using some variation on Relay and GraphQL. [0] https://github.com/rackt/redux https://github.com/rackt/redux [1] https://facebook.github.io/relay/ https://facebook.github.io/relay/

meowface 11y ago
Is there any decent framework that combines the models used by these technologies all into one? It seems a bit unwieldy to have to juggle between React, Redux, and Relay, while also throwing GraphQL into the mix.
- angeloashmore 11y ago
  Relay is basically the framework that brings everything together. Relay handles data fetching, storage, and mutations using a central store and GraphQL. If I'm understanding it correctly, Redux is replaced by Relay.
  - iheartmemcache 11y ago
    Yeah, in the GraphQL lectures the FB presenters basically said. [1] Watch the first ten minutes if nothing else. React = the view layer. GraphQL = the store. Relay = the glue. I'm still ambivalent on this form of stack but it's a move in the right direction. Component composition makes JS a lot less messy. Meteor is doing something real interesting with isomorphic JS, and whether or not it gets widespread adoption, I'm happy that avenue is being explored as well. Stefan Richter is doing some REAL interesting work with isomorphic Clojure [2] in his shop in Germany, that has some real interesting exercises. The talk is from 2010, so it was more novel when I first watched it than you'd think of today. [1] https://www.youtube.com/watch?v=9sc8Pyc51uU https://www.youtube.com/watch?v=9sc8Pyc51uU [2]
- deleted 11y ago
  [deleted]
stream_fusion 11y ago
Can anyone compare and contrast flux, reflux and redux? I have got the hang of writing flux stores - and like the uni-directional dataflow model a lot. I also evaluated relay/graphql - which unfortunately is missing backend support for my relational db for the moment. It feels like I need some experience with all the patterns/frameworks before it's possible to be confident about choosing and investing time writing code.
- simiano 11y ago
  I think this[1] SO answer by the creator of Redux sums up well. [1] http://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux/32920459#32920459 http://stackoverflow.com/questions/32461229/why-use-redux-ov...
- andy_ppp 11y ago
  I have used both Reflux and Redux. Um I guess they both have their place. Reflux is simpler to understand and forgoes switch statements and has various ways to connect stores up, even allowing one store to trigger stuff on another. It's more easy to make a mess I think, largely dues to the multiple stores and how they interact with eachother. Redux is more cleanly uni-drectional, has a larger community, amazing debugger, amazing hot reloading support, and a lovely concept of middlewares that can extend actions as they pass through your system. Most importantly I've found a single store/source of truth makes everything cleaner. It's also simpler code underlying it than Reflux and more of a nice design pattern. I think Redux is clearer what is going on in my final programs and will tend to use this going forward.
- thegoodlab 11y ago
  I'm using React on a few smaller projects where I didn't want to over engineer the whole Flux architecture. I put together the app using Backbone (for the models and collections) and used React for the view layer. The models and collections worked great as "stores" and I used the simple dispatcher from Flux to handle the actions being sent. While I really like the Flux pattern, for smaller'ish apps it did seem a bit of overkill. A couple articles I was referencing for BB and React: https://blog.engineyard.com/2015/integrating-react-with-backbone https://blog.engineyard.com/2015/integrating-react-with-back... http://www.thomasboyt.com/2013/12/17/using-reactjs-as-a-backbone-view.html http://www.thomasboyt.com/2013/12/17/using-reactjs-as-a-back...

meowface 11y ago

Is there any decent framework that combines the models used by these technologies all into one? It seems a bit unwieldy to have to juggle between React, Redux, and Relay, while also throwing GraphQL into the mix.

angeloashmore 11y ago
Relay is basically the framework that brings everything together. Relay handles data fetching, storage, and mutations using a central store and GraphQL. If I'm understanding it correctly, Redux is replaced by Relay.
- iheartmemcache 11y ago
  Yeah, in the GraphQL lectures the FB presenters basically said. [1] Watch the first ten minutes if nothing else. React = the view layer. GraphQL = the store. Relay = the glue. I'm still ambivalent on this form of stack but it's a move in the right direction. Component composition makes JS a lot less messy. Meteor is doing something real interesting with isomorphic JS, and whether or not it gets widespread adoption, I'm happy that avenue is being explored as well. Stefan Richter is doing some REAL interesting work with isomorphic Clojure [2] in his shop in Germany, that has some real interesting exercises. The talk is from 2010, so it was more novel when I first watched it than you'd think of today. [1] https://www.youtube.com/watch?v=9sc8Pyc51uU https://www.youtube.com/watch?v=9sc8Pyc51uU [2]
deleted 11y ago
[deleted]

stream_fusion 11y ago

Can anyone compare and contrast flux, reflux and redux? I have got the hang of writing flux stores - and like the uni-directional dataflow model a lot. I also evaluated relay/graphql - which unfortunately is missing backend support for my relational db for the moment. It feels like I need some experience with all the patterns/frameworks before it's possible to be confident about choosing and investing time writing code.

simiano 11y ago
I think this[1] SO answer by the creator of Redux sums up well. [1] http://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux/32920459#32920459 http://stackoverflow.com/questions/32461229/why-use-redux-ov...
andy_ppp 11y ago
I have used both Reflux and Redux. Um I guess they both have their place. Reflux is simpler to understand and forgoes switch statements and has various ways to connect stores up, even allowing one store to trigger stuff on another. It's more easy to make a mess I think, largely dues to the multiple stores and how they interact with eachother. Redux is more cleanly uni-drectional, has a larger community, amazing debugger, amazing hot reloading support, and a lovely concept of middlewares that can extend actions as they pass through your system. Most importantly I've found a single store/source of truth makes everything cleaner. It's also simpler code underlying it than Reflux and more of a nice design pattern. I think Redux is clearer what is going on in my final programs and will tend to use this going forward.
thegoodlab 11y ago
I'm using React on a few smaller projects where I didn't want to over engineer the whole Flux architecture. I put together the app using Backbone (for the models and collections) and used React for the view layer. The models and collections worked great as "stores" and I used the simple dispatcher from Flux to handle the actions being sent. While I really like the Flux pattern, for smaller'ish apps it did seem a bit of overkill. A couple articles I was referencing for BB and React: https://blog.engineyard.com/2015/integrating-react-with-backbone https://blog.engineyard.com/2015/integrating-react-with-back... http://www.thomasboyt.com/2013/12/17/using-reactjs-as-a-backbone-view.html http://www.thomasboyt.com/2013/12/17/using-reactjs-as-a-back...