{composed:boolean} is missing in Event and EventInit interface within lib.dom.d.ts

[Hotell]

TypeScript Version: 2.5.2 ( and all prior version to latest )

Code

see error in TS playground

class Foo extends HTMLElement {
    constructor() {
        super()
        this.attachShadow({mode:'open'})
    }  
    emitCustomEvent() {
       // error
        this.shadowRoot.dispatchEvent(new Event('hello', {bubbles: true, composed: true}));
    }
    emitCustomEventWithExtractedConfig() {
        const worldEventConfig = {bubbles: true, composed: true}
        // no error --> ! this is strange behaviour of TSC, this should be error as well
        this.shadowRoot.dispatchEvent(new Event('world', worldEventConfig));
    }
}

Expected behavior:
{composed:boolean} should be defined ( this event config flag is needed when triggering custom events from shadow root to pierce outside the shadow.

Also what is very strange is that, when event config is initialized to a variable and used then as a reference within Event creation, TS won't throw error which is very strange behaviour indeed as from structure perspective, the composed property is still there and not allowed by current dom.lib.ts

Actual behavior:
add {composed: boolean} to Event and EventInit interfaces within dom.lib.ts

[kitsonk]

Duplicate of: #17974 (search is your friend)

Covered by PR: microsoft/TypeScript-DOM-lib-generator#284

[Hotell]

thanks, although I didn't find related issue via search, and yes I always look before creating issues if there is already one/similar created.

Still I think there is bug, not related to Event type, which I've described as well:

Also what is very strange is that, when event config is initialized to a variable and used then as a reference within Event creation, TS won't throw error which is very strange behaviour indeed as from structure perspective, the composed property is still there and not allowed by current dom.lib.ts

[kitsonk]

The behaviour around why something like this behaves the way it does:

interface FooOptions {
    foo?: string;
}

declare function foo(options?: FooOptions): void;

foo({
    foo: 'bar',
    bar: 123 // error
});

const options = { foo: 'bar', bar: 123 };

foo(options); // no error

const guardedOptions: FooOptions = { foo: 'bar', bar: 123 }; // error

Has to do with the challenges of dealing with a structural type system. IIRC prior to TypeScript 1.6, an object literal could have excess properties, as that is allowed in a structural type system. That of course causes a lot of potentially unintentional mistakes (though if the interfaces are correct, excess properties shouldn't matter). Because strictly speaking { foo: 'bar', bar: 123 } is actually assignable to the type of { foo: string }.

Because this can be surprising the decision was made to check for excess properties on the assignment of the object literal, but follow the right way of dealing with assignment in other locations. This still means when you have a variable that is contextually typed, it follows the proper assignment rules, but if you assert the type, instead of contextually infer it, the fresh object literal type is checked to see if it has excess properties.

So this is working as designed.

[alan-agius4]

Thanks for nice explanation above.

So, what you be the ideal way to remove excess properties?

using object deconstruction or just use type assertions?

Option 1

const { genericErrorCode, ...someErrorConfig } = errorConfig;
return {
    ...someErrorConfig,
    code,
    data
};

or

Option 2

return {
    ...errorConfig,
    code,
    data
} as AppError;

[kitsonk]

So, what you be the ideal way to remove excess properties?

Question is why you need to remove excess properties... but there are many ways. If you are trying to catch errors, guard the types when authoring "fresh" objects, like I did above:

const guardedOptions: FooOptions = { foo: 'bar', bar: 123 }; // error

[Hotell]

First of thanks so much for thorough explanation @kitsonk didn't know that it works this way !

about:

Question is why you need to remove excess properties... but there are many ways. If you are trying to catch errors, guard the types when authoring "fresh" objects, like I did above:

const guardedOptions: FooOptions = { foo: 'bar', bar: 123 }; // error

Well now with this style, we are getting to "Java" style -> explicitly annotate that string is a string which is a big no no IMHO. ( even there are lint rules within TSLint that will error on this explicit annotation on Classes properties for instance )

Hopefully this can be resolved somehow in future releases of TS

[alan-agius4]

@kitsonk I need to remove excessive properties, to make typescript compile, actually either remove the properties or use the type assertion using the as myInterface.

I am just asking what would be the recommended way :)

[kitsonk]

Hopefully this can be resolved somehow in future releases of TS

It won't be fixable until there is some level of support for co-variant parameters, which is a really difficult thing to introduce. It can be surprising behaviour, but why it is surprising is to permit other functionality that would be really annoying if TypeScript didn't support. This is explained in the FAQ Why are function parameters bivariant?

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.