Today I will be evaluating AngularJS’s template request provider defined in templateRequest.js. At first glance, I didn’t see much that would need updates, but I had noticed some coding that would be interesting to learn. I have removed all the documentation from the source and included it below for our starting point.

The first thing I do is apply a best practice defined for AngularJS and move the embedded function from this.$get to a named function and supply the new name. Not inserting the function definition with the list of dependencies for dependency injection was made to help increase the readability of the code and a good one to follow.

this.$get = ['$exceptionHandler', '$templateCache', '$http', '$q', '$sce', templateProvider];

The following line of code is something new to me. From what it looks like, the author is accessing a “property” on a function. The property is used to keep track of the number of pending requests. The assignment to the function name itself implies that this is possibly a singleton usage. I have not come across a situation that required something like this, I have used private methods and properties as discussed in Douglas Crockford’s document on private methods.

handleRequestFn.totalPendingRequests++;

Moving on we come across an if statement that is overriding the passed in value for tpl with the trusted version if one exists. There is also a long comment describing why the code exists, which an adequately named method would be better.

function getTrustedResourceIfExists(tpl, $templateCache, $sce) {
    if (!isString(tpl) || isUndefined($templateCache.get(tpl))) {
      tpl = $sce.getTrustedResourceUrl(tpl);
    }
  }

We have another area where are getting the transform response and then acting on that response. All of the functionality is related to getting the response so let’s extract it to a separate method so we can reduce the number of things this function is doing.

function getTransformResponse($http) {
  var transformResponse = $http.defaults && $http.defaults.transformResponse;

  if (isArray(transformResponse)) {
    transformResponse = transformResponse.filter(function(transformer) {
      return transformer !== defaultHttpResponseTransform;
    });
  } else if (transformResponse === defaultHttpResponseTransform) {
    transformResponse = null;
  }

  return transformResponse;
}

The final code is listed below with all the changes for review.

Let’s review what we have learned by walking and splitting this code:

  1. Best practices are defined to help the maintenance of your code.
  2. We found an interesting way to define and use a singleton variable by adding a name the function. JavaScripts’ language allows for this type of dynamic addition and can be a useful tool, but also can decrease the readability to others who are not familiar with JavaScript tricks.
  3. Extracting functionality to separate methods helps reduce the complexity and readability of the code.

That is it for today, tune in next week for what lessons we can learn from our next splitting code session.

Remember, if you have a snippet of code that you would like refactored on split code leave a comment below with the code snippet or link to where to obtain it.