Docs

This page contains some general docs that apply to more than just one particular part of Fork.

Design

Optional Function Arguments

Optional function arguments can be a bit ugly. If I have a function like

function foo(a, b, c) {}

where a is required and b and c are optional then I might end up writing a call like this so I can use c but not b.

foo("asdf", null, "fff");

This is unappealing if more than one optional arguments exists and is insufferable if many options are possible. If one optional argument is made obsolete then a null has to exist forever in it's place. If another option is added then it must be added at the end of the long list of arguments.

There are a couple places in the FORK API that have a options object as the last argument. This could be slightly bulky compromise at times but at least the null hole problem doesn't ever happen. So someone could make the above call

foo("asdf", {c:"fff"})

I've used this pattern in the new FORK.Ajax() and FORK.Event.addListener() functions and think both uses are strong improvements over the Yahoo! UI API for the same functions. The change in new FORK.Ajax() was a cleanup by removing an awkward fourth parameter and the change in FORK.Event.addListener() added functionality virtually for free.

Resolving Element Arguments

It is relatively common to see the following pattern in the Fork API functions.

FORK.Mutate.update = function(el, html) {

  if (typeof el == 'string') {el = document.getElementById(el);}
  
  // real business of function...
  
};

This element resolving pattern allows you to call the function with the first argument either an HTMLElement object or with the string id by which the element can be found.

This element resolving line of code is repeated and some might argue should be factored out to a separate function. There are two drawbacks to this. The first problem is the performance hit of turning a simple conditional to a function call. The second is deciding where to put this function and there is no clearly good answer. It might naturally fit in "dom.js" but having to include that file when only the one line is needed would be poor design. It could go in a file called "fork.js" with the namespace definition (var FORK={};) however the first problem would still persist and another file would have to be downloaded. I can see both sides of the arguments and don't think either side is very compelling. I want to avoid a "fork.js" file and so have decided to keep the element resolving line repeated and in place.