Normally if you aren't using promises you can easily do
var a = function(cb){
setTimeout(function(){
var boundCb = cb.bind({hello: 'world'});
boundCb();
}, 100);
};
a(function(){
alert(this.hello);
});
which isn't particularly useful most of the times (as you can pass the same things as normal arguments), but it does allow for some extremely readable code and/or simple to use interfaces.
When switching to promises however it suddenly becomes a lot harder to do. Unsurprisingly the following doesn't work (as resolve isn't a direct reference)
var a = function(){
return new Promise(function(resolve, reject){
var boundResolve = resolve.bind({hello: 'word'});
boundResolve();
});
};
a().then(function(){
alert(this.hello)
});
so is there any way at all to achieve this?
Non essential postscriptum: 'Luckily' in my situation the this scope I want to set is already the same as what the this scope is at a(). So I am currently simply writing .bind(this) after every single Promise callback function and in the future I will be able to use arrow functions for this, but I am looking for a cleaner solution in the interim.
Native Promises do not offer this functionality. However, the Bluebird Promise library offers Promise.prototype.bind
Here's an example usage
MyClass.prototype.method = function() {
return fs.readFileAsync(this.file).bind(this)
.then(function(contents) {
var url = urlParse(contents);
return this.httpGetAsync(url); // this is bound to the MyClass instance
}).then(function(result) {
// this is still bound, further down the chain.
var refined = this.refine(result);
return this.writeRefinedAsync(refined);
}).catch(function(e) {
this.error(e.stack); // Even in event handlers
});
};
Related
I use some Promise code used in my application as below;
import { Promise, resolve, all } from 'rsvp';
someAction: function(secId, fld, callback) {
var self = this;
var section = self.findSection(self.get('allSecs'), secId);
var myPendingPromise = section.myPendingPromise || resolve();
myPendingPromise = myPendingPromise.then(function(){
return self.myCustomPromise(secId, fld, callback);
});
set(section, 'myPendingPromise', myPendingPromise);
},
myCustomPromise: function(secId, fld, callback){
var self = this;
return new Promise(function(resolve, reject){
var deferred = self.myCustomRule(someFlds); //Makes an API call
deferred.then(function(response) {
resolve(response);
}, function(){
resolve(true);
});
});
},
Now, I am a bit confused why the following lines are added specifically;
var myPendingPromise = section.myPendingPromise || resolve();
myPendingPromise = myPendingPromise.then(function(){
return self.myCustomPromise(secId, fld, callback);
});
set(section, 'myPendingPromise', myPendingPromise);
Also, I did not find "myPendingPromise" used anywhere else apart from this function. Is there some pattern which I need to be aware of to be able to understand this code?
It would be great to understand just the usage of these 3 lines of code above.
What is that
It looks like an attempt to solve concurrency problem by adding all new promises to promise chain (queue). I prepared a simplified example based on your code that demonstrates how it works.
What exactly each line does:
//Extract pending promise from section object. If undefined, use resolve()
//to create and resolve dummy promise:
var myPendingPromise = section.myPendingPromise || resolve();
//Add new promise to chain, so it would start after
//pending promise is resolved:
myPendingPromise = myPendingPromise.then(function(){
return self.myCustomPromise(secId, fld, callback);
});
//Save new promise chain into section object:
set(section, 'myPendingPromise', myPendingPromise);
Why it's a bad solution to concurrency problem (my opinion)
A bit hard to read and understand
If promise takes a long time to finish and someAction is called many times, queue can grow uncontrollably long
It seems that nothing indicates to user that something is running
What is a good solution (again, my opinion)
Use library like ember-concurrency to manage concurrency
Avoid using queue strategy for concurrency problems. If you need to use "queue" strategy, take measures to limit queue length
Add some indication so user sees that button worked and request is happening. It's easy to do using ember-concurrency
In playing with Deferred's I see many different combinations of use. Most are the same, but occasionally I see ones that differ slightly.
FOR EXAMPLE...
NORMALLY, I SEE THIS:
Here we are merely using the Deferred.
// NORMALLY I SEE THIS...
function doSomething(){
var deferred = $.Deferred();
var myClass = new MyClass();
myClass.doSomething(function () {
deferred.resolve();
});
return deferred.promise();
};
OCCASSIONALLY, I SEE THIS:
Here we are passing a function into the Deferred's constructor...then using it.
// SOMETIMES I SEE THIS...
function doSomething() {
var deferred = $.Deferred(function (deferred) {
//Q: Is there an advantage to doing this instead?
//Q: Is this a mis-use?
var myClass = new MyClass();
myClass.doSomething(function () {
deferred.resolve();
});
});
return deferred.promise();
};
MY QUESTION IS:
Is there an advantage to doing the 2nd one instead?
Is this a mis-use of the constructor?
Does this practice create issue I just haven't seen yet?
I have yet to see any issue's arise from method 2. So, I'm looking for real insight here.
Is there an advantage to doing the 2nd one instead?
No, unless you enjoy callbacks which defeats the purpose of promises.
Is this a mis-use of the constructor?
Nope. jQuery deffered doc
jQuery.Deferred( [beforeStart ] )
beforeStart
Type: Function( Deferred deferred )
A function that is called just before the constructor returns.
Does this practice create issue I just haven't seen yet?
No it doesn't, unless you intended to use myClass somewhere else which won't be possible since it is defined within your callback.
Conclusion:
In the end, it's more of a personal preference. Solution 1 just seems more clean to be honest.
I'm defining a class which instantiates several modules which depend on previous ones. The modules themselves may require an async operation before they are ready (i.e. establishing a mysql connection) so I've provided each constructor with a callback to be called once the module is ready. However I've run into a problem when instantiating classes which are ready immediately:
var async = require('async');
var child = function(parent, cb) {
var self = this;
this.ready = false;
this.isReady = function() {
return self.ready;
}
/* This does not work, throws error below stating c1.isReady is undefined*/
cb(null, true);
/* This works */
setTimeout(function() {
self.ready = true;
cb(null, true);
}, 0);
}
var Parent = function(cb) {
var self = this;
async.series([
function(callback){
self.c1 = new child(self, callback);
},
function(callback){
self.c2 = new child(self, callback);
}
],
function(err, results){
console.log(self.c1.isReady(), self.c2.isReady);
console.log(err, results);
});
}
var P = new Parent();
I'm guessing the issue is calling cb within the constructor means async proceeds to the next function before the constructor finishes. Is there a better approach to this? I considered using promises, but I find this approach easier to understand/follow.
You will have to delay the call to the callback when everything is synchronous because any code in the callback won't be able to reference the object yet (as you've seen). Because the constructor hasn't finished executing, the assignment of it's return value also hasn't finished yet.
You could pass the object to the callback and force the callback to use that reference (which will exist and be fully formed), but you're requiring people to know that they can't use a normally accepted practice so it's much better to make sure the callback is only called asynchronously and people can then write their code in the normal ways they would expect to.
In node.js, it will be more efficient to use process.nextTick() instead of setTimeout() to accomplish your goal. See this article for more details.
var child = function(parent, cb) {
var self = this;
this.ready = false;
this.isReady = function() {
return self.ready;
}
/* This works */
process.nextTick(function() {
self.ready = true;
cb(null, true);
}, 0);
}
Here's a general observation. Many people (myself included) think that it overcomplicates things to put any async operation in a constructor for reasons related to this. Instead, most objects that need to do async operations in order to get themselves set up will offer a .init() or .connect() method or something like that. Then, you construct the object like you normally would in a synchronous fashion and then separately initiate the async part of the initialization and pass it the callback. That gets you away from this issue entirely.
If/when you want to use promises for tracking your async operation (which is great feature direction to go), it's way, way easier to let the constructor return the object and the .init() operation to return a promise. It gets messy to try to return both the object and a promise from the constructor and even messier to code with that.
Then, using promises you can do this:
var o = new child(p);
o.init().then(function() {
// object o is fully initialized now
// put code in here to use the object
}, function(err) {
// error initializing object o
});
If you can't put the object into a Promise, put a promise into the object.
Give it a Ready property that is a promise.
If you have a class hierarchy (I'm talking about Typescript now) of (say) widgets, the base class can define the Ready property and assign it an already resolved Promise object. Doing this is a base class means it's always safe to write code like this
var foo = Foo();
foo.Ready.then(() => {
// do stuff that needs foo to be ready
});
Derived classes can take control of promise resolution by replacing the value of Ready with a new promise object, and resolving it when the async code completes.
Here's a comprehensive workup of Asynchronous Constructor design pattern
I have several async functions with varying numbers of parameters, in each the last param is a callback. I wish to call these in order. For instance.
function getData(url, callback){
}
function parseData(data, callback){
}
By using this:
Function.prototype.then = function(f){
var ff = this;
return function(){ ff.apply(null, [].slice.call(arguments).concat(f)) }
}
it is possible to call these functions like this, and have the output print to console.log.
getData.then(parseData.then(console.log.bind(console)))('/mydata.json');
I've been trying to use this syntax instead, and cannot get the Then function correct. Any ideas?
getData.then(parseData).then(console.log.bind(console))('/mydata.json');
Implementing a function or library that allows you to chain methods like above is a non-trivial task and requires substantial effort. The main problem with the example above is the constant context changing - it is very difficult to manage the state of the call chain without memory leaks (i.e. saving a reference to all chained functions into a module-level variable -> GC will never free the functions from memory).
If you are interested in this kind of programming strategy I highly encourage you to use an existing, established and well-tested library, like Promise or q. I personally recommend the former as it attempts to behave as close as possible to ECMAScript 6's Promise specification.
For educational purposes, I recommend you take a look at how the Promise library works internally - I am quite sure you will learn a lot by inspecting its source code and playing around with it.
Robert Rossmann is right. But I'm willing to answer purely for academic purposes.
Let's simplify your code to:
Function.prototype.then = function (callback){
var inner = this;
return function (arg) { return inner(arg, callback); }
}
and:
function getData(url, callback) {
...
}
Let's analyze the types of each function:
getData is (string, function(argument, ...)) → null.
function(argument, function).then is (function(argument, ...)) → function(argument).
That's the core of the problem. When you do:
getData.then(function (argument) {}) it actually returns a function with the type function(argument). That's why .then can't be called onto it, because .then expects to be called onto a function(argument, function) type.
What you want to do, is wrap the callback function. (In the case of getData.then(parseData).then(f), you want to wrap parseData with f, not the result of getData.then(parseData).
Here's my solution:
Function.prototype.setCallback = function (c) { this.callback = c; }
Function.prototype.getCallback = function () { return this.callback; }
Function.prototype.then = function (f) {
var ff = this;
var outer = function () {
var callback = outer.getCallback();
return ff.apply(null, [].slice.call(arguments).concat(callback));
};
if (this.getCallback() === undefined) {
outer.setCallback(f);
} else {
outer.setCallback(ff.getCallback().then(f));
}
return outer;
}
This looks like an excellent use for the Promise object. Promises improve reusability of callback functions by providing a common interface to asynchronous computation. Instead of having each function accept a callback parameter, Promises allow you to encapsulate the asynchronous part of your function in a Promise object. Then you can use the Promise methods (Promise.all, Promise.prototype.then) to chain your asynchronous operations together. Here's how your example translates:
// Instead of accepting both a url and a callback, you accept just a url. Rather than
// thinking about a Promise as a function that returns data, you can think of it as
// data that hasn't loaded or doesn't exist yet (i.e., promised data).
function getData(url) {
return new Promise(function (resolve, reject) {
// Use resolve as the callback parameter.
});
}
function parseData(data) {
// Does parseData really need to be asynchronous? If not leave out the
// Promise and write this function synchronously.
return new Promise(function (resolve, reject) {
});
}
getData("someurl").then(parseData).then(function (data) {
console.log(data);
});
// or with a synchronous parseData
getData("someurl").then(function (data) {
console.log(parseData(data));
});
Also, I should note that Promises currently don't have excellent browser support. Luckily you're covered since there are plenty of polyfills such as this one that provide much of the same functionality as native Promises.
Edit:
Alternatively, instead of changing the Function.prototype, how about implementing a chain method that takes as input a list of asynchronous functions and a seed value and pipes that seed value through each async function:
function chainAsync(seed, functions, callback) {
if (functions.length === 0) callback(seed);
functions[0](seed, function (value) {
chainAsync(value, functions.slice(1), callback);
});
}
chainAsync("someurl", [getData, parseData], function (data) {
console.log(data);
});
Edit Again:
The solutions presented above are far from robust, if you want a more extensive solution check out something like https://github.com/caolan/async.
I had some thoughts about that problem and created the following code which kinda meets your requirements. Still - I know that this concept is far away from perfect. The reasons are commented in the code and below.
Function.prototype._thenify = {
queue:[],
then:function(nextOne){
// Push the item to the queue
this._thenify.queue.push(nextOne);
return this;
},
handOver:function(){
// hand over the data to the next function, calling it in the same context (so we dont loose the queue)
this._thenify.queue.shift().apply(this, arguments);
return this;
}
}
Function.prototype.then = function(){ return this._thenify.then.apply(this, arguments) };
Function.prototype.handOver = function(){ return this._thenify.handOver.apply(this, arguments) };
function getData(json){
// simulate asyncronous call
setTimeout(function(){ getData.handOver(json, 'params from getData'); }, 10);
// we cant call this.handOver() because a new context is created for every function-call
// That means you have to do it like this or bind the context of from getData to the function itself
// which means every time the function is called you have the same context
}
function parseData(){
// simulate asyncronous call
setTimeout(function(){ parseData.handOver('params from parseData'); }, 10);
// Here we can use this.handOver cause parseData is called in the context of getData
// for clarity-reasons I let it like that
}
getData
.then(function(){ console.log(arguments); this.handOver(); }) // see how we can use this here
.then(parseData)
.then(console.log)('/mydata.json'); // Here we actually starting the chain with the call of the function
// To call the chain in the getData-context (so you can always do this.handOver()) do it like that:
// getData
// .then(function(){ console.log(arguments); this.handOver(); })
// .then(parseData)
// .then(console.log).bind(getData)('/mydata.json');
Problems and Facts:
the complete chain is executed in the context of the first function
you have to use the function itself to call handOver at least with the first Element of the chain
if you create a new chain using the function you already used, it will conflict when it runs to the same time
it is possible to use a function twice in the chain (e.g. getData)
because of the shared conext you can set a property in one function and read it in one of the following functions
At least for the first Problem you could solve it with not calling the next function in the chain in the same context and instead give the queue as parameter to the next function. I will try this approach later. This maybe would solve the conflicts mentioned at point 3, too.
For the other problem you could use the sample Code in the comments
PS: When you run the snipped make sure your console is open to see the output
PPS: Every comment on this approach is welcome!
The problem is that then returns a wrapper for the current function and successive chained calls will wrap it again, instead of wrapping the previous callback. One way to achieve that is to use closures and overwrite then on each call:
Function.prototype.then = function(f){
var ff = this;
function wrapCallback(previousCallback, callback) {
var wrapper = function(){
previousCallback.apply(null, [].slice.call(arguments).concat(callback));
};
ff.then = wrapper.then = function(f) {
callback = wrapCallback(callback, f); //a new chained call, so wrap the callback
return ff;
}
return wrapper;
}
return ff = wrapCallback(this, f); //"replace" the original function with the wrapper and return that
}
/*
* Example
*/
function getData(json, callback){
setTimeout( function() { callback(json) }, 100);
}
function parseData(data, callback){
callback(data, 'Hello');
}
function doSomething(data, text, callback) {
callback(text);
}
function printData(data) {
console.log(data); //should print 'Hello'
}
getData
.then(parseData)
.then(doSomething)
.then(printData)('/mydata.json');
I know this is a base question... but I'll try to explain.
I've been using a Deferred, but someone pointed out that I'm using it as an anti-pattern.
Basically, I can use the deferred in the child module. BUT if this is an anti-pattern, what is the best way to achieve this in which the "child module" might not be there.. SO, I don't want to explicitly call the child method in the success of the parent ajax call.
So, three questions:
Is this a viable way, if not - what is a good way to achieve what I am going for?
Even though I am resetting the Deferred, it isn't seeming to 'reset'. Why?
CAN this also be achieved coupling it with another event - ie, onload. SO< we have the ajax AND onload doing the same thing.
I have a parent module.
var Z = {};
Z.someVar = $.Deferred();
Z.a = function(){
//methods
//Ajax call on page: can be once or multiple calls.
$AJAX = {
url:...,
dataType: ...,
//etc..
}.success(
function(){
Z.someVar.resolve();
}
).error();
};
// another method that MIGHT exist.
Z.b = function(){
var func1 = function(){
// do some stuff
Z.someVar = $.Deferred(); // reset it.
}
Z.someVar.done(function(){
func1();
})
}
A promise is an abstraction over a single, one time calculation of a value. A promise starts pending, and then can transition to either fulfilled or rejected state. Once a promise resolved (transitioned) it can never change its state again.
Deferreds are used in exactly one - when you want to construct a promise from something that's not a promise*.
In jQuery $.ajax already returns a promise to begin with.
Z.a = function(){ // this method now returns a promise
return $.ajax({...});
};
If we want to chain it, we can use .then :
Z.a().then(function(){
// here a() is done.
});
You can also use a caching pattern, using $.when (Promise.resolve in most promise libraries):
Z._a = null;
Z.a = function(){
if(z._a){ // already have the value cached:
return $.when(z._a); // promise over the value
}
return $.ajax({...}).then(function(res){
Z._a = res;
return res; // chain
});
};
Z.b = function(){
return Z.a().then(function(aValue){
// do something with value, your return value here is the resolution
// value of the a method call.
});
}
Now, if you want to wait for multiple calls, you can use $.when with multiple promises and get their results.
There are other, very rare use cases with aggregation