5

I am a beginner with typescript and playing with it on their Playground site. I have the following code:

class Queue<T> { 
    private data = [];

    push = (item: T) => this.data.push(item);
    pop = (): T => this.data.shift();
}



let button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function () {
    let q = new Queue<number>();
    q.push("asdada");

    alert(q.pop(0));
}

document.body.appendChild(button);

As you can see I created a Queue Object to just accept a number. However, I was able to pass string and able to alert it on my browser. I saw the compiled JS version and it doesn't type check my variable. Isn't typescript supposed to avoid these errors? Or am I mistaken?

Thanks!

iamjc015
  • 2,127
  • 6
  • 25
  • 61

2 Answers2

5

Indeed, TypeScript does not check types at runtime. See the FAQ entry.

Matt McCutchen
  • 28,856
  • 2
  • 68
  • 75
  • But it will still compile successfully? So the benefits are only on development? – iamjc015 Aug 02 '18 at 03:38
  • 3
    Correct. If you don't want to generate JavaScript when there's a type error, you can use `--noEmitOnError`. – Matt McCutchen Aug 02 '18 at 03:40
  • 1
    As Typescript compiles to pure Javascript, event though you see errors while compiling, if the logic is valid in Javascript then it will work. As you are going to run Javascript code not Typescript code. – Plochie Aug 02 '18 at 03:40
  • Probably the one I want is to use that noEmitOnError. Thanks! – iamjc015 Aug 02 '18 at 03:42
  • 1
    No, with the right build setup it shouldn't let you compile if there's typing issues. And ideally you'd have linting which would point out these kinds of errors in real time. The benefits aren't really "only in development", yes the typing stuff only works while you're developing and when transpiled into Javascript the typing isn't enforced, but it means what you develop is less likely to have issues relating to typing as it doesn't let you write code that has dangerous practices, like assuming object properties or the data type of variables. – Jayce444 Aug 02 '18 at 03:43
  • Thanks for all your answers, really appreciated it. Is it recommended to use noEmitOnError? – iamjc015 Aug 02 '18 at 03:44
  • 1
    Yes, that config option should prevent the Javascript output being created if there's any TS errors detected. – Jayce444 Aug 02 '18 at 03:49
  • 2
    Re whether to use noEmitOnError: it depends on your development workflow. You might sometimes find it useful to write code for which you haven't figured out the proper types yet, test it at runtime, and then put in types until the errors are gone. With noEmitOnError, before you can test anything, you'd have to put in a bunch of casts, and then you'd have to remember to take them out during code review. The important thing is not to check code with errors into your main branch. – Matt McCutchen Aug 02 '18 at 03:51
3

Typescript will still output regular javascript, so if its valid javascript it will continue to work. it will only yell at you in the editor you're using.

If you prefer typescript should not generate javascript if there is an error use --noEmitOnError as Matt McCutchen suggested in the comments.

If you want to check the types at runtime you can use User-Defined Type Guards.

See this answer for a quick example.

agDev
  • 855
  • 10
  • 20