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.
Related
This question already has answers here:
Why would you ever call .call() on Observable functions?
(3 answers)
Closed 5 years ago.
I have seen in the ngrx source, for example, that they use call.
pluck.call(route.params, 'id');
What is the difference between the above code and:
route.params.pluck('id');
When do we need to use call when using observables?
When you use call, you explicitly give the context of the function - to which this refers in the function.
See the difference between calls.
function test() {
console.log(this.n);
}
const obj = { n: 'Your Name' };
test();
test.call(obj);
Better. Thanks to #cartant. Based on his comment editing the answer
The call mechanism was recommended for library authors, so that they don't patch Observable.prototype with operators that library clients could accidentally depend upon. If a library were to patch and later remove operators, client code could break. It was tedious for library authors and it can now be avoided using pipe and pipeable/lettable operators
This question already has an answer here:
How do I access an object property dynamically using a variable in JavaScript?
(1 answer)
Closed 5 years ago.
Testing my ability to write code in JavaScript and Node (perhaps a bit of a monumental effort) and also attempting to understand standards.
I want to dynamically change an attribute in an object as in this examnple:
var parms = {
host:'',
port:'',
user:'',
pass:''
};
parms.user='foo';
parms.pass='bar';
console.log(parms.user);
setParm = function(param,value){
parms.param = value;
}
setParm('user','baz');
console.log(parms.user);
However, I'm completely blind. I feel as though I may be in a blind alley in terms of what I think is possible versus what is actually workable.
You are passing the property as a string, so accessing with . won't work. One solution I know is that you can use dict-like indexing:
var parms = {
host:'',
port:'',
user:'',
pass:''
};
parms.user='foo';
parms.pass='bar';
console.log(parms.user);
setParm = function(param,value){
parms[param] = value;
}
setParm('user','baz');
console.log(parms.user);
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:
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.
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.