Javascript promises deep in the stack - javascript

I decided to have a fallback call to the server when creating a model in case we can't find a value from the information available locally. I want to have it async if possible, does it mean I have to make everything in this chain of code consume and return promises?
I'm going to use pseudo code to illustrate this point initially, as the call stack can be a little long and so we don't include things that aren't central to this question. Let me know if you need more to go on though.
function router() {
if (condition) {
controller.renderDocument(options);
}
}
controller.renderDocument(options) {
documentCollection.findOrCreateDocumentHolder(options);
}
documentCollection.findOrCreateDocumentHolder(options) {
var model = this.findOrCreateDocument(options);
}
documentCollection.otherFunction(options) {
// just to illustrate that there's several entry points to this kind of functionality
var model = this.findOrCreateDocument(options);
}
documentCollection.findOrCreateDocument(options) {
if (!options.type)
options.type = resolveType(options);
// other things that use the found options.type
return model;
}
resolveType(options) {
var locallyResolved = resolveLocally(options);
if (locallyResolved)
return locallyResolved;
// try the server as a fallback
var serverResolved = resolveFromServer(options.id);
return serverResolved;
}
resolveLocally(options) {
return stuff;
}
resolveFromServer(id) {
return ajaxRequestResult();
}
Obviously the actual code is a bit longer and actually does stuff.
It feels excessive to make all of this use chaining promises for the sake of 1 possible ajax request down the pipe, especially as this will be a rare occurrence. The other alternative is to just make a synchronous AJAX request.
Are my only options to make everything use promises and whens, or to make it a synchronous AJAX request? Is there a nicer alternative? I'm thinking of C#'s await keyword, but I'm sure other languages have similar functionality.

I want to have it async if possible, does it mean I have to make everything in this chain of code consume and return promises?
Yes. Something that is potentially asynchronous must always return a promise, and must always be consumed as if it was asynchronous (promises enforce this anyway).
Is the only other alternative to just make a synchronous AJAX request?
Yes, and you really don't want that.
Is there a nicer alternative? I'm thinking of C#'s await keyword, but I'm sure other languages have similar functionality.
In fact, async-await is coming to ECMAScript as well. But it doesn't make anything synchronous, it rather is just syntactic sugar for promises-everywhere.

Once you start with promises they do spread around, no way around it really since once you go async you must either wait (not feasible) or pass callbacks (which promises solve).
My approach is to embrace them, you'll be more often returning promises then immediate values, but you'll always take care of handling success/error and have a consistent way of dealing with data flow.
There are many more sources of asynchronicity than AJAX requests and I really can't think of a case where I would require a synchronous return value in Javascript.

Related

Async Function Call in Recursion using node js

How to call Async function in recursion actually I have Async method - async function getSSN(req,res,next) and inside this function block I need to call this function but when I call this method by code - return await getSSN(req,res,next) this code is not working for me in node js. Can anyone give me solution for that.?
So, you can't mix async/await with plain asynchronous callbacks. They do not work properly. Your async function getSSN() is not properly resolving when your request.get() finishes because that's just a plain asynchronous callback which the async function knows nothing about.
Instead, you need to use a promise-based request() option. Since, the request library is now deprecated and should not be used for new projects, I would suggest one of the alternatives that are all based on promises already. My favorite is the got() library, but you can look at the list of alternatives and pick the one that has a programming style you like.
In addition, your getSSN() function has a bunch of side effects (modifying higher scoped variables). This is not a good way to program, particularly for asynchronous operations because the outside world generally doesn't know when things are done and when the higher scoped variables have the values in them you want them to. You should make getSSN() return a promise that resolves to its result and then have the caller use that result to modify the higher scoped variables. Again, if you showed us the rest of the coding context here, we could suggest a better overall way to do this. Please notice here that you're just not providing enough code for us to be able to show you the best way to write this code. That should be a general lesson for stackoverflow. Err on the side of giving us more than you think and we can then often make suggestions and improvements far beyond what you even know to ask about.
Here's your function with all the ill-adivsed side effects still in it (because you haven't shown us the rest of the code) using got():
async function getSSN(next) {
const result = await got('idms.dealersocket.com/api/account/…').json();
if (count <= totalpage) {
const data = Object.assign({}, result.Data);
const len = Object.keys(data).length;
for (var i = 0; i <= len; i++) {
ssn.push(data[i].Row.Borrower1SSN);
}
count++;
}
}
Now, getSSN() will return a promise that resolves or rejects when the network request is finished.

Handling ajax request - Promise vs RxJs observable - rxjs operator preferences

I am using Rxjs Observables to handle nested ajax request like the following way:
Rx.Observable.fromPromise($.getJSON('list1.json'))
.switchMap(function responseA(aResponse){
/* processing aResponse*/
if(aResponse.fileName){
return Rx.Observable.fromPromise($.getJSON(aResponse.fileName));
}
return Rx.Observable.fromPromise($.getJSON('list2.json'));
})
.subscribe(function(finalResponse){
/* processing finalResponse */
});
But, as you know, it can also be done without using Observables and with only promises:
$.getJSON('list1.json')
.then(function responseA(aResponse){
/* processing aResponse*/
if(aResponse.fileName){
return $.getJSON(aResponse.fileName);
}
return $.getJSON('list2.json');
})
.then(function(finalResponse){
/* processing finalResponse */
});
Both code works, but it seems to me that it is more clean in terms of code to use promises.
Am I missing something here as I've heart that Rx Observable is more standard and efficient to handle asynchronous requests.
Which one (promise or Observable) will be the best in terms of code organization, convention and performances to handle ajax request ?
If I prefer to use Observable then which operators (switchMap/MergeMap) will be preferable in these kind of situation ?
Am I missing something here as I've heart that Rx Observable is more standard and efficient to handle asynchronous requests.
No, you're not missing anything. Rx is really useful but in that particular case promise based code is simpler.
In general, if you need a singular value - prefer a promise. If you need multiple values in/out - use observables (or the further ahead in spec async iterators).
Rx would be nice if you want to quickly need to add:
Retrying the requests if they failed (with Observable.defer).
Only caring about the last request.
If you need built in cancellation.
It's worth mentioning - promises can do all that if you use a library. It's not a fundamental property of observables.
Rx really shines if your input is more than a single call. If you needed to make these calls whenever the user clicks something, ignore clicks on some condition, debounce it to 100ms and then only care about the last call - Rx would be really useful.
In this particular case - promises are simpler and fine. Your promise code can be simplified further:
$.getJSON('list1.json').then(x => $.getJSON(x.fileName || 'list2.json'))
There are couple of really good articles out there in web, here is couple of them, I hope those will help you to understand the difference properly.
What Promises Do That Observables Can’t
https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises

How to avoid callback chains in asynchronous programing?

Just like How to avoid "if" chains?, this question is about what should be done to keep asynchronous programs clean.
Asynchronous programming is a totally different paradigm from procedural programming, and its really fun when you get your head around it. However, it can get messy when you have several asynchronous calls.
Consider this example (This is an abstraction of a real world scenario I encountered):
Read file a.txt
Submit contents of a.txt to server X for processing and retrieve the output.
Read file b.txt.
Send contents of b.txt, and the response from server X (step 2) to server Y, and get the output.
Save the response from server Y (step 4) to c.txt.
With asynchronous calls, my JavaScript looks similar to this (function names are made up. All functions are asynchronous calls with callbacks. Error parameters are omitted to improve clarity. Real code with error parameters and error handling is a lot messier than this):
readFile('a.txt', function (file_a_data) {
requestToServer('http://xserver.com/', file_a_data, function (server_x_response) {
readFile('b.txt', function (file_b_data) {
var request_params = server_x_response + file_b_data;
requestToServer('http://yserver.com/', request_params, function (server_y_reponse) {
writeFile('c.txt', server_y_response);
});
});
});
});
As you can see, there is already four levels of indentation, and an arrow of code is building up. How can we avoid this nesting of callbacks, and write some clean code?
What I have tried so far:
One way of doing this would be to write synchronous, no-callback versions of the functions, whenever possible. A value is returned and on error exception is thrown.
try {
var file_content = readFile('a.txt');
// do stuff with file_content
} catch (ex) {
// an error occured
}
But there are few problems with this:
For I/O heavy programs like this, the performance hit is very high.
Elementary API functions (such as XmlHttpReqeust, or Node.js File System API already have callbacks. They are the asynchronous parts, and there is little we can do other than writing thin, synchronous wrappers.
Making all callbacks named functions and just specifying the function name for the callback:
function processFileA(data) {
requestToServer('http://xserver.com/', file_a_data, processRequestX);
}
function processRequestX(response) {
readFile('b.txt', function (file_b_data) {
var request_params = server_x_response + file_b_data;
requestToServer('http://yserver.com/', request_params, processRequestY);
});
}
function processRequestY(response) {
writeFile('c.txt', server_y_response);
}
readFile('a.txt', processFileA);
This is similar to How to avoid hard-coded, chained asynchronous functions in Javascript/jQuery? This question looks like the inversion of my problem. The coding style of this question was one remedy I used to stop chains, but it does not look very nice. I think it looks like thin wrappers and spaghetti:
how to avoid callback chains?: A similar question (in title), but this is not really about asynchronous callbacks. This is about passing functions as parameters.
Use Promises! That's exactly what they were made for:
// assume 'readFile' and 'requestToServer' return a promise for their result
readFile('a.txt').then(function(file_a_data) {
return requestToServer('http://x.example.com/', file_a_data);
}).then(function(server_x_response) {
return readFile('b.txt').then(function(file_b_data) {
return server_x_response + file_b_data;
});
}).then(function(request_params) {
return requestToServer('http://y.example.com/', request_params);
}).then(function(server_y_reponse) {
writeFile('c.txt', server_y_response);
});
(Yes, it stays as clean as this, there is no additional, messy error handling code)
It might get even more clean if you leverage a bit of functional programming and use curried functions, or at least partially apply them. Even reading a and b in parallel would be trivially achievable:
Promise.all([
readFile('a.txt').then(requestToServer.partial('http://x.example.com/')),
readFile('b.txt')
])
.spread(function(server_x_response, file_b_data) {
return server_x_response + file_b_data;
})
.then(requestToServer.partial('http://y.example.com/'))
.then(writeFile.partial('c.txt'));

Asserting values in node.js

I have a function,
Edit1 - Updated function with real one because the previous one was simplified synchronous function and the code would have worked as correctly pointed by #AlexMA in the comments
'returnSuccessOrFailure': function () {
return driver.findElement(wd.By.css('div#button')).then(function (button) {
return button.getAttribute('class').then(function (status) {
return status;
});
});
}
In my node.js test, my assertion is failing because the assert is called before returnSuccessOrFailure finishes execution.
var value = returnSuccessOrFailure();
assert.equal(value,'success', 'Looks like something failed');
If I implement a promise in returnSuccessOrFailure and chain my assert then that works. My question is do I have to implement promises all the time for such situations to block the execution? I am new to Javascript and the async nature of it and any insight when to use promises and when not to would be useful.
you don't have to "implement a promise" in, just return the one you already have:
returnSuccessOrFailure': function () {
return driver.findElement(wd.By.css('div#button')).then(function (button) {
...
but then, yes, you do still need to put your assert in a done handler
returnSuccessOrFailure().done(function(value) {
assert.equal(value,'success', 'Looks like something failed');
}
Chaining you asserts will not only make it work but will also make for more readable code. Knowing what happens in what order can be useful when going back to refactor. Not only that but the structure of callbacks/promises also allow for easily written timer tests.
Also, since your test needs to have the current state of execution, it is more than likely that writing tests with asserts in callbacks is what you will need anyway.
My question is do I have to implement promises all the time for such situations to block the execution?
Notice that promises don't block the execution. They defer the execution of code that depends on the result, notice that you're still chaining callbacks on them.
I am new to Javascript and the async nature of it and any insight when to use promises and when not to would be useful.
Promises are useful wherever you have some code that might run asynchronously and needs to pass back an asynchronous result. Otherwise you would need to use callbacks, which are way more ugly than promises.
This is part of code contracts and representing preconditions (what holds before you execute), postconditions (what holds after you execute), and object invariants (what can not change). JavaScript does not have native support for this, but you can use third party libraries (Cerny.js, ecmaDebug, jsContract, or jscategory)
I think it depends on your coding style, is it EAFP(Easier to ask for forgiveness than permission) or LBYL(Look before you leap). Both are viable! In most compiled languages you would use LBYL. However in Python for example you would use EAFP.
Generally if you know you will fail you want to fail fast. If you like to use assertions to ensure code fails fast it is up to you.

Looking for if then else pattern with async library

I'm not so experienced/elegant programmer. I hope my question is understandable.
I have used java/c++ for most part of my life so my mind is object oriented. Then I learned python and I enjoyed very much functional mind. Now I'm approaching js. It is challenging because it is function based (and I liked it a lot), functional (with underscore I have a lot of pythonic iterutils methods) and asynchronous (it hurts).
A lot of time I have some back-end sync procedural flow like:
if exist(user):
foo(user)
# ok
else:
add(user)
# user added
Now I have to handle this with the so called callback hell:
exists(user, function(userExist) {
if( userExist ) {
foo( user, function(fooResult) {
/* ok */
});
} else {
add( user, function(addResult) {
/* user added */
});
}
});
Sometimes the controls are more nested: check for token, if token is valid check for user exists, if user exists check for valid parameters, then check for no error in foo on user, etc…
Those controls are simply synchronous and imperative-like. Nothing else to say. While with sync language like python I can handle this is (not elegant but at least) readable code with the use of small function that returns values , with javascript I don't know how to refactor things in readable small function. All functions I wrote does not have any return statements but just callback(something_weird_defined_in_caller_function) and I lost myself.
I don't think that promises are good on my case because are more for piping events, IIUC. So I'm looking for some pattern using async library to handle this case:
- continue to execute functions in series only if the previous one succeeded.
Please any help will be appreciated.
I don't think that promises are good on my case because are more for piping events, IIUC
No. Promises don't represent a stream of events to pipe, but a single result that will arrive later (asynchronously). This is exactly what they were made for, and they will give you imperative-like looking code (instead of a nesting callback hell).
Admittedly, you still need nesting for control structures. The code that you presented won't look much different except for the callbacks going into .then() calls, and promises being returned.
However, you can also use exceptions for control flow. Instead of using exists that returns a Promise<boolean>, you could use a find function that returns a Promise<User> which would get rejected when the user doesn't exist. It could be used like
find(user).then(function(/*user*/) {
return foo(user) /* .then(function(fooResult) {
…
}); */
}).catch(UserNotFoundError, function(e) {
return add(user) /* .then(function(addResult) {
…
}); */
});
Which of those to choose is debatable, rejections should be exceptional.

Categories