Home:ALL Converter>Interface type check with Typescript

Interface type check with Typescript

Ask Time:2013-01-20T22:37:38         Author:lhk

Json Formatter

This question is the direct analogon to Class type check with TypeScript

I need to find out at runtime if a variable of type any implements an interface. Here's my code:

interface A{
    member:string;
}

var a:any={member:"foobar"};

if(a instanceof A) alert(a.member);

If you enter this code in the typescript playground, the last line will be marked as an error, "The name A does not exist in the current scope". But that isn't true, the name does exist in the current scope. I can even change the variable declaration to var a:A={member:"foobar"}; without complaints from the editor. After browsing the web and finding the other question on SO I changed the interface to a class but then I can't use object literals to create instances.

I wondered how the type A could vanish like that but a look at the generated javascript explains the problem:

var a = {
    member: "foobar"
};
if(a instanceof A) {
    alert(a.member);
}

There is no representation of A as an interface, therefore no runtime type checks are possible.

I understand that javascript as a dynamic language has no concept of interfaces. Is there any way to type check for interfaces?

The typescript playground's autocompletion reveals that typescript even offers a method implements. How can I use it ?

Author:lhk,eproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article:https://stackoverflow.com/questions/14425568/interface-type-check-with-typescript
pcan :

It's now possible, I just released an enhanced version of the TypeScript compiler that provides full reflection capabilities. You can instantiate classes from their metadata objects, retrieve metadata from class constructors and inspect interface/classes at runtime. You can check it out here\n\nUsage example:\n\nIn one of your typescript files, create an interface and a class that implements it like the following:\n\ninterface MyInterface {\n doSomething(what: string): number;\n}\n\nclass MyClass implements MyInterface {\n counter = 0;\n\n doSomething(what: string): number {\n console.log('Doing ' + what);\n return this.counter++;\n }\n}\n\n\nnow let's print some the list of implemented interfaces.\n\nfor (let classInterface of MyClass.getClass().implements) {\n console.log('Implemented interface: ' + classInterface.name)\n}\n\n\ncompile with reflec-ts and launch it:\n\n$ node main.js\nImplemented interface: MyInterface\nMember name: counter - member kind: number\nMember name: doSomething - member kind: function\n\n\nSee reflection.d.ts for Interface meta-type details.\n\nUPDATE:\nYou can find a full working example here",
2015-11-12T11:50:31
Willem van der Veen :

Type guards in Typescript:\nTS has type guards for this purpose. They define it in the following manner:\n\nSome expression that performs a runtime check that guarantees the type\nin some scope.\n\nThis basically means that the TS compiler can narrow down the type to a more specific type when it has sufficient information. For example:\nfunction foo (arg: number | string) {\n if (typeof arg === 'number') {\n // fine, type number has toFixed method\n arg.toFixed()\n } else {\n // Property 'toFixed' does not exist on type 'string'. Did you mean 'fixed'?\n arg.toFixed()\n // TSC can infer that the type is string because \n // the possibility of type number is eliminated at the if statement\n }\n}\n\nTo come back to your question, we can also apply this concept of type guards to objects in order to determine their type. To define a type guard for objects, we need to define a function whose return type is a type predicate. For example:\ninterface Dog {\n bark: () => void;\n}\n\n// The function isDog is a user defined type guard\n// the return type: 'pet is Dog' is a type predicate, \n// it determines whether the object is a Dog\nfunction isDog(pet: object): pet is Dog {\n return (pet as Dog).bark !== undefined;\n}\n\nconst dog: any = {bark: () => {console.log('woof')}};\n\nif (isDog(dog)) {\n // TS now knows that objects within this if statement are always type Dog\n // This is because the type guard isDog narrowed down the type to Dog\n dog.bark();\n}\n",
2020-10-31T09:56:09
DS. :

Here's another option: the module ts-interface-builder provides a build-time tool that converts a TypeScript interface into a runtime descriptor, and ts-interface-checker can check if an object satisfies it.\n\nFor OP's example,\n\n\ninterface A {\n member: string;\n}\n\n\nYou'd first run ts-interface-builder which produces a new concise file with a descriptor, say, foo-ti.ts, which you can use like this:\n\nimport fooDesc from './foo-ti.ts';\nimport {createCheckers} from \"ts-interface-checker\";\nconst {A} = createCheckers(fooDesc);\n\nA.check({member: \"hello\"}); // OK\nA.check({member: 17}); // Fails with \".member is not a string\" \n\n\nYou can create a one-liner type-guard function:\n\nfunction isA(value: any): value is A { return A.test(value); }\n",
2018-01-26T05:26:07
Daniel Ribeiro :

I would like to point out that TypeScript does not provide a direct mechanism for dynamically testing whether an object implements a particular interface. \n\nInstead, TypeScript code can use the JavaScript technique of checking whether an appropriate set of members are present on the object. For example:\n\nvar obj : any = new Foo();\n\nif (obj.someInterfaceMethod) {\n ...\n}\n",
2015-03-11T19:18:38
Dan Dohotaru :

same as above where user-defined guards were used but this time with an arrow function predicate\n\ninterface A {\n member:string;\n}\n\nconst check = (p: any): p is A => p.hasOwnProperty('member');\n\nvar foo: any = { member: \"foobar\" };\nif (check(foo))\n alert(foo.member);\n",
2018-02-21T12:07:31
frodeborli :

In my opinion this is the best approach; attach a "Fubber" symbol to the interfaces. It is MUCH faster to write, MUCH faster for the JavaScript engine than a type guard, supports inheritance for interfaces and makes type guards easy to write if you need them.\nThis is the purpose for which ES6 has symbols.\nInterface\n// Notice there is no naming conflict, because interfaces are a *type*\nexport const IAnimal = Symbol("IAnimal"); \nexport interface IAnimal {\n [IAnimal]: boolean; // the fubber\n}\n\nexport const IDog = Symbol("IDog");\nexport interface IDog extends IAnimal {\n [IDog]: boolean;\n}\n\nexport const IHound = Symbol("IDog");\nexport interface IHound extends IDog {\n // The fubber can also be typed as only 'true'; meaning it can't be disabled.\n [IDog]: true;\n [IHound]: boolean;\n}\n\nClass\nimport { IDog, IAnimal } from './interfaces';\nclass Dog implements IDog {\n // Multiple fubbers to handle inheritance:\n [IAnimal] = true;\n [IDog] = true;\n}\n\nclass Hound extends Dog implements IHound {\n [IHound] = true;\n}\n\nTesting\nThis code can be put in a type guard if you want to help the TypeScript compiler.\nimport { IDog, IAnimal } from './interfaces';\n\nlet dog = new Dog();\n\nif (dog instanceof Hound || dog[IHound]) {\n // false\n}\nif (dog[IAnimal]?) {\n // true\n}\n\nlet houndDog = new Hound();\n\nif (houndDog[IDog]) {\n // true\n}\n\nif (dog[IDog]?) {\n // it definitely is a dog\n}\n\n",
2021-04-28T13:41:16
Fenton :

You can achieve what you want without the instanceof keyword as you can write custom type guards now:\ninterface A {\n member: string;\n}\n\nfunction instanceOfA(object: any): object is A {\n return 'member' in object;\n}\n\nvar a: any = {member: "foobar"};\n\nif (instanceOfA(a)) {\n alert(a.member);\n}\n\nLots of Members\nIf you need to check a lot of members to determine whether an object matches your type, you could instead add a discriminator. The below is the most basic example, and requires you to manage your own discriminators... you'd need to get deeper into the patterns to ensure you avoid duplicate discriminators.\ninterface A {\n discriminator: 'I-AM-A';\n member: string;\n}\n\nfunction instanceOfA(object: any): object is A {\n return object.discriminator === 'I-AM-A';\n}\n\nvar a: any = {discriminator: 'I-AM-A', member: "foobar"};\n\nif (instanceOfA(a)) {\n alert(a.member);\n}\n",
2013-01-20T15:57:07
Anthony Gingrich :

Approaching 9 years since OP, and this problem remains. I really REALLY want to love Typescript. And usually I succeed. But its loopholes in type safety is a foul odor that my pinched nose can't block.\nMy goto solutions aren't perfect. But my opinion is they are better than most of the more commonly prescribed solutions. Discriminators have proven to be a bad practice because they limit scalability and defeat the purpose of type safety altogether. My 2 prettiest butt-ugly solutions are, in order:\nClass Decorator:\nRecursively scans the typed object's members and computes a hash based on the symbol names. Associates the hash with the type name in a static KVP property. Include the type name in the hash calculation to mitigate risk of ambiguity with ancestors (happens with empty subclasses).\nPros: It's proven to be the most trustworthy. It is also provides very strict enforcements. This is also similar to how other high-level languages natively implement polymorphism. Howbeit, the solution requires much further extension in order to be truly polymorphic.\nCons: Anonymous/JSON objects have to be rehashed with every type check, since they have no type definitions to associate and statically cache. Excessive stack overhead results in significant performance bottlenecks in high load scenarios. Can be mitigated with IoC containers, but that can also be undesirable overhead for small apps with no other rationale. Also requires extra diligence to apply the decorator to every object requiring it.\nCloning:\nVery ugly, but can be beneficial with thoughtful strategies. Create a new instance of the typed object and reflexively copy the top-level member assignments from the anonymous object. Given a predetermined standard for passage, you can simultaneously check and clone-cast to types. Something akin to "tryParse" from other languages.\nPros: In certain scenarios, resource overhead can be mitigated by immediately using the converted "test" instance. No additional diligence required for decorators. Large amount of flexibility tolerances.\nCons: Memory leaks like a flour sifter. Without a "deep" clone, mutated references can break other components not anticipating the breach of encapsulation. Static caching not applicable, so operations are executed on each and every call--objects with high quantities of top-level members will impact performance. Developers who are new to Typescript will mistake you for a junior due to not understanding why you've written this kind of pattern.\nAll totalled: I don't buy the "JS doesn't support it" excuse for Typescript's nuances in polymorphism. Transpilers are absolutely appropriate for that purpose. To treat the wounds with salt: it comes from Microsoft. They've solved this same problem many years ago with great success: .Net Framework offered a robust Interop API for adopting backwards compatibility with COM and ActiveX. They didn't try to transpile to the older runtimes. That solution would have been much easier and less messy for a loose and interpreted language like JS...yet they cowered out with the fear of losing ground to other supersets. Using the very shortcomings in JS that was meant to be solved by TS, as a malformed basis for redefining static typed Object-Oriented principle is--well--nonsense. It smacks against the volumes of industry-leading documentation and specifications which have informed high-level software development for decades.",
2021-10-31T15:04:48
vilicvane :

In TypeScript 1.6, user-defined type guard will do the job.\n\ninterface Foo {\n fooProperty: string;\n}\n\ninterface Bar {\n barProperty: string;\n}\n\nfunction isFoo(object: any): object is Foo {\n return 'fooProperty' in object;\n}\n\nlet object: Foo | Bar;\n\nif (isFoo(object)) {\n // `object` has type `Foo`.\n object.fooProperty;\n} else {\n // `object` has type `Bar`.\n object.barProperty;\n}\n\n\nAnd just as Joe Yang mentioned: since TypeScript 2.0, you can even take the advantage of tagged union type.\n\ninterface Foo {\n type: 'foo';\n fooProperty: string;\n}\n\ninterface Bar {\n type: 'bar';\n barProperty: number;\n}\n\nlet object: Foo | Bar;\n\n// You will see errors if `strictNullChecks` is enabled.\nif (object.type === 'foo') {\n // object has type `Foo`.\n object.fooProperty;\n} else {\n // object has type `Bar`.\n object.barProperty;\n}\n\n\nAnd it works with switch too.",
2015-11-16T10:35:45
Caleb Macdonald Black :

How about User-Defined Type Guards? https://www.typescriptlang.org/docs/handbook/advanced-types.html\n\ninterface Bird {\n fly();\n layEggs();\n}\n\ninterface Fish {\n swim();\n layEggs();\n}\n\nfunction isFish(pet: Fish | Bird): pet is Fish { //magic happens here\n return (<Fish>pet).swim !== undefined;\n}\n\n// Both calls to 'swim' and 'fly' are now okay.\n\nif (isFish(pet)) {\n pet.swim();\n}\nelse {\n pet.fly();\n}\n",
2016-07-16T00:37:48
Joe Yang :

typescript 2.0 introduce tagged union\n\nTypescript 2.0 features\n\ninterface Square {\n kind: \"square\";\n size: number;\n}\n\ninterface Rectangle {\n kind: \"rectangle\";\n width: number;\n height: number;\n}\n\ninterface Circle {\n kind: \"circle\";\n radius: number;\n}\n\ntype Shape = Square | Rectangle | Circle;\n\nfunction area(s: Shape) {\n // In the following switch statement, the type of s is narrowed in each case clause\n // according to the value of the discriminant property, thus allowing the other properties\n // of that variant to be accessed without a type assertion.\n switch (s.kind) {\n case \"square\": return s.size * s.size;\n case \"rectangle\": return s.width * s.height;\n case \"circle\": return Math.PI * s.radius * s.radius;\n }\n}\n",
2016-07-13T09:51:44
yy