Is there a distinction in Typescript between the return types of Object.seal and .freeze?

Question

Is there a distinction in Typescript between the return types of Object.seal and .freeze?

I am looking to safeguard the constant object content from any changes during runtime. This includes alterations to both the object structure and its content. The preferred method for achieving this is by using Object.freeze.

interface iRO<T> {
    readonly [key: string]: T | null;
}

const nc: iRO<HTMLElement> = {
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside"),
}

const go: iRO<HTMLElement> = Object.seal({
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside"),
})

const nogo: iRO<HTMLElement> = Object.freeze({
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside"),
})

To exemplify, I have created three constants with identical content. The compilation succeeds with the constants "nc" and "go". However, the compiler raises an error with "nogo":

»Type 'Readonly<{ main: HTMLBodyElement | null; aside: Element | null; }>' is not assignable to type 'iRO'. Property 'aside' is incompatible with index signature. Type 'Element | null' is not assignable to type 'HTMLElement | null'. Type 'Element' is missing properties such as accessKey, accessKeyLabel, autocapitalize, dir, and more.«

This behavior is perplexing. Shouldn't Object.freeze have the same impact on the assigned type as Object.seal?

Explore the issue further in the Typescript Playground

typescript

Answer 1

Answer №1

The issue arises from how TypeScript determines the type of the object prior to being assigned to the variable on the left-hand side.

When you specify:

const nc: iRO<HTMLElement> = {

This indicates to TypeScript that the object on the right must adhere to iRO<HTMLElement>. In other words, its values must be of type HTMLElement | null. This works for nc because

document.querySelector("body")

with the correct type argument can provide this type. One way to understand the initial version is:

const nc: iRO<HTMLElement> = {
    main: document.querySelector<HTMLElement>("body"),
    aside: document.querySelector<HTMLElement>("body > aside"),
}

This approach is also compatible with Object.seal since Object.seal doesn't alter the type of the argument. Its type definition is:

seal<T>(o: T): T;

However, Object.freeze functions differently. Its type definition is:

freeze<T>(o: T): Readonly<T>;

As it produces a new type, the T cannot change to satisfy generics. The type of the object passed in must remain static. It can be visualized as:

const obj = {
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside"),
};
const nogo: iRO<HTMLElement> = Object.freeze(obj);

However, the parameter has a type of

const obj: {
    main: HTMLBodyElement | null;
    aside: Element | null;
}

and the resultant type returned by Object.freeze is

Readonly<{
    main: HTMLBodyElement | null;
    aside: Element | null;
}>

This creates a new type - and an Element cannot be assigned to an HTMLElement.

If Object.seal yielded a new type, rather than the same type as the argument, the same issue would arise with it as well. However, since Object.seal maintains the same type as its argument, this problem doesn't occur.

To rectify this, utilize the generic parameter for querySelector:

const nc = Object.freeze({
    main: document.querySelector("body"),
    aside: document.querySelector<HTMLElement>("body > aside"),
})

Answer 2

The issue arises from how TypeScript determines the type of the object prior to being assigned to the variable on the left-hand side.

When you specify:

const nc: iRO<HTMLElement> = {

This indicates to TypeScript that the object on the right must adhere to iRO<HTMLElement>. In other words, its values must be of type HTMLElement | null. This works for nc because

document.querySelector("body")

with the correct type argument can provide this type. One way to understand the initial version is:

const nc: iRO<HTMLElement> = {
    main: document.querySelector<HTMLElement>("body"),
    aside: document.querySelector<HTMLElement>("body > aside"),
}

This approach is also compatible with Object.seal since Object.seal doesn't alter the type of the argument. Its type definition is:

seal<T>(o: T): T;

However, Object.freeze functions differently. Its type definition is:

freeze<T>(o: T): Readonly<T>;

As it produces a new type, the T cannot change to satisfy generics. The type of the object passed in must remain static. It can be visualized as:

const obj = {
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside"),
};
const nogo: iRO<HTMLElement> = Object.freeze(obj);

However, the parameter has a type of

const obj: {
    main: HTMLBodyElement | null;
    aside: Element | null;
}

and the resultant type returned by Object.freeze is

Readonly<{
    main: HTMLBodyElement | null;
    aside: Element | null;
}>

This creates a new type - and an Element cannot be assigned to an HTMLElement.

If Object.seal yielded a new type, rather than the same type as the argument, the same issue would arise with it as well. However, since Object.seal maintains the same type as its argument, this problem doesn't occur.

To rectify this, utilize the generic parameter for querySelector:

const nc = Object.freeze({
    main: document.querySelector("body"),
    aside: document.querySelector<HTMLElement>("body > aside"),
})

Answer 3

Answer №2

It is my understanding that when you call

document.querySelector("body")

, it returns an instance of HTMLBodyElement, an extension of HTMLElement.
However, when you call

document.querySelector("body > aside")

, it does not return an HTMLElement but rather an Element, making it a subinterface of HTMLElement.

Therefore, expecting all keys to at least extend from HTMLElement when using iRO<HTMLElement> is reasonable. When you use a normal object or Object.seal, you are performing a smart type cast. On the other hand, using Object.freeze will freeze your object and determine that your aside will only be of type Element, not HTMLElement.

However, there is a workaround:

const nogo: Readonly<iRO<HTMLElement>> = Object.freeze({
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside") as HTMLElement | null,
})

Edit:

After considering the response from @CertainPerformance, it is advisable to use

document.querySelector<HTMLElement>("body > aside")

instead of

document.querySelector("body > aside") as HTMLElement | null

Answer 4

It is my understanding that when you call

document.querySelector("body")

, it returns an instance of HTMLBodyElement, an extension of HTMLElement.
However, when you call

document.querySelector("body > aside")

, it does not return an HTMLElement but rather an Element, making it a subinterface of HTMLElement.

Therefore, expecting all keys to at least extend from HTMLElement when using iRO<HTMLElement> is reasonable. When you use a normal object or Object.seal, you are performing a smart type cast. On the other hand, using Object.freeze will freeze your object and determine that your aside will only be of type Element, not HTMLElement.

However, there is a workaround:

const nogo: Readonly<iRO<HTMLElement>> = Object.freeze({
    main: document.querySelector("body"),
    aside: document.querySelector("body > aside") as HTMLElement | null,
})

Edit:

After considering the response from @CertainPerformance, it is advisable to use

document.querySelector<HTMLElement>("body > aside")

instead of

document.querySelector("body > aside") as HTMLElement | null

Is there a distinction in Typescript between the return types of Object.seal and .freeze?

Answer №1

Answer №2

Similar questions

In Angular 4, you can easily preselect multiple options in a mat-select dropdown by passing an

Exploring the potential of Vue with Router to create a dynamic multi-page

The dimensions of the d3 div remain constant despite any modifications to its attributes

Is it possible to customize the information displayed in a Mat-Dialog based on the object being

Error encountered: The combination of NextJS and Mongoose is causing a TypeError where it is unable to read properties of undefined, specifically when trying

I am unable to utilize ES6 modules alongside typescript in my Node.js project

In my efforts to reset the TypeORM MySQL database upon server shutdown in NestJS, I am exploring different approaches

Error message: "Mismatched data types in Formik errors when utilizing TypeScript"

Consider pushing items onto an array only once when the condition is met, instead of adding to the array every

What seems to be the issue with my @typescript-eslint/member-ordering settings?

Utilizing Prisma's Create Object to Store Return String from Imported Function in Database

Solving the Path Dilemma in TypeScript Functions within the Firebase Environment

There was an unhandled exception that occurred due to a missing file or directory with the lstat error on 'D:a1s ode_modulesquill'

Challenges with implementing asynchronous functions in NestJS controllers

Angular 9: Implementing a synchronous *ngFor loop within the HTML page

Setting input limits in AlertBox in Ionic v3: A step-by-step guide

A versatile method to organize a multi-dimensional array of items

Transform the Standard class into a generic one in typescript

JavaScript code that displays values that are not equal

Jest test encounters Firebase initialization error