didoo / figma-api Goto Github PK

Fixes issue where incorrect type being used.

Using lineIndentationNumber should be lineIndentation

Original Issue: #43

Hello,

While using Api.getFileNodes we have to provide node ids, but those nodes contain special characters and even when using encodeURIComponent() I can't make it work. Would you have a working example? Maybe you could add one in the doc as well

I'm currently doing it this way:

const figmaFileKey = 'key'
const figmaNodeIds = ['220%3A3643']

const file = await api.getFileNodes(figmaFileKey, figmaNodeIds.map(x => encodeURIComponent(x)));

With this output:

Thank you!

Hi - thanks for this very useful library!

Drop shadows in Figma have a "spread" property https://www.figma.com/developers/api#effect-type.

I guess this needs to be added (as a number) to EffectShadow_ in https://github.com/didoo/figma-api/blob/master/src/ast-types.ts#L318

I didn't do a PR because I wasn't sure - let me know if you want me to - thanks!

Hello!

I was working with this library, and it seems like the "document" that we return from api.getFileNodes doesn't reflect the actual data returned:

export interface GetFileNodesResult {
    name: string,
    lastModified: string,
    thumbnailUrl: string,
    version: string,
    err?: string,
    nodes: {
        [nodeId: string]: {
            document: Node<'DOCUMENT'>, // <-- this one!
            components: { [nodeId: string]: Component },
            schemaVersion: number,
            styles: { [styleName: string]: Style },
        }|null
    },
}

In actuality, I think this should be a more generic Node type, something like:

export interface GetFileNodesResult {
    name: string,
    lastModified: string,
    thumbnailUrl: string,
    version: string,
    err?: string,
    nodes: {
        [nodeId: string]: {
            document: Node<NodeType>, // <-- here
            components: { [nodeId: string]: Component },
            schemaVersion: number,
            styles: { [styleName: string]: Style },
        }|null
    },
}

or, if you wanted to add the ability to customize what's returned based on the IDs passed to getFileNodes, you could use generics like this:

export interface GetFileNodesResult<T extends Node<NodeType>> {
    name: string,
    lastModified: string,
    thumbnailUrl: string,
    version: string,
    err?: string,
    nodes: {
        [nodeId: string]: {
            document: T, // <-- here!
            components: { [nodeId: string]: Component },
            schemaVersion: number,
            styles: { [styleName: string]: Style },
        }|null
    },
}

// ...

function getFileNodesApi<T extends Node<NodeType> = Node<NodeType>>( // <-- uses all node types by default
  //...
): : Promise<GetFileNodesResult<T>>

Created a PR: #38

I've been developing a figma plugin at first and later on a tool to connect to figma, which led me here. For figma plugin developers, there are official types as @figma/plugin-typings. Using them felt intuitive while following their docs.

So, when using the types from this repo it felt a bit awkward as this is Node<'TEXT'> (which I am still using?!?) vs TEXT vs TextNode (which it is for figma plugins).

I was wondering, if they somehow can be aligned, as the properties from figma plugins are pretty much equal to what is available through the REST-API (or a subset). So, at least the names to make them sound equal?

As for the subset, if possible, they may even be picked? such as: type VectorNode = Pick<FigmaVectorNode, '...'>.

PS. That may even be a complete non-sense, time-wasting thing, ready to discard (and I'm totally fine with that). But it is in my head for a little while and I wanted to share it.

I would like to use the return type of the getFile call in a state but I can't, GetFileResult is not exposed on the lib. I must import it from figma-api/lib/api-types.

import { GetFileResult } from 'figma-api/lib/api-types'

const [file, setFile] = useState<GetFileResult | null>(null)

const figmaFile = await api.getFile(fileKey)
setFile(figmaFile)

It would be nice to expose thoses types publicly, and all the others as well.

missing the following type: Figma.Node<"COMPONENT_SET">;
in JSON: type:'COMPONENT_SET'

An INSTANCE node should inherits from FRAME, but in ast-types.d.ts the type is defined as a VECTOR :

export declare type INSTANCE<ComponentID = string> = VECTOR & {
    /** ID of component that this instance came from, refers to components table (see endpoints section below) */
    componentId: ComponentID;
};

The documentation for the FrameInfo type in the REST API website is not correct anymore (I suspect some recent changes to the API). See: https://www.figma.com/developers/api#library-items-types

According to the documentation page, the FrameInfo type should return properties with this format page_name. But the API calls for the "Components and Styles" endpoints actually return the properties with this format pageName.

My hunch is that they're migrating from snake_case to camelCase (but forgetting to update the documentation). I have already raised the issue with the Figma support (twice) with no luck, so I'll update the figma-api code anyway.

Hi, and thanks for this library. I however realized that we can pass some id's to getFileNodes method such that we can get results of type GetFileNodesResult which has a property called nodes with this interface:

{
    [nodeId: string]: {
        document: Node<'DOCUMENT'>,
        components: { [nodeId: string]: Component },
        schemaVersion: number,
        styles: { [styleName: string]: Style },
    }|null
}

Unfortunately, this is not always correct. It is possible to pass id's of other nodes and get results with a document property with a different type (not always DOCUMENT).

I hope it makes sense. I am working on a PR that should not break the current types. Please let me know what you think.

I have worked a little bit on the library (see #13) and it would have been super helpful to have a suite of tests to be sure that I was not breaking anything during the refactoring. I want to collect here some ideas, to see if we can come up with something that can be useful.

Jest testing + Mocks
Potentially we could use Jest to test the API calls (using mocks for the API responses), even if I am not 100% sure how much this would be helpful (eg. we would not notice a change a break in the code if Figma updates their APIs, because we're mocking them). Any ideas of possible workaround or approaches for testing API interfaces?

Figma file
We could have a Figma file (.fig) attached to repo, that one can import and then, updating the file ID/key in a specific file, one can run a set of tests against that file (eg. during the development I created a script that listed/posted/deleted comments to a file). Of course, we can't test every API method (eg. we would need a team) but maybe a subset of calls could be tested directly using the real Figma APIs (we test the requests me make, we tests the responses we receive). We could even go further, and create a Figma user (with an email owned by @Morglod) with a base license (in that case I suppose you can test even more calls).

Any other ideas, suggestions?

/cc @honzatmn maybe you have also some ideas :)

https://www.figma.com/developers/api#variables

The new "Variables" feature born in Figma, can we add it to this really usefull package ?

Question in title. Thanks!

The API receives componentSets, but the type is not defined so it shows as an error in typescript.

Now matches API docs here: https://www.figma.com/developers/api#files

Hi, thank you so much for this fantastic library! I noticed that GetFileResult.components has this type:

/** An arrangement of published UI elements that can be instantiated across figma files */
export interface Component {
    /** The key of the component */
    key: string;
    /** The name of the component */
    name: string;
    /** The description of the component as entered in the editor */
    description: string;
}

However, here's the JSON output of a request:

{
    "componentSetId": "2:135",
    "description": "",
    "documentationLinks": [],
    "key": "<redacted>",
    "name": "name redacted"
}

You can see that "componentSetId" seems to be missing. Thanks!

Hi,
can you please publish the 1.6.0 version to npm? I see that there have been changes in the repo to update Axios to correct version, however that version haven't been yet published, as latest is still 1.5.5.

Thanks,
Tomas

The REST API documentation for the "FrameInfo" type is missing the "containingStateGroup" parameter, that is returned when the component is a variant within a component_set (see attached image):
https://www.figma.com/developers/api#library-items-types

I already raised the issue in the forum (https://forum.figma.com/t/missing-containingstategroup-parameter-in-documentation-for-frameinfo/2558) and filed a bug (twice). In the meantime I'll fix it on here.

This is actually an error in the Figma documentation, so I understand why the type is missing from the library. I've alerted Figma to the bug.

The StylesMap you can find at Node<'VECTOR'>.styles should also exist at Node<'FRAME'>.styles, at the very least. However I suspect that it should also be on other types as well; probably anything that you can set styles on. I've only verified so far that is returned in FRAME nodes.

Figma recently added the ability to parse bullet lists from the Figma API. To handle this, they added two new properties lineTypes and lineIndentations. They also updated their documentation.

This PR syncs the types with the new response.