React integration

React integration To use JSX with React you should use the React typings. These typings define the JSX namespace appropriately for use with React. /// <reference path="react.d.ts" /> interface Props { foo: string; } class MyComponent extends React.Component<Props, {}> { render() { return <span>{this.props.foo}</span> } } <MyComponent foo="bar" />; // ok <MyComponent foo={0} />; // error

Type Checking

Type Checking In order to understand type checking with JSX, you must first understand the difference between intrinsic elements and value-based elements. Given a JSX expression <expr />, expr may either refer to something intrinsic to the environment (e.g. a div or span in a DOM environment) or to a custom component that you’ve created. This is important for two reasons: For React, intrinsic elements are emitted as strings (React.createElement("div")), whereas a component you’ve created

Tracing module resolution

Tracing module resolution As discussed earlier, the compiler can visit files outside the current folder when resolving a module. This can be hard when diagnosing why a module is not resolved, or is resolved to an incorrect definition. Enabling the compiler module resolution tracing using --traceResolution provides insight in what happened during the module resolution process. Let’s say we have a sample application that uses the typescript module. app.ts has an import like import * as ts from "t

export = and import = require()

export = and import = require() Both CommonJS and AMD generally have the concept of an exports object which contains all exports from a module. They also support replacing the exports object with a custom single object. Default exports are meant to act as a replacement for this behavior; however, the two are incompatible. TypeScript supports export = to model the traditional CommonJS and AMD workflow. The export = syntax specifies a single object that is exported from the module. This can be

Ambient Modules

Ambient Modules In Node.js, most tasks are accomplished by loading one or more modules. We could define each module in its own .d.ts file with top-level export declarations, but it’s more convenient to write them as one larger .d.ts file. To do so, we use a construct similar to ambient namespaces, but we use the module keyword and the quoted name of the module which will be available to a later import. For example: node.d.ts (simplified excerpt) declare module "url" { export interface Url {

Aliases

Aliases Another way that you can simplify working with of namespaces is to use import q = x.y.z to create shorter names for commonly-used objects. Not to be confused with the import x = require("name") syntax used to load modules, this syntax simply creates an alias for the specified symbol. You can use these sorts of imports (commonly referred to as aliases) for any kind of identifier, including objects created from module imports. namespace Shapes { export namespace Polygons { export cl

Namespaced Validators

Namespaced Validators namespace Validation { export interface StringValidator { isAcceptable(s: string): boolean; } const lettersRegexp = /^[A-Za-z]+$/; const numberRegexp = /^[0-9]+$/; export class LettersOnlyValidator implements StringValidator { isAcceptable(s: string) { return lettersRegexp.test(s); } } export class ZipCodeValidator implements StringValidator { isAcceptable(s: string) { return s.length === 5 && numberRegexp.test(s); }

&lt;reference&gt;-ing a module

/// <reference>-ing a module A common mistake is to try to use the /// <reference ... /> syntax to refer to a module file, rather than using an import statement. To understand the distinction, we first need to understand how compiler can locate the type information for a module based on the path of an import (e.g. the ... in import x from "...";, import x = require("...");, etc.) path. The compiler will try to find a .ts, .tsx, and then a .d.ts with the appropriate path. If a speci

Update tsconfig.json

Update tsconfig.json Now that Angular 2 and its dependencies are installed, we need to enable TypeScript’s experimental support for decorators and include the es6-shim typings. In the future decorators and ES6 will be the default and these settings will not be needed. Add "experimentalDecorators": true, "emitDecoratorMetadata": true to the "compilerOptions" section, and add "./typings/index.d.ts" to the "files" section. Finally, we need to add a new entry in "files" for another file, "./src/mod

Call the script from a view

Call the script from a view In the Solution Explorer, open Views Home Index.cshtml. Change the code to be the following: @{ ViewBag.Title = "Home Page"; } <script src="~/Scripts/App/app.js"></script> <div id="message"></div> <div> Compiler: <input id="compiler" value="TypeScript" onkeyup="document.getElementById('message').innerText = sayHello()" /><br /> Framework: <input id="framework" value="ASP.NET" onkeyup="document.getElementById('m