Dispatchers

[atrauzzi]

Instead of a Dispatchers type/interface, have a constant that is all of the functions combined:

export const Dispatchers = {
    createThing,
    updateThing,
    deleteThing,
};

Then, in the component class declaration, use typeof against the constant in the generic props param!

[atrauzzi]

Best that can be done right now until microsoft/TypeScript#6606 is resolved.

type Dispatchers<T> = {

    [D in keyof T]: (...args: any[]) => any;
};

[KiaraGrouwstra]

Much of 6606 should work now (outside of function return types) -- are you sure you can't typeof that const there now?

[atrauzzi]

@tycho01

Hmm, I just tried that recently and sadly wasn't able to get it. Mostly because the typeof the const doesn't hint the correct return type when calling the redux dispatchers. (TS still thinks they return the factories rather than the functions themselves)

I think no matter what happens, I'll always have to create some kind of wrapper type/interface to represent dispatchers. That's why I hard-code any or Promise<any>. Even though it has the same keys as the const, after the redux connect middleware is done with them, the value is no longer the function, it's the return of the function.

.. Yeah, confusing 😜

Imagining I had a magic wand, I think it'd have to be something like this:

interface Dispatchers<T> {
    [D in keyof T]: (...args: any[]) => typeof T[D]();
}

The subtle bit there is the () at the end. That's not currently valid TypeScript syntax, but kind of implies what we'd need. The redux connect dispatchers list contains a dictionary of functions that return functions. It's not the first-level return we need, but the actual values the nested functions return.

Bleh, complicated :)

Maybe I should open a separate ticket on the TS repo, just to get the use case documented.

[KiaraGrouwstra]

After 6606 you'd just `R.map(f => f(), Dispatchers)`, using Ramda's `map` function and your object of dispatcher functions. Or lodash's mapObj. But yeah, those would be implemented pretty much as you stated anyway, so same thing. Until then, I guess you'd need to manually do it for each entry. Since your functions don't take parameters, you may wanna check @kube's approach as mentioned in 6606. If the dispatchers are supplied by users instead of hard coded into your library (that is, you need proper inference on a map operation on a heterogeneous object), afaik you're just boned without 6606.

[KiaraGrouwstra]

feel free to let them know of your use-case though, as so far they've really underestimated it. I wish they'd better prioritize the whole thing too! I actually came from a similar use case, the redux ripoff in the angular ecosystem, where the API also largely seems to stem from limitations in TS interference. I guess state management libs are one of the primary places where one would wanna operate on known values (dispatcher/reducer functions), which has so far gone neglected in TS for being harder and less common.

[atrauzzi]

@tycho01 - Ticket made and linked to this one. Feel free to comment/vote/clarify :)

[KiaraGrouwstra]

Looks good to me. Just added this use-case to the list in 6606 as well -- no-one had really kept track of its uses anymore.