Apollo Form State Management - reactjs

Question

What is the most conventional way to deal with form state management using the React Apollo Client? There are too many walkthroughs of basic apollo queries and simple todo apps, but none I've seen showing how to deal with realistic forms.
Imagining three different user flows:
Edit an existing entity (update form)
Edit a collection by adding/removing an element (update form)
Create a new entity (create form)
There seem to be a few solutions:
Use a stateful React component. That stateful form is nested within a <Query /> and <Mutation /> or otherwise has access to both data and mutate. On submit, use the mutate function directly to submit the mutation and (if necessary) manually update the cache on success. It works, but requires a more complex stateful component. One of the side effects is that you have to compute state from props (componentWillReceiveProps etc) because the form requires both a query (for the update form, to show current values) and a mutation, and could potentially receive new data after the form is already rendered (on refetch/poll)
Use Apollo-Link-State and #client- scoped queries. This seems to face all the same problems as a stateful component, if not more because of the extra indirection. It is intuitive for a create form/new entity, since that new entity could be saved in the local cache and then sent to the remote API on submit, and would automatically appear in the normal cache on success. However, it's less intuitive for an update form, since now you have two copies of the same object, essentially. The form will also have to switch its source of truth, to originally read from the normal cache to populate the form, then write to/read from the local cache during editing, then possibly revert to the normal cache after submit. Otherwise good explanations like https://www.robinwieruch.de/react-apollo-link-state-tutorial/ don't show how to send in that locally-cached data, and generally focus on data that's only meant to stay local, such as device API results and user configuration.
Write to the authoritative/'normal' apollo cache, right over the api-fetched data, then read it back from the cache to submit it to the remote API. This seems to make more sense for an update form, since there's only one state for that entity, but won't work for a new entity since that entity won't have an id yet (while we could generate a uuid on the client, I would prefer to allow the backend to generate the id) and thus isn't something the Apollo cache can work with, AFAIK. Another problem with this is that the form data the user just submitted will be overwritten on fetch, which could be frustrating if something didn't work.
Appreciate any advice, examples, or input - thanks in advance!

Answer 1

I find apollo-link-state to be more useful for situations when you want to manage state that's entirely client-side and not part of the data you're fetching from your server. I don't think it's well suited for managing component state, especially forms. What works great is combining Apollo with a library like Formik. This reduces the boilerplate and overall complexity and of your component. Here's a rough example:
<Query query={SOME_QUERY} />
{({ loading, data }) => {
if (loading) return <LoadingIndicator/>
return (
<Mutation query={SOME_MUTATION}>
{(mutate) => (
<Formik
initialValues={_.pick(data.someData, ['foo', 'bar'])}
validate={/** optional validation function or schema **/}
onSubmit={values => mutate({ variables: values })}
>
{(formikProps) => (
<YourFormComponent {...formikProps}/>
)}
</Formik>
)}
</Mutation>
)
}}
</Query>
The Formik component's render function gets a ton of props, which are all described here. Your actual form component can be stateless and basically just render what props are passed down to it (values, errors, onChange handlers, etc.). Formik accepts yup schemas for validation, which makes validating inputs a snap as well.