Excess Property Checks

Developed with
QA

The course is part of this learning path

Typescript: Zero to Hero
course-steps
8
certification
2
play-arrow
Start course
Overview
DifficultyBeginner
Duration9m
Students37
Ratings
5/5
starstarstarstarstar

Description

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

Prerequisites

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).

Feedback

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

Transcript

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.

Lectures

About the Author

Students1799
Labs8
Courses29
Learning paths5

An outstanding trainer in software development with more than 15 years experience as a Corporate and Apprentice Trainer, ICT Teacher and Head of Department, with a passion for technology and its uses. Continuing to develop existing and new skills and courses, primarily in web design using PHP, JavaScript, HTML, CSS and SQL but also OOP (Java), programming foundations (Using Python), DevOps (Git, CI/CD, etc) and Agile/Scrum. Practically minded, a quick learner and a problem solver with an attention to detail to ensure high quality outcomes.

Covered Topics