To ensure that the path and format properties of ColumnType<T> are linked, you cannot achieve it when ColumnType<T> is a standalone interface. In your current definition:
export interface ColumnType<T> {
path: Paths<T>,
format?: (value: Magic<T>) => string,
}
The type Paths<T> represents a union of all possible paths from T, and regardless of what Magic<T> is, there's no way for it to be related to segments of Paths<T>.
What you really need is for ColumnType<T> itself to be a combination of path/format pairs, each corresponding to a path in Paths<T>. This implies discarding separate types like Paths<T> and Magic<T>, and instead trying to integrate them.
Here's one potential solution:
// Join<K, P> adds key K to path P with a dot
// (unless either K or P are empty)
type Join<K, P> = K extends string | number
? P extends string | number
? `${K}${'' extends P ? '' : '.'}${P}`
: never
: never;
// PathFormat<P, V> denotes the path/format pair for path P and value V
type PathFormat<P, V> = { path: P, format?: (value: V) => string }
// PrependToPathFormat<K, PF> takes a key K and an existing
// PathFormat PF and generates a new PathFormat where key K
// is added to the path.
type PrependToPathFormat<K, PF> =
PF extends PathFormat<infer P, infer V> ? PathFormat<Join<K, P>, V> : never
// ColumnType<T> contains the union of PathFormat<K, T[K]> for
// every key K in keyof T and, recursively, the result of adding K
// to the PathFormat union obtained from ColumnType<T[K]>
type ColumnType<T> = T extends object ? { [K in keyof T]-?:
PathFormat<K, T[K]> | (PrependToPathFormat<K, ColumnType<T[K]>>)
}[keyof T] : never
The concept behind this approach is that ColumnType<T> will encompass PathFormat<K, T[K]> for each key K and value T[K] in T, along with a modified version of ColumnType<T[K]>.
Let's illustrate with an example:
interface SimpleObject { c: number, d: boolean }
type ColumnTypeSimple = ColumnType<SimpleObject>;
// type ColumnTypeSimple =
// PathFormat<"c", number> |
// PathFormat<"d", boolean>
interface NestedObject { a: string, b: SimpleObject }
type ColumnTypeNested = ColumnType<NestedObject>;
// type ColumnTypeNested =
// PathFormat<"a", string> |
// PathFormat<"b", SimpleObject> |
// PathFormat<"b.c", number> |
// PathFormat<"b.d", boolean>
As seen above, ColumnType<SimpleObject> combines PathFormat types for the c and d properties of SimpleObject. Furthermore, ColumnType<NestedObject> integrates PathFormat types for the a and b properties of NestedObject, along with ColumnType<SimpleObject> adjusted so that the paths "c" and "d" become "b.c" and "b.d" respectively.
Now let's evaluate your itemsColums code, which operates correctly:
const itemsColumns: ColumnsType<Item> = [
{
path: 'field1',
},
{
path: 'field2',
format: ({ field21, field22 }) => field21 > 0 ? field22.field221 : field22.field221
},
{
path: 'field2.field22',
format: ({ field221, field222 }) => `${field221} - ${field222}`,
},
]; // okay
We will also detect errors where the path or format are incorrect or do not align properly:
const badItemsColumns: ColumnsType<Item> = [
{ path: "field3" }, // error!
//~~~~ <--
//Type '"field3"' is not assignable to type
//'"field1" | ... | "field2.field22.field222"'.
{ path: "field2.field21", format: (({ field222 }) => "") }, // error!
// ---------------------------------> ~~~~~~~~
// Property 'field222' does not exist on type 'Number'.
];
PLEASE NOTE that such recursive mapped types may exhibit unusual edge cases, so extensive testing is recommended to ensure coverage of various scenarios. Depending on the specific type T passed into ColumnType<T>, unexpected outputs, recursion limits, or performance issues with the compiler might arise. There are strategies to address these concerns, but addressing them comprehensively beforehand exceeds the scope of a single Stack Overflow inquiry.
Link to Playground for Code Testing