flatMorph in a type

I'm trying to use flatMorph to generate dynamic template literal keys for a type but it's becoming unknown.

const test = flatMorph(
  Array.from({ length: 15 }, (_, i) => i + 1),
  (i, v) => [`test_${i}` as const, 'string'],
);
const a = type(test)

const test = flatMorph(
  Array.from({ length: 15 }, (_, i) => i + 1),
  (i, v) => [`test_${i}` as const, 'string'],
);
const a = type(test)

The types are:

const test: {
    [x: `test_${number}`]: string;
}

const a: Type<unknown, {}>

const test: {
    [x: `test_${number}`]: string;
}

const a: Type<unknown, {}>

Why is a not preserving the type?

8 Replies

TizzySaurus•2mo ago

Surely the 'string' has to be const too? Have you tried that? I also seem to remember template literals not being supported, although not certain of that What type were you expecting?

outsideurimaginationOP•2mo ago

Thanks but that doesn't change anything. I want to have keys of an object match the template literal and be able to assert their values' types

ssalbdivad•2mo ago

type is not meant to parse non-literal definitions, e.g. in this case having an object with test_${number} as an index signature. It's not really clear how this should even be inferred as a Type since it's not the same as if you had an index signature with a regex like /test_d+/ (which you'd have to cast but at least it would tell you exactly what data would be valid). It works if you specify the input array in a way TS can infer:

const test = flatMorph(
    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14],
    (i, v) => [`test_${i}`, "string"] as const
)

const aa = type(test)

const test = flatMorph(
    [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14],
    (i, v) => [`test_${i}`, "string"] as const
)

const aa = type(test)

outsideurimaginationOP•2mo ago

Lovely! Makes sense! Can't have an unbounded range (ie, template string literal) of indexes. But then I'm not sure how regex would work, still have to learn more.

ssalbdivad•2mo ago

It can with the regex literal approach, but you wouldn't be inferring it from an array at that point since it would need to be infinite Something like this:

const ttt = type({
    // don't allow non-matching keys
    "+": "reject",
    // d+ can be changed to whatever matcher for numbers you want to allow
    "[/^test_d+$/]": "string"
}).as<{ [k: `test_${number}`]: string }>()

const ttt = type({
    // don't allow non-matching keys
    "+": "reject",
    // d+ can be changed to whatever matcher for numbers you want to allow
    "[/^test_d+$/]": "string"
}).as<{ [k: `test_${number}`]: string }>()

outsideurimaginationOP•2mo ago

wow! 🤯 I'm wondering how this would be compatible with when you have a lot of other properties in the same object you want to validate. Since the "+": "reject" one would invalidate all others if you merge this type with another object type, and the cast erases all the other keys unless you explicitly mention each of them again in the cast generic, doesn't seem practical. Actually now I'm thinking you define the other one first, and then you can union the types in the generic of this one:

const b = type({b: "string"})
const a = type({"+": "reject", "[/^test_d+$/]": "string", ...b}).as<{ [k: `test_${number}`]: string } | typeof b['infer']>()

const b = type({b: "string"})
const a = type({"+": "reject", "[/^test_d+$/]": "string", ...b}).as<{ [k: `test_${number}`]: string } | typeof b['infer']>()

ssalbdivad•2mo ago

.merge does a property-wise merge that inherits the undeclared behavior of the merged type:

const ttt = type({
    // d+ can be changed to whatever matcher for numbers you want to allow
    "[/^test_d+$/]": "string"
})
    .as<{ [k: `test_${number}`]: string }>()
    .merge({
        // don't allow non-matching keys
        "+": "reject",
        b: "string"
    })

const ttt = type({
    // d+ can be changed to whatever matcher for numbers you want to allow
    "[/^test_d+$/]": "string"
})
    .as<{ [k: `test_${number}`]: string }>()
    .merge({
        // don't allow non-matching keys
        "+": "reject",
        b: "string"
    })

So just make sure whatever you merge last is where you specify reject (or in both places)

ssalbdivad•2mo ago

You're right that an intersection would fail because that would require both types be satisfied which is impossible if they have mutually exclusive props Merge is usually better for combining objects anyways

Gaming

Programming

flatMorph in a type

Did you find this page helpful?