[pferdone]

> When I reference a Person object in my view that I'm using, will phone number be there or not, who knows.

Well you know, because your view has a query that asks for a Person object with or without a phone number. The cache (your store) is managed by Apollo not yourself.

[seanalltogether]

I theory yes, but in practice react native development seems to be a grab bag of 3rd party libraries and design patterns. Redux, apollo, some typed objects, some untyped objects, stateful wizard views, stateless normal views. Maybe your objects are defined and queried on the view you are looking at, maybe they came from a previous view.

[pferdone]

I‘m not talking about theory here but about my professional experience using GraphQL and Apollo for two years in production code. To be specific: I would hardly have a use-case for Redux when apollo-client already has built in local state handling capabilities. Throw in TypeScript and generate your type interfaces from your schema and your queries and there‘s no second guessing. GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together.

[LargeWu]

"GraphQL and Apollo is not at fault for people writing bad code who mix patterns and ideas that shouldn‘t go together."

When you say this, I hear "Apollo and GraphQL are fragile technologies that don't play well with others."

Furthermore, technical decisions like which libraries to use are many times not at all related to technical reasons like this, but rather what a particular developer with influence wants to do, based on their own personal preferences. OR, the downsides of decisions to use certain technologies are often not understood until problems begin to creep up, and by then it's too late. Of course, technology companies, especially venture backed ones, don't want to highlight those things to decision makers. Either way, I have a hard time blaming the rank and file developers who probably had no input in the first place.