Wednesday, November 27, 2013

Damn extra comma and IE

Regex to check for extra comma in js (because IE will choke)

(?s),\s*\}

Tuesday, September 17, 2013

Javascript Named Function Expressions

BLUF: unless you are working in a controlled environment (intranet) where supported browsers only expose the identity of Named Function Expressions to the inner scope of the function (for recursive calls) they should be avoided.

In reading Test Driven Javascript Development there was discussion around using named functions to improve debugging. To provide some context lets look at this example.
Which produces the following stack trace

Those anonymous functions are hard to track down.

If we use named function expressions instead, then we can improve this stack trace.






Only problem is now we have to deal with browser quirks associated with named function expressions.

Here are a couple of great reads on the topic. 1, 2

Ideally the name would only be available to the inner scope (for the purpose of calling itself recursively) and then the rest of the issues would go away. Until then the issues outweigh the benefits. Fortunately Function Declarations will give us the same debugging benefit and won't create a new function every call.

This is hard to follow, though not significantly harder to read than before. To fix that I would recommend using promises (off topic).

The biggest issue is actually not apparent in the example, and that is that the scope context has changed. While our closure used to have access to parameters of our parent function,  it no longer does (in other words, Third could access variables from First and Second.

The simplest recommendation - and that from the books author, is to use a function declaration inside the closure.

Another option albeit off topic is to pass those variables into the function making them more explicit. Again this is where promises can help as each function can add / modify the model. (Or return different objects, etc.)



In summary, unless you are working in a controlled environment (intranet) where supported browsers only expose the identity of Named Function Expressions to the inner scope of the function (for recursive calls) they should be avoided.  

Javascript Function Constructors

BLUF: using Function constructors gives you greater control of the scope context and enables you to create dynamic functions but should be reserved for optimizations only as they are unintuitive to most developers and will rarely be worth it. 

In  reading Test Driven Javascript Development I discovered that you can create functions using the Function constructor.

This is in contrast to Function Declarations.

and Function expressions
So for an example, notice the Function below (log is just a supporting function)
Notice:

  1. I had to pass log in by reference. We are used to this being added the the scope context automatically and in the case of Function that isn't the case.  
  2. The last string argument is the function body. 
  3. The first string argument contains multiple parameters separated by commas
  4. You can also pass in as separate arguments as shown by p4. 
I expect that this would rarely be used as it adds complexity and instead should be considered a tool for optimization because you have greater control over scope context / closure. 

It also could be used to dynamically build functions but IMO most of the time you will be able to achieve this with normal syntax and so this should be reserved for improving performance.