Allow object as input of API functions

[tpluscode]

I see that the jsonld functions now take JsonLd as input. It is defined in a way which causes compilation to complain when any arbitrary JS object is passed.

jsonld.js works just fine this way and I think the JsonLd typing could be updated accordingly

[blakeembrey]

The tests are working with an "arbitrary object". Please elaborate on the issue. You can always use the type when defining the object.

[tpluscode]

The code work. The thing I'm seeing is tsc throwing errors like

Error:(28, 28) TS2345: Argument of type '{ "@context": ... }' is not assignable to parameter of type 'JsonLdObject | JsonLdObject[] | string'.
Type '{ "@context": ... }' is not assignable to type 'string'.

[tpluscode]

Hm I tried to get rid of that error. I think that adding Object explicitly works

export type JsonLd = JsonLdObject | JsonLdObject[] | Object | Object[];

What do you think?

[felixfbecker]

@tpluscode Please show the code where your error occurs. JsonLdObject is an interface, and whatever object is compatible with that interface can get passed to the function.

[tpluscode]

I'm seeing two cases. One where the input is an object created with an object literal: https://github.com/wikibus/heracles/blob/master/tests/ApiDocumentation-spec.ts#L17

And second where I'm calling jsonld on self (https://github.com/wikibus/heracles/blob/master/src/Resources.ts#L53) in which case the error reads

Error:(53, 31) TS2345: Argument of type 'this' is not assignable to parameter of type 'JsonLdObject | JsonLdObject[] | string'.
Type 'Resource' is not assignable to type 'JsonLdObject | JsonLdObject[] | string'.
Type 'Resource' is not assignable to type 'string'.
Type 'this' is not assignable to type 'string'.
Type 'Resource' is not assignable to type 'string'.

[felixfbecker]

It's hard to tell on GitHub because I don't want to clone the repo and you don't use explicit type annotations, but one of your properties in Resource is not matching the type of the interface, so it appears to me that the typings are correct here and the usage is wrong. Putting Object in there would cripple the type safety and allow anything (except primitives).

[tpluscode]

I added return types to Resource and it didn't help. Which property do you think does not match the interface? There are three return types: string, boolean and string | string[].

[tpluscode]

And what about imported var? I see that usage like below works fine.

jsonld.compact({
  '@id:' '...',
  '@context': { ... }
});

But if that object is imported variable, tsc complains

[felixfbecker]

Are you saying this fails while your example works?

// a.ts
export const whatever = { '@id': '...', '@context': { ... } }
// b.ts
import {whatever} from './a;
jsonId.compact(whatever)

that is impossible, it is only the type that matters. The input needs to match the interface ;)

[tpluscode]

In my case whatever is actually inside a namespace. But yes, either way it doesn't work. I mean, it works. It just refuses to compile without an error :)

[felixfbecker]

Could you try to create an SSCCE?

[tpluscode]

Will do in the evening.

[blakeembrey]

I think I see the issue, and it is probably because jsonld uses "own properties" and your code has methods as part of the interface, but functions are incompatible with the signature. To be honest, I don't think TypeScript can express this specific limitation. If jsonld (the library) can accept functions as "own properties", I'd be happy to add those to the input object so this would work.

[felixfbecker]

Methods are non-enumerable by default though

[blakeembrey]

In TypeScript or JavaScript? In any case, they're on the prototype but the jsonld library uses Object.keys internally, so never encounters the functions. That's all. Also, methods are enumerable in the JavaScript emit of TypeScript (http://www.typescriptlang.org/play/#src=class%20Foo%20%7B%0A%20%20%20%20method()%20%7B%20%7D%0A%7D%0A%0Afor%20(var%20key%20in%20new%20Foo())%20%7B%0A%20%20%20%20console.log(key)%0A%7D). TypeScript has no concept of prototypes here, so we can't type an interface that checks "own properties" only.