Develop Reference

Assign and Query Javascript Arrow Function for Metadata

The problem is rather simple. We need to imbue a function with a parameter, and then simply extract that parameter from the body of the function. I'll present the outline in typescript...
abstract class Puzzle {
abstract assign(param, fn): any;
abstract getAssignedValue(): any;
async test() {
const wrapped = this.assign(222, async () => {
return 555 + this.getAssignedValue();
});
console.log("Expecting", await wrapped(), "to be", 777);
}
}
Let's set the scene:
Assume strict mode, no arguments or callee. Should work reasonably well on the recent-ish version of v8.
The function passed to assign() must be an anonymous arrow function that doesn't take any parameters.
... and it's alsoasync. The assigned value could just be stored somewhere for the duration of the invocation, but because the function is async and can have awaits, you can't rely on the value keeping through multiple interleaved invocations.
this.getAssignedValue() takes no parameters, returning whatever we assigned with the assign() method.
Would be great to find a more elegant solution that those I've presented below.
Edit
Okay, we seem to have found a good solid solution inspired by zone.js. The same type of problem is solved there, and the solution is to override the meaning of some system-level primitives, such as SetTimeout and Promise. The only headache above was the async statement, which meant that the body of the function could be effectively reordered. Asyncs are ultimately triggered by promises, so you'll have to override your Promise with something that is context aware. It's quite involved, and because my use case is outside of browser or even node, I won't bore you with details. For most people hitting this kind of problem - just use zone.js.

Hacky Solution 2
class HackySolution2 extends Puzzle {
assign(param: any, fn: AnyFunction): AnyFunction {
const sub = Object(this);
sub["getAssignedValue"] = () => param;
return function () { return eval(fn.toString()); }.call(sub);
}
getAssignedValue() {
return undefined;
}
}
In this solution, I'm making an object that overrides the getAssignedValue() method, and re-evaluates the source code of the passed function, effectively changing the meaning of this. Still not quite production grade...
Edit.
Oops, this breaks closures.

I don't know typescript so possibly this isn't useful, but what about something like:
const build_assign_hooks = () => {
let assignment;
const get_value = () => assignment;
const assign = (param, fn) => {
assignment = param;
return fn;
}
return [assign, get_value];
};
class Puzzle {
constructor() {
const [assign, getAssignedValue] = build_assign_hooks();
this.assign = assign;
this.getAssignedValue = getAssignedValue;
}
async test() {
const wrapped = this.assign(222, async () => {
return 555 + this.getAssignedValue();
});
console.log("Expecting", await wrapped(), "to be", 777);
}
}
const puzzle = new Puzzle();
puzzle.test();

Hacky Solution 1
We actually have a working implementation. It's such a painful hack, but proves that this should be possible. Somehow. Maybe there's even a super simple solution that I'm missing just because I've been staring at this for too long.
class HackySolution extends Puzzle {
private readonly repo = {};
assign(param: any, fn) {
// code is a random field for repo. It must also be a valid JS fn name.
const code = 'd' + Math.floor(Math.random() * 1000001);
// Store the parameter with this code.
this.repo[code] = param;
// Create a function that has code as part of the name.
const name = `FN_TOKEN_${code}_END_TOKEN`;
const wrapper = new Function(`return function ${name}(){ return this(); }`)();
// Proceed with normal invocation, sending fn as the this argument.
return () => wrapper.call(fn);
}
getAssignedValue() {
// Comb through the stack trace for our FN_TOKEN / END_TOKEN pair, and extract the code.
const regex = /FN_TOKEN_(.*)_END_TOKEN/gm;
const code = regexGetFirstGroup(regex, new Error().stack);
return this.repo[code];
}
}
So the idea in our solution is to examine the stack trace of the new Error().stack, and wrap something we can extract as a token, which in turn we'll put into a repo. Hacky? Very hacky.
Notes
Testing shows that this is actually quite workable, but requires a more modern execution environment than we have - i.e. ES2017+.

Use of Either and returning the error immediately

I have a function which returns an instance of Either where the Left side represent the exception / error, while the second side stores the return value.
If the Either instance has been Left instantiated to the Error branch I want to return immediately. If the instance has been Right instantiated I want to wrap that in a Maybe and continue on (as it comes into the function as a Maybe, and only gets looked up if it is Nothing).
This is working per my test cases:
isNothing being passed in :: lookup is in error
isNothing being passed in :: lookup is successful
isJust(22) being passed in (lookup doesn't execute)
The code feels OK, but I don't supect I may be missing sme of the finer points of the Folktale data.either library.
// from data.monad
const someValue = Maybe.Nothing()
// ...snip...
if (someValue.isNothing) {
// from data.either :: Either.Left | Either.Right
const possiblySomeValue = yield lookupSomeValue()
if(possiblySomeValue.isLeft) {
return possiblySomeValue
} else {
someValue = Maybe.Just(possiblySomeValue.get())
}
}
I am combining ES6 (Node 4.1) with Folktale: data.either and data.maybe. My goal is really elevating my understanding in how to write properly in this style
update the problem is a little more complex I ahve back to back independent lookups, which I feel could be chained together:
// from data.monad
const someValue = Maybe.Nothing()
// ...snip...
if (someValue.isNothing) {
// from data.either :: Either.Left | Either.Right
const possiblySomeValue = yield lookupSomeValue()
if(possiblySomeValue.isLeft) {
return possiblySomeValue
} else {
someValue = Maybe.Just(possiblySomeValue.get())
}
}
// from data.monad
const someValue2 = Maybe.Nothing()
// ...snip...
if (someValue2.isNothing) {
// from data.either :: Either.Left | Either.Right
const possiblySomeValue2 = yield lookupSomeValue2()
if(possiblySomeValue2.isLeft) {
return possiblySomeValue2
} else {
someValue2 = Maybe.Just(possiblySomeValue2.get())
}
}
Its the back to back occurances whcih make the code super ugly...

This is the current state of my code which I think is better. First be able to convert the Maybe to an either, to allow me to chain / orElse with transformations (Maybe.orElse does not allow take a function, whereas the Either.orElse does take a function for the transformation)
const maybeToEither = function(maybe) {
if (maybe.isNothing) {
return Either.Left(undefined)
} else {
return Either.Right(maybe.get())
}
}
then, since I ma unpackaging the Maybe.Just into the Either.Right as part of the conversion, I simply need to provide the orElse transformation.
const someValue = maybeToEither(maybeSomeValue).orElse(function(ignore){
return lookupSumValue()
}).get()
Blending into my actual problem, with generators lead to a slightly ugglier solution. lookupSomeValue is a generator function, so we need to yield. Also since the value is used in multiple places we want to force this into a value with get.
const someValue = (yield maybeToEither(maybeSomeValue).orElse(function(ignore){
return lookupSumValue()
})).get()
so when repeated the code isn't nearly as bad as my original solution -
const someValue = (yield maybeToEither(maybeSomeValue).orElse(function(ignore){
return lookupSumValue()
})).get()
const someValue2 = (yield maybeToEither(maybeSomeValue2).orElse(function(ignore){
const someRandom = getRandom()
return lookupSumValue2(someRandom)
})).get()
I am still looking for a more concise grammar. Will update with another solution if I find one.

Maybe (pun fully intended) a better approach
const someValue = (yield maybeToEither(maybeSomeValue).cata({
Left: lookupSumValue,
Right: yieldableRight})).get()
with these two helper functions
const yieldableRight = function(value){
return function*(){ return Either.Right(value) }
}
const maybeToEither = function(maybe) {
if (maybe.isNothing) {
return Either.Left(undefined)
} else {
return Either.Right(maybe.get())
}
}
Where lookupSomeValue is in the form (a function that returns a Generator):
const lookupSomeValue = function(){
return ((function *(){
return 10
})())
}
The problem is that the Right side needs to return something that is yieldable. For some reason Koa/Co is choking on the Either.Right() (even though Objects are yieldable), as a yieldable - so I return a generator that returns the value. I get that (I don't understadn whay I can't yield on the Either.Right, but thats a different problem).
I don't understand why the Right side needs to be wrapped back up in an Either, while the Left side doesn't.

Why use parentheses when returning in JavaScript?

In the Restify framework code I found this function:
function queryParser(options) {
function parseQueryString(req, res, next) {
// Some code goes there
return (next());
}
return (parseQueryString);
}
Why would the author write return (next()); and return (parseQueryString);? Does it need parentheses there and if so, why?

Using parentheses when returning is necessary if you want to write your return statement over several lines.
React.js offers a useful example. In the return statement of the render property in a component you usually want to spread the JSX you return over several lines for readability reasons, e.g.:
render: function() {
return (
<div className="foo">
<h1>Headline</h1>
<MyComponent data={this.state.data} />
</div>
);
}
Without parentheses it results in an error!
More generally, not using parentheses when spreading a return statement over several lines will result in an error. The following example will execute properly:
var foo = function() {
var x = 3;
return (
x
+
1
);
};
console.log(foo());
Whereas the following (without the parentheses) will throw errors:
var foo = function() {
var x = 3;
return
x
+
1
;
};
console.log(foo());

It doesn't need to be that way, but it's valid JavaScript code. Actually it's quite uncommon to see such syntax. I guess it's a personal preference of the author.

Parenthesis are used for two purposes in a return statement.
To support multi-line expression as mentioned in #Andru Answer.
To allow returning object in arrow function like the below:
() => ({ name: 'Amanda' }) // Shorthand to return an object
This is equivalent to
() => {
return { name : 'Amanda' }
}
For more information, please check this article.
https://medium.com/#leannezhang/curly-braces-versus-parenthesis-in-reactjs-4d3ffd33128f

// Create a component named MessageComponent
var MessageComponent = React.createClass({
render: function() {
return (
<div>{this.props.message}</div>
);
}
});
NOTE Why do we need the parentheses around the return statement (line
3)? This is because of JavaScript's automatic semicolon insertion.
Without the parentheses, JavaScript would ignore the following lines
and return without a value. If the JSX starts on the same line as the
return, then parentheses are not needed.
Taken from here.

Just to add to what others have said.
Using brackets around the return value is valid JavaScript, but mostly a bad thing to do.
Mostly bad because it doesn't add anything yet increases the size of the JavaScript which means that there is more to download to the browser. Yes most people have fast broadband connections, but don't lose sight of the fact that everything you put in the JavaScript file needs to be downloaded so avoid unnecessary code bloat. This probably doesn't matter if you use a tool to compact your code (minifier has already been mentioned), but not everyone does.
Sometimes it might aid readability. Hard pressed to think of an example in this case, but if the use of brackets makes your JavaScript clearer to you as the developer and thus easier to maintain then use them - even if it goes against what I said about code bloat.

Why would the author write return (next()); ... ?
Regarding next():
Probably because his function is something like this:
function next()
{
var i=0;
return function (){
// Do something with that closured i....
}
}
Regarding (xxx);:
It is unnecessary. Every minifier will remove it.
Example (uglifyJS):
becomes:

I tried:
var a = function() {
return true || true
}
console.log(a());
//return: true
var a = function() {
return
true || true
}
console.log(a());
//return: undefined
var a = function() {
return (
true || true
)
}
console.log(a());
//return: true

While Andru's answer is popular, it is wrong that parantheses are required for multiline return statement. Here, you can see an object of foo and bar is returned with no parantheses needed.
function foo () {
return {
foo: 'foo',
bar: 'bar',
}
}
console.log(foo())
As long as the return line is not just empty space or linebreak, you can have a multiline return just fine. Otherwise Automatic Semicolon Insertion takeover and break your return statement as demonstrated by Andru.
Regarding your question, I am onboard with Darin's answer.

This may be old but the return () can be used in this way:
function parseQueryString(req, res, next) {
var id = req.param('id');
return (id ? "Foo" : "Bar");
}
Less code, easy to read :)

jQuery/Javascript: How can I evaluate the validity of function arguments efficiently with a range of valid types?

I've got a rather large plugin that I am currently writing in jQuery which is using a lot of internal functions that can accept varying arguments depending on the function.
I caught myself constantly writing the following in every function to stop the code from running if an argument hasn't been supplied or isn't valid:
add : function(args) {
if (args===undefined) return;
// function code;
},...
I was hoping that in a DRY type of sense it would be a good idea to write a little internal helper function that would do this for me.
Is this actually a good idea and most importantly what is the best/secure way to check for a varied range of acceptable arguments?
There are a lot of functions with multiple arguments in this plugin, for example:
load : function( filename , path , excludeFromRandom , callback ) {}
where filename is a string,
path is a string,
excludeFromRandom is a boolean and
callback can be a function or a string.
What is a good way to check for the existence and validity of these types of arguments without rewriting the same code over and over?
Any suggestions and ideas would be great.
Thanks for reading.

It depends to what extent you want to do this. In idea would be to create a validation function which takes a argument -> rule mapping. E.g.:
function foo(somestring, somenumber) {
var rules = {
'somestring': Validator.rules.isString,
'somenumber': Validator.rules.inRange(5,10);
};
}
Validator would contain the basic logic and some helper functions (rules):
var Validator = {
valid: function(args, rules) {
for(var name in rules) {
if(!rules[name](args[name])) {
return false;
}
}
return true;
},
rules: {
isString: function(arg) {
return (typeof arg === 'string');
},
inRange: function(x,y) {
return function(arg) {
return !isNaN(+arg) && x <= arg && arg <= y;
}
}
}
}
This is just a sketch, it certainly can be extended (like accepting multiple rules per argument), but it should give you some idea.
That said, you don't have to check every argument. Provide decent documentation. If people use your plugin in a wrong way, i.e. passing wrong argument types, then your code will throw an error anyway.
Update:
If want to do this very often, then a good idea is to write a wrapper function and you just pass the function and the rules to it:
function ensure(func, rules, context) {
context = context || this;
return function() {
if(Validator.valid(arguments, rules)) {
return func.apply(context, arguments);
}
return null; // or throw error, whatever you want
}
}
Then you can define your function normally as:
var foo = function(somestring, somenumber) {
// ...
};
and just add validation to it:
var rules = {...};
foo = ensure(foo, rules);
You could even consider to make ensure accept a callback which gets called on error or success of the function, instead of returning a value. There are a lot of possibilities.

How to determine if a function is empty

I want to be able to check whether a given function is empty or not. That is, there is nothing in its body, eg:
function foo() {}
function iAmEmpty(a) {
// yep, empty
}
With some initial playing around, I've got something which I think might be ok, by using toString() and some regexes.
function foo(a, b, c) {}
/^function[^{]+\{\s*\}/m.test(foo.toString()); // true
function bar(a, b, c) { var d; }
/^function[^{]+\{\s*\}/m.test(bar.toString()); // false
I was just wondering if there was a better approach? Are there any problems with the above you can see?

This isn't advisable. There is no standard determining precisely what a function's toString() method should return, so even if you get this working in current browsers, future browsers may justifiably change their implementation and break your code.
Kangax has written briefly about this: http://perfectionkills.com/those-tricky-functions/

Arrow functions...
As I am sure you are aware, javascript supports arrow functions which are really succinct but unfortunately don't work with your neat regex.
I quickly converted your nice regex into its own function which takes a function as an input and returns whether or not it is empty for simplicity later. Just to demonstrate how arrow functions can be widely used, I put it in one:
isEmpty = f => /^function[^{]+\{\s*\}/m.test(f.toString())
Now, we can easily test an empty function:
function eF() {}
which as we would expect with isEmpty(eF) returns true.
And once more with an actual function:
function retOne() {return 1;}
which again as expected with isEmpty(retOne) returns false.
However, the issue I encountered was with arrow functions so to initialize an empty one again, we have a shorter syntax of the original:
eF = () => {}
and the 'stringified'version of that is quite different to the one before:
"() => {}"
so of course in this case the call isEmpty(eF) returns false when we want true. I'm not sure if you require to test if all functions (i.e. including arrow functions) are empty but if you do, your regexwill need modifying...
I am not great at writing them myself, but have attempted a couple and one further thing that you might want to consider is the lenient nature of the arrow functions especially this part of the documentation:
(param1, param2, …, paramN) => { statements }
(param1, param2, …, paramN) => expression
// equivalent to: (param1, param2, …, paramN) => { return expression; }
// Parentheses are optional when there's only one parameter name:
(singleParam) => { statements }
singleParam => { statements }
which shows how the curly brackets {...} are not always necessary. So this function:
retOne = () => 1
is valid and could make forming a new regex more difficult. One workaround I thought of is to just remove all curly brackets from f.toString() using:
str.replace(/[{}]/g, '').
and then work with a regex test from there.
Hopefully this is something helpful to consider if you want arrow functions to also be able to be tested.

The best thing you can try, to fit the maximum possibilities (as this is pretty hard to achieve), is to add acorn or esprima (works with arrow functions too) libraries and process the JavaScript function. It will tokenize it for you to parse, so you can process it to your likings, checking if there's actually zero code inside, or there's only variable declarations without any calculation nor return, etc...
Is pretty straightforward to implement:
function check(f) {
console.log("");
console.log("Checking", f);
var syntax = esprima.parse(f);
if (syntax.body.length != 1) {
console.log("Weird process");
} else {
function processBody(body) {
if (!body || body.length == 0) {
console.log("Body seems empty. YAY!");
} else {
for (var i = 0, command; command = body[i]; i++) {
if (command.type != "VariableDeclaration") {
console.log("Body has a", command.type, ", so is not empty.");
return;
}
}
console.log("Body has only variable declarations, so is empty! (or not, whatever fit your needs)");
}
}
function process(dec) {
if (dec.type != "FunctionDeclaration") {
console.log("Weird declaration");
} else {
console.log("Function", dec.id.name, "has", dec.params.length, "params");
processBody(dec.body.body);
}
}
process(syntax.body[0]);
}
}
check("function hasReturn(arg1, arg2) {var a = arg1 + arg2;return a;}");
check("function hasArgumentsButNoBody(arg1, arg2) {}");
check("function isCompletelyEmptyWithSpacesAndTabsAndLinefeeds() { \t \t \r\n \r\n }");
check("function hasOnlyVariables() {var a, b = 2; var c = 1 + b;}");
<script src="https://cdnjs.cloudflare.com/ajax/libs/esprima/2.7.3/esprima.min.js"></script>
This will not run the functions, just parse them, so is safe to run with non-secure functions.

I don't see the use for this, but you could make it simpler by anchoring the pattern to the end of the string.
/[^{\s]\s*\}$/.test(String(bar))

Function.prototype.hasBody = function() {
return !/{\s*}$/.test(this.toString());
};

It's simple just check the function contain and then check the contain if it's empty or not .
check this Plunker
here's full working code:
function foo(a, b, c) {}
function bar(a, b, c) {
var d;
}
function isEmpty(value) {
return (value == null || value.length === 0);
}
function check(test) {
var entire = test.toString();
var body = entire.slice(entire.indexOf("{") + 1, entire.lastIndexOf("}"));
return body;
}
console.log(isEmpty(check(foo)), isEmpty(check(bar))); //return true false