-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
payloadCreator arg argument => asyncThunk arg type #502
Conversation
380dc1d
to
47eac02
Compare
Deploy preview for redux-starter-kit-docs ready! Built with commit 380dc1d https://deploy-preview-502--redux-starter-kit-docs.netlify.com |
Deploy preview for redux-starter-kit-docs ready! Built with commit 267274b https://deploy-preview-502--redux-starter-kit-docs.netlify.app |
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 380dc1d:
|
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 267274b:
|
@phryneas This looks pretty good! Would it be a bad idea to change type ActionCreator = IsAny<
ThunkArg,
(arg: ThunkArg) => AsyncActionThunkAction,
unknown extends ThunkArg
? (arg: ThunkArg) => AsyncActionThunkAction
: [ThunkArg] extends [void] | [undefined]
? () => AsyncActionThunkAction
: [undefined] extends [ThunkArg] | []
? (arg: ThunkArg) => AsyncActionThunkAction
: (arg?: ThunkArg) => AsyncActionThunkAction
> I'm also not sure at all about how this would impact the issue you referenced with extending the types for My 🧠 has trouble processing those type tests this late at night, so I made a gist of the common typing patterns to check against as well. (I just dropped this in a If you look at the last sample in that gist, I did Thanks again for putting this up, and sorry in advance if this isn't helpful! |
That would not prevent the issue, but introduce two new ones:
Essentially, the question is if we handle optional arguments or just replace the last three lines with Something like Gotta run to work now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this solves the simpler form of my problem. didn't see any test cases for when the thunkApi is pulled in though. is that case all good also?
would there be another way to handle figuring out types for some of these edge cases looks like a pain 😂 |
@phryneas Gotcha. In that case, the only issue I see with the current types is this: const usingInline = createAsyncThunk(
'test/usingInline',
(arg: string, { getState }) => {
const { test } = getState() as RootState
return {
banana: 'test'
}
}
)
usingInline() // i would expect an error being that we say `arg: string`, but this doesn't get caught as the resulting type is `arg?: string` If there is a way to get const usingInline = createAsyncThunk(
'test/usingInline',
(arg?: string, { getState }) => { // results in - A required parameter cannot follow an optional parameter.
const { test } = getState() as RootState
return {
banana: 'test'
}
}
) // you can't do `string?` here as the `arg` param, so how would a user accomplish this?
const usingInline = createAsyncThunk<{ banana: string }, string, { state: RootState }>(
'test/usingInline',
(arg, { getState }) => {
const { test } = getState()
return {
banana: 'test'
}
}
) My only other input is that I don't think |
I've added lots of tests for usage with a seconds argument. Optional arguments there can now be typed The "optional" or Have I missed any weird case? |
c2e8ee3
to
d9fdd70
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you left off thunkApi on your last few tests for that case.
Thanks... guess I was tired. Added those, I hope that were all. |
thanks @phryneas I think this is the best experience I have had with getting something updated in a project. lgtm |
@stephen-dahl I still have to extract some helper types to make #486 less painful, but now with the tests in place & thus the behaviour reviewed from you it's gonna be pretty straightforward - I'll try to finish this up today or tomorrow :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed all common typing use cases work as expected per https://gist.github.com/msutkowski/81a69be15e96028c848bf3764334a323
@phryneas Once #486 is addressed, I'll open a PR for the docs with common typing recipes, and include an example of typing a generic helper per that thread. |
Okay, I've just extracted these types out and exported one of them, When the tests are finished running, I believe this is ready to merge from my side. @markerikson what do you think? |
abort(reason?: string): void | ||
} | ||
|
||
type AsyncThunkActionCreator< |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I sure hope you know what you're doing here, because my eyes are glazing over
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added more tests than I added code, guess we'll be fine :)
9209999
to
267274b
Compare
Rebased on master after merging #512 . |
This would address #489 without changing any external signatures to this point. So @stephen-dahl and @msutkowski please take a look.
The complete behavioral change should be covered by this test:
https://github.com/phryneas/redux-toolkit/blob/47eac023cd18e86cf888224381a77b9776a97677/type-tests/files/createAsyncThunk.typetest.ts#L185-L230
My only concern is the handling of optional parameters. For people with
strictNullChecks: false
in theirtsconfig.json
, this would make the parameter optional for all their asyncThunks - which is only consequent, but may be undesirable.I've gotta take a second look if this can be done better - on the other hand, we have the same behavior with
createSlice
actions already, so I would not try too much there.Also, this might make extending createAsyncThunk with Typescript (#486) a little more difficult (we'd have to do some things for that anyways, but it might be simpler before this change), so I've got to evaluate that before we merge it.
But please already take a look.