Apollo-client: [Question] Should all local state mutations be replaced by reactive variables?

Created on 27 Jul 2020  路  1Comment  路  Source: apollographql/apollo-client

Hi Apollo team, thanks again for the 3.0 release, all the new features and fixes makes our life so much easier! 馃殌

I have one question regarding the changes on Apollo local state.
Local resolvers for "_local-only_" Queries can be easily replaces by Type Policies, however, I don't see how to migrate "_local-only_" mutation to Type Policies or something similar.

Looking at the doc and also ac3-state-management-examples, it seems that there is now way to update local data using GraphQL, the only remaining options are Reactive variables or Cache API writeQuery/modify.

This is not a feature request, just to make sure that I'm not missing anything here 馃憖

Thanks!

Most helpful comment

I was wondering the same thing. For me, a big plus on local resolvers was the transparency on whether or not the data was coming from/ or is updated on the server or local. I could add fields, queries and mutations without modifying the server while the UI components just use the extended GraphQL schema with Apollo Client taking care of handling some of those fields, queries, or mutations locally. The read() works the same way (fields, queries) but suddenly mutations are not transparent anymore (unless using deprecated local resolvers).

>All comments

I was wondering the same thing. For me, a big plus on local resolvers was the transparency on whether or not the data was coming from/ or is updated on the server or local. I could add fields, queries and mutations without modifying the server while the UI components just use the extended GraphQL schema with Apollo Client taking care of handling some of those fields, queries, or mutations locally. The read() works the same way (fields, queries) but suddenly mutations are not transparent anymore (unless using deprecated local resolvers).

Was this page helpful?
0 / 5 - 0 ratings