Monthly Archives: January 2014

[TL;DR version: use cookies to store the results of async calls; render the results of past async calls immediately and then validate them after page-load.]

I’ve been working on SharePoint intranet site for a client that features, among other things, a stylized secondary navigation whose menu options are managed via a regular old custom list. The idea is that the client gets to control “their” site’s menu without affecting or being affected by the global navigation put out by IT.

(there is something incredibly subversive about adding a CEWP that points to an HTML file that loads some CSS and JS to fundamentally alter almost everything about a site’s behavior… but that’s for another post)

The code for this pretty simple:

Wait for the page to finish loading and make an async call to load up menu items from a list using REST or lists.asmx or whatever

The sore spot here is that every time anyone hits one of the site’s pages, that user’s web browser is reaching out to get items from the list. Once dev is complete and testing has proven things to be stable and complete, this call is unnecessary more than 99% of the time since the menu rarely changes. It also has a weird UI affect which is common in this brave new world of hyper-ajaxy web sites – the page renders and only then does the menu render. It’s jittery and distracting in my view. And jittery. So, caching.

I modified the logic thusly:

Look for a cookie in the browser that contains the menu as I last read it

If found, render it immediately. Don’t wait for the page to finish loading. (You need to make sure your HTML is strategically placed here, but it’s not hard to do).

Wait for the page to finish loading and make an async call to load up menu items from a list using REST or lists.asmx or whatever

Compare what I got against the cookie

If it matches, STOP

Otherwise, using jQuery, dynamically populate a bunch if <li>’s in a <ul>

Use CSS to do all the formatting

Profit!

Some of you are going to say, “hey! there’s no real caching going on here since you’re reading the menu anyway every single time.” And you’re right – I’m not giving the server any kind of break. But because the call is async and happens after the page’s initial HTML payload fully renders, it “feels” more responsive to the user. The menu renders pretty much as the page draws. If the menu happens to the change, the user is subjected to a jittery re-draw of the menu, but only that one time.

There are some ways to make this caching more effective and help out the server at the same time:

Put in a rule that the “cookie cache” is valid for a minimum of 24 hours or some other timeframe. As long as there is no expired cookie, use the cookie’s menu snapshot and never hit the server.

Well … that’s all that come to mind right now :).

If anyone has any clever ideas here I’d love to know them.

And lastly – this technique can be used for other stuff. This client’s page has a number of data-driven things on various pages, many of them changing relatively rarely (like once a week or once a month). If you target specific areas of functionality, you can give a more responsive UI by pulling content from the local cookie store and rendering immediately. It feels faster to the user even if you’re not saving the server any cycles. You can save the server cycles by deciding on some conditions and triggers to invalidate this local cookie cache. That’s all situational and artsy stuff and really the most fun :).

Intro

I’ve been exploring unit testing and test coverage for JavaScript as I work on a new SharePoint app for SharePoint online in the Office 365 suite. The obvious research paths led me to Qunit.js and right after that, to Blanket.js.

QUnit let me set up unit tests and group them into modules. A module is just a simple way to organize related tests. (I’m not sure I’m using it as intended, but it’s working for me so far with the small set of tests I have thus far defined).

Blanket.js integrates with Qunit and it will show me the actual lines of JavaScript that were – and more importantly – were not actually executed in the course of running the tests. This is “coverage” – lines that executed are covered by the test while others are not.

Between setting up good test cases and viewing coverage, we can reduce the risk that our code has hidden defects. Good times.

Qunit

Assuming you have your Visual Studio project set up, start by downloading the JavaScript package from http://qunitjs.com. Add the JavaScript and corresponding CSS to your solution. Mine looks like this:

Figure 1

As you can see, I was using 1.13.0 at the time I wrote this blog post. Don’t forget to download and add the CSS file.

That out of the way, next step is to create some kind of test harness and reference the Qunit bits. I’m testing a bunch of functions in a script file called “QuizUtil.js” so I created an HTML page called “QuizUtil_test.html” as shown:

If you look across the top, you have a few options, two of which are interesting:

Hide passed tests: Pretty obvious. Can help your eye just see the problem areas and not a lot of clutter.

Module: (drop down): This will filter the tests down to just those groups of tests you want.

As for the tests themselves – a few comments:

It goes without saying that you need to write your code such that it’s testable in the first place. Using the tool can help enforce that discipline. For instance, I had a function called “getTodayAsCaml()”. This isn’t very testable since it takes no input argument and to test it for equality, we’d need to constantly update the test code to reflect the current date. I refactored it by adding a data input parameter then passing the current date when I want today’s date in CAML format.

The Qunit framework documents its own tests and it seems pretty robust. It can do simple things like testing for equality and also has support for ajax style calls (both “real” or mocked using your favorite mocker).

Going through the process also forces you to think through edge cases – what happens with “undefined” or null is passed into a function. It makes it dead simple to test these scenarios out. Good stuff.

Coverage with Blanket.js

Blanket.js complements Qunit by tracking the actual lines of code that execute during the course of running your tests. It integrates right into Qunit so even though it’s a whole separate app, it plays nicely – it really looks like it’s one seamless app.

This is blanket.js in action:

Figure 4

Figure 5

(You actually have to click on the “Enable coverage” checkbox at the top [see Figure 3] to enable this.)

The highlighted lines in Figure 5 have not been executed by any of my tests, so I need to devise a test that does cause them to execute if I want full coverage.