Follow

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use
Contact

Can I trust Typescript when dealing with a reference to a DOM element?

The following function gets a reference to a DOM element and then does stuff:

function getElementAndDoStuff() {
  // element: HTMLElement | null
  const element = document.getElementById('id');

  if(!element) throw new Error('Error.');

  // element: HTMLElement
  element;
}

After the throwing line, element is considered an HTMLElement by TypeScript, however the element may disappear from the DOM at any time, so is it safe to trust TypeScript?

Even if instead of accessing element right after the throwing line, we put random function calls and asyn/await in between?

MEDevel.com: Open-source for Healthcare and Education

Collecting and validating open-source software for healthcare, education, enterprise, development, medical imaging, medical records, and digital pathology.

Visit Medevel

Are there cases when it’s not safe to trust TypeScript?

>Solution :

It is safe to trust it, because whether or not it’s in the DOM, it’ll still be an HTMLElement.

const element = document.querySelector('div');
console.log(element instanceof HTMLElement);
element.remove();
console.log(element instanceof HTMLElement);
<div>div</div>

If the element is not attached to the DOM, and you try to do something that requires an element currently in the DOM, you will get warned about if. For example, you couldn’t do

const parent = document.querySelector('parent');
parent.appendChild(element);

without changing it to something like

const parent = document.querySelector('parent');
if(!parent) throw new Error('Error.');
parent.appendChild(element);

Even if instead of accessing element right after the throwing line, we put random function calls and asyn/await in between?

Yes, that’s safe, as long as the variable never gets reassigned – it can’t ever get mutated from an HTMLElement to something else, so keeping it typed as such, no matter what other code runs, is safe.

Are there cases when it’s not safe to trust TypeScript?

There are generally edge cases in every faucet of programming. Nothing is 100% perfect. TypeScript, being written by humans, has bugs. But given how long it’s been worked on, many things have been fixed, and most of those that still exist are relatively unusual to come across in the normal process of writing a script.

In my experience, TypeScript problems are much more frequently along the lines of TypeScript not being able to infer a type properly without a bit of extra help from the programmer, though a type assertion or type guard or something like that. Going the other way around – a type being A despite TypeScript inferring it to be B and definitely not A – is much, much more unusual in a decent codebase (that doesn’t, for example, throw around anys and ass liberally). I’ve written a decent amount of TS and can’t remember the last time I ran into that issue, or even if I ever have. There are frequently false-positive type warnings, and very rarely false-negative type inferences.

Add a comment

Leave a Reply

Keep Up to Date with the Most Important News

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

Discover more from Dev solutions

Subscribe now to keep reading and get access to the full archive.

Continue reading