Closed chrischen closed 5 years ago
It is not a good idea to mix client state with GraphQL data cache; a better way is to use React context and hooks APIs.
Also, if you find yourself managing complex client state (for example multi-step builders, quotations, etc.) it is probably a good idea to manage that state via the GraphQL API properly. That way your users can close and reopen browser tabs, resume an activity on other devices, etc. A record of activity is also nice for analytics purposes.
Thanks for the suggestion though ❤️
I'm trying to buy into which paradigm is best, as Apollo recommends doing all client state in graphql as well: https://spectrum.chat/apollo/apollo-link-state/apollo-link-state-vs-redux-vs-react-hooks-context~dcb1118c-8819-4593-8b22-040229ed4282
Could you let me know the reasons you believe this should be avoided?
Let me answer your question with another question… other than because Apollo recommends it, why do you want to mix local application state with GraphQL cache?
Plenty of smart people think it's a bad idea, so don't be bamboozled by hype 🙃
React context and hooks were purposely designed to make managing state easy. Frankly in all of my projects (before hooks came out) I only ever needed component setState()
. Redux was a complex waste of time every time I tried to use it.
There is nowhere logical for local state to go in graphql-react
cache. Cache entries are filed according to the data and error results of each GraphQL request, which is a different (I say better) way than how Apollo Client "normalized" cache works; see https://github.com/jaydenseric/graphql-react/tree/next#cache-strategy .
All of Apollo Client's complexity is riddled with bugs and has an unacceptable bundle size cost, 40-50kb+ which is larger than all of React! See https://github.com/jaydenseric/graphql-react/tree/next#bundle-impact .
Support managing client-only state with graphql.