Is it bad practice to declare global variables in a.js file?
I have a .js file where I initialize two parameters that are used in a separate function:
var submyvar1;
var submyvar2;
function init(myvar1 , myvar2){
submyvar1= myvar1;
submyvar2= myvar2;
}
function (){
//subvar1 & subvar 2 used here
}
Is declaring global variables a bad practice?
If so, what is the alternative, wrap the whole .js file in an object?
source to share
At least this is not good practice, you can use an expression called by the called function :
(function() {
var x;
var y;
window.init = function(xValue, yValue) {
x = xValue;
y = yValue;
}
window.doWhateverYouWant = function() {
console.log(x + y);
}
}());
You can use this pattern if you don't need access to your global variable outside of this .js file , when cross-access between .js files or elements is required <script>
, the global variable is simple (although you could have used AMD or sth else instead).
source to share
You should avoid doing this where possible to prevent cluttering the global namespace. There will likely be bits of your code that you want to expose, so that's okay in this case. For example, the jQuery, obviously, is to make the variables jQuery
and $
global (it does this by creating their properties window
.
To avoid this, you can include your code in a function followed by parentheses:
var mySingleGlobalVar = (function () {
var submyvar1;
var submyvar2;
function init(myvar1 , myvar2){
submyvar1= myvar1;
submyvar2= myvar2;
}
function (){
//subvar1 & subvar 2 used here
}
return init;
}());
This is a function that is executed immediately. In this example, I have allocated the return value (init function) for the global var, and this will be the only global var that your script will create (if you declare them all correctly with var
).
source to share
In JavaScript: The good parts (also briefly here ) he suggested that:
Global variables impair the resiliency of programs and should be avoided. One way to minimize the use of global variables is to create a single global variable for your application:
var MYAPP = {};
This variable becomes the container for your application:
MYAPP.stooge = { "first-name": "Joe", "last-name": "Howard" };
By reducing the global reach to a single name, you greatly reduce the chances of poor interaction with other applications, widgets, or libraries. Your program also becomes easier to read because it is obvious that MYAPP.stooge is a high-level structure.
source to share
I decided to use the dropdown module pattern as described in: Good article here on a possible implementation using the "dropdown module template": http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad -javascript-habits-part-1 /
Its very similar to the accepted answer.
Here's an example template that was inserted on top of enterprisejquery:
We looked at the Self-Executing Anonymous Function earlier as a pattern you could use to keep all your code private. As it turns out, you can actually modify the pattern somewhat so that you can achieve the same benefits of the Revealing Module Pattern. Not only can we achieve public and private properties and methods, but we can also provide an easy way to extend the namespace while keeping the content protected from the global namespace. In addition, the following pattern can protect the $ from conflicting with other JavaScript libraries and also protect undefined from being redefined.
Take a look at the following example, and we will walk through the code explaining the key changes to the pattern.
//Self-Executing Anonymous Func: Part 2 (Public & Private)
(function( skillet, $, undefined ) {
//Private Property
var isHot = true;
//Public Property
skillet.ingredient = "Bacon Strips";
//Public Method
skillet.fry = function() {
var oliveOil;
addItem( "\t\n Butter \n\t" );
addItem( oliveOil );
console.log( "Frying " + skillet.ingredient );
};
//Private Method
function addItem( item ) {
if ( item !== undefined ) {
console.log( "Adding " + $.trim(item) );
}
}
}( window.skillet = window.skillet || {}, jQuery ));
//Public Properties
console.log( skillet.ingredient ); //Bacon Strips
//Public Methods
skillet.fry(); //Adding Butter & Fraying Bacon Strips
//Adding a Public Property
skillet.quantity = "12";
console.log( skillet.quantity ); //12
//Adding New Functionality to the Skillet
(function( skillet, $, undefined ) {
//Private Property
var amountOfGrease = "1 Cup";
//Public Method
skillet.toString = function() {
console.log( skillet.quantity + " " +
skillet.ingredient + " & " +
amountOfGrease + " of Grease" );
console.log( isHot ? "Hot" : "Cold" );
};
}( window.skillet = window.skillet || {}, jQuery ));
try {
//12 Bacon Strips & 1 Cup of Grease
skillet.toString(); //Throws Exception
} catch( e ) {
console.log( e.message ); //isHot is not defined
}
You can execute and modify the above code from jsFiddle.
First, since we have a Self-Executing Anonymous Function, we can actually provide some parameters to pass to it when it executes. In this case we are passing 2 arguments to the anonymous function.
The first argument looks quite strange. What is window.skillet = window.skillet || {} doing? The code checks to see if skillet exists in the global namespace (window). If it does not exist, then window.skillet is assigned an empty object literal. Using this approach we can build a library across JavaScript files. If another script uses the same technique, then it will pass in the existing instance and append logic to it. Inside the Anonymous Function, if we want something to be public, then we append it to the skillet object. Any other properties or methods will be considered private.
The second argument passed in jQuery. The benefit of this is that the named parameter is referenced as $, which allows us to refer to jQuery as $ within the Anonymous Function without having to worry that it will conflict with the $ declared in other JavaScript libraries. This is a common practice that you will most likely run across when looking at well written jQuery code.
You might notice a 3rd parameter to the Anonymous Function called undefined. Why did we add that parameter and why didn’t we pass an argument to it? In JavaScript, you can unfortunately redefine what undefined means. Imagine that some code somewhere deep in one of your 3rd party libraries redefines undefined to something strange like true. If anywhere in your code you test against undefined, then you code will most likely not behave like you intended. In JavaScript, if you have a parameter that doesn’t have a matching argument, then it’s value is set as undefined. By using this trick, it can save us from the bad code someone wrote to redefine undefined.
Pros
Gives you the ability to have public and private properties and methods
The code inside doesn’t use the Object Literal notation
Keeps undefined’s value as undefined in case someone overrode the value
Allows you to use $ inside your code without worrying about clashing with other libraries
Allows your library to grow across files using the "window.namespace = window.namespace || {}" technique
A common pattern that you will see in many libraries, widgets, and plugins
Cons
Slightly more complicated pattern, but not overly difficult to understand
If you are interested in digging deeper into some of the patterns I mentioned above then I encourage you to check out Klaus Komenda’s post entitled JavaScript Programming Patterns. The article provides an insightful view of how JavaScript patterns have changed over the years.
source to share