This question already has answers here:
What is the use case for var in ES6?
(5 answers)
Closed 6 years ago.
If I write ECMAScript 6 code, what will be better: to use only let and const or var too? I know the difference between them, but I want to know can I not use var at all? What is the best practice?
I wanted to ask about Code Style
Nice write-up by Eric Elliot on this topic: (Emphasis mine)
[...] I favor const over let in ES6. In JavaScript, const means that the identifier can’t be reassigned. (Not to be confused with immutable values. Unlike true immutable datatypes such as those produced by Immutable.js and Mori, a const object can have properties mutated.)
If I don’t need to reassign, const is my default choice over let because I want the usage to be as clear as possible in the code.
I use let when I need to reassign a variable. Because I use one variable to represent one thing, the use case for let tends to be for loops or mathematical algorithms.
I don’t use var in ES6. There is value in block scope for loops, but I can’t think of a situation where I’d prefer var over let.
Related
This question already has answers here:
Array.of vs "[ ]". When to use Array.of over "[ ]"?
(3 answers)
What’s the difference between "Array()" and "[]" while declaring a JavaScript array?
(19 answers)
Closed 4 years ago.
For example,
let x = [1,2,3,5];
is equivalent to:
let x = Array.of(1,2,3,4,5);
(Unless I'm missing an important detail, which is why I'm asking the question)
You could also mix these with spread ... syntax and variables and thus other arrays. To me, it seems Array.of() has more overhead. Would Array.of() have to parse an arguments object into another array?
I know there's also new Array() as others have before questioned here, but that has a different semantic purpose, so I don't see this question as a duplicate to that.
As I see it now, Array.of() and [ ] seem redundant. The function's intent does seem more explicit on the former, but the latter's intent is simple enough to not be misunderstood.
So to summarize:
When is one preferable over the other?
Why does Array.of() exist when JavaScript survived without it for so long?
And, what're the differences of these two methods, if any? Would there be any needless overhead?
This question already has answers here:
Using 'let' as a variable name is not throwing any errors in google v8
(3 answers)
Closed 4 years ago.
I'm wondering how a variable can be named let because let is a reserved word in JavaScript!
var let = "a value"; // this works!!!
let let = "a value"; // luckily this doesn't work
While reading about reserved words in JavaScript I used this website and also I checked this Stackoverflow question (see the answer of art4theSould) and both of them (also the same thing in other sources) said that let -as everyone can image- is a reserved word in JavaScript.
According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#Keywords, let is only reserved when it's found in strict mode code.
This appears to be for backward compatibility, so that pre-ES6 code is not impacted. This explains why let let is not allowed: since you're actually using the new let keyword, pre-ES6 compatibility is obviously not a concern.
This question already has answers here:
Multiple arguments vs. options object
(10 answers)
Closed 6 years ago.
I've really fallen in love with object destructuring with functions.
For example:
var buyCoffee = function({sku, pounds = 1, roast:''}){
...more code
}
buyCoffee({sku:"cf-100" pounds: 3, roast: 'dark'});
buyCoffee({sku:"cf-101" roast: 'light'});
Pros
Flexibility similar to the args object.
Added Simplicity
Not required to put in parameters if I don't need them.
Cons
Variable names are locked all the way through.
Currying would be much harder.(From what I can tell)
Significant computational overhead vs traditional params ?
Harder to test?
I'd like to know what downsides there are to this approach? Is this a good pattern to use as I grow as a developer? Just looking for some wisdom from the trenches on this. Thoughts?
Variable names are locked all the way through.
Not at all. You can easily destructure into arbitrary variables:
function({sku:mySku, pounds:localPounds=1, roast=''}) { … // use mySku, localPounds and roast
Currying would be much harder.
There's no currying when you pass objects anyway. And currying with optional parameters is always hard.
Potential computational overhead?
Depends on what you compare it against.
This question already has answers here:
Why is extending native objects a bad practice?
(9 answers)
Closed 8 years ago.
I want to make some utility functions for which the obvious place is as a method on some core objects
e.g.
Math.sum = function(arr) {
var total=0;
for ( x in arr)
{
total+= parseFloat(arr[x]);
}
return total;
}
I know that extending core types such as Array is generally considered a bad idea (although I'm not clear on the reasons for that). Would extending the Math object be an equally bad idea?
Obviously I can collect these functions elsewhere, it just seems logical to me that they should reside on the core objects.
First of all you can rewrite the core sum method if it exist.
Other point could be the fact that other people will not now about your implementation.
Better way to wrap this object and to add your own implementation.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
JavaScript: Class.method vs. Class.prototype.method
I am trying to understand object in JavaScript. Now I see a lot of different uses of object, and I can not tell them apart.
For starters, the biggest thing I want to know is what the difference is between these two
Something.prototype.else = function(){
return 6;
}
And
Something.else = function(){
return 6;
}
Both look different, but they are used in the same way, or am I mistaken.
If you are familiar with other programming languages you can consider the second one to be a static method.
The first one you need an instance of the object in order to use it:
var x = new Something();
x.else();
The second one you do not need an instance in order to use it:
Something.else();
It's a good question for an interview for a JavaScript job indeed.
The difference is that Something.else overrides Something.prototype.else. That is, if you have both, Something.else will be used.
The advantage of having prototypes is that a prototype can be shared between many objects to reduce memory usage, make monkey-patching easier and implement prototype-based inheritance.