What is the rationale behind permitting surplus properties in Typescript interfaces even though all properties are declared as optional?

Question

What is the rationale behind permitting surplus properties in Typescript interfaces even though all properties are declared as optional?

Exploring the code snippet...

interface Options {
  allowed?: string;
}

function test(options: Options) {
  return options;
}

const options = {
  allowed: 'allowed',
  notAllowed: 'notAllowed',
};

test(options); // no error thrown

Why does adding notAllowed to options not result in an error in Typescript when calling test(options)?

Is there a way to modify this to disallow excess properties?

UPDATE 1...

If I change it to const options: Options = {...};, Typescript will raise an error.

Shouldn't Typescript automatically infer this since I specified that the options parameter should be of type Options?

If not, shouldn't there be an error when passing in const object = {...};?

If not, this could lead to issues for other developers using their own objects with the test function.

UPDATE 2...

The reason for this is to prevent errors in option bags caused by misspelled properties. For example, allowing only include and excluding includes. Is the only solution when passing an object variable (not a literal object) as a parameter to declare a property like includes?: null; in the Options interface?

typescript

Answer 1

Answer №1

One of the challenges with TypeScript is its lack of support for exact types, where properties are constrained only to those explicitly defined. If you're looking for excess property checking, that occurs in a specific scenario when using a fresh object literal.

An approach to handle this issue is to make your `test()` function generic in a manner that fails compilation upon detecting extra properties. The answer provided in the linked duplicate question elaborates on how this mechanism operates. Here's an example:

type Exactly<T, U> = T & Record<Exclude<keyof U, keyof T>, never>;
function test<T extends Exactly<Options, T>>(options: T) {
    return options;
}

const okay = { allowed: "okay" };
test(okay); // no error

const excess = {
    allowed: 'allowed',
    notAllowed: 'notAllowed',
};
test(excess); // error

Link to code

Answer 2

One of the challenges with TypeScript is its lack of support for exact types, where properties are constrained only to those explicitly defined. If you're looking for excess property checking, that occurs in a specific scenario when using a fresh object literal.

An approach to handle this issue is to make your `test()` function generic in a manner that fails compilation upon detecting extra properties. The answer provided in the linked duplicate question elaborates on how this mechanism operates. Here's an example:

type Exactly<T, U> = T & Record<Exclude<keyof U, keyof T>, never>;
function test<T extends Exactly<Options, T>>(options: T) {
    return options;
}

const okay = { allowed: "okay" };
test(okay); // no error

const excess = {
    allowed: 'allowed',
    notAllowed: 'notAllowed',
};
test(excess); // error

Link to code

Answer 3

Answer №2

Is there a way to prevent excess properties in TypeScript?

Unfortunately, it is not possible to restrict excess properties in TypeScript due to its implementation of duck typing, where an object's type is based on the properties it has rather than a specific interface.

In simpler terms, if an object meets the requirements of a certain type (even if it contains additional properties), TypeScript will still consider it as that type.

Answer 4

Is there a way to prevent excess properties in TypeScript?

Unfortunately, it is not possible to restrict excess properties in TypeScript due to its implementation of duck typing, where an object's type is based on the properties it has rather than a specific interface.

In simpler terms, if an object meets the requirements of a certain type (even if it contains additional properties), TypeScript will still consider it as that type.

Answer 5

Answer №3

When creating a test function for future developer use, it's advisable to avoid using interfaces in parameter typing. This is because the function may not work unless the object is properly typed before being passed to the test() function. A good alternative approach is to utilize optional parameters:

function test(allowed?: string) {
  return { allowed };
}

const options = {
  allowed: 'allowed',
  notAllowed: 'notAllowed',
};

test(); //works as expected
test(options.allowed); //works as expected
test(options.allowed, options.disallowed);  //throws an error

Answer 6

When creating a test function for future developer use, it's advisable to avoid using interfaces in parameter typing. This is because the function may not work unless the object is properly typed before being passed to the test() function. A good alternative approach is to utilize optional parameters:

function test(allowed?: string) {
  return { allowed };
}

const options = {
  allowed: 'allowed',
  notAllowed: 'notAllowed',
};

test(); //works as expected
test(options.allowed); //works as expected
test(options.allowed, options.disallowed);  //throws an error

What is the rationale behind permitting surplus properties in Typescript interfaces even though all properties are declared as optional?

Answer №1

Answer №2

Answer №3

Similar questions

Encountering Problems when Converting Vue Application from JavaScript to TypeScript with Vue and Typescript

retrieve the checkbox formgroup using the Response API

Typescript: Unfiltering a string array

Initiate and terminate server using supertest

The value of the filename property cannot be determined as it is undefined

Enhance a subject's behavior by overriding the .next method using a decorator

Angular 7 introduces updates to the way lists are ordered

JavaScript: Translating Date into Moment

Associate a unique identifier string with a randomly generated integer identifier by Agora

What is the method for referencing a subtype within an established type?

Make TypeScript parameter optional if it is not supplied

Issue with dependencies: Incorrect value passed to `ts.resolveTypeReferenceDirective` causing a problem

Starting up various modules in Angular 6 using arrays

Vue3 project encountering issues with Typescript integration

When an empty array is returned from a catch statement in an async/await method, TypeScript infers it as never

When converting a PDF to a PNG, the precious data often disappears in the process

Retrieve the value of a hidden input when a button is clicked using reactive forms in Angular

Tips for handling catch errors in fetch POST requests in React Native

Troubleshooting the "Request failed with status code 500" error when refreshing a page in a React application

Incorporating an interface into a data property within a router using TypeScript and Angular