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

Mutation Payloads and Relations #114

Closed
tim-field opened this issue Sep 15, 2016 · 6 comments
Closed

Mutation Payloads and Relations #114

tim-field opened this issue Sep 15, 2016 · 6 comments
Milestone

Comments

@tim-field
Copy link
Contributor

tim-field commented Sep 15, 2016

Lets say I have a comment table related to my posts table.

Post {
  commentNodesByPostId
}

And my post page uses commentNodesByPostId to show a list of comments.
I want to add a comment, so in another component I call the generated;

insertComment mutation

The problem I'm having is that payload of this mutation doesn't include the post that I'm related to, and because of this I haven't been able to work out how to get Relay to correctly update it's local store.

Relay's RANGE_ADD seems to need post in the top level of the mutation payload in order to work. If it did I could follow along with this example;

https://facebook.github.io/relay/docs/guides-mutations.html#range-add-example

And have a fatQuery that looked like;

fragment on InsertCommentPayload {
        post { commentNodesByPostId },
        commentEdge,
}

Without post in the payload I can't get Relay to update correctly ( I can't find an incarnation of FIELDS_CHANGE to force the correct update either )

I imagine this is really common use case, how are people getting around this?

@calebmer
Copy link
Collaborator

Yeah, a similar issue is this #110 and this keeps popping up from time to time in the chatroom. I’m not sure of a good way to fix this (short of praying Relay 2 gets released quickly 😉), I’d like to hear if other people have found workarounds.

I think what we’ll need to do is just flatten out some of the fields of the return type unfortunately. I don’t like having to do that, but I agree that might be the best/only way to make Relay happy.

If anyone is interested in writing a proposal, I’ll see what I can do to implement it 👍

@tim-field
Copy link
Contributor Author

tim-field commented Sep 15, 2016

I think what we’ll need to do is just flatten out some of the fields of the return type unfortunately

Yes this seems to be what's needed. Could we do this for all foreign key fields in the table being mutated? How difficult would this be? If you don't have time could you point me in the general direction in the code base.

@calebmer
Copy link
Collaborator

The fields would be defined in the createInsertMutationField’s payload. It should probably be as easy as taking a GraphQL field off of the type returned by createTableType(table) and adding them to the payload. So something like:

fields: {
  [table.getFieldName()]: {
    type: tableType,
    description: `The inserted ${table.getMarkdownTypeName()}.`,
    resolve: ({ output }) => output,
  },

  post: tableType.getFields().commentNodesByPostId,

You might also need to wrap resolve though.

@ferdinandsalis
Copy link
Contributor

I cam a across the same problem and have yet to find a way around i :) Will let you know if I do.

@tim-field
Copy link
Contributor Author

Ok so we just need this bit post: tableType.getFields().commentNodesByPostId to be automatic for all foreign keys in the table. With this in place Relay mutations will be much easier!

@calebmer
Copy link
Collaborator

I’m going to close this as its in the PostGraphQL 2.0 beta 🎉

Specifically, all related tables are including in create mutations, update mutations, delete mutations, and procedure mutations that return a table.

Start playing with the pre-release, the final release should be out really soon. Tell me what you think! 👍

npm install -g postgraphql@next
postgraphql

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

3 participants