Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setting up multiple mutations #3231

Closed
anthonychung14 opened this issue Mar 28, 2018 · 7 comments
Closed

setting up multiple mutations #3231

anthonychung14 opened this issue Mar 28, 2018 · 7 comments

Comments

@anthonychung14
Copy link

anthonychung14 commented Mar 28, 2018

Intended outcome:

We want to use the Mutation component, but conditionally execute on two Mutations (dependent on a prop received by the component it wraps).

I can't find documentation or use-cases that demonstrate this. Would this be a better use case for a HOC using graphql? or should I have a totally separate mutation function (that does A + B) rather than have one mutation that does A and maybe B?

Actual outcome:


<Mutation
        mutation={createMutation}
    >
        {(createNode) => {           
                const maybeCreateNewNodes = (propData) => 

                createNode({
                    variables: {
                        nodes: [newFolderNode],
                        options,
                    },
                });
               if (propData.specialProp) {
                   doSecondMutation({ variables: { specialProp }})
               }
            };

            return (
                <NewtemContainer
                    twoMutations={maybeCreateNewNodes}
                    {...props}
                />
            );
        }}
    </Mutation>

Stacking Mutation components doesn't seem to be a great use-case if I can just do

yield call (firstMutation)
if (specialProp)
yield call(secondMutation)

Version

@hwillson
Copy link
Member

Thanks for the suggestion @anthonychung14. This is something that could be handled by using HOC's with graphql and Recompose's branch functionality. I agree though, it would be helpful to have something like this documented. PR's encouraged! 🙂

@hwillson
Copy link
Member

Just a quick update here - we're going to add a new nested mutation section to the docs shortly. This new section will cover:

  • Example(s) showing how to handle nested mutations using the <Mutation /> component + render props
  • Example(s) outlining how to leverage a composable render prop solution, like react-adopt (also covering the pros/cons of this approach)
  • How leveraging too many mutations in a single component might mean it's time to refactor
  • Outline how HOC's can still be used

@mssngr
Copy link

mssngr commented Jun 14, 2018

Looking forward to those docs updates! I'm facing this situation, as well.

@aaronkchsu
Copy link

Same!! :) +1

@aviov
Copy link

aviov commented Jun 17, 2018

+1: have need to mutate parent object, straight after create mutation of object itself.
Just managed this with 2 nested Mutation components, used their update props for cache and UI updates.
Question: Would it be equally good practice to nest Mutation component into ApolloConsumer component and use client.mutate({ mutation, variables, update }) ?

@denkrasnov
Copy link

Mutations can be more than just 2. So, looking forward for docs updates.

@hwillson
Copy link
Member

To help provide a more clear separation between feature requests / discussions and bugs, and to help clean up the feature request / discussion backlog, Apollo Client feature requests / discussions are now being managed under the https://github.com/apollographql/apollo-feature-requests repository.

Migrated to: apollographql/apollo-feature-requests#8

@apollographql apollographql locked and limited conversation to collaborators Jul 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants