Fix unknown type assignment

[wojtek1150]

Fixing TS2322: Type 'unknown' is not assignable to type 'boolean' in uischema definition

Examples:

• 278 obj && typeof obj === 'object';
• 284 obj && typeof obj === 'object';

[CLAassistant]

All committers have signed the CLA.

[sdirix]

Hi @wojtek1150, how did you run into this problem? When I use the regular development setup I don't get this Typescript error reported.

Either way I don't think the fix is to change unknown to any. unknown is used so Typescript helps us writing valid type guards for any kind of value which could be passed to the type guard. By using any Typescript will not help us at all and we might miss some checks.

Would !!obj also work for you? This should convert the unknown into a valid boolean.

[coveralls]

Coverage remained the same at 84.356% when pulling 3c102c6 on wojtek1150:patch-1 into 852057c on eclipsesource:master.

[wojtek1150]

This is a fix. Since property can be anything. In the function you are checking type of the input. It cannot be boolean since it is unknown. From typescript documentation:

Anything is assignable to unknown, but unknown isn't assignable to anything but itself

You cannot reproduce because you have disabled multiple ts checks

[sdirix]

Shouldn't !!obj convert the unknown to a boolean and therefore fix the error? I would rather not change unknown to any as this just bypasses the Typescript checks.

[wojtek1150]

Shouldn't !!obj convert the unknown to a boolean and therefore fix the error? I would rather not change unknown to any as this just bypasses the Typescript checks.

as unknown as boolean will also bypass typescript check, see example: https://stackoverflow.com/a/72078863/2782133

But !!obj seems to be right choice so we can get right of typeof null // 'object' issue. I'll use that way.

Anyway I'm not in the project so I can ommit something, but IMO here it could be good place for overloading with all possible (from code not type :P) scenarios so you will have 100% sure what type can be here (in the future ofc)

[sdirix]

The reported issue was fixed with #2023