I'm creating this es6 class to organize documents in folders, and the class has one method that should be used by the user: go, example:

const options = {
 // options here.
};
const organizer = Organizer("path/to/folder", options);

// example
organizer.go().then(() => {

}).catch(console.error);

And inside the go method, i'm using Promises to control the flow of what i need to do:

class Organizer {
  constructor(path, options) {
    this.path = path;
    this.options = options;
  }


  go() {
    return Promise.resolve(getListOfFiles())
      .then(doSomethingOne)
      .then(doSomethingTwo)
      .then(etc)
  }

  getListOfFiles() {
    // use this.path to get list of files and return in a Promise way (resolve, reject)
    return new Promise((resolve, reject) => {
    });
  }

  doSomethingOne(files) {
    // something sync
    return .....;
  }

  doSomethingTwo(files) {
    // something async
    return new Promise((resolve, reject) => {
      // ....
    });
  }

  etc() {
  }
}

And i would like to know if I'm doing wrong by using Promises to control the execution flow, i never really program using the OOP paradigm, i always used FP, but in this case the options will be needed in several places.

Thank you.

I'm creating this es6 class to organize documents in folders, and the class has one method that should be used by the user: go, example:

const options = {
 // options here.
};
const organizer = Organizer("path/to/folder", options);

// example
organizer.go().then(() => {

}).catch(console.error);

And inside the go method, i'm using Promises to control the flow of what i need to do:

class Organizer {
  constructor(path, options) {
    this.path = path;
    this.options = options;
  }


  go() {
    return Promise.resolve(getListOfFiles())
      .then(doSomethingOne)
      .then(doSomethingTwo)
      .then(etc)
  }

  getListOfFiles() {
    // use this.path to get list of files and return in a Promise way (resolve, reject)
    return new Promise((resolve, reject) => {
    });
  }

  doSomethingOne(files) {
    // something sync
    return .....;
  }

  doSomethingTwo(files) {
    // something async
    return new Promise((resolve, reject) => {
      // ....
    });
  }

  etc() {
  }
}

And i would like to know if I'm doing wrong by using Promises to control the execution flow, i never really program using the OOP paradigm, i always used FP, but in this case the options will be needed in several places.

Thank you.

• javascript
• node.js
• oop
• functional-programming
• ecmascript-6

• Promises are an appropriate way to handle asynchronous operations. Wouldn't go() need to return the promise it creates, so that you can say organizer.go().then(...) as in your example? – nnnnnn Commented May 30, 2017 at 2:52
• Yes! Sorry, i already fixed that. – user7479925 Commented May 30, 2017 at 2:54
• For starters, you need to use new when creating an instance as in const organizer = new Organizer("path/to/folder", options);. – jfriend00 Commented May 30, 2017 at 3:20
• Ok, but the whole point of using the Promises with OOP? – user7479925 Commented May 30, 2017 at 3:34
• 2 You choose promises when you have asynchronous operations that you need to monitor or coordinate. You choose to use OOP when you have an object in which you want to encapsulate data/methods. You might choose to use the two together (depends upon what the methods do), but they two are pletely separate concepts and you choose each for its own reason. – jfriend00 Commented May 30, 2017 at 3:35

1 Answer 1

Aside from the invalid semantics, there is nothing inherently wrong about controlling the control flow of your program using promises.

Slight Corrections

As I said earlier, there are some erroneous semantics and logical errors in your code. Here is a rewrite of your code with inline explanation.

class Organizer {
  constructor(path, options) {
    this.path = path;
    this.options = options;
  }

  go() {
    // Use explicit 'this'
    // no need to call Promise.resolve
    return this.getListOfFiles() 
      .then(this.doSomethingOne) 
      .then(this.doSomethingTwo)
      .then(this.etc);
  }

  getListOfFiles() {
    return new Promise((resolve, reject) => {
      // todo
    });
  }

  doSomethingOne(files) {
    // todo
  }

  doSomethingTwo(files) {
    return new Promise((resolve, reject) => {
      // todo
    });
  }

  etc() {
    // todo
  }
}

Remendation

When it es to using promises as a flow control mechanism, it depends on personal preference. I've also encountered this design dilemma and I've learned that it is quite subjective. As a personal remendation, I would ask you to be careful how you name your methods and to make sure you are consistent on your use of promises.

If your getListOfFiles method returns a promise instead of an Array then make sure that another method called getSomething also returns a promise for consistency sake. Otherwise, you along with others who read your code might bee confused on the return types. Consistency is key, you can see this from other major libraries such as Selenium.

Try to be explicit. I suggest that instead of having getListOfFiles return a promise, getListOfFilesAsync should return a promise instead. The name getListOfFiles would suggest you are returning an Array-like object but you aren't - this is kind of deceptive and might hurt you in the long run. Try to add a suffix such as Async to functions that return a promise.