Typescript Deep Dive by Basarat Ali Syed

TypeScript Deep Dive
This is because foo is used as a variable.
Use case: Lazy loading
Type inference needs to be done upfront. This means that if you want to use some type from a file foo in a file bar you
will have to do:
import foo = require('foo');
var bar: foo.SomeType;
However you might want to only load the file foo at runtime under certain conditions. For such cases you should use the
import ed name only in type annotations and not as a variable. This removes any upfront runtime dependency code being
injected by TypeScript. Then manually import the actual module using code that is specific to your module loader.
As an example, consider the following commonjs based code where we only load a module 'foo' on a certain function call
import foo = require('foo');
export function loadFoo(){
// This is lazy loading `foo` and using the original module *only* as a type annotation
var _foo: typeof foo = require('foo');
// Now use `_foo` as a variable instead of `foo`.
}
A similar sample in amd (using requirejs) would be:
import foo = require('foo');
export function loadFoo(){
// This is lazy loading `foo` and using the original module *only* as a type annotation
require(['foo'], (_foo: typeof foo) => {
// Now use `_foo` as a variable instead of `foo`.
});
}
This pattern is commonly used:
in web apps where you load certain JavaScript on particular routes
in node applications where you only load certain modules if needed to speed up application bootup.
Use case: Breaking Circular dependencies
Similar to the lazy loading use case certain module loaders (commonjs/node and amd/requirejs) don't work well with
circular dependencies. In such cases it is useful to have lazy loading code in one direction and loading the modules upfront
in the other direction.
Fork me on github
File Module Details
45