Sign in to join this conversation, and others like it, in the communities you care about.
React / General
We went from tons of stuff in Redux to almost nothing
Now with apollo-link-state (https://www.apollographql.com/docs/link/links/state.html) you can even use GraphQL for the things you use Redux for!
I don't know how popular that will be, but it's an option
GraphQL is a query language while Redux is a library for state management. Two completely different things. You may say that Apollo client will replace Redux, which might be true, but even that's is inaccurate today, because Apollo uses Redux under the hood. However, since I'm using Apollo and GraphQL and haven't wrote a single reducer (yet). There're several hooks to update state after mutation/query/subscription and writing a custom reducer is the last choice.
This feels like a weird statement. A query protocol replacing a front end state management lib. We will always need both of those things. Optimistic updates Can’t be done without state management. Offline first. The question needs rewording. Maybe “Is it worth managing our own state now that Apollo or Relay do it so well?” For our application the answer to that question is yes, we do optimistic updates and server sent events that need reconciling on the front end. If either Apollo or Relay can handles SSEs our the box please fill me in.
Hi James, here's one article anyway: https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a
From our experience, most of our state management code was all trying to merge state from our API server and manage the asynchronous nature of all that. Once we switched to GraphQL, those issues were gone and we no longer had to manage business state in a store at all.w Hope that helps!
They aren't. The GraphQL query language is completely independent from the GraphQL *client library*. The thing is, a lot of GraphQL client libraries include a caching mechanism to manage the data that is pulled from a GraphQL backend. So the "state management" part is really just some GraphQL clients managing cached GraphQL data. This is completely optional though, and you can use GraphQL without it, potentially with Redux.
Hi all, inspired by this thread, I've drafted an article about how our team ended up losing the need for state management libraries after switching to GraphQL. This is still a draft so please don't share yet, but I'd love to get your feedback on the post: https://medium.com/@wmdmark/how-graphql-replaces-redux-3fff8289221d
@wmdmark Using redux for 'navigation has several advantages, I'm too lazy to explain them ATM but this SO post might explain better than me https://stackoverflow.com/questions/47104756/what-is-the-advantage-of-using-redux-integration-in-react-navigation
Having the routing logic coupled to redux allows for example to implement time travel around your app by also taking the current screen in consideration. You can do it w/o Redux, but that would be more a mess IMHO.
I'm currently working on a react+react-native bug reporting solution and it involves time travel, basically I record the redux state, replace the sensitive keys (auth, username, personal informations) by some placeholder, etc. Then I send the whole state serialized and encrypted to my bug-report server. That way when a new issue is found I get the imediate path user has followed to get the error. Permits me to reproduce & fix it faster ;)
Apollo never had a good integration with Redux beyond time-traveling. In Addition Apollo isn't synonymous with query components--that's just sugar on their powerful caching architecture. If React had the notion of "controllers" as in Redux-First Router (https://github.com/faceyspacey/redux-first-router) & we fetched from our global route abstraction instead, graphql results could go into our Redux store de-normalized. That would mean you could far more easily select the combination of UI state + graphql domain state in `connect`. Currently, most people get the denormalized results as props to components, and have very little means to properly integrate with what's in redux. ...That's something I'm working on, as I've found the complexity of doing so much in components to have spiraled out of control. The return of the ancient wisdom of "controllers" and "separation of concerns" is on its way. Fetching doesn't need to be done in nested components; you can figure out all the fetching you're gonna have to do based on the URL + cookies/etc. Like for 99.99% of most apps. If you're using state in your view layer to figure out what to fetch, that's very likely because of other async work higher up the component tree that also could be moved to the global controller/routing layer.
I think that's specific to our app though, I don't think there's anything like Redux Saga for Apollo Client
I feel like Redux has been put to use in many cases where it shouldn't have (guilty of this myself). In my case, it was mostly because of a lack of experience with the stack, and the problems of modern web development. After writing a ton of Redux boilerplate around data fetching, one starts to realize this is not where Redux shines.
I actually feel like the cases where Redux really shines - cases of very complex local state, perhaps games and such - are more edge-cases than they are the norm. For your average web-app, I would rather guess that Apollo's model of data fetching covers way more of the average usage.
If you are using GraphQL with Apollo, then I reckon Redux is not needed as all the queries are cached and once cached, it does not make a request to the server anymore so you can just keep calling the query without worrying about network overhead. Also with Apollo link state, you can manage app state as you do on GraphQL server.
I'll give someone 5 dollars to DM me and tell me what problems redux-saga actually solves! Still don't really get it.