React Apollo State Management Best Practices

[@oskarsrukmans8997]

Would love to see updated version of this based on Apollo client 3 and reactive vars

[@benji9325]

same here

[@SaschaB2B]

I migrated all data fetching to apollo graphql hooks. 99% of the time I just fetched data, show it, mutate it and save it. The last 1% is mostly global states like "Is the menu open?" or "Which country/language is selected?"That's handled with context now. Global wrapper component to provide access everywhere

[@iandaley2295]

same here, exactly. useContext w/ useMemo/useCallback are so powerful. I think a lot of peopleare still leaning on Redux out of habit/comfort...

[@MungeParty]

That may be fine for simple applications but if your business logic has interdependent data with complex relationships, context is not the best practice. Apollo 3 has more client state management features.

[@joohimks]

For information such as country, language and login do you think Context replaces redux for a complex application?

[@avi7278]

Why do you use useContext when you could just use a local-only Apollo field for that last bit of global state?

[@pannihto7588]

It would be nice to see an overview of Apollo Client 3.0. It's got some interesting new features

[@EricBishard]

Excellent video, I'm literally doing everything you explained already, I came to this video thinking I would get some magic bullet about how to use GraphQL client instead of ContextAPI or instead of useState , useReducer, or even Redux. But once explained it makes complete sense.

[@tayloraucoin168]

Over the past year I think I've developed a pretty cleaver way to handle the balance between React, GraphQL and Redux. After a long stretch of trying to use Apollo-local-state (hate it) I decided to make the switch back to Redux for local-state. In doing so I decided to move all my 'page-initializer' fetches into a separate action library in my store. I trigger these initializers by setting up a router-history watcher that fires on history change. Upon reception I store the data in Redux directly before it trickles down to the components. The extra bonus is that when I make these fetch calls I am also storing a record of what api calls have been made and at what unix time. That way, I can pivot between pages and restrict additional api calls from being fetched that are not needed because I already have that in my state and do not need it again. The unix time is for any features I may add where I want fresh data and essentially have an expiry to when a new fetch is permitted on history change. I will look into graphql-request though! Since I have already minimized the apollo library to just a request agent, that seems like it may be a better solution. Good suggestion

[@asdf3568]

I hate both

[@edwardslayd7816]

Great video! Exactly what I was looking for. I am having to use Redux to pass state between roots due to mapbox & React3Fiber needing a new root. However the project that I inherited already has Apollo and Reactjs context. I was looking at transferring the state all into Redux but I am no thinking all I really need is the ThreeJS context in Redux and all the rest can stay in apollo

[@rahulsriram6295]

What if you wanna pass the fetched { data, loading, error } from one component to its children components? All examples you took are single component examples. What if we want the fetched results to be passed to child components? For example you have a blog post, and you got an update button under it. When you click on update, you render a pre-filled update form to edit. For that will we pass the body of the blog post to the form's text-area....or re fetch the data in the updating form component again?

[@exactzero]

Use props.

[@rahulsriram6295]

@@exactzero sending props to down the component tree? Till whatever level I need it? If we are using context or redux, we can fetch data in our reducers and use them in any component without passing through props. We can't do that here cz useQuery is a hook we can use it only inside functional components.

[@exactzero]

@@rahulsriram6295 If it is not more than one or two levels deep, it's fine to pass it down. In your case, you can execute useQuery again in the form component and Apollo will fetch the post from the local cache without touching your server.

[@rahulsriram6295]

@@exactzero Yeah man I totally forgot we can fetch from the cache too without touching the server. Thanks

[@migom6]

what if I need to pass down user data to all my child components and the user data is fetched using graphql hooks? Can I use apollo graphql hooks inside reducers?

[@charleshughes1417]

How would one manage frontend only mutations of persisted data? If I have a form that doesn't call the backend until the "Submit" button is pressed, how would I manage the ephemeral state without useState?

[@avi7278]

I agree with not duplicating data, however if you're using apollo, what use do you have to keep the state of a sidebar in useContext? Apollo provides a global state store that's tied to the cache itself and that you can query for local fields the same as you would for network requests, and even mix and match the two with @client decorators on local only fields, and subscribe to updates to those fields with watchQuery. There's no situation that Apollo can't handle that another state management solution could, and in fact it's very much the opposite of that. You can then get every bit of data you need for any one render with a single query. At this point, if you're using a gql server and redux/mobx/etc, something's wrong.

[@fev4]

Could you sometime in the future take a deep dive into apollo-link-state? I find it confusing where the data is stored and how to access/manipulate it. I understand you don't like the approach but if you could explain this with examples and pros/cons for both apollo-link-state vs context/useState, that would be really awesome.

[@devk6810]

+100

[@iandaley2295]

The #1 con from my experiencewould be on performance. If you need to manipulate data in the cache with apollo-link-state, you're adding another apollo lib (or using the already very bloated apollo-boost lib) to call and manipulate your data tree (via the cache, think O(n)+ ). And for what? For data that your app's state tree really doesn't need to involve GQL with... Better, as Ben suggests, set up a memoized function and store the client-only call using useContext() & useMemo() (or useCallback(), as the case may be). In this case, you're leaving the GQL-managed piece of your app's state tree untouched and the optimized client-side code will be using ReactJS's own native library functions, rather than layering in Apollo's on top of everything to manipulate the same data...

[@devk6810]

Yet its better than making follow up request or subscription I guess

[@iandaley2295]

​@@Nick-oh5jc yes, that's from the docs and its an improvement for Apollo, definitely, however it's still additional overhead compared with theuseContext() & useMemo()/useCallback() hooks, which are part of the React project itself.

[@fev4]

In general I'd really like a deep dive into global state management comparing Apollo vs useContext

[@higochumbo8932]

Is there any reason why you memoize the .map() instead of putting it inside an useEffect that only runs on component mount?

[@liftingisfun2350]

Hi Ben, what if I want to have an offline mode where users can still manipulate the data without a connection to the server?

[@chiubaca]

so its ok to mutate the apollo cache directly as if it was like a redux store?

[@devk6810]

Hey ben, can you make a video on updating cache data, for, eg: let say in case of e-commerce, I fetched all my product orders from the server, then use cancels the order, so I need to update its status to CANCEL. for this what I would do is, first update on the server then refetch all orders so that, cancel status gets reflected in UI or I can use subscription, wouldn't it be better to first update on the server then updated local cache so that I don't need to make followup fetch request or subscription hope you got that please help me

[@stefanfeederle4429]

Hey, you can use a subscription to propagate changes to the frontend: subscription orderCancelled { orderCancelled { orderId state } } This can be fired from the backend everytime an order is cancelled. Apollo should automatically update the cache if you include the orders key and the updated field.

[@alextjn]

when creating or deleting documents, you need to manual update the cache. When editing, you don't have to, just make sure the mutation returns the edited document's id and the edited field(s). www.apollographql.com/docs/react/data/mutations/#updating-the-cache-after-a-mutation

[@ModdingMontagesHD]

just finished up a pretty advanced e commerce site using react+context, would be a good implement.

[@bawad]

I agree with the suggestion to use a subscription here. updating cache data: kzbin.info/www/bejne/ooKapWVmnKuFZ5Y

[@mirandaineslopez1491]

Hey tks for sharing What would u do when the { data }fetched from apollo is global data u will need in many components? Im looking for the best way to implement graphql + redux at a considerably big app, where the graphql Querys I receive from BE have data which I need to implement through the hole app... Would then be justified to store the apollo data in the store 4 u? Regards

[@EatMyHacks]

Totally agree with treating Apollo cache as source of truth. In my project there is a case where I store a kanban board in react state rather than pull directly from the cache. This is because when a user moves a card with react-beautiful-dnd, it returns to it's initial position before the state is updated by a subscription. I'd like to use the cache as the source of truth while also maintaining fluid ux. I have played around with cache update queries in my mutations, but haven't been able to get them to play well with subscriptions(duplicated data etc). Thoughts?

[@bawad]

When you need the ui to update instantly, take a look at optimistic updates in Apollo

[@bridlershoc6569]

Hi guys, I am implementing this solution, but my Apollo keeps going to the first item in the list. How to prevent this?

[@robhybustami7718]

Thanks @Ben Awad great video. Could you give a couple examples of where the apollo for local/global state management can be painful. Doing some research before I commit to a framework/style for a new project

[@sreekumarmenon]

Nice, we do the same in our project, Apollo for api data + mobX for shared state.

[@exactzero]

Short and concise. Perfect.

[@mrbiditY]

Hey! Nice niche but very important topic again! It would be nice to get more React Native content like how to set up a robust project and what are the difficulties or just general React Native specific topics like deep linking or linking native modules with cocoapods etc.

[@md.akib5124]

Ben, how do you find out libraries like graphql-request? what kind of search term do you put in the URL bar?

[@wojciechkaras8997]

For me, the most common use case for coping date from useQuery to useState is when it is used as initial data for a form that can be changed later on many times before saving. How do you approach this kind of situation without duplicating data?

[@bawad]

I think that's fine, not really duplicating there because the data will change

[@Kasukke]

Yeah I think form data can be treated as local state, like the todoCompleteMap in the video, as opposed to remote data

[@andrestone]

Just beware of missing subscription support on graphql-request.

[@pierrega3418]

I agree that apollo local state management is verbose, but I'm sure we can create tool which can generate ORM-like layer above the apollo cache.

[@brisketbaron]

I just use the Apollo cache as my state and manage it with the methods you get when you create a cache object (readQuery, writeQuery, ...etc) and normalize it and use it like a redux store. If it’s client side only I use the @client directive. Don’t need useState or useReducer at all.

[@adamsinger1890]

I would recommend making a subcomponent to maintain the extra-state rather than creating a map in the main component. You will have a memory leak or have to manage the removal of items from the state map. Plus its just cleaner with a subcomponent since you can just store your todoComplete directly in a variable and not have it indexed in an object

[@bawad]

I'm not sure why you would have a memory leak, but I agree sticking the logic in a subcomponent or custom hook can be a good idea to split up concerns

[@adamsinger1890]

@@bawad If the data changes and an ID you had indexed no longer exists, it would still exist in state unless you are managing that. Its a minor leak

[@bawad]

oh I see

[@shawnradke]

Thanks Ben! I just needed to send a graphql query and fetch data normally

[@ray-lee]

reactive var in apollo client 3 is a lot more easier than context or redux!

[@kylehenson2259]

how are you ben , you think context is good or redux

[@TheRenaissanceTechnologist]

This is a great tutorial. Thank you. One question though.. in your "setTodoCompleteMap" function, you're setting the "!todo.complete" ... but 'todo' is sourced from the Apollo query, so maybe 2 problems... (1) We need to have a 'complete:false' already coming in from our data source; and (2) 'setTodoComplete' will always set to 'true' -- so no toggle if incorrectly marked as complete. I may have missed something, but would appreciate some thoughts because I'm diving deeper into Apollo cache and leveraging the Provider to access data further down the tree... and really like the strategy you're applying here. Thank you for this and all your tutorials. They've helped me tremendously.

[@bawad]

If the field should be stored in the db, then you should do a mutation then update the value in the cache otherwise storing whether its complete or not in useState is fine 2. I think it's fine to do that

[@hamedhatami518]

I wish you had a Fullsrack tutorial of graphql-yoga/prisma/react/apollo

[@bawad]

I'm waiting on Prisma until v2 is ready for prod

[@ДенисМалышок]

Love u dude!

[@alextjn]

Hi Ben, great insight. But for the "additional-field usecase", apollo-link-state offers an elegant solution as well. You can use @client directive, and write a local resolver for the additional field, very similar to the example provided in the docs here: www.apollographql.com/docs/react/data/local-state/#local-data-query-flow

[@bawad]

imo it's not very elegant

[@mariomerino9758]

Awesome video ! Thanks man

[@jorgebaraltquintero]

Really helpful videos, thanks for doing this!

[@Kasukke]

Hey Ben, thanks for the video. I'm new to hooks, context, and GQL and this was very helpful. I've made every mistake in your list of bad examples haha. Architectural/design pattern question... If a piece of Apollo state is used by many components and components deep down the tree, how do you avoid the prop drilling issue? It's basically remote + global app data. Passing down as props is verbose, hard to read, and error prone to manage. We're currently stuffing this type of state and the mutation callbacks from useQuery into useContext. The extra level of indirection feels wrong. Do you have any advice? A video on architectural patterns would be cool.d

[@artgurianov]

Exactly when I need it! Again! How? 👽👽👽

[@luciano-lima]

What are you think to setup apollo server to use relay config?

[@bawad]

don't have much thoughts on it, never tried it

[@luciano-lima]

@@bawad oh see, thanks anyway for your good job with videos here

[@zoachim]

This was helpful thank you

[@chaddeveloper6990]

Good video

[@jdcb18]

Can you do a video on best practices for useLazyQuery

[@bawad]

You just use it whenever you don't want the query to be called right away

[@ayazpathan2671]

Hey Ben, I watched a lot of your videos, found helpful. I want to request you that can you make tutorials with GraphQl and Relay Modern?

[@bawad]

when I try relay, sure

[@apenet-]

Nice technique

[@thomasini]

4:20 Interesting. This is the first time I've seen a ternary statement broken into multiple lines...

[@avi7278]

You don't use Prettier?

[@dealloc]

I tend to separate state management for data fetching and state management for UI. I rarely use any state management library, but this depends on the complexity of the UI. For complex UI I use a FSM (Finite State Machine), XState being a great library for this. But most of the time I just stick with Context and hooks as they make for nice and reusable API for React apps.

[@alisalahio]

Awesome vid! Your accent is really similar to Naval 🤔

[@bawad]

interesting, you're the first one to say that

[@alisalahio]

Ben Awad Maybe it’s the way of talking or explaining. Anyway, I like that way :D

[@shamilmammadov8246]

Thx!

[@aleksd286]

Cheers