Can't index a property value by its type when using Typescript

[RianGallagher]

It'd be nice to be able to access the "type-specific data" in a property object without caring about what the type actually is. For example, to be able to do this: const propertyData = property[property.type]. Typescript won't let you do this though because there is no index signature on the PropertyValue type.

If I try to write this function:

const getAllPropertyData = async () => {
    const databaseId = process.env.NOTION_DATABASE_ID ?? "";
    try {
        const { results } = await notion.databases.query({ database_id: databaseId });
        const propertiesData = results.map(({ properties }) => {
            // type PropertyValue
            const property = properties.Day;

            // "number" | "title" | "rich_text" | "select" ... etc.
            const type = property.type;

            // Type error here.
            const propertyData = property[type];

            return propertyData;
        });
        return propertiesData;
    } catch (error) {
        console.error(error);
    }
}

I'll get the following type error:
Element implicitly has an 'any' type because expression of type '"number" | "title" | "rich_text" | "select" | "multi_select" | "date" | "formula" | "rollup" | "people" | "files" | "checkbox" | "url" | "email" | "phone_number" | "created_time" | "created_by" | "last_edited_time" | "last_edited_by"' can't be used to index type 'PropertyValue'.

But the type always refers to another key in the property object as it states in the working with databases guide here. It makes sense then to have an index signature to allow you to access property data in this way.

I think something like this would work:

export interface PropertyValueBase {
    [typeSpecificDataKey: string]: RichText[] | number | Select // ... etc. ;
    id: string;
    type: string;
}

[blackmad]

Hey Rian -

I'm not sure what you're describing would achieve the type safety we're aiming for in the library, since your function would return a bunch of property data that can no longer be type-discriminated.

You can see an example of how we imagine this being used in a type-safe way at https://github.com/makenotion/notion-sdk-js/blob/main/examples/generate-random-data/index.ts

I'm open to other suggestions!

[danecando]

I'm pretty new to TypeScript but I don't understand why this shouldn't work either. If the related key in the block is always the same name as the type, seems like I should be able to access it using the key. I get that TypeScript doesn't know that but is there not a simple way to handle this? My first instinct is that it's an issue with the structure of the objects; that they should use a common prop name to store the data.

(clearly im still in the why can't we just use js phase of my ts journey) :)

[blackmad]

Okay I understand now what you're trying to do. Let me consult the typescript sages.

…

On Thu, May 27, 2021 at 12:34 PM Dane Grant ***@***.***> wrote: I'm pretty new to typescript but I don't understand why this shouldn't work either. If the related key in the block is always the same name as the type, I should be able to access it with a key. I get that TypeScript doesn't know that but is there not a simple way to handle this? [image: Screen Shot 2021-05-27 at 12 30 55 PM] <https://user-images.githubusercontent.com/3721977/119863515-a337d480-bee7-11eb-9b84-a160169215c4.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMZMHELYCRY4MYTUPPCF3TPZX7VANCNFSM45KTSVLQ> .

[EnixCoda]

I had similar issues using this SDK. And attempted to solve with TS type prediction in PR #115

@RianGallagher Would you take a look at the PR and let me know your thoughts from the aspect of an user? Thank you :D