{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/relay/issues/973","repository_url":"https://api.github.com/repos/facebook/relay","labels_url":"https://api.github.com/repos/facebook/relay/issues/973/labels{/name}","comments_url":"https://api.github.com/repos/facebook/relay/issues/973/comments","events_url":"https://api.github.com/repos/facebook/relay/issues/973/events","html_url":"https://github.com/facebook/relay/issues/973","id":142424157,"number":973,"title":"Synthesize tracked queries lazily","user":{"login":"wincent","id":7074,"avatar_url":"https://avatars.githubusercontent.com/u/7074?v=3","gravatar_id":"","url":"https://api.github.com/users/wincent","html_url":"https://github.com/wincent","followers_url":"https://api.github.com/users/wincent/followers","following_url":"https://api.github.com/users/wincent/following{/other_user}","gists_url":"https://api.github.com/users/wincent/gists{/gist_id}","starred_url":"https://api.github.com/users/wincent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wincent/subscriptions","organizations_url":"https://api.github.com/users/wincent/orgs","repos_url":"https://api.github.com/users/wincent/repos","events_url":"https://api.github.com/users/wincent/events{/privacy}","received_events_url":"https://api.github.com/users/wincent/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/facebook/relay/labels/mutations","name":"mutations","color":"bfd4f2"}],"state":"open","locked":false,"assignee":{"login":"wincent","id":7074,"avatar_url":"https://avatars.githubusercontent.com/u/7074?v=3","gravatar_id":"","url":"https://api.github.com/users/wincent","html_url":"https://github.com/wincent","followers_url":"https://api.github.com/users/wincent/followers","following_url":"https://api.github.com/users/wincent/following{/other_user}","gists_url":"https://api.github.com/users/wincent/gists{/gist_id}","starred_url":"https://api.github.com/users/wincent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wincent/subscriptions","organizations_url":"https://api.github.com/users/wincent/orgs","repos_url":"https://api.github.com/users/wincent/repos","events_url":"https://api.github.com/users/wincent/events{/privacy}","received_events_url":"https://api.github.com/users/wincent/received_events","type":"User","site_admin":false},"milestone":null,"comments":1,"created_at":"2016-03-21T18:00:03Z","updated_at":"2016-03-22T06:18:00Z","closed_at":null,"body":"(We already have an internal task for this — t10388334 for anybody watching along at home — but creating this issue to give it some external visibility, seeing as it was asked about [here](https://github.com/facebook/relay/issues/967#issuecomment-199382654)).\r\n\r\nAs part of #538, we want to change the way we do tracked queries, which currently result in substantial amounts of memory use over time. The basic idea is to do this in two steps at mutation time:\r\n\r\n1.Figure out what records in the store could be affected by a mutation by intersecting the fat query and the mutation config with what we have in the store. Mark those records as stale by moving them from `nodeData` to `cachedData`.\r\n2. (Possibly asynchronously/incrementally, after applying the optimistic update) find all query resolvers observing affected IDs and do a traversal of the resolver fragments to reconstruct what would have been in the tracked query.\r\n\r\nThere are a few potential \"gotchas\" that we will want to handle here, but that's the basic overview."},"comment":{"url":"https://api.github.com/repos/facebook/relay/issues/comments/199653471","html_url":"https://github.com/facebook/relay/issues/973#issuecomment-199653471","issue_url":"https://api.github.com/repos/facebook/relay/issues/973","id":199653471,"user":{"login":"eyston","id":187389,"avatar_url":"https://avatars.githubusercontent.com/u/187389?v=3","gravatar_id":"","url":"https://api.github.com/users/eyston","html_url":"https://github.com/eyston","followers_url":"https://api.github.com/users/eyston/followers","following_url":"https://api.github.com/users/eyston/following{/other_user}","gists_url":"https://api.github.com/users/eyston/gists{/gist_id}","starred_url":"https://api.github.com/users/eyston/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eyston/subscriptions","organizations_url":"https://api.github.com/users/eyston/orgs","repos_url":"https://api.github.com/users/eyston/repos","events_url":"https://api.github.com/users/eyston/events{/privacy}","received_events_url":"https://api.github.com/users/eyston/received_events","type":"User","site_admin":false},"created_at":"2016-03-22T06:18:00Z","updated_at":"2016-03-22T06:18:00Z","body":"First off, thanks!  Second off, feel free to ignore any / all of this -- I am just curious :).\r\n\r\nI'm not sure I follow why two steps.  If in (1) you are intersecting the fat query I'm not sure what (2) does (I'm assuming query resolvers are components subscribed to the store?).\r\n\r\nAs for gotcha's with (1) I'm aware of an issue currently handled by Relay where the store has a `null` value but the tracking query might be:\r\n\r\n```\r\nselectedTodo { text completed }\r\n```\r\n\r\nLooking at the store data only you wouldn't know `text` and `completed` were being tracked since `selectedTodo` was currently `null` (or at least that is my understanding).  Any other major gotcha's for intersecting the fat query with the store data itself?\r\n\r\nI previously had asked @josephsavona about the tracked queries and he mentioned performance was a big benefit.  I might not be fully understanding this, but are connections the performance driver here?  e.g. I have 100 edges in a connection, in order to intersect I don't want to have to traverse all 100 edges?  Or is that not how to handle the connection case anyways?\r\n\r\nDo abstract types pose a problem for intersecting or in all cases does Relay have the type information required stored in the store?"}}