Test Driven JavaScript Development- P18

Test Driven JavaScript Development- P18:This book is about programming JavaScript for the real world, using the techniquesand workflow suggested by Test-Driven Development. It is about gaining confidencein your code through test coverage, and gaining the ability to fearlessly refactor andorganically evolve your code base. It is about writing modular and testable code. Itis about writing JavaScript that works in a wide variety of environments and thatdoesn’t get in your user’s way.
Nội dung trích xuất từ tài liệu:
Test Driven JavaScript Development- P18 13.4 The Comet Client 333 The test fails as dispatch was not called. To fix this we need to parse the responseText as JSON and call the method from within the success callback of the request. A very naive implementation can be seen in Listing 13.63. Listing 13.63 Naive success callback to the poller function connect() { if (!this.url) { throw new TypeError(Provide client URL); } if (!this.poller) { this.poller = ajax.poll(this.url, { success: function (xhr) { this.dispatch(JSON.parse(xhr.responseText)); }.bind(this) }); } } At this point I am expecting this test to still fail in at least a few browsers. As we discussed in Chapter 8, ECMAScript 5th Edition, EcmaScript5 specifies a JSON object. However, it is not yet widely implemented, least of all in older browsers such as Internet Explorer 6. Still, the tests pass. What’s happening is that JsTestDriver is already using Douglas Crockford’s JSON parser internally, and because it does not namespace its dependencies in the test runner, our test accidentally works because the environment loads our dependencies for us. Hopefully, this issue with JsTest- Driver will be worked out, but until then, we need to keep this in the back of our heads. The proper solution is of course to add, e.g., json2.js from json.org in lib/. I mentioned that the above implementation was naive. A successful response from the server does not imply valid JSON. What do you suppose happens when the test in Listing 13.64 runs? Listing 13.64 Expecting badly formed data not to be dispatched test should not dispatch badly formed data: function () { this.client.url = /my/url; this.client.dispatch = stubFn(); this.client.connect();Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 334 Streaming Data with Ajax and Comet this.xhr.complete(200, OK); assertFalse(this.client.dispatch.called); } Furthermore, if we expect the server to return JSON data, it would probably be a good idea to indicate as much by sending the right Accept header with the request. 13.4.5.1 Separating Concerns The current implementation has a code smell—something that doesn’t feel quite right. JSON parsing doesn’t really belong inside a Comet client; its responsibili- ties are delegating server-side events to client-side observers and publishing client- side events to the server. Ideally the transport would handle correct encoding of data. As I’ve mentioned more than a few times already, the ajax.request should be refactored such that it provides an object that can be extended. This would have allowed us to extend it to provide a custom request object specifi- cally for JSON requests, seeing as that is quite a common case. Using such an API, the connect method could look something like Listing 13.65, which is a lot leaner. Listing 13.65 Using tailored JSON requests function connect() { if (!this.url) { throw new TypeError(Provide client URL); } if (!this.poller) { this.poller = ajax.json.poll(this.url, { success: function (jsonData) { this.dispatch(jsonData); }.bind(this) }); } } Granted, such a poller could be provided with the current implementation of ajax.request and ajax.poll, but parsing JSON belongs in ajax.poll as little as it does in ajax.cometClient.Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 13.4 The Comet Client 335 13.4.6 Tracking Requests and Received Data When polling, we need to know what data to retrieve on each request. With long polling, the client polls the server; the server keeps the connection until new data is available, passes it, and closes. Even if the client immediately makes another request, there is a risk of loosing data between requests. This situation gets even worse with normal polling. How will the server know what data to send back on a given request? To be sure all the data makes it to the client, we need a token to track requests. Ideally, the server should not need to keep track of its clients. When polling a single source of data, such as “tweets” on Twitter, a reasonable token could be the unique id of the last tweet received by the client. The client sends the id with each request, instructing the server to respond with any newer tweets. In the case of the Comet client, we expect it to handle all kinds of data streams, and unless the server uses some kind of universally unique id, we cannot rely on the ...