Warning: The magic method SFML_Singleton::__wakeup() must have public visibility in /home/public/wp-content/plugins/sf-move-login/inc/classes/class-sfml-singleton.php on line 72
{"id":264,"date":"2018-06-15T07:45:30","date_gmt":"2018-06-15T13:45:30","guid":{"rendered":"http:\/\/www.munderwood.ca\/?p=264"},"modified":"2018-06-15T07:45:59","modified_gmt":"2018-06-15T13:45:59","slug":"side-effects-of-js-data-http-and-async-operations","status":"publish","type":"post","link":"https:\/\/www.munderwood.ca\/index.php\/2018\/06\/15\/side-effects-of-js-data-http-and-async-operations\/","title":{"rendered":"Side effects of js-data-http and async operations"},"content":{"rendered":"

Recently I encountered a rather strange scenario, wherein I created two different\u00a0findAll<\/span>\u00a0operations using the js-data-http<\/a> adapter for a js-data<\/a> query, only to see two identical network requests emitted. The root of the problem turned out to be that I was creating a single object to hold the query options and reusing it across requests, in combination with the fact that js-data-http mutates its parameters in place during asynchronous operation.<\/p>\n

\/\/ This will find posts from user 4 twice!\r\nconst opts = { force: true };\r\nstore.findAll('post', { userId: 2 }, opts);\r\nstore.findAll('post', { userId: 4 }, opts);<\/pre>\nHere is a brief demonstration of the behaviour<\/a>. In the fiddle two requests are made to the JSONPlaceholder test API<\/a>, for posts from different users. When the responses are received, they both contain the posts for the user specified in the second query.<\/p>\n
The simple solution is to not use the same object for multiple requests.<\/p>\n
\/\/ This works as expected.\r\nstore.findAll('post', { userId: 2 }, { force: true });\r\nstore.findAll('post', { userId: 4 }, { force: true });<\/pre>\nWhy does this work?<\/h2>\nOr more interestingly, why doesn’t<\/em> the first method work?<\/p>\nPart of the process js-data-http uses is to move the query object passed as the second argument to\u00a0findAll<\/span>\u00a0into a new property of the third argument,\u00a0options.params<\/span>. This is because the function that actually makes the network request expects any query parameters to be specified in\u00a0options.params<\/span>, at least in part because the query parameter format used in GET requests is not the same as the JSON-formatted query syntax<\/a> used by js-data. So some<\/em> amount of transformation is required between what we pass in to js-data and what it sends to the server.<\/p>\n
However, because the transformation is done in place, js-data mutates the object that is passed into it. The chain of events goes roughly as follows, due to the asynchronous promise-based nature of the findAll<\/span>\u00a0 operation.<\/p>\n
\nAn\u00a0options<\/span>\u00a0object is created in your code.<\/li>\n
The first\u00a0findAll<\/span>\u00a0process, Process A, begins, with Query A and Options A.<\/li>\n
The second\u00a0findAll<\/span>, Process B, begins, with Query B and Options B.<\/li>\n
Process A moves its query parameters onto the options<\/span>\u00a0object, so that\u00a0options.params<\/span>\u00a0contains (a transformed version of) Query A.<\/li>\n
Process B moves its<\/em> query parameters onto the same <\/em>options<\/span>\u00a0object. Now\u00a0options.params<\/span> contains Query B, but it is still also being referenced from Process A!<\/li>\n
Process A makes its network request, based on Query B.<\/li>\n
Process B makes its network request as well, also based on Query B.<\/li>\nTwo responses to the second query are received.<\/li>\n<\/ul>\nMoral of the story<\/h2>\nThis turned out to be a very simple solution to a problem that required a very lengthy debugging process, all because I made the incorrect assumption that a third-party library would not have undocumented side effects on the variables that I passed into it. It was complicated by the fact that the side effects were themselves dependent on a different parameter, and of course by the async nature of the operations, but at its heart that was the issue.<\/p>\n","protected":false},"excerpt":{"rendered":"Recently I encountered a rather strange scenario, wherein I created two different\u00a0findAll\u00a0operations using the js-data-http adapter for a js-data query, only to see two identical network requests emitted. The root of the problem turned out to be that I was creating a single object to hold the query options and reusing it across requests, in … [Read more…]<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,13],"tags":[17],"_links":{"self":[{"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/posts\/264"}],"collection":[{"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/comments?post=264"}],"version-history":[{"count":7,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/posts\/264\/revisions"}],"predecessor-version":[{"id":271,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/posts\/264\/revisions\/271"}],"wp:attachment":[{"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/media?parent=264"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/categories?post=264"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.munderwood.ca\/index.php\/wp-json\/wp\/v2\/tags?post=264"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}