带可选索引器的打字稿中返回类型的问题

Question

In the following example I want to type the return type of a function:

type MakeNamespace<T> = T & { [index: string]: T }

export interface INodeGroupProps<T = unknown[], State = {}> {
  data: T[];
  start: (data: T, index: number) =>  MakeNamespace<State>;
}

export interface NodesState {
  top: number;
  left: number;
  opacity: number;
}

export type Point = { x: number, y: number }

const points: Point[] = [{ x: 0, y: 0 }, { x: 1, y: 2 }, { x: 2, y: 3 }]

const Nodes: INodeGroupProps<Point, NodesState> = {
  data: points,
  keyAccessor: d => {
    return d.x
  },
  start: point => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
    }
  }
}

The return type of the start function could be:

    return {
      top: point.y,
      left: point.x,
      opacity: 0
    }

or it could be:

return {
  namespace1: {
    top: point.y,
    left: point.x,
    opacity: 0
  },
  namespace2: {
    top: point.y,
    left: point.x,
    opacity: 0
  }
}

My code will not allow this and typescript complains:

Property 'top' is incompatible with index signature

Changing MakeNamespace to type MakeNamespace<T> = T | { [index: string]: T } type MakeNamespace<T> = T | { [index: string]: T } works but won't cover this case:

const Nodes: INodeGroupProps<Point, NodesState> = {
  data: points,
  start: point => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0
      namespace1: {
        top: point.y,
        left: point.x,
        opacity: 0
      }
    }
  }
}

Where i have a combination of both.

Due to return type widening, I lose type safety on the namespace key because it is going for the T part of the union.

My thoughts would be to make the indexer optional but I am not sure how to do that.

Here is a playground

Answer 1

If you are in control of enough code to change the design to something more TypeScript-friendly, that would be my suggestion. For example, if you place the extra namespaces in a single property with a known name, it will be much simpler to describe the type (note that I'm going to remove code and types that are not relevant to the issue, such as the INodeGroupProps['data'] property):

// add an optional "namespaces" property which is itself a bag of T
type MakeNamespace<T> = T & { namespaces?: { [k: string]: T | undefined } };

export interface INodeGroupProps<T, State> {
  start: (data: T, index: number) => MakeNamespace<State>;
}

export interface NodesState {
  top: number;
  left: number;
  opacity: number;
}

export type Point = { x: number, y: number }

// okay
const Nodes: INodeGroupProps<Point, NodesState> = {
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
    }
  }
};

// also okay
const Nodes2: INodeGroupProps<Point, NodesState> = {
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
      namespaces: {
        namespace1: {
          top: point.y,
          left: point.x,
          opacity: 0,
        }
      }
    }
  }
};

That still has the issue of widening the return type to INodeGroupProps<Point, NodesState> so the compiler will forget, for example, that Nodes2.namespaces.namespace1 exists:

const ret = Nodes2.start({ x: 1, y: 2 }, 0);
const oops = ret.namespaces.namespace1; // error! possibly undefined?
if (ret.namespaces && ret.namespaces.namespace1) {
  const ns = ret.namespaces.namespace1; // okay, ns is NodeState now
} else {
  throw new Error("why does the compiler think this can happen?!")
}

Generally the way around this is to change your possibly-too-wide type annotations to calling a helper function which requires that the value matches the annotation, but does not widen to it. Like:

const ensure = <T>() => <U extends T>(x: U) => x;

const ensureRightNodes = ensure<INodeGroupProps<Point, NodeState>>();


const Nodes = ensureRightNodes({
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
    }
  }
});

const Nodes2 = ensureRightNodes({
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
      namespaces: {
        namespace1: {
          top: point.y,
          left: point.x,
          opacity: 0,
          timing: { duration: 500 }
        }
      }
    }
  }
});

// Now Nodes and Nodes2 are narrowed:

const ret = Nodes2.start({ x: 1, y: 2 }); // Nodes2.start takes ONE param now
const ns = ret.namespaces.namespace1; // okay, ns is NodesState.

There are benefits to both widening and narrowing (widening: Nodes2.start() will accept two parameters as defined in INodeGroupProps ; narrowing: Nodes2.start(p).namespaces.namespace1 is known to exist) so it's a tradeoff and it's up to you to figure out where the right balance is for your needs.

---

Backing up, it's possible you might need to keep the original " T plus all sorts of extra properties" definition, and in that case you can coax and cajole the compiler to accepting it using conditional types , with the same caveats about narrowing as above:

type MakeNamespace<T, K extends keyof any> = T & Record<Exclude<K, keyof T>, T>;

export interface INodeGroupProps<T, State, K extends keyof any> {
  start: (data: T, index: number) => MakeNamespace<State, K>;
}

type ExtraKeysFromINodeGroupProp<T, State, N> =
  N extends INodeGroupProps<any, any, any> ?
  Exclude<keyof ReturnType<N['start']>, keyof State> : never

type InferINodeGroupProp<T, State, N> =
  INodeGroupProps<T, State, ExtraKeysFromINodeGroupProp<T, State, N>>;

const inferNodeGroupPropsFor = <T, State>() =>
  <N>(ingp: N & InferINodeGroupProp<T, State, N>):
    InferINodeGroupProp<T, State, N> => ingp;

const ngpPointNodesState = inferNodeGroupPropsFor<Point, NodesState>();

const Nodes = ngpPointNodesState({
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
    }
  }
});

const Node2 = ngpPointNodesState({
  start: (point: Point) => {
    return {
      top: point.y,
      left: point.x,
      opacity: 0,
      namespace1: {
        top: point.y,
        left: point.x,
        opacity: 0,
      }
    }
  }
});


Node2.start({ x: 1, y: 1 }, 0).namespace1.left; // okay

To get that working you need to make MakeNamespace generic enough to represent which extra keys K you are adding, and then do all kinds of things to verify that a passed-in value matches INodeGroupProps<T, State, K> for some K that you extract from the value's type. It's frankly a mess... so if possible I'd really recommend trying not to go the dynamic-extra-properties route.

---

Okay, hope that helps. Good luck!