Add full types to useMutation's returned callback #1014

Shrugsy · 2021-04-24T07:12:06Z

useMutation returns a 'trigger function' as it's first item in the return tuple.
This PR changes the signature of the value returned by that 'trigger function' to include all properties it actually has, including that it returns a Promise, not a plain object.

e.g.

Before - only `unwrap`

After - all properties

codesandbox-ci · 2021-04-24T07:22:39Z

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit dc9fc32:

Sandbox	Source
Vanilla	Configuration
Vanilla Typescript	Configuration
rsk-github-issues-example	Configuration

phryneas · 2021-04-24T07:45:15Z

query-old/docs/api/created-api/hooks.md

-  },
-  MutationSubState<D> & RequestStatusFlags
-];
+type UseMutation<Definition> = () => [UseMutationTrigger<Definition>, UseMutationResult<Definition>];


I don't know the best way to write this, but like this it is omitting selectFromResult

I've added in a pseudo-type for UseMutationStateOptions, but it's definitely getting very crowded. What are your thoughts on removing the Definition pseudo-generic from this section completely? My thoughts are that it's already an inaccurate generic compared to the real types, and it probably clutters the explanation more than it clarifies anything.

query-old/docs/api/created-api/hooks.md

phryneas · 2021-04-24T07:47:54Z

query-old/docs/api/created-api/hooks.md

+
+type UseMutationTrigger<Definition> = (
+  arg: ArgTypeFrom<Definition>
+) => Promise<{ data: ResultTypeFrom<Definition> }> & {


Suggested change

) => Promise<{ data: ResultTypeFrom<Definition> }> & {

) => Promise<{ data: ResultTypeFrom<Definition> | { error: unknown } }> & {

could be a bit more accurate thatn unknown, but definitely mention the error here

Done, went with this option:

) => Promise<{ data: ResultTypeFrom<Definition> } | { error: BaseQueryError | SerializedError }> & {

phryneas · 2021-04-24T07:49:08Z

query-old/docs/api/created-api/hooks.md

+  arg: {
+    endpointName: string; // The name of the given endpoint for the mutation
+    originalArgs: ArgTypeFrom<Definition>; // Arguments passed to the mutation
+    track?: boolean; // Whether the mutation is being tracked in the store
+    startedTimeStamp: number; // Timestamp for when the mutation was initiated
+  };


This is kinda "implementation detail". Could we mark that as @internal in the docblock and omit it here instead?

Yep sounds good to me

phryneas · 2021-04-24T07:52:12Z

src/query/core/buildInitiate.ts

+   * A method to cancel the mutation promise. Note that this is not intended to prevent the mutation
+   * that was fired off from reaching the server, but only to assist in handling the response.
+   *
+   * Calling `abort()` prior to the promise resolving will make it throw with an error like:


I actually have no idea what that would do, have you tested that? I assume it would resolve with { error: { name: 'AbortError', message: 'Aborted' } unless you unwrapped it.

Ah yeah my wording is definitely off. When I wrote it, in my head I was specifically thinking of the unwrapped promise, but that's not what I actually wrote.

I'll re-word it to make sense

Re-worded to refer to 'error state' rather than saying it will 'throw'

Also fwiw, it behaves exactly like you thought for the 'wrapped' promise

src/query/core/buildInitiate.ts

Co-authored-by: Lenz Weber <mail@lenzw.de>

Shrugsy · 2021-04-24T10:24:02Z

src/query/core/buildInitiate.ts

 > = Promise<
-  ReturnType<
-    BaseQueryResult<
-      D extends MutationDefinition<any, infer BaseQuery, any, any>
-        ? BaseQuery
-        : never
-    >
-  >
+  | { data: ResultTypeFrom<D> }
+  | {
+      error:
+        | BaseQueryError<
+            D extends MutationDefinition<any, infer BaseQuery, any, any>
+              ? BaseQuery
+              : never
+          >
+        | SerializedError
+    }
 > & {


@phryneas I've tried fixing the type for the resolved value of the 'trigger' promise here, but the actual error type produced has an additional undefined type attached to it.

Can you make any sense out of that?

I've temporarily suppressed the error in order to allow codesandbox to build, in order to see how it behaved there:
https://codesandbox.io/s/vanilla-typescript-forked-duy39?file=/src/index.ts

Ah it's just occurred to me; would that be caused by the scenario where the extends MutationDefinition ternary fails?

| BaseQueryError< D extends MutationDefinition<any, infer BaseQuery, any, any> ? BaseQuery : never >

I'm particularly stumped because it looks like BaseQueryError is explicitly intended to remove the case with { error: undefined }

export type BaseQueryError<BaseQuery extends BaseQueryFn> = Exclude< UnwrapPromise<ReturnType<BaseQuery>>, { error: undefined } >['error']

I pushed a new version which explicitly removes undefined from the type returned by BaseQueryError like so:

Promise< | { data: ResultTypeFrom<D> } | { error: | Exclude< BaseQueryError< D extends MutationDefinition<any, infer BaseQuery, any, any> ? BaseQuery : never >, undefined > | SerializedError } >

But I'm iffy about two things:

Is undefined actually supposed to be there for some reason?

If not, and I remove it doing the above, and someone defines their error type like: { error: undefined }, then the promise type will be wrong (Because it will remove undefined from the union, leaving only SerializedError)

…solve value

- Fix promise result in pseudo-types on docs - Fix wording for 'abort' method docblock

Shrugsy · 2021-04-24T12:23:25Z

src/query/tests/queryFn.test.tsx

@@ -247,7 +247,7 @@ describe('queryFn base implementation tests', () => {
    {
      const thunk = mutationWithNeither.initiate('mutationWithNeither')
      const result = await store.dispatch(thunk)
-      expect(result.error).toEqual(
+      expect((result as any).error).toEqual(


FYI this change is because result previously got inferred as any, but is now more accurately:

{ data: string; } | { error: string | SerializedError }

If anyone has a better idea for handling this than any-casting I'm all ears

Decided on a better option than as any:

expect('error' in result && result.error).toEqual(

markerikson

LGTM, but would like a 👍 from @phryneas or @msutkowski to confirm

msutkowski · 2021-04-24T17:18:23Z

query-old/docs/api/created-api/hooks.md


 - **Returns**: a tuple containing:
-  - `trigger`: a function that triggers an update to the data based on the provided argument
+  - `trigger`: a function that triggers an update to the data based on the provided argument. The trigger function returns a promise with the properties shown above that may be used to handle the behaviour of the promise.


Your non-American behavior here is silly! 🤣

msutkowski · 2021-04-24T17:21:49Z

src/query/tests/buildHooks.test.tsx

+      fireEvent.click(
+        screen.getByRole('button', { name: 'Update User and abort' })
+      )
+      await screen.findByText('An error has occurred updating user Banana')


Appreciate you keeping the 🍌 s around 💯

phryneas · 2021-04-24T17:51:58Z

query-old/docs/api/created-api/hooks.md

+
+The generated `UseMutation` hook will cause a component to re-render by default after the trigger callback is fired as it affects the properties of the result. If you want to call the trigger but don't care about subscribing to the result with the hook, you can use the `selectFromResult` option to limit the properties that the hook cares about.
+
+Passing a completely empty object will prevent the hook from causing a re-render at all, e.g.


Even giving selectFromResult, starting a mutation will trigger at least one re-render.

Add full types to useMutation's returned callback

a42105b

phryneas requested changes Apr 24, 2021

View reviewed changes

Shrugsy and others added 5 commits April 24, 2021 18:36

Apply suggestions from code review

36ecc80

Co-authored-by: Lenz Weber <mail@lenzw.de>

Tweak promise result type for useMutation trigger

2bb34a9

temporarily suppress ts error

3b56f57

Fix test failure

b377eb3

Actually fix test failure

1a44f22

Shrugsy marked this pull request as draft April 24, 2021 10:14

Shrugsy changed the title ~~Add full types to useMutation's returned callback~~ [DRAFT] - Add full types to useMutation's returned callback Apr 24, 2021

Shrugsy commented Apr 24, 2021

View reviewed changes

Shrugsy added 4 commits April 24, 2021 20:54

Exclude BaseQueryError from being undefined in useMutation trigger re…

d7e83f0

…solve value

Misc changes to useMutation types/docblocks:

07a430b

- Fix promise result in pseudo-types on docs - Fix wording for 'abort' method docblock

Add missing UseMutationStateOptions to UseMutation pseudo type

b47b6fc

Remove arg from the UseMutationTrigger docs signature

66dd9bb

Shrugsy commented Apr 24, 2021

View reviewed changes

Shrugsy changed the title ~~[DRAFT] - Add full types to useMutation's returned callback~~ Add full types to useMutation's returned callback Apr 24, 2021

Shrugsy marked this pull request as ready for review April 24, 2021 12:26

Remove as any cast in altered test

dc9fc32

markerikson approved these changes Apr 24, 2021

View reviewed changes

msutkowski approved these changes Apr 24, 2021

View reviewed changes

markerikson merged commit b74a529 into reduxjs:feature/v1.6-integration Apr 24, 2021

phryneas reviewed Apr 24, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add full types to useMutation's returned callback #1014

Add full types to useMutation's returned callback #1014

Shrugsy commented Apr 24, 2021 •

edited

Loading

codesandbox-ci bot commented Apr 24, 2021 •

edited

Loading

phryneas Apr 24, 2021

Shrugsy Apr 24, 2021

phryneas Apr 24, 2021

Shrugsy Apr 24, 2021

phryneas Apr 24, 2021

Shrugsy Apr 24, 2021

phryneas Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021 •

edited

Loading

Shrugsy Apr 24, 2021

Shrugsy Apr 24, 2021

markerikson left a comment

msutkowski Apr 24, 2021

msutkowski Apr 24, 2021

phryneas Apr 24, 2021 •

edited

Loading

	) => Promise<{ data: ResultTypeFrom<Definition> }> & {
	) => Promise<{ data: ResultTypeFrom<Definition> \| { error: unknown } }> & {


		The generated `UseMutation` hook will cause a component to re-render by default after the trigger callback is fired as it affects the properties of the result. If you want to call the trigger but don't care about subscribing to the result with the hook, you can use the `selectFromResult` option to limit the properties that the hook cares about.

		Passing a completely empty object will prevent the hook from causing a re-render at all, e.g.

Add full types to useMutation's returned callback #1014

Add full types to useMutation's returned callback #1014

Conversation

Shrugsy commented Apr 24, 2021 • edited Loading

Before - only unwrap

After - all properties

codesandbox-ci bot commented Apr 24, 2021 • edited Loading

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Shrugsy Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

markerikson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

phryneas Apr 24, 2021 • edited Loading

Choose a reason for hiding this comment

Shrugsy commented Apr 24, 2021 •

edited

Loading

Before - only `unwrap`

codesandbox-ci bot commented Apr 24, 2021 •

edited

Loading

Shrugsy Apr 24, 2021 •

edited

Loading

phryneas Apr 24, 2021 •

edited

Loading