Can nodejs have two functions in different classes with the same name ?
If not then why not ? otherwise there is something wrong in the code.
Following is the example;
var admins = require('./routes/admins');
var users = require('./routes/users');
Both singleton classes
var users = function users(){
this.foo = foo = function(bar){ ...
}
}
users.getInstance = getInstance = function(){
if(this.instance == null){
this.instance = new users();
}
return this.instance;
}
module.exports = users.getInstance();
The admin class is also similar, both the classes have the same function names as well.
Now when foo is called it gets called of user class no matter what.
If i change the require order the foo of admin class is called.
As literally written in your question, I don't see a reason why this would happen. However, you are leaking into global scope, and that's how you might end up with duplicates.
users.getInstance = getInstance = function(){ ...
First, notice that the middle getInstance isn't scoped with var, so it gets assigned to the global scope. While this doesn't cause immediate problems, you're still polluting global scope, which is bad.
The real issue appears if you just do:
module.exports = getInstance();
Whether or not you've scoped getInstance with var, you're calling it in the global context, which means that inside the function, this == global. This means that the first time the function runs, it is basically doing:
global.instance = new users();
...and when your second file runs, it sees there's already a global.instance and just returns it.
Consider using 'use strict'; so these kinds of errors are caught for you.
Finally -- why are you doing all these getInstance gymnastics? They are entirely unnecessary. Your users file should just look like:
exports.foo = function(bar) {
...
};
Since the function name are same and the code is executed in sequential order, the function inside the second class overrides the first.
So the function will be called from whichever file is in second place.
Related
I have problem with (most probably) the context of this:
Im new in JS and think more like c++ guy.
Please, see the code:
controller.js :
function CController(){ ...
this.myCanvas = new CCanvas(this);
}
CController.prototype.resize() {...}
canvas.js :
function CCanvas(_mainController){
var controller = _mainController;
}
CCanvas.prototype.myEvent(){
this.controller.resize(); // <--- here!
}
I get the error at mentioned line that controller is undefined.
how can it be corrected?
Most likely not a scoping issue. Assuming your _mainController is actually a controller (which I'll add in the version I'm about to show you), your problem is that in the constructor of CCanvas, you're assigning var controller, not this.controller. This in turn causes controller to be dropped (as var is the keyword for a local variable, after all.
function CCanvas(_mainController){
if (!(_mainController instanceof CController)) throw "Not a controller";
this.controller = _mainController;
}
This should work. And it prevents you from supplying a non-controller.
If you really want to stick to your guns as in the comments and having the variable not on the class but still in lexical scope, do this:
var CCanvas = function(_mainController) {
var outputCCanvas = function(){
};
outputCCanvas.prototype.myEvent = function(){
console.log("Event");
}
return outputCCanvas;
};
The level of indirection on this one is crazy, and you lose a ton of good stuff doing it:
It'll be impossible to do instanceof checks on CCanvas, as each and every instance is generated dynamically every time you call the method
Oh, yeah, your instantiation changes. Now, you're doing new (CCanvas(_mainController))(), since CCanvas is now a method returning a class
I've got a school assignment of creating an app and one of the restrictions were that only one global variable was allowed, named "App". So I need to put the whole JS inside this variable.
I thought of doing something like:
App = function() { this.test = () => alert("test"); }
And then calling it with App.test().
But this doesn't work, the error I'm getting is:
Uncaught TypeError: App.test is not a function at HTMLLIElement.onclick (index.html:25)
Am I doing something wrong?
You need to define your app in a variable as an object and then you can use those members of the object such as:
// Object creation
window.App = {};
Then you add more properties like functions or variables and use it later inside of that variable.
window.App.test = function() {
alert('test');
}
window.App.variable = 'my variable';
console.log( App.test() );
console.log( App.variable );
Another thing is you can omit the word window from App.
Keeping most of your approach as it is, you could return an object that has functions as properties.
App = function() {
return {
test: () => alert("test"),
test2: () => alert("test2")
};
}
App().test();
App().test2();
To be able to use your function that contains this.test..., you'll need to use it as a "constructor function" because this in a function declaration means "instance property", meaning you will need to explicitly create an instance of App with the new keyword:
// Declare the global
var App = function() { this.test = () => alert("test"); }
// Make an instance of an object via the constructor function
var myApp = new App();
// Invoke the functionality via the instance
myApp.test()
Or, set up App as an object, connect that object to the Global window object and set test as a property of App all without any instance properties (this references), which avoids having to make the explicit instance:
// Declare the global property as an Object
// and set up a "test" property that stores
// a function in that object:
window.App = { test: function(){alert("test");}}
// Invoke the functionality directly
App.test()
The test function is not defined before executing the App function:
App = () => test = () => alert("test")
<button onclick='App(); test()'>:</button>
App can be defined as object instead:
App = { test: () => alert("test") }
<button onclick='App.test()'>:</button>
Just to piggyback on to what the other answers have suggested, this technique is most commonly used (in browser developement) when you "namespace" some JS code. Namespacing is useful because it helps the developer reduce global variable pollution by adding all their code under one namespace under window.
This also helps the developer modularise the code.
Here's a pattern you might see from time to time that adds code to a single namespace under window.
// This first function is what's known as an Immediately-invoked
// function expression (IIFE). `window` is passed in as an argument
// to the function - all other declared variables are local to the scope
// of the function so you don't get anything leaking to global.
// PS, the semi-colon is there before the opening parenthesis to prevent
// any errors appearing if you minimise your code
;(function (window) {
// Here we declare something new to add to the namespace
// It could be another object, a string, an array, or a constructor
// like Model
function Model() {...}
// If namespace `window.app` doesn't exist instantiate it with
// an empty object. If it _does_ exist it probably means that another
// module like this one has already been added to the namespace.
window.app = window.app || {};
// Then assign your new module as a property under that namespace
window.app.Model = Model;
})(window);
You can then use it later something like this:
var model = new app.Model();
var game = new Game(model);
For further reading: Addy Osmani on namespacing.
Thus far I've worked only with relatively small projects (and mostly alone), but this time I have to collaborate with other programmers... basically because of that I must plan the structure of the website very carefully for the avoidance of spending hours debugging the code.
At this point I suppose doing that in the following manner. I divide my code in modules and store each module in a separate file inside an object (or a function) with a made-up name (lzheA, lzheB, lzheC etc.) to avoid conflicts whether an object with the same name was used in an another piece of code. When the document is loaded, I declare a variable (an object) that I use as a main namespace of the application. Properties of the object are the modules I defined before.
// file BI.lib.js
var lzheA = {
foo: function() {
},
bar: function() {
},
}
// file BI.init.js
function lzheK() {
BI.loadPage();
}
// file BI.loadPage.js
function lzheC() {
var result = document.getElementById('result');
result.innerHTML = "that worked";
}
// and so on
var lzheA,lzheB,lzheD,lzheE,lzheF,lzheG,lzheH,lzheI,lzheJ;
// doing the following when the document is loaded
var BI = {
lib: lzheA,
menu: lzheB,
loadPage: lzheC,
customScripts: lzheD,
_index: lzheE,
_briefs: lzheF,
_shop: lzheG,
_cases: lzheH,
_blog: lzheI,
_contacts: lzheJ,
init: lzheK,
}
BI.init();
https://jsfiddle.net/vwc2og57/2/
The question... is this way of structuring worth living or did I miss something because of lack of experience? Would the made-up names of the modules confuse you regardless of the fact that each one used only twice - while declaring the variable and assigning it to a property?
I consider the namespaces a good option when you want to modularize applications in Javascript. But I declare them in a different way
var myModule = myModule || {}; // This will allow to use the module in other places, declaring more than one specificComponent in other js file for example
myModule.specificComponent = (function(){
// Private things
var myVar = {};
var init = function() {
// Code
};
return {
init: init // Public Stuff
};
})();
If you want to call the init method, you would call it like this
myModule.specificComponent.init();
With this approach, i guarantee that the module will not be overwritten by another declaration in another place, and also I can declare internal components into my namespaces.
Also, the trick of just exposing what you want inside the return block, will make your component safer and you will be encapsulating your code in a pretty way.
Hope it helps
I've just seen this pattern in javascript:
var test = function () {
function test(args) {
this.properties = args || {}; //etc
}
}
test.prototype.methodName = function (){} //...etc
What is going on with the function definition; declared once outside and once inside. What is the value of this approach?
It is strange. The "outer" function acts as a constructor, you can use var myTest = new test(); to create a new test.
The inner function, because of JS function-scoping, would only be available within the constructor method. You could call the inner test(...) from within the constructor, but it seems pointless as presumably args should be passed in to the constructor.
What might have been intended is:
var test = function(args) {
this.properties = args || {}; // you may want to actually parse each arg here
}
test.prototype.someOtherMethod = function() {}
The first thing to understand here is that functions in JavaScript create new scopes – there is no block scope (yet). So every variable or function declared inside another function is not visible to the outside.
With that in mind: when you define the inner function with the same name of the outer, you lose the ability to call the outer function recursively from itself, by name, because the inner function will "take over" (or "shadow") that name. Inside both functions, test will refer to the inner function, and outside the outer function test always refer to the outer function.
Since after the function definition you're modifying test.prototype, we can assume test (the outer one) will be used as a constructor. In this case, the inner test can be seen as a "private" method of the constructor, callable only from within the constructor. For detailed examples of this object-oriented use of functions within functions, see James T's answer.
This is scope.
When you define a variable as a function, it creates function scope.
Inside that function you can declare the same name, because that function is declared within that scope... Take an easier to follow example:
var User = function()
{
function PrivateToScope()
{
// A Function Only Accessible Inside This Function
alert( "private" );
}
return
{
PublicToScope: function()
{
// A Function Accessible From Outside This Function
alert( "public" );
}
}
}
var James = new User();
James.PublicToScope(); // Will alert "public"
James.PrivateToScope(); // Will fail to do anything
So to explain the answer, the User sets scope, and because you declare the function as above wit the same name, it does not matter.
People do not like me saying this but you can think of this approach as if it were a class in other languages.
var User = function()
{
}
is like
class User
{
}
var User = function()
{
function Something()
{
}
}
is like
class User
{
private function Something()
{
}
}
and finally
var User = function()
{
this.Something = function()
{
}
// or
return {
Something: function(){}
}
}
is like
class User
{
public function Something()
{
}
}
It's alllll about scope. maybe you have a user variable declared as a function and you wish to allow people to get his first name and last name, you would declare these variables or functions as "public"... but what if you wanted to know his diet was good or bad, you may have some complex functions to work it out, but you want to know one thing, good or bad.. you could make all these functions that do ugly stuff private, and then just display the result with a public function...
var User = function()
{
function CalculateDiet()
{
// Lots of scary diet calculating stuff comes out with the result
return result;
}
return
{
FirstName: "James",
LastName: "Poop",
StandardOfDiet: function()
{
return CalculateDiet();
}
}
}
var MyUser = new User();
alert( MyUser.FirstName );
alert( MyUser.StandardOfDiet() );
Why do you care?
Quantifying it is both easy and hard but here are some good ones...
It's neat
If you place a pile of chocolates on a table, they'll all get eaten.. but one of them was for you, people are greedy... Only layout on the table what you want them to eat, they can't be greedy then an accidently eat your chocolate
It sets you up for class oriented programming
It's clear what the programmer meant to do with the code
Memory usage (I'm sure there are overheads to declaring more functions public without need to
Finally, and on a very different note, you have a prototype attached to test, so let's go do this for our user example. Imagine we had an array of users:
var users = [
new User(),
new User()
];
we can iterate over these and get all their usual properties and methods:
for( a in users )
{
alert( users[ a ].FirstName );
}
But let's say something happens in our application... a user clicks on a button that asks each user if they like fish and chips or not, we now need a new method for the user... We can prototype a new method to all iterations of that variable "user" we created... We could declare it before hand, but then we'd waste memory and maybe confuse future programmers with its presence that is based off of something very specific:
// user clicks button and runs this code
User.protoype.DoesUserLikeChips = function(){
// put some code in here that somehow makes this example make sense :)
}
now on every user in your array, you can call this new method... New functionality babehhh!
You may be thinking, why do you not just go users[ a ].DoesUserLikeChips = function(){}... The answer is that it is applied to only that one instance...
Inner test function is a private function of outer test function. And then a methodName function has been set as public function of outer test function. There are no special thing about naming inner function as outer one.
I've got a browser addon I've been maintaining for 5 years, and I'd like to share some common code between the Firefox and Chrome versions.
I decided to go with the Javascript Module Pattern, and I'm running into a problem with, for example, loading browser-specific preferences, saving data, and other browser-dependent stuff.
What I'd like to do is have the shared code reference virtual, overrideable methods that could be implemented in the derived, browser-specific submodules.
Here's a quick example of what I've got so far, that I've tried in the Firebug console, using the Tight Augmentation method from the article I referenced:
var core = (function(core)
{
// PRIVATE METHODS
var over = function(){ return "core"; };
var foo = function() {
console.log(over());
};
// PUBLIC METHODS
core.over = over;
core.foo = foo;
return core;
}(core = core || {}));
var ff_specific = (function(base)
{
var old_over = base.over;
base.over = function() { return "ff_specific"; };
return base;
}(core));
core.foo();
ff_specific.foo();
Unfortunately, both calls to foo() seem to print "core", so I think I've got a fundamental misunderstanding of something.
Essentially, I'm wanting to be able to call:
get_preference(key)
set_preference(key, value)
load_data(key)
save_data(key, value)
and have each browser do their own thing. Is this possible? Is there a better way to do it?
In javascript functions have "lexical scope". This means that functions create their environment - scope when they are defined, not when they are executed. That's why you can't substitute "over" function later:
var over = function(){ return "core"; };
var foo = function() {
console.log(over());
};
//this closure over "over" function cannot be changed later
Furthermore you are "saying" that "over" should be private method of "core" and "ff_specific" should somehow extend "core" and change it (in this case the private method which is not intended to be overridden by design)
you never override your call to foo in the ff_specific code, and it refers directly to the private function over() (which never gets overridden), not to the function core.over() (which does).
The way to solve it based on your use case is to change the call to over() to be a call to core.over().
That said, you're really confusing yourself by reusing the names of things so much, imo. Maybe that's just for the example code. I'm also not convinced that you need to pass in core to the base function (just to the children).
Thanks for your help. I'd forgotten I couldn't reassign closures after they were defined. I did figure out a solution.
Part of the problem was just blindly following the example code from the article, which meant that the anonymous function to build the module was being called immediately (the reusing of names Paul mentioned). Not being able to reassign closures, even ones that I specifically made public, meant I couldn't even later pass it an object that would have its own methods, then check for them.
Here's what I wound up doing, and appears to work very well:
var ff_prefs = (function(ff_prefs)
{
ff_prefs.foo = function() { return "ff_prefs browser specific"; };
return ff_prefs;
}({}));
var chrome_prefs = (function(chrome_prefs)
{
chrome_prefs.foo = function() { return "chrome_prefs browser specific"; };
return chrome_prefs;
}({}));
var test_module = function(extern)
{
var test_module = {};
var talk = function() {
if(extern.foo)
{
console.log(extern.foo());
}
else
{
console.log("No external function!");
}
};
test_module.talk = talk;
return test_module;
};
var test_module_ff = new test_module(ff_prefs);
var test_module_chrome = new test_module(chrome_prefs);
var test_module_none = new test_module({});
test_module_ff.talk();
test_module_chrome.talk();
test_module_none.talk();
Before, it was running itself, then when the extension started, it would call an init() function, which it can still do. It's just no longer an anonymous function.