Readable promise logic flow

Question

I am trying to figure out what the best practice is for structuring Promise logic with both modals and http requests. Say I have a situation like this:

// normal logic flowing to here
// ...
// encounter special case

if (needToDoSomeGuidedPreprocessing) {
    doSomeAsyncHttpCall
    .then(doSomeStuff);
    .then(sendUpSomeDialogThatNeedsToConfirmToProceed)
}

// ...
// if dont need guided preprocessing, continue to normal operations 
// (includes more dialogs). Also, if guided preprocessing worked, make sure
// code down here doesn't fire until pre-processing is done (i.e. all these
// operations need to be done sequentially, so .all( ) wont work

How can I accomodate my code to be readable here?

I thought of this but thought maybe there is some better way? The problem is that I have yet more async methods/dialogs after this, and would prefer to keep in a singular method rather than jumping out to an entirely new method.:

// ...
// encounter special case

if (needToDoSomeGuidedPreprocessing) {
    doSomeAsyncHttpCall
    .then(doSomeStuff);
    .then(sendUpSomeDialogThatNeedsToConfirmToProceed)
    .then(callSomeCommonMethod)
}
else{
  callSomeCommonMethod()
}

// ...

Is this just the nature of dialogs/async operations or am I doing something wrong?

Your code *does* look pretty readable. What's wrong with it? — Bergi, Aug 25 '15 at 23:01
Possible duplicate of [if-else flow in promise](http://stackoverflow.com/q/26599798/1048572)? If you agree, I'll close, if not I'll elaborate. — Bergi, Aug 25 '15 at 23:02
Yes, it needs to run in sequence. The output of the initial operations feeds into the next. I'll mention that callSomeCommonMethod has a ton of code as well — maschwenk, Aug 25 '15 at 23:04
Bergi, I see your answer to the duplicate. I was thinking along the same lines but it seems this is a misappropriation of a promise in a way. But, I'll probably end up doing it how you suggested there. Thanks!! — maschwenk, Aug 25 '15 at 23:08
Bergi, New Dev provided a very similar and elaborated answer, I'll leave it to you if you want to close or not. — maschwenk, Aug 25 '15 at 23:18
@maschwenk: Well, it only looks odd at the start of a promise chain. Inside a `then` chain, where you could just `return` undefined instead of `Promise.resolve()`, it feels totally natural :-) — Bergi, Aug 25 '15 at 23:56

score 1 · Accepted Answer · answered Aug 25 '15 at 23:15

If your operation could be async, it should always be treated as if it's async to the outside world, even if under certain (or even most) conditions it is sync.

So, to accomplish that, the function should return a promise.

Other than that, .then chaining provides the sequential processing you need. Otherwise, your code is pretty readable.

function doSomething(){

  var promise = $q.resolve();

  if (needToDoSomeGuidedPreprocessing){
    promise = promise.then(doSomeAsyncHttpCall)
                     .then(doSomeStuff)
                     .then(sendUpSomeDialogThatNeedsToConfirmToProceed)
  }

  promise = promise.then(callSomeCommonMethod);

  // etc...

  return promise;
}

Readable promise logic flow

1 Answers1