Excess Property Checks

The course is part of this learning path

Start course

This module introduces you to Interfaces in TypeScript.

Learning Objectives

The objectives of this module are to provide you with an understanding of:

  • How to use Function Types
  • How to use Optionals
  • How to use Excess Property Checks
  • How to use Indexable Types
  • How Interfaces work with Classes
  • How to create Extendable Interfaces

Intended Audience

This learning path is aimed at all who wish to learn how to use TypeScript


It is essential you understand the face of contemporary web development to attend this course. You should have a good working knowledge of Javascript. Please note: Before attending this class delegates must have a Microsoft account (signing up one is free).


We welcome all feedback and suggestions - please contact us at to let us know what you think.


TypeScript will perform access property checks on any object that has signed an interface contract. Using the interface means that the structure of the object has to be adhere to. It can lead to silent errors. TypeScript treats object literals with caution, and does access property checks. You can see the access property check is done on car three on line 32 at the bottom left hand of the screen will hover over to show you the error. Window property is not known in vehicle, at the top right on line 35. We define another car object without signing the vehicle contract. On line 42 we have a function called Park vehicle that expects to receive an object sign the vehicle contract. Car three could be parked here with no problems, duck typing in action. The same goes for car for more duck typing Passing in an object literal notation produces an error if the object doesn't meet the vehicle interface requirements. This is shown on line 55. Accesses property checking in action again. I submit an object lecture is seen as dangerous and error prone, and iterators could have problems here, with the being too many fields. Also passing in an object literal, it's already been signed is okay and seen as less dangerous, especially if the object passed in meets the contract. All this is not really recommended. We could use type assertion at a type index signature, or assigned to a variable first to get around all of this. But should we be trying to? The answer is probably not as the majority of access property check errors usually end up in being an indication of a book.


About the Author
Learning Paths

Ed is an Outstanding Trainer in Software Development, with a passion for technology and its uses and holding more than 10 years’ experience.

Previous roles have included being a Delivery Manager, Trainer, ICT teacher, and Head of Department. Ed continues to develop existing and new courses, primarily in web design using: PHP, JavaScript, HTML, CSS, SQL, and OOP (Java), Programming Foundations (Python), and DevOps (Git, CI/CD, etc). Ed describes himself as practically minded, a quick learner, and a problem solver who pays great attention to detail. 

Ed’s specialist area is training in Emerging Technologies, within Web Development. Ed mainly delivers courses in JavaScript covering vanilla JS, ES2015+, TypeScript, Angular, and React (the latter is authored by Ed) and has delivered on behalf of Google for PWAs. Ed has also developed a new suite of PHP courses and has extensive experience with HTML/CSS and MySQL. 

Ed is responsible for delivering QA’s Programming Foundations course using the Eclipse IDE. His skillset extends into the DevOps sphere, where he is able to deliver courses based around Agile/Scrum practices, version control, and CI/CD.

Covered Topics