{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/graphql/issues/165","repository_url":"https://api.github.com/repos/facebook/graphql","labels_url":"https://api.github.com/repos/facebook/graphql/issues/165/labels{/name}","comments_url":"https://api.github.com/repos/facebook/graphql/issues/165/comments","events_url":"https://api.github.com/repos/facebook/graphql/issues/165/events","html_url":"https://github.com/facebook/graphql/issues/165","id":149555937,"number":165,"title":"Literal aliases (not necessarily fields)","user":{"login":"geospofford-anaplan","id":14062522,"avatar_url":"https://avatars.githubusercontent.com/u/14062522?v=3","gravatar_id":"","url":"https://api.github.com/users/geospofford-anaplan","html_url":"https://github.com/geospofford-anaplan","followers_url":"https://api.github.com/users/geospofford-anaplan/followers","following_url":"https://api.github.com/users/geospofford-anaplan/following{/other_user}","gists_url":"https://api.github.com/users/geospofford-anaplan/gists{/gist_id}","starred_url":"https://api.github.com/users/geospofford-anaplan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/geospofford-anaplan/subscriptions","organizations_url":"https://api.github.com/users/geospofford-anaplan/orgs","repos_url":"https://api.github.com/users/geospofford-anaplan/repos","events_url":"https://api.github.com/users/geospofford-anaplan/events{/privacy}","received_events_url":"https://api.github.com/users/geospofford-anaplan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-04-19T19:20:25Z","updated_at":"2016-07-02T21:56:37Z","closed_at":null,"body":"(I'm building a GraphQL query service outside the context of Relay, just as an interesting retrieval specification layer for API which might be machine-to-machine as well as GUI-driven.)\r\n\r\nGiven than an object may implement multiple interfaces, if a collection is of a union of types (like subclasses of a superclass) there is not necessarily a long-term-stable type id for each object in the collection that a client can use.  As a simple example, you may have physical and non-physical items in your shopping basket: all have id, description, and price, but only physical items have pictures. Pets are physical items that have lifespans. (We're not shipping pets, this is for in-store use only.) A pet is both animal and physical item. \r\n\r\nTo put the client fully in charge of what it cares about for type identification, one vehicle would be to allow the client to specify literals for aliases. I'm not saying there aren't other ways to handle this particular use case, only that this illustrates a single use case for the capability. In the following, one request can see 'physical' as the type for cart contents, while another could see 'pet' called out specifically.\r\n\r\nThis is completely analogous to selecting constant column expressions in SQL, eg. `select 'foo' from myTable`\r\n\r\n```\r\n{\r\n  cartContents {\r\n    id description price\r\n    type : 'generic'\r\n    ... on physicalItem {\r\n      picture (size: 'small')\r\n      type: 'physical'\r\n    }\r\n}\r\n```\r\nvs\r\n```\r\n{\r\n  cartContents {\r\n    id description price\r\n    type : 'generic'\r\n    ... on physicalItem {\r\n      picture (size: 'small')\r\n      type: 'physical'\r\n       ... on pet {\r\n         type: 'pet'\r\n         age\r\n       }\r\n    }\r\n}\r\n```"},"comment":{"url":"https://api.github.com/repos/facebook/graphql/issues/comments/230123875","html_url":"https://github.com/facebook/graphql/issues/165#issuecomment-230123875","issue_url":"https://api.github.com/repos/facebook/graphql/issues/165","id":230123875,"user":{"login":"geospofford-anaplan","id":14062522,"avatar_url":"https://avatars.githubusercontent.com/u/14062522?v=3","gravatar_id":"","url":"https://api.github.com/users/geospofford-anaplan","html_url":"https://github.com/geospofford-anaplan","followers_url":"https://api.github.com/users/geospofford-anaplan/followers","following_url":"https://api.github.com/users/geospofford-anaplan/following{/other_user}","gists_url":"https://api.github.com/users/geospofford-anaplan/gists{/gist_id}","starred_url":"https://api.github.com/users/geospofford-anaplan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/geospofford-anaplan/subscriptions","organizations_url":"https://api.github.com/users/geospofford-anaplan/orgs","repos_url":"https://api.github.com/users/geospofford-anaplan/repos","events_url":"https://api.github.com/users/geospofford-anaplan/events{/privacy}","received_events_url":"https://api.github.com/users/geospofford-anaplan/received_events","type":"User","site_admin":false},"created_at":"2016-07-02T21:56:37Z","updated_at":"2016-07-02T21:56:37Z","body":"It's a question of where object type is coupled to the use of type information. If I have an interface that is implemented by 12 specific types, then `__typename` will return one of 12 specific strings that the client needs to map to the interface, and if the server decides to implement a 13th then doesn't the client code need to update accordingly? Similar for unions. I may be missing an `instanceof` capability apart from the type name switching provided by fragments, but **one simple case** is to indicate a generic rather than specific type in the query result as opposed to putting the detail logic in the result consumer.\r\n\r\nA literal facility is much broader in utility than just type switching, though that was the driver in the use case. `__typename` is limited to returning a server-defined string, whereas a literal would not be. (I suppose I have only been thinking about scalar literals, but no reason to disallow object literals too.) \r\n\r\nA literal can be defined by the query generator for use by the consumer when they are separated. I realize that part of the Relay philosophy is to connect generation and consumption but I think that's not the only use case for GraphQL. In this case, we want decision logic like this to happen pre-consumer and not in the consumer. The decision might not be a type switch but something that is performed by the query generator unrelated to the type of the object, but to the context of the specific request.\r\n\r\nSince this allows client-specified query results, which can be a vector of denial-of-service, I'm happy if supporting it is controlled by server-side option or an option of specific classes/interfaces/unions."}}
{"actor":{"display_login":"geospofford-anaplan"}}