Looks good. Please fix linter error and I'll merge it.

Thanks!

I could use this in my application as well. Are there any scheduled plans for an update to npm so we can use this? It seems really useful.

Just to be sure; this let us skip theparams for async action creators? So now I can just do

typeIPost={title:string};typeErrorMessage=string;constfetchPosts=actionCreator.async<IPost[],ErrorMessage>('FETCH_POSTS');fetchPosts.started();fetchPosts.done([{title:'Hello'},{title:'World'}]);fetchPosts.failed('Could not retrieve posts!');

Would it also make this possible?

typePostId=number;typeIPost={title:string};typeErrorMessage=string;constfetchPosts=actionCreator.async<PostId,IPost[],ErrorMessage>('FETCH_POSTS');fetchPost.started(23);fetchPost.done([{title:'Hello'},{title:'World'}]);fetchPost.failed('Could not retrieve posts!');

I have a hard time seeing where you would use the sameparams forstarted,done andfailed. This might not be the right place to ask but in which cases would you use the sameparams for all three? Thecurrent example is not very clear to me. Why do we pass{foo: 'lol'} for each action? I kind of getstarted (but with this I guess that would be optional) but how aboutdone andfailed?

Thanks for helping me type checking my actions more easily with this library!

I'll make a release to NPM in a few moments.

Async action creators are intended to wrap some async process, like a promise. Theparams is the arguments of your process. Having the sameparams object indone andfailed actions is useful to correlate response with the request. Imagine you had multiple simultaneous instances of the process running with different arguments. It is also handy for optimistic updates.

This PR makes it possible forparams-less async action creators to be called with noparams:

constemptyAsync=actionCreator.async<undefined,{foo:string},{bar:string}>('EMPTY_ASYNC');conststarted=emptyAsync.started();constdone=emptyAsync.done({result:{foo:'foo'}});constfailed=emptyAsync.failed({error:{bar:'bar'}});

Without this PR you'd had to write

conststarted=emptyAsync.started(undefined);constdone=emptyAsync.done({params:undefined,result:{foo:'foo'}});constfailed=emptyAsync.failed({params:undefined,error:{bar:'bar'}});

Released as2.1.0. Sorry that it took so long.

Perfect, thank you so much! I initially read moment as months and got worried for a second. :-)

I will update my code now to use this async action creator that will cut down some of my boilerplate. I am just curious that if we can skipparams with this then is it not possible to get rid ofresult too or would that cause too much ambiguity with objects?

I don't know if it possible to express but if the first type isundefined then we can maybe infer there will be noparams and then can skipresult as well?

I guess this won't matter now anyway since it would result in breaking changes and thus require 3.0.0 which is not worth it. I am just curious to learn more really.

Unfortunately, in TS{field: undefined} doesn't mean that the field can be omitted. So to enable omittingparams we had to add two extra interfaces. Adding another signature withoutresult (and also another one without bothparams andresult) would bloat the code too much IMO.

So, for now, the best we can do is{result: undefined} or{result: null}.

Also, in my experience, there aren't many cases for calling async action creators manually. Async processes are usually expressed as functions returning promises (or generators in case ofredux-saga), and I'd rather write a generic wrapper for such functions that binds them with async action creators. You may want to check out the code fortypescript-fsa-redux-saga.

I'm sorry, but I have to revert this. For some reason, after this change, we can't instantiate async action creators with payload, i.e. TypeScript always chooses the first signature of these two:

async<undefined,S,E>(type:string,commonMeta?:Object|null,):EmptyAsyncActionCreators<S,E>;async<P,S,E>(type:string,commonMeta?:Object|null,):AsyncActionCreators<P,S,E>;

even if we call.async<{foo: string}, {bar: string}, {baz: string}>('...').

I couldn't quickly find a way to make it work, so we have to fall back to the old typings.

That is understandable if it breaks code. Would it make sense to just renameasync<undefined, S, E> toemptyAsync<S, E> or something similar?

How about usinggeneric parameter defaults in TypeScript 2.3 or is it still a problem?

@lauritzsh I don't really like adding another method, I prefer to keep API surface as small as possible.

Also if we add another method for emptypayload.params, we'd also want to add another one for emptypayload.result. And probably a third one for both of them being empty. Looks ugly to me :(.

I'm not sure how generic defaults would solve this, but if you find a working solution, please let me know.

Fixed in3.0.0-beta-1.