Readonly properties Some properties should only be modifiable when an object is first created. You can specify this by putting readonly before the name of the property: interface Point { readonly x: number; readonly y: number; } You can construct a Point by assigning an object literal. After the assignment, x and y can’t be changed. let p1: Point = { x: 10, y: 20 }; p1.x = 5; // error! TypeScript comes with a ReadonlyArray<T> type that is the same as Array<T> with all mutating

Readonly modifier You can make properties readonly by using the readonly keyword. Readonly properties must be initialized at their declaration or in the constructor. class Octopus { readonly name: string; readonly numberOfLegs: number = 8; constructor (theName: string) { this.name = theName; } } let dad = new Octopus("Man with the 8 strong legs"); dad.name = "Man with the 3-piece suit"; // error! name is readonly.

Red flags

Rest Parameters Required, optional, and default parameters all have one thing in common: they talk about one parameter at a time. Sometimes, you want to work with multiple parameters as a group, or you may not know how many parameters a function will ultimately take. In JavaScript, you can work with the arguments directly using the arguments variable that is visible inside every function body. In TypeScript, you can gather these arguments together into a variable: function buildName(firstName:

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

Re-exports Often modules extend other modules, and partially expose some of their features. A re-export does not import it locally, or introduce a local variable. ParseIntBasedZipCodeValidator.ts export class ParseIntBasedZipCodeValidator { isAcceptable(s: string) { return s.length === 5 && parseInt(s).toString() === s; } } // Export original validator but rename it export {ZipCodeValidator as RegExpBasedZipCodeValidator} from "./ZipCodeValidator"; Optionally, a module can wra

Putting it all together Just run: webpack Now open up index.html in your favorite browser and everything should be ready to use! You should see a page that says “Hello from TypeScript and React!”

Re-export to extend Often you will need to extend functionality on a module. A common JS pattern is to augment the original object with extensions, similar to how JQuery extensions work. As we’ve mentioned before, modules do not merge like global namespace objects would. The recommended solution is to not mutate the original object, but rather export a new entity that provides the new functionality. Consider a simple calculator implementation defined in module Calculator.ts. The module also exp

Putting it all together Just run: tsc Now open up index.html in your favorite browser and everything should be ready to use! You should see a page that says “Hello from TypeScript and Knockout!” Below that, you’ll also see two input boxes. As you modify their contents and switch focus, you’ll see that the original message changes.

Re-declarations and Shadowing With var declarations, we mentioned that it didn’t matter how many times you declared your variables; you just got one. function f(x) { var x; var x; if (true) { var x; } } In the above example, all declarations of x actually refer to the same x, and this is perfectly valid. This often ends up being a source of bugs. Thankfully, let declarations are not as forgiving. let x = 10; let x = 20; // error: can't re-declare 'x' in the same scope The variabl