These are some of the common idioms I find myself using again and again. I am going to keep this as a live document and will update as I discover more useful idioms.
Disclaimer: I’ll be using the Underscore library in all of my examples
- Array.join to concatenate strings
- Minimize use of if/else blocks by creating object hashes
- Make the paramter value be of any type: string | number | array | function
- Use IIFE to compute values on the fly
Use Array.join to concatenate strings
It is quite common to build html in strings, especially when you are writing a custom formatter or just plain building simple views in code. Lets say you want to output the html for 3 buttons:
1 2 3 4 5
This works, but consider the alternate version, where you build the strings as elements of an array and join them using
1 2 3 4 5 6 7
It reads a little better and can almost look like real-html with the identation ;)
Minimize use of if/else blocks by creating object hashes
Lets say you want perform a bunch of different actions based on the value of a certain parameter. For example, if you want to show different views based on the weather condition received via an AJAX request, you could do something like below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
You will notice in
showWeatherView(), there is lot of imperative noise with if/else statements. This can be removed with an object hash:
1 2 3 4 5 6 7 8 9 10 11
If you want to support more views, it should be easier to add it to the
viewMap hash. The general idea is to look at a piece of code and think in terms of
code. What part is pure data and what part is pure code. If you can make the separation, you can easily capture the
data part as an object-hash and write simple
code to loop/process the data.
As a side note, if you want to eliminate the use of
switch statements, you can have Haskell-style pattern-matching with the matches library.
Make the parameter value be of any-type
When you are building a simple utility library/module, it is good to expose an option that can be any of
function type. This makes the option more versatile and allows for some logic to be executed each time the option value is needed. I first saw this pattern used in libraries like HighCharts and SlickGrid and found it very natural.
Let’s say you want to build a simple formatter. It can accept a string to be formatted using one of the pre-defined formats or use a custom formatter. It can also apply a chain of formatters, when passed as an array. You can have the API for the formatter as below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
As an addendum to a multi-type parameter, it is also common to normalize the parameter value to an object hash and remove type differences.
Use IIFE to compute on the fly
Sometimes you just need a little bit of code to set the value of an option. You can either do it by computing the value separately or do it inline by writing an Immediately Invoked Function Expression (IIFE):
1 2 3 4 5 6 7 8 9
In the above code there is little bit of computation for the title text. For simple code like above it is sometimes best to have the logic right in there for improved readability.