Hacker News Reader

Comment by ken47 | Hacker News Reader

Typescript is GREAT. Strict null-checking eliminates the dreaded null-pointer exception. It enables type-safe mixins. It allows for mapped types. Literal types, especially string literal types, makes it so easy to work with pre-existing JS libraries.

The way I look at Typescript vs. Javascript is that with Typescript, it's like having always having a pair programming buddy (the compiler) who never makes mistakes.

View on HN

The new null-checking is great, but is notably missing first-class support for dealing with null. If you're familiar with Options (e.g. Java 8, Scala, Haskell), I've written a library [1] to fill that void until TypeScript does so.

[1] https://github.com/jiaweihli/monapt

> Strict null-checking eliminates the dreaded null-pointer exception

When I was using typescript this still came up if you missed an array bounds check, you'd end up with an unexpected undefined. Pretty annoying and tough to debug.

Has this changed (I can't see how it could have, but... maybe?)

Sort of. Strict null checking now lets you distinguish between the types Foo[] and (Foo | undefined)[]. The first will type with the assumption that there are no out of bounds indices (which, as you say, could be wrong). The second will require you to always check the result of array dereferences to see if they're undefined before you reference the object.

  var foos1 = [] as Foo[],
      foos2 = [] as (Foo | undefined)[];
  
  // ... later
  
  var foo1 = foos1[i],
      foo2 = foos2[i];

  foo1.bar(); // types fine, TS assumes non-undefined
  foo2.bar(); // TS type error, as you haven't checked undef
  if (foo2) foo2.bar(); // types fine, undef excluded

> (Foo | undefined)[]

This says "either an array of Foo or an array of undefined", right? Not "either an array of Foo or just undefined"?

No, (Foo | undefined)[] means an array of elements that are either of type Foo or are undefined.

Foo[] | undefined[] means either 1) an array of Foo, or 2) an array of undefined.

Ahh got it - thanks!

It says an array whose elements can be either Foo or undefined.

This isn't the issue I'm describing at all.

E.g. if I missed a bounds check, and access past the end of a `Foo[]`, it would be typed as `Foo` (and not `Foo | undefined`), but really be `undefined.

Consider this code.

    var foos: Foo[] = [new Foo()];
    foos[1].bar();

foos[1] will be undefined (since it's past the end of the array) but will typecheck as a Foo.

Obviously it's bad if I forget a bounds check, but it's similarly bad if I forgot a null check.

Of course, I understand why this issue exists, but it is an issue.

null checking can have some surprising results. The standard React pattern:

        ReactDOM.render(
        <Start />,
        document.getElementById("content")
        );

Will error because getElementById can return null. And it's 100% valid and imo 100% worth checking for - but I can't say I've ever heard of anyone doing it before Typescript suggested it.

2.0 added an exclamation mark (!) postfix operator that asserts a type as being non-null/non-undefined. So these checks are easy to explicitly ignore.

Thanks! I wasn't aware of that. That said, I don't actually want to ignore it - I think it's good that Typescript is showing people some potentially errors they never thought to look for.

This pattern really isn't hard and if it saves you from one "undefined is undefined" then it was worth it.

    const item = document.getElementById("content");
    if (item == null) {
        console.log("Render container missing");

Could you (or someone else) help me out here? I'd rather like getting an error in this situation, but in my code, with strictNullChecks turned on, TypeScript seems to be fine with the above... What am I missing?

Unfortunately all I've got here is that the behaviour can be seen in my boilerplate React app:

https://github.com/technion/awesome-sec-audit/blob/master/as...

If you insert the element directly in line 25 you'll get:

    error TS2345: Argument of type 'HTMLElement | null' is not assignable to parameter of type 'Element'.

Strange. On my end it does look like ReactDOM's 'render' method actually accepts HTMLElement | null, and therefore doesn't throw an error.

What exactly do you mean by "null-pointer exception"?

He's referring to the dereference of a null object. For instance, calling "foo.bar" when foo is null (or potentially undefined).

Reply on news.ycombinator.com