Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Ability to retrieve a UID in a mutation resolver #18

Open
pixeldrew opened this issue Sep 7, 2019 · 1 comment
Open

Question: Ability to retrieve a UID in a mutation resolver #18

pixeldrew opened this issue Sep 7, 2019 · 1 comment

Comments

@pixeldrew
Copy link

pixeldrew commented Sep 7, 2019

I'm trying to use the uid as a key to mutate data in my resolver, since the uid only lives in the directive and is output via a graphql query i'm having a hard time designing the best way to link the uid back to the data outside of the graph. ie.

const schema = gql`
directive @uid(from: [String]) on OBJECT

type Element @uid(from: ["email", "name"]) {
  name: String!
  email: String!
}

type Query {
  elements: [Element]
}

mutation DeleteElement($uid:String) {
  deleteElement(uid:$uid) : Boolean
}`;

const elements = [{name:"bill", email: "blah@blah.com"}]
const resolvers = {
  Query: {
    elements: () => elements
  },
  Mutations: {
    deleteElement: (parent, {uid}) => {
      // how am I supposed to find the index in elements without redoing the hash work you do in the resolve function of UniqueIdDirective
   
    }
  }
}

I understand I could redo the work that is done here UniqueId.visitObject()fields[].resolve
but this seems like a hack.

Should this uid be used for anything but caching? Is there another way to resolve the uid outside of the graph? Has anyone done something else to resolve this problem?

@czystyl
Copy link
Member

czystyl commented Sep 9, 2019

The lib was created mainly for support better caching on the client-side.

You are passing arguments to @uid directive so you can predict the unique.

What we could do is to pass created UUID to the context or root resolver?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants