{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/relay/issues/125","labels_url":"https://api.github.com/repos/facebook/relay/issues/125/labels{/name}","comments_url":"https://api.github.com/repos/facebook/relay/issues/125/comments","events_url":"https://api.github.com/repos/facebook/relay/issues/125/events","html_url":"https://github.com/facebook/relay/issues/125","id":102051734,"number":125,"title":"getFatQuery – necessary? Too knowledgable?","user":{"login":"mhart","id":367936,"avatar_url":"https://avatars.githubusercontent.com/u/367936?v=3","gravatar_id":"","url":"https://api.github.com/users/mhart","html_url":"https://github.com/mhart","followers_url":"https://api.github.com/users/mhart/followers","following_url":"https://api.github.com/users/mhart/following{/other_user}","gists_url":"https://api.github.com/users/mhart/gists{/gist_id}","starred_url":"https://api.github.com/users/mhart/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mhart/subscriptions","organizations_url":"https://api.github.com/users/mhart/orgs","repos_url":"https://api.github.com/users/mhart/repos","events_url":"https://api.github.com/users/mhart/events{/privacy}","received_events_url":"https://api.github.com/users/mhart/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/facebook/relay/labels/discussion","name":"discussion","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-08-20T03:20:19Z","updated_at":"2015-08-20T22:56:21Z","closed_at":null,"body":"Probably stemming from a lack of understanding, but is there a reason that `getFatQuery` needs to be so fine-grained and nested and not just rely on the server to send back the fields that have changed (possibly with a little help from the client by just specifying a query root or similar)?\r\n\r\n(I'm thinking of things like https://github.com/facebook/relay/blob/master/examples/todo/js/mutations/MarkAllTodosMutation.js#L26-L37 )\r\n\r\nIt feels like the client needs to have a lot of knowledge of what fields the server will actually change, which makes it harder to change behaviour on the server without also updating the clients – I get this is generally true for traditional REST APIs, but I kinda feel like GraphQL could be smarter than that?\r\n\r\nPossibly the same is true for `getConfigs` – is there no way for the server to signal to the client what it did?"},"comment":{"url":"https://api.github.com/repos/facebook/relay/issues/comments/133206304","html_url":"https://github.com/facebook/relay/issues/125#issuecomment-133206304","issue_url":"https://api.github.com/repos/facebook/relay/issues/125","id":133206304,"user":{"login":"yuzhi","id":1166086,"avatar_url":"https://avatars.githubusercontent.com/u/1166086?v=3","gravatar_id":"","url":"https://api.github.com/users/yuzhi","html_url":"https://github.com/yuzhi","followers_url":"https://api.github.com/users/yuzhi/followers","following_url":"https://api.github.com/users/yuzhi/following{/other_user}","gists_url":"https://api.github.com/users/yuzhi/gists{/gist_id}","starred_url":"https://api.github.com/users/yuzhi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/yuzhi/subscriptions","organizations_url":"https://api.github.com/users/yuzhi/orgs","repos_url":"https://api.github.com/users/yuzhi/repos","events_url":"https://api.github.com/users/yuzhi/events{/privacy}","received_events_url":"https://api.github.com/users/yuzhi/received_events","type":"User","site_admin":false},"created_at":"2015-08-20T22:56:21Z","updated_at":"2015-08-20T22:56:21Z","body":"@taion They may look similar in that example because the optimistic payload is very thorough, but keep in mind that optimistic responses are completely optional. Mutations can have simpler optimistic response or no optimistic updates at all. The optimistic response also doesn't tell Relay store where to add edges or what to do with fields that are just a list of ids that are meant to be deleted. One potential thing we might not need from the optimistic payload is the `story.id` since that can be inferred from the `getConfigs`, but I'm not sure how the rest are being overlapped.\r\n\r\n@mhart Fragments in mutations are mainly a way to declare what the mutation might need to generate the optimistic payload, which might also include fields that don't need to be in the `fatQuery` or be part of the `getConfigs`. It's similar to how components has fragments to declare what it needs to generate the view. What do you think it is duplicating or does it just look similar to the other ones in the examples?"}}