Closed flq closed 6 years ago
Hello, Thanks for suggestion but you can easily read in motivation that this solution is about to be free from explicit type annotations. And moreover there is already at least one solution that I saw with same exact API that you propose.
Also there are more limitations to your proposal that are impossible to work around that I'm concerned about, for instance one of them is optional parameters. As an experiment please try to implement below example with your proposal and check if you can achieve the same resulting type as in the example :
const notify3 = createAction('NOTIFY',
(username: string, message?: string) => ({
type: 'NOTIFY',
payload: { message: `${username}: ${message || ''}` },
meta: { username, message },
}),
)
// resulting type:
// const notify3: (username: string, message?: string | undefined) => {
// type: "NOTIFY";
// payload: { message: string; };
// meta: { username: string; message: string | undefined; };
// }
// you can call it without a second param!
notify3('Piotr')
You're probably right that it makes more sense to keep those functions inside your domain, where you may have certain opinions about actions with a similar structure.
@flq as to the boilerplate what I think should be possible is to remove the first typeString argument, so that then it become a simple decorator function and will be used like this:
const notify3 = createAction((username: string, message?: string) => ({
type: 'NOTIFY',
payload: { message: `${username}: ${message || ''}` },
meta: { username, message },
}))
But probably in the next major release as the last time I tested there was some issue with type inference.
I was playing a bit with providing additional createAction methods which have a very specific shape and came up with the following for e.g. actions with a payload:
which you could call like this:
You can push this even further:
And you call it like this:
What do you think?