Here are 2 files:
// main.js
require('./module');
console.log(name); // prints "foobar"
// module.js
name = "foobar";
When I don't have "var" it works. But when I have:
// module.js
var name = "foobar";
name will be undefined in main.js.
I have heard that global variables are bad and you better use "var" before the references. But is this a case where global variables are good?
Global variables are almost never a good thing (maybe an exception or two out there...). In this case, it looks like you really just want to export your "name" variable. E.g.,
// module.js
var name = "foobar";
// export it
exports.name = name;
Then, in main.js...
//main.js
// get a reference to your required module
var myModule = require('./module');
// name is a member of myModule due to the export above
var name = myModule.name;
I'm unable to find an scenario where a global var is the best option, of course you can have one, but take a look at these examples and you may find a better way to accomplish the same:
Scenario 1: Put the stuff in config files
You need some value that it's the same across the application, but it changes depending on the environment (production, dev or test), the mailer type as example, you'd need:
// File: config/environments/production.json
{
"mailerType": "SMTP",
"mailerConfig": {
"service": "Gmail",
....
}
and
// File: config/environments/test.json
{
"mailerType": "Stub",
"mailerConfig": {
"error": false
}
}
(make a similar config for dev too)
To decide which config will be loaded make a main config file (this will be used all over the application)
// File: config/config.js
var _ = require('underscore');
module.exports = _.extend(
require(__dirname + '/../config/environments/' + process.env.NODE_ENV + '.json') || {});
And now you can get the data like this:
// File: server.js
...
var config = require('./config/config');
...
mailer.setTransport(nodemailer.createTransport(config.mailerType, config.mailerConfig));
Scenario 2: Use a constants file
// File: constants.js
module.exports = {
appName: 'My neat app',
currentAPIVersion: 3
};
And use it this way
// File: config/routes.js
var constants = require('../constants');
module.exports = function(app, passport, auth) {
var apiroot = '/api/v' + constants.currentAPIVersion;
...
app.post(apiroot + '/users', users.create);
...
Scenario 3: Use a helper function to get/set the data
Not a big fan of this one, but at least you can track the use of the 'name' (citing the OP's example) and put validations in place.
// File: helpers/nameHelper.js
var _name = 'I shall not be null'
exports.getName = function() {
return _name;
};
exports.setName = function(name) {
//validate the name...
_name = name;
};
And use it
// File: controllers/users.js
var nameHelper = require('../helpers/nameHelper.js');
exports.create = function(req, res, next) {
var user = new User();
user.name = req.body.name || nameHelper.getName();
...
There could be a use case when there is no other solution than having a global var, but usually you can share the data in your app using one of these scenarios, if you are starting to use node.js (as I was sometime ago) try to organize the way you handle the data over there because it can get messy really quick.
If we need to share multiple variables use the below format
//module.js
let name='foobar';
let city='xyz';
let company='companyName';
module.exports={
name,
city,
company
}
Usage
// main.js
require('./modules');
console.log(name); // print 'foobar'
Save any variable that want to be shared as one object. Then pass it to loaded module so it could access the variable through object reference..
// main.js
var myModule = require('./module.js');
var shares = {value:123};
// Initialize module and pass the shareable object
myModule.init(shares);
// The value was changed from init2 on the other file
console.log(shares.value); // 789
On the other file..
// module.js
var shared = null;
function init2(){
console.log(shared.value); // 123
shared.value = 789;
}
module.exports = {
init:function(obj){
// Save the shared object on current module
shared = obj;
// Call something outside
init2();
}
}
a variable declared with or without the var keyword got attached to the global object. This is the basis for creating global variables in Node by declaring variables without the var keyword. While variables declared with the var keyword remain local to a module.
see this article for further understanding - https://www.hacksparrow.com/global-variables-in-node-js.html
Not a new approach but a bit optimized. Create a file with global variables and share them by export and require. In this example, Getter and Setter are more dynamic and global variables can be readonly. To define more globals, just add them to globals object.
global.js
const globals = {
myGlobal: {
value: 'can be anytype: String, Array, Object, ...'
},
aReadonlyGlobal: {
value: 'this value is readonly',
protected: true
},
dbConnection: {
value: 'mongoClient.db("database")'
},
myHelperFunction: {
value: function() { console.log('do help') }
},
}
exports.get = function(global) {
// return variable or false if not exists
return globals[global] && globals[global].value ? globals[global].value : false;
};
exports.set = function(global, value) {
// exists and is protected: return false
if (globals[global] && globals[global].protected && globals[global].protected === true)
return false;
// set global and return true
globals[global] = { value: value };
return true;
};
examples to get and set in any-other-file.js
const globals = require('./globals');
console.log(globals.get('myGlobal'));
// output: can be anytype: String, Array, Object, ...
globals.get('myHelperFunction')();
// output: do help
let myHelperFunction = globals.get('myHelperFunction');
myHelperFunction();
// output: do help
console.log(globals.set('myGlobal', 'my new value'));
// output: true
console.log(globals.get('myGlobal'));
// output: my new value
console.log(globals.set('aReadonlyGlobal', 'this shall not work'));
// output: false
console.log(globals.get('aReadonlyGlobal'));
// output: this value is readonly
console.log(globals.get('notExistingGlobal'));
// output: false
With a different opinion, I think the global variables might be the best choice if you are going to publish your code to npm, cuz you cannot be sure that all packages are using the same release of your code. So if you use a file for exporting a singleton object, it will cause issues here.
You can choose global, require.main or any other objects which are shared across files.
Otherwise, install your package as an optional dependency package can avoid this problem.
Please tell me if there are some better solutions.
If the target is the browser (by bundling Node code via Parcel.js or similar), you can simply set properties on the window object, and they become global variables:
window.variableToMakeGlobal = value;
Then you can access this variable from all modules (and more generally, from any Javascript context).
Related
I have a file called app.js:
let id = 0;
const Func = require('./func.js');
Func.myFunc();
console.log(id);
module.exports = {
id
};
Also I have another file called func.js:
const App = require('./app.js');
var myFunc = () => {
App.id = 100;
}
module.exports = {
myFunc
};
But console.log(id) returns: 0
What you are doing is termed circular dependencies. It is generally frowned upon and there is no allowed instance where this may be required. You're better off creating a third file that will use both of them...
Read this to have a better understanding:
https://nodejs.org/api/modules.html#modules_cycles
How to deal with cyclic dependencies in Node.js
Add another log like:
// app.js ...
console.log(module.exports);
module.exports = { id };
console.log(id);
to see that your code does work somehow, in the way that module.exports has an id property set, but you override that afterwards. Also the property of the export object has nothing todo with the id variable (well, the later gets copied into the first) so console.log will never log 100.
There are two problems with your piece of code:
the circular dependency
module.exports.id is not the same object as the variable id in app.js
In order to solve the first problem, you should create a third file where the variable will be declared and other modules will use that.
Now, to illustrate the second problem, look at the following.
// testModule.js
let variable = 0;
function get_variable() {
return variable;
}
module.exports = {variable, get_variable};
// app.js
const testModule = require('./testModule.js');
testModule.variable = 1234;
console.log(testModule.variable); // will print '1234'
console.log(testModule.get_variable()); // will print '0'
This little misunderstanding of modules, could lead to subtle nasty bugs. I consider that the best practice to solve this would be not to export the 'variable' property directly, but having getter/setter functions in the module, almost like transforming it into a class-like thing.
// testModule.js
let variable = 0;
function get_variable() {
return variable;
}
function set_variable(value) {
variable = value;
}
module.exports = {get_variable, set_variable};
My understanding of modules is that they are distinct from each other. However I don't understand why this code works then.
Lets say I have three files in the node.js framework. One "app.js" driver file and two modules:
Module "one.js" simply has a property called "name":
module.exports = {
name: null
}
Module "two.js" loads module "one.js" and declares a function that prints out the contents of the property "name" in the "one.js" module:
var one = require('./one');
module.exports = {
printname: function()
{
console.log(one.name);
}
}
Now the driver (app.js) imports both modules, sets the property of the first module, then calls the name printing function of the second:
var one = require("./one");
var two = require("./two");
two.printname();
one.name = "John";
two.printname();
When I run this, it prints "null" (fine, it should be empty), then "John" (not fine). How is the second module learning of the value in the first module?
My thought process is: when "two.js" loads its own version of "one.js", the property "name" should always be null. Why is this not the case?
Because you are modifying a property of an Object, and Objects are passed by reference, therefore all the instances that imported one.js got the same instance.
If you need different instances you should export a class and create an instance on demand.
Something like that:
//one.js
class Data {
constructor(data) {
this.data = data;
}
}
export.module = Data;
//two.js
const Data = require('./one');
const data = new Data('John');
one's export is a static object. It it not new every time.
You can change it like so:
module.exports = function() {
return { name: null }
}
Then:
var one = require("./one");
var willAlwaysBeNew = one();
willAlwaysBeNew.name = "john"
var willAlwaysBeNewToo = one();
console.log(willAlwaysBeNew.name) // john
console.log(willAlwaysBeNewToo.name) // null
I have a setFilelocation and I'm using this variable in multiple .js files. So the same path is set every time I use this variable.
Is there any way I can use this variable as a global variable and I can hardcode this location only once, such as:
var setFileLocation = '/home/name/parent1/parentdirec/direc/qa.json';
As you are using node you can use require
I do this with config info like this
in one file called config.js for example
module.exports = {
v1: somevalue,
fileLocation: "/default/file/loc",
computePath: (dir, subdir, file) {
//use Vasans example here
}
};
Then in your code require config.js
var config = require('./config.js');
And you will have access to the variable or the funtion to create the path, whichever way you want
Have a global function instead which will take these inputs and return the full path.
var path = require('path')
function computePath(dir, subdir, file) {
var pathParts = [];
pathParts.push(dir, subdir, file);
return pathParts.join(path.sep);
}
Set it as a global variable:
global.setFileLocation = '/home/name/parent1/parentdirec/direc/qa.json';
Then you can use it in any place of your code:
console.log(setFileLocation);
But remember that using global variable like that is not recommended.
there are many options
using global (not suggest because in the practise, node.js app should not contain global variable)
global.setFileLocation = '/home/name/parent1/parentdirec/direc/qa.json';
export to utility module and import it
==== YOUR_APP/config.js ====
module.exports = {
fileLocation: "/home/name/parent1/parentdirec/direc/qa.json"
};
=== YOUR_APP/SOME_PATH/a.js ====
require('rootpath')();
var config = require('/config')
// config.fileLocation
As a newbie in Design Patterns in Javascript, I came across the Module Pattern but I don't get something with namespace.
In the namespacing part of Addy Osmani's online book about JS Design Patterns, Addy explains those 5 ways of checking for variable / namespace existence:
// This doesn't check for existence of "myApplication" in
// the global namespace. Bad practice as we can easily
// clobber an existing variable/namespace with the same name
var myApplication = {};
// The following options *do* check for variable/namespace existence.
// If already defined, we use that instance, otherwise we assign a new
// object literal to myApplication.
//
// Option 1: var myApplication = myApplication || {};
// Option 2 if( !MyApplication ){ MyApplication = {} };
// Option 3: window.myApplication || ( window.myApplication = {} );
// Option 4: var myApplication = $.fn.myApplication = function() {};
// Option 5: var myApplication = myApplication === undefined ? {} : myApplication;
What I really don't get is how it solves the problem of naming.
Let's say myApplication is set up before my code tries to use myApplication. Using Option 1 for example (or actually all of the options), does not seem to change anything in case myApplication was already in use but only overwrite the previous values for myApplication:
// Higher in some script, where I don't know about it
var myApplication = 'whatever string or object used by the script';
// A bit of code later, where I come with my little Module Pattern
var myApplication = myApplication || {}; // Using Option 1
myApplication = (function($) {
var myAppVariable = 'blabla';
var myAppFunction = function() {
// Doing a few things here
};
return myAppFunction;
}) (jQuery);
// Using the module
myApplication.myAppFunction();
To me it is very confusing because I don't see how it prevents me for also stepping on other's toes.
When you load a module in javascript, you're probably (depending on the code I guess) going to have to overwrite whatever variable is already in your modules namespace. A popular pattern for preserving whatever may have held your modules name before load is the noConflict() pattern. The idea behind this pattern is you hold the original value of your namespace in a variable and if noConflict is called, you replace your namespace with the original value and return your library. The pattern can be written more or less elegantly like this:
myModule = "some stuff ya";
(function(namespace, undefined) {
var _module = "myModule";
var __originalModule = namespace[_module];//holds the original value in case you wish to restore it
/****** Code your module here following whichever module pattern you wish to follow ****/
var module = {
log: function() {
if(console.log) {
console.log(arguments);
}
}
}
/****** End of your module ****/
//calling this method will remove your module from the namespace and replace it with whatever
// originally held your module name.
//This function returns your module
module.noConflict = function() {
namespace[_module] = __originalModule;
return module;
}
namespace[_module] = module; //add your module to the namespace
})(window);
console.log(window.myModule); // => {log: function...}
var myMod = window.myModule.noConflict();
console.log(window.myModule); // => "some stuff ya"
//lib.js
var opt = 0
exports.set = function(arg) {
opt = arg
}
exports.prn = function() {
console.log(opt)
}
///prog.js
var lib = require('./lib')
var lib2 = require('./lib')
lib.set(222)
lib2.set(333)
lib.prn()
lib2.prn()
prog.js will output:
333
333
but I need it to output:
222
333
In ohter words, opt must be unique to variable lib and to variable lib2. How to achieve that?
That's because normally nodejs caches its modules which are got via require. You may use the following helper:
// RequireUncached.js
module.exports = function(module) {
delete require.cache[require.resolve(module)]
return require(module);
}
and the usage of the helper:
var requireUncached = require('RequireUncached.js');
requireUncached("./lib");
Have in mind that this approach is considered as bad practice and should not be used. I'll suggest to wrap your logic into a function, require the module and call the function. So, every time you get a new instance.
require will not load scripts multiple times, but always yield the same instance.
If you need different environments, make your module a constructor function that allows to be instantiated multiple times. Store opt on each object for that instead of in the (global) module scope.
// lib.js
module.exports = function constr() {
var opt = 0
this.set = function(arg) {
opt = arg
};
this.print = function() {
console.log(opt)
};
};
// prog.js
var lib = require('./lib'),
inst1 = new lib(),
inst2 = new lib();
/* or short:
var inst1 = new require('./lib')(),
inst2 = new require('./lib')(); */
inst1.set(222)
inst2.set(333)
inst1.print()
inst2.print()
The way the NodeJS module system works, the output is correct and your expectations contradict the design principle here.
Each module is loaded once and only once, and subsequent calls to require simply return the reference to the pre-existing module.
Maybe what you need to do is create a class you can create one or more instances of instead of using module-level globals.
Adding to Bergi's answer, You may also try it like
// prog.js
var lib = require('./lib')(),
lib2 = require('./lib')();
lib.set(222)
lib2.set(333)
lib.print()
lib2.print()
// lib.js
module.exports = function constr() {
var opt = 0
return { set : function(arg) {
opt = arg
},
print : function() {
console.log(opt)
}
}
};
Add this line as first line of your lib.js
delete require.cache[__filename]
now your module becomes in a separate namespace each time you require it.