Typescript: Generic Type Guard for Interface Detection at Runtime

Question

Complete Re-Edit

I have a variety of classes, using a common base class and implementing common interfaces, that are instantiated at run-time based on config files. Because they are dynamically created, by default there is no intellisense/auto-complete unless I use a type guard. Right now I am tagging the classes using a _interfaces prop. As a contrived example...

abstract class BaseClass {
    _interfaces: any[] = []
}

interface A {
    propA: string
    funcA: (arg1: number) => void
}

interface B {
    propB: string
    funcB: (arg1: string) => void
}

class ExampleClass extends BaseClass implements A, B {
    propA = 'someValue'
    funcA(arg1: number){
        console.log('do a thing')
    }
    propB = 'anotherValue'
    funcB(arg1: string){
        console.log('do another thing')
    }
    _interfaces = ['A', 'B']
}

let myExampleClass = new ExampleClass() //this part is done dynamically at runtime

The runtime check in the type guard is simple, but actually typing the check for intellisense/auto-complete purposes is proving to be tricky.

I have a complicated version of this that works, but I am not fond of it. Currently am using a "type of types" and a few overly complicated types from here and here. There is a playground link here, but it is not for the faint of heart

I could have upwards of 10 interfaces or more applied to some classes so checking for specific properties isn't really scalable here.

Is there a simpler, more generic way, to get run-time detection of interfaces and get intellisense/auto-complete from a type guard?

Updated

Made a simpler version based on @jcalz comments and other posts using his Intersectprops. Playground link here. I still don't quite follow how the Intersectprops type works though.

The code here is pretty complicated/confusing if the question is about how to write a curried type guard function. Using `K` for a non-keylike type parameter (i.e., `K extends Pick`) is unconventional and distracting. Could you try to pare this down to a [mre] with less stuff going on? — jcalz, Jul 23 '22 at 19:29
Like, what is `prop` doing? It doesn't seem to be used anywhere. And in `isUsingInterfaces` there's no inference site for `K`. What is `K` doing at all? Is it just falling back to the constraint? I'm more than happy to help here but the more I look at this the less I understand what you're doing — jcalz, Jul 23 '22 at 19:30
@jcalz prop will be for testing whether the type guard evaluates to true or not, I am more concerned right now with getting TS to understand what type the input is IF it evaluates to true hence why I omitted showing the test itself — pure_bordem, Jul 23 '22 at 19:35
Edited to try and make it more clear, part of the problem is this I do not think I can get this more minimal. Since the complicated helper types are needed. Let me know if its still confusing. — pure_bordem, Jul 23 '22 at 19:42
If you're not using `prop` in the question, then having it in the question is distracting. Please make your code a [mre] that doesn't include any code that isn't being used. I feel like the answer to your original issue is something like [this](https://tsplay.dev/wgZ5MW), but it doesn't use your particular helper types. Does that work for you? If so I can write up an answer for that. If not, then... please explain what you're trying to do. — jcalz, Jul 23 '22 at 19:43
"I do not think I can get this more minimal"... I think that's because this might be an XY problem. You have an actual goal, got partway to that goal using a collection of too-complex typings, and then got stuck. Maybe you could [edit] the question to ask only about the goal without the potential distractions of partial solutions. — jcalz, Jul 23 '22 at 19:47
That intersectprops example seems to be exactly what I was looking for, will poke around and get back — pure_bordem, Jul 23 '22 at 19:53
Completely re-wrote question, and yes, I think the intersectprops approach works wonders! I literally have been googling for over a week and never tripped across that (probably because I didn't know to look up intersectprops) — pure_bordem, Jul 23 '22 at 20:53
Well I'd like to write up my answer but now I'm not exactly seeing how it connects to your question I'd have expected something like: "let's say I have a type-name-to-type mapping like `interface Mapping { a: {x: string}, b: {y: number}, c: {z: Date} }`. How can I give types to a type guard function that ideally behaves like `if (guard(obj, ["a", "c"])) { obj.x.toUpperCase(), obj.z.getFullYear() }`, and barring that, using currying like `const mappingGuard = guard()` and then `if (mappingGuard(obj, ["a", "c"])) {...}`?" — jcalz, Jul 23 '22 at 21:14
The most ideal pipe dream case would look something the effect of `if (guard(obj))` but I don't see how that would be possible. I am trying to keep the guard as DRY as possible for the end-user so they don't need to re-write the interface types multiple times every time they use the guard. And again, it needs to actually runtime check since as well. — pure_bordem, Jul 24 '22 at 00:19
Well you can't generate magic run-time type guards from TS types which are erased. `if (guard(obj))` becomes `if (guard(obj))` at runtime. If you want something that *kind* of works like this you need a different approach, possibly [this one](https://stackoverflow.com/a/59483318/2887218). Is this a duplicate of that question? I thought this was mostly a type manipulation question: "how do you convert `{a: A, b: B, c: C}` and `"a" | "b"` into `A & B`?"... if this is right I'd be happy to show how `IntersectProps` works and the curried function. If not, then I'm more lost than ever. — jcalz, Jul 24 '22 at 01:11
Yah I understand the TS being erased and why the "ideal" wouldn't actually work. I did see the other answer sometime ago and I am not keen on completely re-writing everything using custom types like `gNumber`, `gString`, since I can just tag the class and check the tag for which interfaces are implemented. Also not keen on using transformers. I left an edit in the post showing how I used your `Intersectprops` — pure_bordem, Jul 24 '22 at 15:15
I can’t figure out how you want me to answer the question so I think I have to disengage, unfortunately. — jcalz, Jul 24 '22 at 15:19
I don't think the term "Runtime Guards" is correct, especially the word "Runtime". There are no TypeScript types/type information that persist after transpilation to JavaScript, they are completely erased. Therefore, there are definitely no Runtime type checks related to TypeScript. Intellisense and autocomplete is a design-time matter, a matter of static analysis. — Lzh, Jul 24 '22 at 15:37
You say "The runtime check in the type guard is simple, but actually typing the check for intellisense/auto-complete purposes is proving to be tricky." which leading me to think that title "[...] Interface Detection at Runtime" is a typo — Lzh, Jul 24 '22 at 15:39
At this point, I am open to suggestions because I can't seem to format these questions in any such way that the good people here at SO can understand. The playground link at the bottom of the post does exactly what I need it to do, thanks to @jcalz — pure_bordem, Jul 24 '22 at 15:47
Ok, I'm reading through the code samples and I'm starting to understand that this is like a function to automatically trigger narrowing (instead of using many discriminators and `if` statements). Interesting +1 — Lzh, Jul 24 '22 at 15:48
I think that is a correct statement? I don't want to have long winded checks and `if` statements just to say "this thing is using these interfaces" — pure_bordem, Jul 24 '22 at 15:53

Typescript: Generic Type Guard for Interface Detection at Runtime

0 Answers0