Customize ID behavior

[houdinigraphql]

Customize ID behavior

[AlecAivazis]

I've started working on this in a branch and need a place to hold onto some thoughts:

• a single type could have multiple keys that are used together to form a record's ID
• the node query used by refetches should be configurable to allow for specific queries that look up a value.

My current thinking for the API:

config  = {
    defaultKeys: ['_id'], 
    types: { 
        User: { 
            keys: ['email'],
            // not quite sure what to call this 
            refetch: {
                queryField: 'user',
                arguments: (user) => {email: user.email}
            },
        }
    }
}

[lyle]

My Vote...

I like the idea of the defaultKeys - not sure of the name... it might be better to call it defaultKeyField: '_id' as I think the default should only be a single.

And for entity key I would go with keyFields

config  = {
    defaultKeyField: '_id', 
    types: { 
        User: { 
            keyFields: ['email'],
            // not quite sure what to call this 
            refetch: {
                queryField: 'user',
                arguments: (user) => {email: user.email}
            },
        }
    }
}

[AlecAivazis]

Thanks for the input @lyle! I'm also unsure about the names. I was hoping that "key" implied "keyField" but I guess if a user is coming up to a config file for the first time it might not be totally clear. I'll think on it some more.

Do you have any ideas for what I could use instead of "refetch"? In case it wasn't clear from the example, that object configures the query that the cache uses to support things like paginated fragments. For any object that implements the Node interface, that object would take the default value:

{
    //...
    refetch: { 
        queryField: 'node',
        arguments: node => ({ id: node.id })
    }
}

edit: I just realized I named the internal function that looks up the keys for a field keyFieldsForType() so i guess I agree with you subconsciously 🤦