Mapping value to compatible function creates uncallable function union

I have to deal with ingesting one of many possible values, but within those values there is an id which can be used to get the correct change function. With typescript, however this does not work because the union of all functions is not callable.

type Module<T> = {
  change: (value: T) => void
}
enum ModuleID {
  A = "id:A",
  B = "id:B"
}
interface Identifiable<ID extends ModuleID> {
  id: ID
}
// Module A
interface A extends Identifiable<ModuleID.A> {
  item: 'value:A'
}
export const moduleA: Module<A> = {
  change(a: A) {}
}
// Module B
interface B extends Identifiable<ModuleID.B> {
  item: 'value:B'
}
export const moduleB: Module<B> = {
  change(a: B) {}
}
// Map id to module containing the correct `change` function
const moduleMap = {
  [ModuleID.A]: moduleA,
  [ModuleID.B]: moduleB
}
// While conceptually correct, this does not work with typescript
function changeValue(value: A | B) {
  const module = moduleMap[value.id]
  // The intersection 'A & B' was reduced to 'never' because 
  // property 'item' has conflicting types in some constituents.
  module.change(value)
}

How could I restructure this so that I can call the appropriate change method based on the value's id in a type-safe way.

This is an issue I call correlated unions, as described in microsoft/TypeScript#30581. Inside the body of changeValue(), the type of module.change and the type of value are both union types, but the compiler is unable to model the correlation between them. If the compiler could narrow value first to A and then to B, it would be happy:

function changeValue(value: A | B) {
if (value.id === ModuleID.A) {
const module = moduleMap[value.id]
module.change(value) // okay
} else {
const module = moduleMap[value.id]
module.change(value) // okay
}
}

But it can only do so via different control flow, which is not what you want to do, since it's redundant and scales in redundancy with the input union. It can't look at a single line of code and evaluate it for each narrowing at once.

The recommended solution for dealing with correlated unions is described in microsoft/TypeScript#47109, and involves refactoring the types so that you use generics instead of unions, and that the generic operations are written explicitly in terms of mapped types and indexes into such types. The goal is that changeValue() should be generic in some keylike type K, such that value is seen of type F<K> for some F, and module.change is seen of type (value: F<K>) => void for the same F. This will allow the call.

Here's one way to do it. First let's make a type in which we can look up the argument type for change() based on the ModuleID:

type Modules = A | B;
type ChangeArg = { [M in Modules as M['id']]: M }
/* type ChangeArg = {
"id:A": A;
"id:B": B;
} */

Then we will write the type of moduleMap explicitly as a mapped type on this:

const moduleMap: { [K in ModuleID]: Module<ChangeArg[K]> } = {
[ModuleID.A]: moduleA,
[ModuleID.B]: moduleB
}

And finally, we will make changeValue generic in K, the type of the ModuleID involved:

function changeValue<K extends ModuleID>(value: Identifiable<K> & ChangeArg[K]) {
const _value: Identifiable<K> = value;
const module = moduleMap[_value.id]
module.change(value)
}

That needs some explanation; in order for this to work, the compiler needs to understand that value is an Identifable<K> so that value.id is of type K, and also that value is of type ChangeArg[K] so that its seen as a valid input to moduleMap[value.id]. This turns out to be a little tricky, so I help the compiler along by defining value's type as the intersection of those two types (even though ChangeArg[K] is already a subtype of Identifiable<K> for every K), and then widening to Identifiable<K> before getting its id property (so the compiler keeps it generic as K and doesn't widen to something less usable).

You can verify that module.change is now seen as type (value: ChangeArg[K]) => void, which accepts an argument of type Identifiable<K> & ChangeArg[K], and so the body of changeValue() compiles without error.

Let's also make sure that callers still have reasonable behavior:

changeValue({ id: ModuleID.A, item: 'value:A' }); // okay
changeValue({ id: ModuleID.A, item: 'value:B' }); // error
changeValue({ id: ModuleID.B, item: 'value:B' }); // okay
changeValue({ id: ModuleID.B, item: 'value:A' }); // error

Looks good!

Finally, it might not be worth the time/effort/complexity to you to refactor this way. It's perfectly reasonable for you to just leave your code as-is and just use a type assertion to suppress the warning, as long as you're convinced that it's correct:

const module = moduleMap[value.id] // Module<A> | Module<B>
module.change(value as never); // I know this line is fine so leave me alone

Which way you proceed depends on what's more important for your use case: if you want compiler-verified type safety and don't care about complexity then refactoring might be the way to go; if you want compiler-verified type safety but without the complexity, you might want to do the narrowing via redundant control flow. And if you care less about compiler-verified type safety that making forward progress, then an assertion might be your solution. It's up to you.

Playground link to code