Default Parameters in JavaScript(designpepper.com)
designpepper.com
Default Parameters in JavaScript
http://designpepper.com/blog/drips/default-parameters-in-javascript
8 comments
One problem though it that it's modifying the opts parameter so it might create unwanted side-effects.
var myopts = {foo: 1}
foo(myopts)
console.log(myopts) // => {foo: 1, bar: "baz"}As with _.extend, _.defaults takes 1..n arguments and will fold 2..n into 1. If you fear callers will pass in an object they rely on for function options (doubtful, but why not) you can just write:
This also fixes the issue of a caller passing in no options (or "null" or "undefined") without having to add an `||`
var actual_opts = _.defaults({}, opts, {
// Your defaults here
});
This also fixes the issue of a caller passing in no options (or "null" or "undefined") without having to add an `||`
zimbatm notes an issue with altering the object you're provided, but there's actually a bigger one with this method: if the function is called with no options or `null` or `undefined` it will blow up with a rather unhelpful message.
Unless you have a truly huge set of options, I'd suggest using
Unless you have a truly huge set of options, I'd suggest using
var final_opts = _.defaults({}, opts, defaults);
This is a good point, and unfortunately it means that most of the advantage of using _.defaults() goes by the wayside. It just becomes a matter of personal preference. Thanks for the tip.
> This is a good point, and unfortunately it means that most of the advantage of using _.defaults() goes by the wayside.
How and why? I don't consider mutating the original object to be an advantage of using _.defaults, unless the object is completely under your control and you're essentially calling `_.defaults(this, defaults)`.
How and why? I don't consider mutating the original object to be an advantage of using _.defaults, unless the object is completely under your control and you're essentially calling `_.defaults(this, defaults)`.
Thanks for pointing out the _.defaults method. If I have time, I'll update the article to include that point.
Library agnostic version if anyone cares for it: https://gist.github.com/jonjaques/3036701
for many cases the following will work well enough:
function(arg1, arg2) {
arg1 = arg1 || "foo";
arg2 = arg2 || "bar";
}
arg1 = arg1 !== 0 ? 1234 : arg1;
arg1 = arg1 !== false ? "foo" : arg1;
arg1 = arg1 !== null ? "foo" : arg1;
arg1 = arg1 !== "" ? "foo" : arg1;
You are correct, except this will not work in the significant case where any falsy value is passed ("", 0, null, NaN... I exclude undefined because that is the intended behavior) or with booleans.
A slightly more verbose, yet hardy syntax would go like this:
A slightly more verbose, yet hardy syntax would go like this:
function foo(arg1, arg2){
arg1 = arg1 === undefined ? "foo" : arg1;
arg2 = arg2 === undefined ? "bar" : arg2;
}
already was updating :)
If you don't mind, I need to correct the form a little. If this becomes a pattern in a big application you are losing performance for nothing.
In fact you're just compacting an if:
In fact you're just compacting an if:
if (arg1 == null) { // check for both `undefined` and `null`
arg1 = 'default';
}
// compacted to:
arg1 = arg1 == null ? 'default' : arg1;
(arg1 == null) && (arg1 = 'default');The assignment is hardly a performance concern in modern javascript. I imagine if we set up a jsperf test case we would find the difference negligible and the ops/s in the 10s of millions range. This is not the kind of thing that slows down JS apps.
I could see, using the if statement form, that you might have a programmer decide to compact it and drop the brackets - and then you might fall in the trap where somebody thinks they're in an if block when they're really not. Happens pretty often.
In addition, I don't know if you really would want to check for null. I usually just check for undefined, which would be the absence of any provided value (as opposed to a provided value that just happens to be null). Of course, it depends on the app.
In addition, I really don't like using short-circuited boolean ops for assignment. The style is grating to me - it's not immediately obvious what it's really doing. To each his own.
EDIT: Created a simple jsperf test. Difference is about 6.8%, but we're talking hundreds of millions of ops/s. Not the kind of stuff that matters outside of raw benches.
http://jsperf.com/ternary-vs-if-for-default-args
I could see, using the if statement form, that you might have a programmer decide to compact it and drop the brackets - and then you might fall in the trap where somebody thinks they're in an if block when they're really not. Happens pretty often.
In addition, I don't know if you really would want to check for null. I usually just check for undefined, which would be the absence of any provided value (as opposed to a provided value that just happens to be null). Of course, it depends on the app.
In addition, I really don't like using short-circuited boolean ops for assignment. The style is grating to me - it's not immediately obvious what it's really doing. To each his own.
EDIT: Created a simple jsperf test. Difference is about 6.8%, but we're talking hundreds of millions of ops/s. Not the kind of stuff that matters outside of raw benches.
http://jsperf.com/ternary-vs-if-for-default-args
I'm not talking about single occurence of the "bad" pattern. If you multiple it to the occurence in a whole code base... well you get the point. That's why underscore and coffee-script treat default assignement that way.
Interestingly, in JSPerf, sometimes the ternary pattern is actually faster than the if statement. Must be something V8 is doing.
If you want to allow undefined to be passed as a valid non-default value for a trailing parameter, you can also use arguments.length to determine how many arguments were explicitly specified.
var foo = function(a, b) {
if (arguments.length < 2) {
b = 'some default value';
}
// ...
};I wish jQuery's setter methods worked this way. It's too easy to accidentally turn a setter into a getter.
It should be noted that ES6 implements default parameters, so they are coming to javascript soon: http://wiki.ecmascript.org/doku.php?id=harmony:parameter_def...
but not reliably to a browser for some quite considerable time.
I thought this was common knowledge? If you've read any JS library code you'd have seen this before. I'm not sure what the 'best' library to study is these days- I remember there was HN discussion about it and someone mentioned underscore.js since it was simple utilities.
It is certainly common knowledge in some groups, but not in others. There are plenty of people who are primarily designers who know just a little JS, as well as developers in other languages who have learned just enough JS to get by.
Or you could just use CoffeeScript.
The difference between _.defaults and _.extend is significant; _.extend will overwrite all properties in the first object with those defined in the second (and third, fourth, etc.), while _.defaults will only overwrite properties that are null or undefined.
The advantage is, using _.defaults, that you aren't passing a defaults object around within the body of your method and using it as if it were the opts, or reassigning to yet another var (see `finalParams` defined in the last example). This makes the method a bit clearer.