I am writing some bookmarklets here and I have some questions related to built-in javascript functions.
Let's say I want to replace the built-in prompt function (not necessarily in a bookmarklet). That seems easy enough, but is there a way to call the builtin prompt function from within this replacement?
prompt = function(message){
var tmp = prompt(message);
hook(tmp);
return tmp;
}
I couldn't get the scoping to work out right; this example yields infinite recursion.
Also is there a way to restore the default behavior of a builtin javascript function that has been replaced (without hanging on to an extra reference).
(function () {
var old_prompt = prompt;
prompt = function (msg) {
var tmp = old_prompt(msg);
hook(tmp);
return tmp;
};
prompt.restore = function () { prompt = old_prompt; }
// analogous for other functions you want to replace
})();
Wrapping it up in a (self-executing) function ensures that old_prompt doesn't leak to the outside. You do need to expose something though. I chose to provide a function doing the restoring, for convenience and perhaps, one could say, future-proofing and encapsulation. As long as higher order functions refrain from fiddling with someone else's scope...
Also, no, it's (I'd assume) not possible to restore the previous value of a variable without any reference to it (the old value), even if that value happened to be a built-in. Even if it was possible, it'd be a pretty obscure trick - this way works, so let's just stick with it.
(Credit for func.restore goes to Martijn)
Related
Let's say that I'm making a JS library that has some functions for DOM manipulation. I have a few functions that are added to elements, for example myElement.empty();. I would like the same functionality for NodeLists (the objects returned from, for example, querySelectorAll). To dynamically add the functions, I have done the below (and please note that the below does work):
var funcs=["text","html","attr","remove","empty","css"];
var n=funcs.length;
while(~--n){
var f=function(){
var i,l=this.length;
for(i=0;i<l;i++){
this[i][ funcs[arguments.callee.n] ].apply(this[i], arguments);
}
return this;
};
f.n=n;
NodeList.prototype[funcs[n]]=f;
}
This works, but I have heard that arguments.callee doesn't work in "strict" mode.
Someone said to give the function a name, but I can't, although I tried:
var funcs=["text","html","attr","remove","empty","css"];
var n=funcs.length;
while(~--n){
this[funcs[n]]=function(){
var i,l=this.length;
for(i=0;i<l;i++){
this[i][ funcs[name] ].apply(this[i], arguments);
// In the above it has 'name' which references the function name
}
return this;
};
NodeList.prototype[funcs[n]]=this[funcs[n]];
}
That didn't work. I was able to do it using eval. I decided not to use eval, although it worked (by putting n into the string and making the function out of that). I figured that arguments.callee is probably better than eval, if I had to use one of them.
How can I make my function work without using anything that is suggested against (such as arguments.callee and eval)?
Edit for more details:
Let's say I define an empty function (and once again for the purpose of the question let's assume that modifying the prototype is OK):
Element.prototype.empty=function(){
while(this.childNodes[0])
this.childNodes[0].remove();
};
This works for one element. What if the user wants to do something similar to:
document.querySelectorAll("button .myclass").empty();
So I want to make a script that dynamically creates functions for NodeLists that call the corresponding functions for each element, for example:
NodeList.prototype.empty=function(){
var i,l=this.length;
for(i=0;i<l;i++)
this[i].empty();
return this;
};
If I want to do the above I will need to create many functions that do very similar things. So I want to write some code that dynamically creates functions for NodeList. As you probably read above, I did it with arguments.callee (and eval), but I want to use something that is standard and considered OK to use.
How would I do this?
If you need any more information then please ask in the comments, and I will try to respond as soon as possible.
Don't use that weird iteration style, but an idiomatic for … of loop that allows for a block-scoped variable:
const funcNames = ["text","html","attr","remove","empty","css"];
for (const name of funcNames) {
NodeList.prototype[name] = function(...args) {
for (let i=0; i<this.length; i++) {
this[i][name](...args);
}
return this;
};
}
No reason to access the current function or store the name on its .n property, just access it through closure.
I want to parse function dynamic and apply this to variables in the function auto.
var functionContent = "console.log(v)";
var context = {v:'show some thing'}
(new Function(functionContent)).apply(context);
The parsed function will throw an error about can't found v. If I use console.log(this.v) instead, everything will be ok. But for better experience of end users, I don't want use this in functionContext. How can I do this?
What you want to do in javascript terms is called binding. You're setting the function scope for another function to an object.
var ctx = {v:'show some thing'};
var newFunction = (new Function("console.log(this.v)")).bind(ctx);
newFunction();
I would also state, as the other answer does, that this is not a great thing. new Function actually does use eval under the hood, it's basically just
eval("function(yourParams) { " + yourCode + "}")
Whether or not to get rid of it, well that's up to you. If it's used on the broader internet and loads up some data people can edit... then yeah it may be an issue, but less so if it's just something small to play around with.
The function I want to create requires an access myObject.
Is it better to create the helper function inside the main function so I have access to myObject with the scope.
Or should I make the helper function outside of myFunction and pass myObject as a parameter?
EDIT: Could I get memory-leak problem with those methods?
//Method 1
var myFunction = function(myObject){
var helper = function(i){
return console.log(i,myObject[i]);
}
for(var i in myObject){
var callback = helper(i);
}
}
//Method 2
var myFunction = function(myObject){
for(var i in myObject){
var callback = helper(i,myObject);
}
}
var helper = function(i,myObject){
return console.log(i,myObject[i]);
}
I assume you're asking for performance.
Here is a jsperf to test it for you (Yup, this exists and is very neat).
So in running the tests a bunch of times I note that neither method clearly wins. It's very close and almost certainly doesn't matter. I also note that on Windows 8.1, IE 11 blows Chrome out of the water, it's not even close - like by a factor of 20. That's a neat little result but not really indicative of real world code performance and likely we're just hitting an optimized case. Within IE the in-function version is a tiny-almost-irrelevant bit faster.
You can play with the inputs somewhat (for example I just passed in a small object, maybe a big one has different results), but I'm ready to call a preliminary conclusion: Don't worry about performance here. Use whichever one makes more sense for your specific case in terms of code clarity.
Apart from performance benefit mentioned by George Mauer, I think it will be a good idea to keep it inside to keep global context clean.
Different functions can have their own helpers defined inside them with same name rather than having function1Helper, function2Helper... in the global context.
I have this function call passed as a string:
var dcall = "tumbsNav(1)";
Is it possible to execute this dynamically like exec in SQL??
exec(dcall)
eval is the equivalent, but you should NOT use it.
Instead, pass the function like this:
var dcall = function() {tumbsNav(1);};
Then call it with:
dcall();
To do this, you want eval(dcall).
eval can open terribly security holes and performance issues in your program. If you need to use it, that usually means you have designed your program poorly.
Instead, you might keep a reference to the function you want to call and hold an array of arguments and use apply, e.g., tumbsNav.apply(null, [1]);. I don't know your code, so that's most general solution I can offer.
Wherever you're storing
var dcall = "tumbsNav(1)";
You can instead store
var dcall = function() {
return tumbsNav(1);
};
Wherever you were calling it, instead of calling
eval(dcall);
You can instead call
dcall();
The only case this wouldn't work is if tumbsNav wasn't defined at the time var func = ... is called. Then you would have to store the string. If the string is completely under your control, then there's no security hole, but be aware of all the problems mentioned by #Porco
As Kolink mentioned, my example would not cause a problem if tumbsNav was not defined when assigning it with a wrapped anonymous function that calls tumbs. The comment above would only make sense if the example had been the following:
var dcall = tumbsNav, darg = 1;
// later in the code, you can call
dcall(darg) ;
Use eval(dcall).
As others have mentioned eval is considered bad practice. The main reasons for this are
1) Improper use can leave your code vulnerable to injection attacks.
2) Maintaining code becomes more difficult (no line numbers, can't use debugging tools)
3) Executes more slowly (browsers can't compile)
4) Scope becomes impossible to predict.
However, if you understand all these then eval can be very helpful.
This question already has answers here:
var functionName = function() {} vs function functionName() {}
(41 answers)
Closed last year.
What's the difference between these two ways of declaring a function?
function someFunc() { ... }
var someFunc = function() { ... }
I'm not asking in the technical sense. I'm not asking which is better for readability, or which style is preferred.
I am on different opinion with most of the people here. Technically this syntax may mean the same for declaring functions both ways
(I stand incorrect on my last statement. I read up on a diff post why they are technically diff and I'll add in the end, why)
; but the way they play a role in evolving patterns is massive. I would highly recommend "Javascript: The Good Parts" by Doughlas Crockford.
But to prove my point in a subtle and a simple manner; here is a small example.
//Global function existing to serve everyone
function swearOutLoud(swearWord) {
alert("You "+ swearWord);
}
//global functions' territory ends here
//here is mr. spongebob. He is very passionate about his objects; but he's a bit rude.
var spongeBob = {
name : "squarePants",
swear : function(swearWord) {
name = "spongy";
alert("You "+ swearWord);
return this;
}
}
//finally spongebob learns good manners too. EVOLUTION!
spongeBob.apologize = function() {
alert("Hey " + this.name + ", I'm sorry man!");
return this;
}
//Ask spongebob to swear and then apologize in one go (CASCADING EFFECT!!)
alert(spongeBob.swear("twit").apologize());
if you look at the code above I declared a function with a name swearOutLoud. Which would take a swear word from any object or a call and will give you the output. It can do operations on any object using the "this" parameter that is passed to it and the arguments.
However second declaration is declared as an attribute of object called "spongeBob". This is important to note; as here I am moving towards an object driven behavior. While I am also maintaining "cascading effect" as I return "this" if i have nothing else to return.
Somthing similar is done in jquery; and this cascading pattern is important if you are trying to write a framework or something. You'll link it to Builder design pattern also.
But with functions declared as an attributes of an object I am able to achieve an object centric behavior which leads to a better programming paradigm. Unless designed well; individual functions declared outside with global access lead to a non-object oriented way of coding. I somehow prefer the latter.
To see cascading in effect, look at the last statement where you can ask spongebob to swear and apologize at once; even though apologize was added as an attribute later on.
I hope I make my point clear. The difference from a technical perspective may be small; but from design and code evolution perspective it's huge and makes a world of a difference.
But thats just me! Take it or leave it. :)
EDIT:
So both the calls are technically different; because a named declaration is tied to global namespace and is defined at parse time. So can be called even before the function is declared.
//success
swearOutLoud("Damn");
function swearOutLoud(swearWord) {
alert("You " + swearWord)
}
Above code will work properly. But code below will not.
swear("Damn!");
var swear = function(swearWord) {
console.log(swearWord);
}
One advantage of using function someFunc() { ... } is that the function name appears in Firebug debugger. Functions that are declared the other way (var someFunc = function() { ... }) come up as anonymous.
Actually, the difference is that the second declaration gives us the ability to declare functions like this making it possible to have a function as a property for an object :
var myObject=new Object();
myObject.someFunc=function() { ... };
Style wise the second example is more consistent with other common ways to declare functions and therefore it could be argued that it is more readable
this.someFunc = function() { ... }
...
someFunc: function() { ... },
However, as also mentioned it's anonymous and therefore the name does not appear when profiling.
Another way to declare the function is as follows which gets you the best of both worlds
var someFunc = function someFunc() { ... }
Another difference is that, on most browsers, the latter allows you to define different implementations depending on circumstances, while the former won't. Say you wanted cross-browser event subscription. If you tried to define a addEventListenerTo function thusly:
if (document.addEventListener) {
function addEventListenerTo(target, event, listener) {
....
}
} else if (document.attachEvent) {
function addEventListenerTo(target, event, listener) {
....
}
} else {
function addEventListenerTo(target, event, listener) {
....
}
}
on some browsers, all the functions end up being parsed, with the last one taking precedence. Result: the above just doesn't work. Assigning anonymous functions to variables, however, will work. You can also apply functional and basic aspect oriented programming techniques using anonymous functions assigned to variables.
var fib = memoize(function (n) {
if (n < 0) return 0;
if (n < 2) return 1;
return fib(n-1) + fib(n-2);
});
...
// patch the $ library function
if (...) {
$ = around($, fixArg, fixResult);
}
It is both true that the first form:
function test() { }
is a more recognized syntax and that the second form:
var test = function() { ... }
allows you to control the scope of the function (through the use of var; without it, it would be global anyway).
And you can even do both:
var test = function test() { ... test(); ... }
This allows you to define a recursive function in the second form.
For readability, I'd say the first is clearly better. A future maintenance programmer, even assuming they're familiar enough with javascript to know many of the finer points coming up in this thread, are going to assume the first format.
For example, if they should some day want to ctrl-f to search for the definition of your function to see what's happening in there, are they going to first search for someFunc = function() or function someFunc()?
Also, to get downright typographical about it (since we're talking readablity) readers are often scanning the text quickly, and would be more inclined to skip over a line that starts with "var" if they're looking for a function definition.
I know this is a non-technical answer, but it's harder for humans to read code than computers.
When you write
function Test() {
}
JavaScript is really creating a property to which it assigns the function object that once called will execute the code reported in the function definition. The property is attached to the object window, or to the object that contains the function definition.