Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
While in VS Code, I hit the tab after typing return and the VS Code Intellisense auto-completed "return" to "this.return".
I've never seen this before and cannot find any documentation on it.
Does anybody know if this is actually a thing, or if VS Code possibly lost it's marbles.
Note: the object I was working in does not have any properties or functions called "return".
Well, an object could have a property called return:
const obj = {
return: () => { console.log('↩️'); }
};
obj.return();
Were you in the context of a class that had a return property, or maybe its superclass did?
(Honestly it seems more likely VS Code was just being weird.)
You can run console.log("this", this) in most modern browsers this will return the JSON data of this (the variable this refers to the current instance of declared object FYI), and console.log(typeof(this.return)) and it will likely return function (if you get undefined just change it from this.return to return;)
Likely the object either has a property called return that is a function, or something has gone wrong in the autocomplete.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
When creating functions, What is the main difference and when to use these ways of creating a function?
onSubmit = () => {}
functionsName : () => {}
There's no difference in the creation of the functions, just what is done with the function once it's created:
Your onSubmit one creates a function and assigns it to an in-scope variable.
Your functionsName one creates a function and assigns it to an object property. This form is only valid within an object initializer. (Outside of an object initializer, it's not a syntax error, but it's just a labelled statement and the function is never assigned to anything.)
You may find another answer of mine useful as well. It's a rundown of various ways of creating functions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
According to the Google JS style guide getters and setters are discouraged. Why is this?
Mozilla JS Object docs explicitly advocate using getters and setters in js. I'm confused about the discrepancy.
Because using getters and setters can, from the outside point of view be confusing.
Lets say I make an object myObject with the following property status. That property uses a getter and computes a result for getting it. Example:
const status = myObject.status;
const open = status.open; // true
const color = status.color; // "blue"
Now everytime I use myObject.status it looks like I just access a direct property but it s not true. In fact it calls a function that can take a lot of computation.
Now another person who didn't implement myObject comes in and does this
const open = myObject.status.open; // true
const color = myObject.status.color; // "blue"
And it works ! But a potentially compute heavy function is called twice instead of once.
It can also have side effects (worst situation, don't use getters with sideeffects), and when you look for a bug and you don t know where it comes from it is hard to tell.
That is why some recommend to use const status = myObject.getStatus();. It is an explicit function call.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Given the following function:
function lamePathValidator(path) {
if (typeof path !== 'string') {
throw new TypeError(`Invalid path "${path}": should be a string.`);
}
return path;
}
Is it considered bad practice if occasionally it's being used without storing the return value to a variable?
...
lamePathValidator('./data');
...
Edit: The only use case in which I need the returned value, is for property assignments in constructors, such as:
constructor(basepath) {
this._basepath = this._validatePath(basepath);
}
I could of course write:
constructor(basepath) {
this._validatePath(basepath)
this._basepath = basepath;
}
The former block is more concise though.
Edit #2:
I could also pass constructor parameters to a _validateAll(params) function since none of them are actually being altered in any way. It's "validate", not "sanitize" after all. :)
There are lots of functions that return data that is not always useful, but sometimes is. In those cases not storing the output when you don't need it makes sense.
However if the return value is never useful then you shouldn't be returning it in the first place. In your example function the path is not altered so there is no reason to return it, the calling code already has it.
A function can return a value if required. It is not mandatory to return some value from it. In your case there is no need to return any value.
Read the js function documentation here
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
var main = function() {
this.first = this;
}
console.log(new main().first);
The code is here :
Object is creating recursively ,I didnot understand why the console not throwing any error.
Please tell me if there is any concept behind this.
You are making it circular (not recursive) with this:
this.first = this
It's the same as if you do:
var obj = {}
obj.first = obj
obj.first will reference obj. That in javascript is like saying obj.first is obj. Really the javascript engine isn't creating infinite objects, just an object that has a reference to itself.
It doesn't throw an error simply because the value of a property of an object is allowed to be a reference to that object. You don't have any actual recursion here.
You'd only get an error if, for example, you wrote a function to recursively crawl down through the properties of the object, but that would be because you had too many functions on the stack and the self reference would only be a factor that led to that.
There's no recursion here. What you have is a self reference (where one object stores a property that refers to itself).
Your code does not throw because console.log() is smart enough to handle self references. It doesn't infinite loop just because of a self reference as it is coded to specifically handle that situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
function Foo(p)
{
if(!check(p))
{
return false;
}
//do something
}
If above code is acceptable? Because Foo() sometimes will return false, but most time no value return.
If this isn't a good code, what's good?
If sometimes your function returns a value, and sometimes it returns undefined, then it will come down to how you capture what it returns, a type mismatch could halt your code.
If you just call your function like so
Foo(thisvalue);
then there will be no problems; however, if you call your function
var thisvariable = Foo(thisvalue);
then you need to be careful with how you try to use thisvariable.
Functions in javascript will always return some value. If you don't specify it it returns undefined. I think it is acceptable as long as you specify this behavior. Note that in your case, it is not a good idea to return false since you won't be able to distinguish it easily from undefined (you have to use === comparison)