David's Tech Blog

I’ve been noticing comments about race conditions in async code, most specifically javascript used server side as in node.js. As someone who has written more lines of blocking code than I care to think about, I can relate to the angst of people trying to make the mind bending transition to thinking asynchronously. I think that just the name “race condition” is an artifact of the age of blocking code. There are no race conditions in the async world. The term is about bugs in blocking code. In async code there are no races, because it isn’t about getting done in order, its about getting done when you’re done. Thinking in terms of avoiding race conditions isn’t about bugs, its thinking in the wrong paradigm. There is no spoon.

Anyone who has written more than a handful of lines of Javascript has found a need to find out the type of a variable. A quick search on their favorite search engine or in their reference book turns up typeof, which indeed tells you the type of a variable. It works great, except if you’re looking for arrays, null, or NaN.

The typical way that typeof is used is in tests:

var my_string = "llamas";
var my_number = 42;

if( typeof my_string === "string" ){ 
   // do something with my string
}

if( typeof my_number === "string" ){ 
   // do something with my number
}

This type of test works well for strings, numbers, functions, and undefined. You most often see it used for the first three of these. Most people check for undefined more directly:

if( something === undefined){
   // treat it like it isn't defined
}

This is particularly useful if you are wanting to know whether an argument for your function was included when the function was called.

var myfunction = function(foo){
    if(foo === undefined) foo = "bar";
    // now we can do something with it, knowing that it is defined.
}

So, what do you do if you have a variable that might be an array or an object, and you need to know which it is? Using typeof doesn’t help, because it tells you that it’s an object either way. It is an object either way, actually, but that’s not very helpful.

The easiest test between a non-array object and an array is by checking for length. Arrays have a length, non-array objects do not. So if typeof says its an object, and its length !== undefined, then it is an array.

NaN is a special confusing case. NaN is a value representing “Not a Number,” except that of course typeof says that NaN is a number. It is useful for working with messed up math and bad dates, both of which are best detected as quickly as possible. NaN is returned by several Javascript methods such as parseFloat and parseINt. NaN is never equal to any number, including itself. So to test for NaN you use the aptly named isNaN(testValue), which returns true if testValue is indeed not a number.

Putting all this in a simple function that you can use to find the type of something is fairly easy:

function(thing){
  return (thing === null) ? "null" : 
    (typeof thing == "object" && thing.length !== undefined) ? "array" : 
    (typeof thing == "number" && isNaN(thing)) ? "NaN" :
    typeof thing;
}

If there’s a law against abusing the ternary operator anywhere, that is sure to break it.

One other thing worth noting about testing variable types is testing booleans. Using typeof we get “boolean” as the response if the operand is actually (===) true or false. So the following variables are all boolean, according to typeof:

  var yes = true;
  var no = false;
  var another = ( 1 == 2 );
  var tistrue  = ( yes !== undefined );

However NaN, null and undefined, even though they test as false, aren’t boolean according to typeof. All of these test as false:

( null )
( undefined )
( false )
( NaN )
( 1 == 2 )

But only one of them (false) has a typeof Boolean.

I recently wrote a post reviewing Google Apps Scripts. Buried in that post was a code snippet that showed my workaround for the lack of CSS or global styling in Google Apps Scripts.  The problem is that it is in the middle of my venting about some of this service’s limitations, and most people will likely overlook it.  So I’m editing that post and putting that piece of it here on its own.

Google Apps Scripts doesn’t allow you to work with CSS at all.  Instead, they provide a mechanism for setting in-line styles as style attributes to your HTML elements.  This is done by using the setStyleAttribute method, which is available on several of the classes.  This method takes two string arguments, a style name (“line-height”, “font-size”, and so on) and the value for that style setting (10px, 1.1em, 90%, ‘bold’, etc).  These aren’t CSS styles, they are inline style attributes.  Its been a while since I’ve worked with this attribute, and I may have forgotten some of what I once knew about using these.   I found that it didn’t work well to set a “font” attribute to “110% bold serif,” you needed to set that with three separate setStyleAttribute calls.  You can chain these, which is still verbose but does make it somewhat easier.

var label = app.createLabel("Text for the label").setStyleAttribute("font-size","110%").setStyleAttribute("font-weight","bold");

That works fine, except that you end up with LOTS of setStyleAttribute calls throughout your script, and if you want to change something uniformly you’ll be copy and pasting all over the place.  That gets old fast.  So I wrote a little function as a workaround for this issue, and it seems to work reasonably well.

First, I created an object to hold my global styles

var appStyles = {
  "tableheaders": {
    "font-weight": "bold",
    "font-size": "1.1em",
    "padding": "0px 5px 0px 5px",
    "text-decoration": "underline"
  } ,
  "listtable": {
    "border-top": "1px solid #CCC" ,
    "margin-top": "6px",
    "width": "99%"
  },
  "helptext": {
    "font-size": ".9em",
    "color": "#999"
  }
};

Actually, pasting that in I realized that you don’t need the quotes around the property names. My fingers have been typing too much JSON. That does work as it appears there though, and its what I’ve tested, so I’ll leave it for now.

 

The next part is the function to apply the styles, uncreatively called applyStyles:

function applyStyles(element, style){
  if(!element.setStyleAttribute || !(style in appStyles)) return element;
  for(var attribute in appStyles[style]){
    element.setStyleAttribute(attribute, appStyles[style][attribute]);
  }
  return element;
}

Many of the classes in Google Apps Scripts support setStyleAttribute, but not all. So we’re checking before we try to use it. Then, we iterate over the attributes in the appStyles object and apply the styles that match the passed in style name to the element. You can pass any element that supports setStyleAttribute to this function and it will be styled, and instead of copied styles all across your script you have one place to tweak the style headings.

This isn’t an ideal solution, and if I was going to use it much I’d probably do more with it. However, it is a start at a way to turn unmanageable styles in Google Apps Scripts into something you can work with and maintain.