removing promise dependencies

Question

I'm aware of the power of promises, however I have several old functions that are synchronous:

function getSomething() {
  return someExternalLibrary.functionReturnsAValue()
}

console.log(getSomething()); // eg prints 'foo'

Unfortunately, when someExternalLibrary updated, it has removed functionReturnsAValue() and has lumped me with functionReturnsAPromise():

function getSomething() {
  return someExternalLibrary.functionReturnsAPromise()
}

console.log(getSomething());  // now prints '[object]'

This of course, breaks absolutely everything written that depends on what used to be a simple value.

Obviously, I'd prefer two things:

1. ask the original library to keep a synchronous return value. (Not going to happen -- b/c they have refused)
2. A way to actually wait for a value

I have read numerous articles on why promises are great, ad nauseam, but the simple fact is: If I embrace promises, all I really do is shuffle promises onto some other part of the code, which then must deal with the promise of a value...

Is there a way (in nodejs) to actually wait for a promise to get itself together?

The best I can find is to use coroutines and yield, but really, it's still passing the buck. To be clear, I want the function getSomething to continue to return a value. Is there a way to do it?

Clearly, I fear I've misunderstood something about Promises...

The app is for non-browser implementations and runs purely from the command line. I've been trying to understand how bluebird's reflect() might help, to no avail.

(Yes, I'm aware this question has been asked many times in various formats, but I can't find a suitable answer to the core issue. If anything, I'm looking for the opposite of this question. The closest related (but unhelpful) question I can find is: Managing promise dependencies.)

Answer 1

There's the concept of generator functions. These are a special kind of function in both syntax (asterisk notation) and semantics. Unlike regular functions, generator functions return something that's also new to ECMAScript: iterators. Iterators happen to be objects made specifically to be iterated on, e.g. with the all new for...of loop. They can be also iterated on manually by calling their 'next' method. Each such call produces an object containing two properties: 'value' (iterator's current value) and 'done' (a boolean indicating whether we reached the last value of the iterable). However, the best thing about generator functions is their ability to suspend their execution each time a keyword 'yield' is encountered. Let's have a glimpse of how it all works together:

'use strict';

let asyncTask = () =>
  new Promise((resolve, reject) => {
    if (Math.random() > 0.5) {
      resolve(1);
    } else {
      reject(new Error('Something went wrong'));
    }
  });

let makeMeLookSync = fn => {
  let iterator = fn();
  let loop = result => {
    !result.done && result.value.then(
      res => loop(iterator.next(res)),
      err => loop(iterator.throw(err))
    );
  };

  loop(iterator.next());
};

makeMeLookSync(function* () {
  try {
    let result = yield asyncTask();

    console.log(result);
  } catch (err) {
    console.log(err.message);
  }
});

Answer 2

The short answer

I am told repeatedly: You can't undo functions that have been promisified.

Edit: An upcoming solution

It appears that the ES2017 (although still draft), goes a long way in making promisified code easier to work with: https://ponyfoo.com/articles/understanding-javascript-async-await

It seems that there is also a node library ready for this support too: https://github.com/normalize/mz.

Using this methodology, having apis converted to Promises won't be so bad (although it still appears that promises still poison the rest of the codebase):

const fs = require('mz/fs')

async function doSomething () {
  if (await fs.exists(__filename)) // do something
}

The rest of this answer is just a general commentary on the problem.

Why we need a solution

Let's start with a sample piece of traditional synchronous code, in 3 flavours from more 'older-fashioned' to 'newer':

This is the traditional javascript way, requiring exception based programming to handle unexpected errors:

function getSomething() {
    if (someproblem) throw new Error('There is a problem');
    return 'foo';
}

However, adding try/ catch statements becomes very laborious and tedious, very quickly.

With the advent of node.js, callbacks were made popular, which nicely circumvented the issue, since each caller was explicitly forced to deal with error conditions in the same callback. This meant less errors in the caller's code:

function getSomething(callback) {
    if (callback) {
        if (someproblem) 
            callback(new Error('There is a problem'), null);
        else 
            callback(null, 'foo');
    }
    return 'foo';
}

Then, the after some teething issues, node.js quickly proved itself for server-side communications, and people were amazed at the speed that asynchronous solutions provided. Node application frameworks like Express and Meteor grew, which focused on this.

Unfortunately, using the same callback scheme quickly became troublesome and the developers dealing in asynchronous code started using Promises in an effort to linearize the code, to make it readable, like the traditional (try/catch) code was.

The problem is that it got evangenlized too much. Everyone started thinking that Promises are the way to go. Personally, I call it a poison on a codebase. Once you have anything that uses Promises, your whole codebase must become asynchronous. This is not always a sensible nor a practical solution, IMHO.

The worst of all side effects is that the above function, even though it is completely synchronous, can be written in Promises too:

var bluebird = require('bluebird');

function getSomething() { 
    // IMHO, this is ridiculous code, but is increasingly popular.
    if (someproblem) return Promise.reject(new Error('There is a problem'));
    return Promise.resolve('foo');
}

For those who doubt this is a problem, perhaps should look at the SO question: How do I convert an existing callback API to promises?. Pay particular attention to #3, Node-style callback.

So, for anyone who cares, I would like to suggest that there needs to be a 'pill' for Promises. I urge that we need more than promises: we need results, and sometimes in a timely manner.

Take a look at the default node.js api. It does not use Promises. It also provides both synchronous and asynchronous calls to appropriate parts of the api (eg File System).

For those of you who feel tempted to downvote this answer: that is your prerogative, but there are clear issues on when Promises are not the answer, and I feel strongly that there are cases when we need to be able to re-synchronize decoupled code.

I also apologize for this 'blog-post' styled answer.