React Apollo State Management Best Practices

so I see a lot of people get confused when they're trying to decide how to do state management and react when they're also using graph QL so in this video I'm going to go through how I actually like to do it and approach it and split things up and I'm going to also go through some techniques which I don't think are very good that I see some people do and that make things more complex now in this video I'm going to be specifically showing examples using Apollo but I think this really applies to whatever graphic you'll client you happen to be using like Arkell or relay so we're gonna start with what I would not recommend doing and that is fetching some data with Apollo then taking that data and sticking it in a different store or a different state management library so here's an example that here I'm using the used query hook from Apollo and I'm fetching some to do's and then I'm taking this data and in a use effect took I'm calling set to deuce so I'm taking the data that I fetched from Apollo and I'm sticking it in this state right here in this use state hook and so I have now access to the to Do's here but I could also access the to Do's from the data and so now I have basically duplicate data and the way I did this here as I was just doing it with the you state hook but again it doesn't really matter that I chose that we could have also dispatched this as an action if we were using Redux and stored our data in Redux the point is we now have two places where we have duplicate data and we're now having to keep them in sync as we either fetch more data from Apollo or we update Apollo we then have to make sure other store has the same data or we have a problem now I usually see people do this for one of two reasons the first is the entire application is already using some state management library like redux and they wanted to keep all the data in redux and have that as the single source of truth so they're fetching with apollo but they're really ignoring the cache that Apollo has and just storing everything in Redux and if that's your case I would recommend just avoiding Apollo all together right you're gonna have a larger bundle size because reactor Paul is pretty large and Apollo has its own cache so you're storing duplicate data whether you want to or not you could just go through and turn off the cache for Paulo if you wanted to but my opinion if all you're doing is making a graph QL requests and then sticking it in Redux you may want to use something like graph QL requests because all this is is it the lightweight wrapper over fetch so it takes a query alright you can write your graphical queries and then you can make a fetch request to the graphical API with your query and then after that is finished you can just you know dispatch that data to redux or other state management library you want to store it in the second reason I see people putting data they get from Apollo in another store is they want to add some extra fields to it so for example here I'm fetching from two do's and then I'm taking that to do data here and in the use effect I am mapping over it before I call set to do's and you can notice here I am adding an extra field here complete I'm saying it to false so the this might be a field that's only needed on the client for example and then I just take the two dews that are in my state and then I am rendering the two dews here and right and I might make some decision based on whether the to do is complete and I might strike a line through it and then every whenever I want to update this I'm just calling set to do's and I'm passing in the new to Do's right after I click on item I want to flip whether it's complete or not the problem is this gets really messy again if the data ever changes from the - duze query here I'm having to sync it with the local state here and making sure that what is complete should stay complete or whatever I'm gonna have to have write some logic to handle that so the way I like to solve this is by just directly accessing the data from Apollo so here I have my data that I'm fetching the two dews and this used query and then I'm just using that data to map over the siddhu's here and then the extra state that I want to store for example whether to do is complete or not that's the only thing that I'll store in the state so you notice here I now have a map and basically what this map does is I'm just mapping to do ID - whether it's complete or not so like true or false for example and so when I map over the - duze now I just look up in my to-do map whether it's complete or not looking up by the to-do ID and if it is complete then I have to show a line through it and then when I click on it to do I just update that state right I said that the to do ID is the opposite of complete and so now I have basically separated my state the data that I am fetching from Apollo I keep that in Apollo here and then any of the extra fields or data that I need to add just on the client side I keep that isolated in the you state here now sometimes you don't need to store anything in state you just need to transform the data in some way all right so if I want to transform the data I can just actually add that directly in the render method right here so I could say new - duze is equal to data dot - duze and then I can map over them here for example if I want to just add some random field like good so length of name or something I could say X dot name dot length I don't know some random field you want to add here right I can map over it and I can filter if I want to based on some value make sure the names aren't blank so here I'm just removing any blank names for example and you could do all kinds of stuff here now if this becomes computationally heavy which most of the time it doesn't but if it does you just stick like a used memo in there and memorize this so you're not doing it on every single render so in our project I'll probably use a mix of Apollo you state context or some other state management library like redux or mob X but I won't stick data from Apollo and other places like Redux or use state instead I'll keep the data isolated so for example I'll use the data that I fetched from api's and keep that in Apollo and the Apollo cache and then any local state data that I have I will stick that in either you state or use reducer and then if I need to share data either between components or maybe it is global state then I will stick that in context or a state management library so for example here you can see I'm mixing all three of those things in a single component here have a use query so this is the data I get from Apollo here's some local state and then here's I'm also grabbing like for example whether a sidebar is open and this is just some global states that I'm storing in context and I want to be able to access it here and one last thing that I'll mention is we can store absolutely everything in the Apollo cache if you want to there is a Paul link state so we could kind of replace these things and store local state stuff in Apollo but personally I'm not a big fan of that technique I think the graph fuel abstraction doesn't work quite that well with state management I don't think there's really anything wrong with the technique or you're doing it in that way I just personally have found splitting it up and using you state in Redux or context to be a lot easier and a lot simpler than trying to store everything in the Apollo cache and sticking local state and Apollo and trying to use a paul link state you

Channel: Ben Awad

Views: 35,506

Rating: 4.9269037 out of 5

Keywords: apollo, redux, Apollo State Management, React, React Apollo

Id: N2q-ZYuQWI8

Length: 7min 33sec (453 seconds)

Published: Thu Jan 23 2020