Fixing common TS typings


#1

In the scenegraph I’m getting a few warnings in the typings. I’d like to fix them but it looks like there’s properties that I need to add to the definitions and others don’t make sense. Why can’t a scene node be used in a dictionary?

Matrix
[ts] Property ‘e’ does not exist on type ‘Matrix’. [2339]

var transform = item.transform;
transform.e = 0;

Module

[ts] Cannot find module ‘os’. [2307]

const platform = require("os").platform();

File

[ts] Type ‘File | File[ ]’ is not assignable to type ‘File’.
Type ‘File’ is missing the following properties from type ‘File’: lastModified, size, type, slice [2322]

 /**@type {File} */
 let selectedFile = await fileSystem.getFileForOpening();

[ts] Property ‘nativePath’ does not exist on type ‘File’. [2339]

var value = selectedFile.nativePath;

[ts] Property ‘read’ does not exist on type ‘Entry’. [2339]

const entries = await pluginDataFolder.getEntries();
const files = await entries.filter(entry => entry.name.indexOf(filename) >= 0);
var file = files[0];
let data = await file.read();

[ts] Property ‘write’ does not exist on type ‘Folder | File’.
Property ‘write’ does not exist on type ‘Folder’. [2339]

newFile.write(data);

[ts] Cannot find name ‘Folder’. [2304]

 /** @type { Folder } */
 const folder = await pluginFolder.getEntry(filePath);

Color

[ts] Property ‘serialize’ does not exist on type ‘Color’. [2339]

console.log("Color:" + new Color("red").serialize()); // returns "rgb(255, 0, 0)" 

SceneNode

[ts] Type ‘SceneNode’ cannot be used as an index type. [2538]

itemsDictionary[sceneNode] = nestLevel;

#2

As per the documentation, Matrix has no attribute e: https://adobexdplatform.com/plugin-docs/reference/Matrix.html

OS – according to the docs – is a global class and therefore not a module that can get imported by using require() – cf. https://adobexdplatform.com/plugin-docs/reference/uxp/class/OS.html

This could be an interference with the File type from the “standard” DOM typings (see https://developer.mozilla.org/de/docs/Web/API/File). I – unfortunately – haven’t found a way to get around that (except for disabling the DOM typings which would mean not having capabilities around the UI aspects).

I would guess that this is the same problem as above. Again, that’s due to an incompatibility of some aspects of the XD APIs with the way typescript handles things (more on that later :wink:)

That’s to be expected since at that point, file is only known to be an Entry, and only a File has the property read(). Unfortunately, that’s a point where there’s a big incompatibility between the way the APIs work and the way typescript works. With the APIs, we would simply check for the Entry being a File by using entry.isFile(), but TypeScript – unfortunately – doesn’t support something like this, which is why there is no good solution for this (at least none that I’m aware of and I’ve searched for a long time when developing the definitions).

Same as above.

Since Folder isn’t an exported member of the module, it seems to have difficulties to resolve that name. Unfortunately, I don’t know of any way around that (sometimes it works, sometimes it doesn’t).

While it’s interesting to hear about that serialize() method, it isn’t stated anywhere in the docs and therefore not inlcuded in the typings (since it is my goal to keep those up to date with the docs where I have docs to copy etc. and not with some “mysterious, hidden APIs” :wink:) – cf. https://adobexdplatform.com/plugin-docs/reference/Color.html#color

That’s due to the way TypeScript handles index types. Please refer to https://basarat.gitbooks.io/typescript/docs/types/index-signatures.html for further information about index signatures in anything related to TypeScript. The short version is, that you could use sceneNode.toString() to hack your way around that and otherwise can’t use complex data structures as index types (out of curiosity: why would you want to do that anyway? It seems a bit strange to me since once you loose the reference of an object, you’ll never be able to access the elements of the dictionary anymore?)


#3

Is DocumentRoot one of the types that is complicated to work around?


#4

@Velara

I’m not sure I can follow you here – if you’re referring to the RootNode class: That’s implemented in scenegraph.d.ts.

If you use it as a parameter (as second parameter of a command called by XD), you’ll need to specify the parameters type in the JSDoc (see the sample.js file for an example of that), since this is “your” function and the typings can’t specify argument types of functions declared elsewhere.

I hope this helps,
Best,
Pablo


#5

I was looking up type DocumentRoot. :stuck_out_tongue:


#6

While it’s interesting to hear about that serialize() method, it isn’t stated anywhere in the docs and therefore not inlcuded in the typings

Thank you for that by the way! :slight_smile:  If an API is undocumented, it’s not supported and it may change or be deleted at any time. It’s also always possible, in the future, that we may reject plugin submissions if they are using undocumented APIs that we consider unstable. So we strongly encourage everyone to only use APIs that are seen in our official public docs.