I have a function in a component that calls another function and both have the same name.
It works, both of the functions run
I would like to know why does it work (see my assumption below)?
A followup question, what if i want to call the external function recursively should i use this.myMethod()?
Is this pattern safe to use?
Example:
myMethod(){
const {myMethod} = this.props;
if(typeof myMethod == 'function'){ // i was sure this will check the external myMethod func
myMethod(); // i was sure it will call the external myMethod func.
}
// what if i want to call to the external "myMethod" func (recursively)?
}
I assume that the engine is searching for a function named myMethod inside the body of external myMethod (lexical scope?) and it finds it.
can anyone confirm this assumption?
EDIT
Just to make my question more clear about how common and safe this pattern is.
Let's say i have a component of Item and it has an onTouch prop of PropTypes.func, i would like to run some internal logic inside my own function and then run the function that received via the props as a callback or something similar.
Should i bother finding a new name to my internal function like onInternalTouch or is it safe to stick with the same name onTouch?
onTouch(){ // is this common practice?
const {onTouch} = this.props;
// ... internal component logic
onTouch();
}
onInternalTouch(){ // or should i bother finding a new name?
const {onTouch} = this.props;
// ... internal component logic
onTouch();
}
Please note that component myMethod method is defined as object (class) method so to call it from any component method you have to use this.myMethod(). There's no possibility that calling myMethod() (without this.) inside any component method will call component method with the same name. If you didn't define myMethod variable inside the method and tried to call it you'd get an error telling that myMethod is not defined. So such code will give you mentioned error:
myMethod(){
myMethod();
}
When you call a function JS firstly try to find such function defined in closest scope (in your case inside component myMehod method body), if there's no such function JS moves to next (parent) scope (in your case it'd be the same scope in which react component is defined) and tries to find it again and so on.. But it's imporant that component methods are not defined in any of those scopes but are defined as class methods so you have to use this.myMethod to tell JS that you mean method defined on 'this' object. Generally to call any object method you have to use method name associated with an object.
Situation would be different if it wasn't component methods but normal functions. Consider such code:
//here is outer scope
function myMethod() {
//here is inner scope
myMethod(); // this will call function defined in outer scope
}
myMethod();
it would give you 'too much recursion' error - there is no myMethod function defined in inner scope so JS uses function defined in outer scope.
If you now override outer function with inner variable with the same name there would be no errors:
//here is outer scope
function myMethod() {
//here is inner scope
var myMethod = function() {
console.log(12);
}
myMethod();
}
myMethod();
In above code variable defined in inner scope overrides function defined in outer scope so JS finds myMethod in inner scope and even doesn't try to search for myMethod in outer scope.
Back to you question - yes, if you want to call the external function recursively you have to use this.myMethod().
Question edit update:
As for your question regarding naming practice both options will work. It's just a matter of code readability and good practices. I'd personally use different meaningful names. In your example I'd use e.g. handleTouch for method name and touchCallback for prop name. Generally it's more difficult to understand code using the same names for different functions - you have to pay more attention to grasp what function does and where it comes from (is it component method or function passed as prop?).
Generally it's easy to get confused if you use the same names especially if someone else reads your code. Of course it's totally ok if two or more components have method with the same name if they do similar job but if one function calls another function IMO they should have different names because they have different purpose which should be reflected in their names.
Related
I have a class that I use to load external resources via an XMLHttpRequest (this is for WebGL) so I'm loading models, shaders etc. My plan was to put a loading display up whilst it did all these requests and then when it's finally complete I want it to run a callback function from the original function that created it. However, I'm getting strange results when I try to run that call back (such as it has no access of any of the objects within the class that did the loading).
I can get around this problem by passing "this" into the loading class and then doing
self = this;
promise(self.callback());
but I'd much rather specify the function that I want it to callback to after its done the loading. Does anyone know if this can be done? My code looks like this:
Main Class
this.loadingClass = new LoadingClass(this.LoadingComplete, resources);
Main.prototype.LoadingComplete = function()
{
// Returns undefined if i specify the callback function instead of just "this"
console.log(this.loadingClass.anyOfTheMembersOfThisClass);
}
Loading Class
LoadingClass = function(callback, resources) {
..
Promise.all(resources).then(function(loadedResources)
{
..
callback();
});
}
When you pass the function object as
(this.LoadingComplete, resources)
the object to which it was bound, will not be passed. So, only the function object LoadingComplete is passed to LoadingClass and when it is invoked as
callback()
the this value will be undefined (in strict mode).
To fix this,
you need to bind the this object, like this
new LoadingClass(this.LoadingComplete.bind(this), resources)
if your environment supports ES2015's Arrow functions
new LoadingClass(() => this.LoadingComplete(), resources);
In both these cases, when the LoadingComplete is invoked from LoadingClass, the this will be retained.
You are detouching callback (read about "this") function from the root object, so of course it loses context. Specify bindingContext explicitly with Function.prototype.bind method:
this.loadingClass = new LoadingClass(this.LoadingComplete.bind(this), resources);
I'm start working with existing rails application, and I found something i don't understand. Every js function (write as coffe) was declared in followed style.
this.functionA = function(){}
and then invoke like:
functionA()
There wasn't any namespace, so all of functions was assigned to window object.
I removed this because i thought that it is not necessary, but I get error that functionA() does not exist. Why I get this error? And is it a reason to declare function in above style?
I have a clarification in using IIFs in javascript .
I have downloaded a javascript file called called test.js as follows and I have got following questions after googling IIFs:
define(function () {
(function (window) {
this.test = function() {};
Test.prototype.function1 = function(){
//Do something
},
function Delete(){
//Code to Delete
}
window.Delete = Delete;
})(window);
});
I do have the following questions:
Is the line,
this.test = function() {}; a constructor?
If so can I have 2 constructors in a single file like for example:
this.test = function() {};
this.test2 = function() {};
And also, why would I need a constructor when I know that this is an automatically invoked file where everything gets executed initially itself.
Is this a private function?
Test.prototype.function1 = function(){
//Do something
},
Does this not get automatically? Should I need to create an object of the test and then invoke it?
Is this a public function?
function Delete(){
//Code to Delete
}
window.Delete = Delete;
The last line of the above says that . If it is so then whats the difference between first and second function?
What is keyword window here?
It's worth noting that this code will fail with an error, as Test is undefined, and you can't set the prototype property on undefined.
In JavaScript, any function can be a constructor. It's up to how you use it. You can add functions and properties to the .prototype property of any function, and any objects created from it using new will get them from the prototype chain. In your case, this.test = function(){} doesn't look like a prototype.
There's no such things a "public" or "private" functions in JavaScript, there's only what's exposed via return out of the function (or in your case, by using the global window object, which is considered bad practice) If the Test function is exposed somewhere, then Test.prototype.function1 is also exposed. All prototype methods are "public".
Yes, sort of. Like I said, "public" or "private" isn't a thing in JavaScript. You created a function and placed it on the window object, which is global. Essentially, you've made the function global.
window is the global browser object. Although when used like this (function(window) { ... })(window), the first window is the name of the parameter, (and any instances of window inside the function reference to that parameter, and the second one (passed to the function call), is the global window object.
Further reading:
The Revealing Module Pattern
I'm using the FB.Event.subscribe() observer model to find out when a user logs in. This method takes two arguments, a string containing the thing to watch, and callback function.
I'm following several events that handle the event the same way, so I've set up the callback function as a pre defined method and passed this to FB.Event.subscribe() like this:
Controller.prototype.go = function() {
FB.Event.subscribe('auth.login', this.fbHandleStatusChange);
FB.Event.subscribe('auth.logout', this.fbHandleStatusChange);
}
Controller.prototype.fbHandleStatusChange = function(response) {
// Doesn't work
this.otherFunction();
}
Controller.prototype.otherFunction = function() {
alert('hello');
}
Unfortunately this means that I loose access to 'this' within the scope of fbHandleStatusChange, obviously I don't want to start coding references to concrete versions of Controller!
I'm guessing I'm passing the function incorrectly?
Thanks.
In JavaScript, this is defined entirely by how a function is called, not where it's defined. This is different than some other languages. (JavaScript doesn't have methods, it just has functions and some syntactic sugar that makes them look like methods sometimes.) So although you're passing in your function correctly, Facebook doesn't know about your object instance and can't set this correctly when calling your function.
Check the FB.Event.subscribe docs to see if it offers a way to say what "context" to use to call the event handler function. It may offer a way to do that. (This will usually be a context or thisArg parameter.)
If not, you can readily solve the problem with a closure:
Controller.prototype.go = function() {
var self = this;
FB.Event.subscribe('auth.login', handleChange);
FB.Event.subscribe('auth.logout', handleChange);
function handleChange() {
return self.fbHandleStatusChange();
}
}
That grabs a copy of this into a variable called self, which is used by the handleChange function (which is a closure over the scope containing the self variable) to call your function with the correct context. More about closures here: Closures are not complicated More about this here: You must remember this
Alternately, though, are you really going to have multiple instances of Controller? People coming to JavaScript from class-based languages tend to use constructor functions (a rough "class" analogue) unnecessarily. They're the right choice if you need to have more than one instance of an object, but if you're only ever going to have a single Controller object on the page, then using a constructor function and fiddling about with this is overkill.
If you don't need multiple, independent Controller instances, then:
var controllerObject = (function() {
var inst = {};
inst.go = go; // Make `go` a publicly-accessible function of the object
function go() {
FB.Event.subscribe('auth.login', fbHandleStatusChange);
FB.Event.subscribe('auth.logout', fbHandleStatusChange);
}
// This is private to us, so we don't expose it as a property on the object
function fbHandleStatusChange(response) {
// Doesn't work
otherFunction();
}
// This is also private to us
function otherFunction() {
alert('hello');
}
return inst;
})();
That creates a private scope via the outer anonymous function, and within that scope creates an instance (inst) which we then return and refer to as controllerObject. controllerObject in the above only has one property, the function go. All of our other functions are truly private. (I've also taken the liberty of ensuring that the functions have names, because that helps your tools help you.)
Note that we don't actually refer to inst anywhere in our function calls, because they're all local to the closure scope. We can even have private data, by having other vars within the outer closure.
Consider this:
window.onload = function () {
myObj.init();
};
var myObj = {
init: function () {
console.log("init: Let's call the callMe method...");
//callMe is not defined...
callMe();
//Works fine!
this.callMe();
},
callMe: function () {
console.log('callMe');
}
};
Since the init function gets called this way (myObj.init), I expect this to be myObj in the init function. And if that is the case, why the callMe function fails? How am I supposed to call the callMe function without using the this context in the init body? (Actually, it's too annoying to call the object methods using this over and over again through the functions. So what's the point of having a single object?)
I would like to know how can I fix this so that the callMe method gets called using the first invocation in the code above?
this is never implicit in JavaScript as it is in some other languages. Although there are ways to do it, like this using the with statement:
init: function () {
console.log("init: Let's call the callMe method...");
// Make `this` implicit (SEE BELOW, not recommended)
with (this) {
// Works
callMe();
}
},
...it's generally a bad idea. Douglas Crockford probably wrote one of the better descriptions of why it's a bad idea, which you can find here. Basically, using with makes it nearly impossible to tell what the code's going to do (and slows the code down, if you do anything else in that with statement that doesn't come from the this object).
This isn't the only way that JavaScript's this is not the same as it is in some other languages. In JavaScript, this is defined entirely by how a function is called, not where the function is defined. When you do this.callMe() (or the equivalent this["callMe"](), or of course foo.callMe(), etc.), two things happen: The function reference is retrieved from the property, and the function is called in a special way to set this to be the object that property came from. If you don't call a function through a property that way, the call doesn't set any particular this value and you get the default (which is the global object; window on browsers). It's the act of making the call that sets what this is. I've explored this in depth in a couple of articles on my blog, here and here.
This (no pun) can be made even clearer if you look at JavaScript's call and apply functions, which are available on all function objects. If I do this:
callMe.call({});
...it'll call the callMe function with a blank object ({}) as this.
So basically, just get used to typing this. :-) It's still useful to have properties and methods associated with an object, even without the syntactic convenience (and confusion!) of an implicit this.
You can also use the module pattern, which captures all private variables inside a closure, so you are free to use them without this, as they're in the same scope. You then pick and choose which methods/variables you want to make public:
var myObj = (function () {
var init = function () {
callMe(); // This now works
};
var callMe = function () {
...
};
// Now choose your public methods (they can even be renamed):
return {
init: init, // Same name
callMyName: callMe // Different name
};
}) ();
Now:
myObj.init(); // Works
myObj.callMyName(); // Works
myObj.callMe(); // Error