Tips and tricks to handling the shell : Typescript
Typescript and things i wish i would've known
Typescript and The DOM
As you begin using and learning TypeScript it becomes apparent that its very in touch with the browser environment. Lets say you needed a element on the page and you used a basic document.querySelector(‘desired element’)
TypeScript will show you the error if you misspell the element on the page !!
But how is it that it recognizes your’e misspelling the elements name on the page ? The reason why is because of the lib.dom.d.ts file. This file is a part of the TypeScript library and basically describes everything that occurs in the browser. It can be an object, function or events it recognizes them. It isn’t perfect since it only works on basically element sector but i’ve been caught in mistyped errors more than once myself.
Does the search end ?
Does the document.querySelector(...) method actually return us an object? If an element matching the selector is not on the page, but an object is found instead the function returns null.
By default, the type checker does consider null and undefined as assignable types.You can override the default and be safer in your approach by restricting the behaviour adding checks to the tsconfig.json:
{
"compilerOptions": {
"strictNullChecks": true
}
}TypeScript will now complain if you try to access the property on an object that is possibly null, and you will have to “reassure” it about the object’s existence. You can do this by wrapping that part with if (textEl) {...} condition. You may not always find what your’e looking for but there are tools.
Migrating to the Shell
Often when you have a codebase that you want to migrate to TypeScript, one of the hassles is to adhere to your TSLint rules. What you can do is edit all these files by adding
// tslint:disableThen only when a developer works on a legacy file, he will start by removing this one comment and fix all linting errors only in this file.
As for adding the actual types to that old JavaScript code, you actually can often do without. TypeScript’s type inference will take care of it and only if you had some nasty code, e.g. that assigns different type of values to the same variable, you can have a problem. If refactoring that is not a trivial issue you can resolve to using any
But really use it as a last resort. TypeScript and any do not go well together.
More Restrictions
Sometimes TypeScript can’t infer the type. Most common case is a function parameter:
function fn(param) {
console.log(param);
}Internally, it needs to assign some type to param, so it assigns any. Since we want to limit it to the minimum it's usually recommended to restrict that behaviour with another tsconfig.json setting:
{
"compilerOptions": {
"noImplicitAny": true
}
}Unfortunately, we can’t put that’d require an explicit typing on a function return type. TypeScript will not keep an eye on what I return, or even if I return anything from that function. To be more accurate it will infer the return value from whatever you’ve returned or not returned.
Thankfully that’s where TSLint helps. With the typedef rule you can make return types required:
{
"rules": {
"typedef": [
true,
"call-signature"
]
}
}TypeScript is our shell to our turtle. There are many times when the errors within our code whether they are mistypes or incorrect punctuation can break our app. Its better to be safe than sorry. There are many other tips and tricks that can be done with TypeScript but ill leave that for the next blog.
Sources
