Mutation component #1520

excitement-engineer · 2018-01-05T21:27:44Z

This is an implementation of the <Mutation /> component.

Note, this is still a WIP. I will be improving it over the next few days and adding tests.

lifeiscontent · 2018-01-06T09:22:10Z

@excitement-engineer first thing I see is being able to pass variables to runMutation. If you can take variables from both the function and props it would make for a much more powerful API because then you can partially apply the function from props and pass the rest of the variables into the function itself.

lifeiscontent · 2018-01-06T09:25:48Z

src/Mutation.ts

+          error,
+        };
+
+    return children(this.runMutation, result);


What if we add props instead of result here? That way people can still use polling functions from the component as well.

rosskevin

Some WIP type feedback - I think we should go ahead and define our own MutationResult like we did with Query, as I'm not sure when apollographql/apollo-client#2795 will be handled.

rosskevin · 2018-01-06T16:25:07Z

src/Mutation.tsx

+    client: PropTypes.object.isRequired,
+  };
+
+  constructor(props: any, context: any) {


props: MutationProps<TData, TVariables>

rosskevin · 2018-01-06T16:26:21Z

src/Mutation.tsx

+// update?: MutationUpdaterFn;
+// notifyOnNetworkStatusChange?: boolean;
+
+export interface MutationProps {


MutationProps<TData = any, TVariables = OperationVariables>

rosskevin · 2018-01-06T16:26:39Z

src/Mutation.tsx

+
+export interface MutationProps {
+  mutation: DocumentNode;
+  variables?: OperationVariables;


: TVariables

rosskevin · 2018-01-06T16:28:50Z

src/Mutation.tsx

+  mutation: DocumentNode;
+  variables?: OperationVariables;
+  optimisticResponse?: Object;
+  children: (mutateFn: () => void, result?: any) => React.ReactNode;


This result is the from apollo-client mutate<T>(options: MutationOptions<T>): Promise<FetchResult<T>>

Note there is a typing issue on it so it cannot yet be fully typed results: apollographql/apollo-client#2795

Alternately, we could define our own MutationResult like we did in Query and solve the type problem ourselves.

rosskevin · 2018-01-06T16:29:52Z

src/Mutation.tsx

+    });
+
+    try {
+      const response = await this.client.mutate({


This will ultimately need parameterized types but apollographql/apollo-client#2795 needs fixed first to use them.

lifeiscontent · 2018-01-20T12:36:22Z

@rosskevin @excitement-engineer what do you guys think about the following?

use render as the prop for render props.
use React.children to pass the props from Mutate into the children of Mutate.
use this pattern for the Subscriptions and Query components as well.

I see this API being a lot more flexible, because 1. you get the render prop pattern, and 2. if you need to compose React Components together, it's really straight forward.

rosskevin · 2018-01-20T15:30:32Z

use render as the prop for render props.

use React.children to pass the props from Mutate into the children of Mutate.
use this pattern for the Subscriptions and Query components as well.

No, this will be far more confusing. I've already made my opinion known - children are for rendering. If render was used for all rendering in react, then yes, but that is not the case.

Along these lines, I have discussed with @excitement-engineer and I'm not even sure there is a great use case for a Mutation component at all. Given mutations aren't simply fired when they are rendered, and are usually fired in in a callback which will live in the class somewhere, I think the primary use case for mutation usage is with withApollo or ApolloConsumer to get the client and call client.mutate directly. I've done this with our entire codebase in conjunction with using the Query component.

lifeiscontent · 2018-01-20T15:52:20Z

@rosskevin if I create a demo of what I discussed in a real use case would you consider otherwise? Or should I just create my own node module for the api I am thinking about?

The pattern I’ve discussed would compose incredibly well with apollo-link-state when providing local state used in turn as variables for a remote query/mutation

rosskevin · 2018-01-20T16:26:08Z

@lifeiscontent I am not the ultimate authority on the decision, but my thoughts are centered around ability for many to understand. What is clear is that many would not comprehend passing parameters as children, therefore it would be a docs/education problem and would create more issues.

I suggest wrapping it as you desire. I have a wrapper on Query to tweak a few things to suit our opinions that aren't suitable for maney as well.

kandros · 2018-01-25T08:56:17Z

Might be worth to take a look at #1550 (comment)

Currently what is the state of this?

I would like to help

excitement-engineer · 2018-01-25T12:51:50Z

@kandros I have been on holidays for the past few weeks. But I will be picking this PR up again in a couple of days when I get back:)

lifeiscontent · 2018-01-26T17:12:44Z

@excitement-engineer when can I test the latest release? e.g. Mutate, Query, etc.

kandros · 2018-01-27T08:42:34Z

You can use Query by installing react-apollo@beta Mutation is WIP

kandros · 2018-01-27T17:36:55Z

@excitement-engineer totally personal feedback: I think onComplete andonError are against the purpose of using a function renderer, I find them redundant and not clear

excitement-engineer · 2018-01-27T18:49:00Z

@kandros I think there is a use case for performing some custom operation as soon as the mutation is done or there is an error (e.g. updating the state or calling a callback in the props). This cannot be done using the render prop AFAIK. Therefore the onError and onComplete serve a different function from the render prop.

kandros · 2018-01-27T19:00:58Z

Since onComplete just pass data and onError pass the error, can’t we estimate the completion state by the loading prop and error state by state prop in the renderer? Am I missing some specific usecases?

kandros · 2018-01-27T19:05:36Z

I re read your answer, I get it now 👍🏻

# Conflicts: # src/index.ts

leoasis · 2018-01-27T21:42:45Z

src/Mutation.tsx

+      return;
+    }
+
+    this.verifyDocumentIsMutation(nextProps.mutation);


Do we want to do this only if the mutation is different from the previous one? It involves calling parser which I think does a couple things that may add unnecessary overhead if the mutation doesn't change, which should be most of the time

Nice! good tip

…flight

kiurchv · 2018-02-01T23:26:40Z

src/Mutation.tsx

+    const mutationId = this.mostRecentMutationId;
+
+    try {
+      const response = await this.mutate();


Could we return the result when this.mutate was resolved?

leoasis · 2018-02-01T23:48:40Z

src/Mutation.tsx

+
+    try {
+      const response = await this.mutate();
+      this.onCompletedMutation(response, mutationId);


I think we should run this outside of the try/catch. Otherwise, if there's an error inside this method (which is likely since it calls user code), it would trigger the mutation error path, which would be incorrect.

Good point. Thanks, updated it.

leoasis · 2018-02-02T12:37:41Z

src/Mutation.tsx

+  mutation: DocumentNode;
+  variables?: TVariables;
+  optimisticResponse?: Object;
+  refetchQueries?: string[] | PureQueryOptions[];


@jbaxleyiii if we want to get rid of the query recycler, should we also get rid of the string array in this option? This would look up the currently watched queries by name, which seems to be the same thing that the deprecated updateQueries does.

@leoasis yes for sure!

leoasis · 2018-02-02T13:18:53Z

src/Mutation.tsx

+  variables?: TVariables;
+  optimisticResponse?: Object;
+  refetchQueries?: string[] | PureQueryOptions[];
+  update?: MutationUpdaterFn;


I'm wondering if we should improve the type of the updater function so that it is parametric on TData, so that the second argument provides the result in the shape you'd expect, instead of an object of any keys of any value.
We could do this here in react apollo, the same way we did it to improve some of the Query types, and then we can send some PRs to correctly fix this in apollo client.

I tried to improve on the type and made it parametric on TData, the second argument is now fully typed. The issue with this is that it is not so easy to to fix this issue. I had to override the type definition for ExecutionResult which is contained in graphql-js. So we will have to update the type in that repo to create a long-term sustainable solution I think,

lifeiscontent · 2018-02-03T19:56:35Z

src/Mutation.tsx

+      update,
+    } = this.props;
+
+    const response = await this.client.mutate({


why not return the await'd mutate function instead of creating a variable?

Good point! I updated the PR:) Thanks

thomasdashney · 2018-02-07T16:18:34Z

I agree with @lifeiscontent - I think it's important for the mutate function to take mutation variables for the following reasons:

It's very possible that the variables come from a child component (e.g. using the Formik library):

<Mutation mutation={mutation}>
  {({ mutate }) => (
    <Formik onSubmit={(formValues) => mutate({ variables: formValues })}
      {/* etc */}
    </Formik>
  }}
</Mutation>

The existing HOC version's mutate function also takes variables.

jbaxleyiii · 2018-02-09T01:27:02Z

@excitement-engineer I think the only question remaining here is the usage of variables. Is it better done as a prop or passed to the function or both (i.e. assign). This is def a case where I think the prop remapping of the HOC gets it right and would be nice to replicate the ideas of that here in some manner?

JonathanZWhite · 2018-02-13T05:12:37Z

@excitement-engineer I'm really excited about your work on the Mutation Component! Will this be included in the non-beta 2.1 release? 🎉

trulysinclair · 2018-02-14T07:50:56Z

@JonathanZWhite I'm hoping

excitement-engineer · 2018-02-14T09:41:49Z

Hey @JonathanZWhite, nice to hear that you like the component! As far as I'm aware this will not be included in the 2.1 release. We will however do our best to get it in your hands as quickly as possible:)

JonathanZWhite · 2018-02-14T17:39:16Z

@excitement-engineer Awesome! Thanks for letting me know 🤘

…ad of through the props.

excitement-engineer · 2018-02-14T20:39:19Z

I updated the PR! It is now possible to pass variables as options in the mutation function.

<Mutation mutation={mutation}>
      {(createTodo, result) => {
          setTimeout(() => {
            createTodo({ variables });
          });
        return <div />;
      }}
    </Mutation>

Thanks @thomasdashney for providing a use case with formik where passing variables in the props doesn't work

jbaxleyiii · 2018-02-16T18:03:45Z

@excitement-engineer I've merged this into a branch on the upstream so I can finish it out! :yay:

JonathanZWhite · 2018-02-16T21:18:17Z

@jbaxleyiii @excitement-engineer Do you see mutation components replacing the HOC mutation pattern completely? Or are there still going to be use-cases for both? In the latter case, what are some good guidelines to figure out when a component should be used vs a HOC?

* Mutation component (#1520) * Initial implementation for Mutation component * Updated the error message * Improved the component. Added some initial tests * Added more props to the mutation component. * Improved typescript typings * fixed listing issues. * Added onComplete and onError props * Implemented logic for handling changes in props. * Changelog * prop-types validation * The render prop only shows the result of the most recent mutation in flight * Only verify document if the mutation has updated * Moved the onCompletedMutation outside the try-catch * Improved the type for the update prop. * Allow for passing variables as options in the mutation function instead of through the props. * removed all types for mutation component * return result from mutate call * remove default data type * bundle size increase for mutation component

excitement-engineer added 2 commits January 5, 2018 22:25

Initial implementation for Mutation component

bc034dc

Updated the error message

2907909

excitement-engineer mentioned this pull request Jan 6, 2018

Mutation Component #1515

Closed

lifeiscontent suggested changes Jan 6, 2018

View reviewed changes

Improved the component. Added some initial tests

1122462

rosskevin suggested changes Jan 6, 2018

View reviewed changes

excitement-engineer added 3 commits January 6, 2018 21:57

Added more props to the mutation component.

618191f

Improved typescript typings

23c0a11

fixed listing issues.

42e813b

kandros mentioned this pull request Jan 23, 2018

Feature Request: Render Props Implementation #1570

Closed

Added onComplete and onError props

29ead4b

excitement-engineer added 4 commits January 27, 2018 21:40

Implemented logic for handling changes in props.

889bfc3

Merge branch 'apollographql/master' into mutation-component

c639e64

# Conflicts: # src/index.ts

Changelog

a49e268

prop-types validation

333b813

leoasis reviewed Jan 27, 2018

View reviewed changes

The render prop only shows the result of the most recent mutation in …

a344bcf

…flight

Only verify document if the mutation has updated

4968fca

kiurchv reviewed Feb 1, 2018

View reviewed changes

leoasis reviewed Feb 1, 2018

View reviewed changes

leoasis reviewed Feb 2, 2018

View reviewed changes

lifeiscontent reviewed Feb 3, 2018

View reviewed changes

excitement-engineer added 2 commits February 4, 2018 10:34

Moved the onCompletedMutation outside the try-catch

351121f

Improved the type for the update prop.

0b2daca

Allow for passing variables as options in the mutation function inste…

97c704a

…ad of through the props.

James Baxley added 2 commits February 16, 2018 12:25

Merge branch 'master' into mutation-component

8762931

Merge branch 'master' into mutation-component

dab8b30

jbaxleyiii changed the base branch from master to mutation-component February 16, 2018 18:02

Merge branch 'mutation-component' into mutation-component

70b7fe2

jbaxleyiii merged commit f433edf into apollographql:mutation-component Feb 16, 2018

Mutation component #1520

Mutation component #1520

Conversation

excitement-engineer commented Jan 5, 2018

lifeiscontent commented Jan 6, 2018

Choose a reason for hiding this comment

rosskevin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lifeiscontent commented Jan 20, 2018 • edited Loading

rosskevin commented Jan 20, 2018

lifeiscontent commented Jan 20, 2018 • edited Loading

rosskevin commented Jan 20, 2018

kandros commented Jan 25, 2018 • edited Loading

excitement-engineer commented Jan 25, 2018

lifeiscontent commented Jan 26, 2018

kandros commented Jan 27, 2018

kandros commented Jan 27, 2018

excitement-engineer commented Jan 27, 2018

kandros commented Jan 27, 2018

kandros commented Jan 27, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomasdashney commented Feb 7, 2018 • edited Loading

jbaxleyiii commented Feb 9, 2018

JonathanZWhite commented Feb 13, 2018

trulysinclair commented Feb 14, 2018

excitement-engineer commented Feb 14, 2018

JonathanZWhite commented Feb 14, 2018

excitement-engineer commented Feb 14, 2018 • edited Loading

jbaxleyiii commented Feb 16, 2018

JonathanZWhite commented Feb 16, 2018

lifeiscontent commented Jan 20, 2018 •

edited

Loading

lifeiscontent commented Jan 20, 2018 •

edited

Loading

kandros commented Jan 25, 2018 •

edited

Loading

thomasdashney commented Feb 7, 2018 •

edited

Loading

excitement-engineer commented Feb 14, 2018 •

edited

Loading