Use native promises before others

[mokkabonna]

Now that ES 2015 is final it would be better to use native promises before any external libraries. https://github.com/philschatz/octokat.js/blob/master/src/helper-promise.coffee#L17

I happened to be using jquery promises without knowing it.

The following also didn't chain properly, it resolved with a promise not the values.. not surprising as jquery promises are very broken. It also does not allow me to use catch. Not very nice since that is a standard method on a promise now.

var staleBranchCutoff = new Date().getTime() - (1000 * 60 * 60 * 24 * 90); //90 days in milliseconds
var staleBranches = self.repository.branches.fetch().then(function(branches) {
  return Promise.all(branches.map(function(branch) {
    return self.repository.branches(branch.name).fetch().then(function(branchInfo) {
      var branchLastCommitDate = new Date(branchInfo.commit.commit.author.date).getTime();
      if (branchLastCommitDate < staleBranchCutoff) {
        return branchInfo;
      } else {
        return undefined;
      }
    });
  })).then(_.compact);
});

staleBranches.then(function(stale){
  console.log(stale) //logs a promise, not an array of branch information
})

I can either wrap this in a proper promise implementation (I use bluebird) or works if I manually edit the octokat code to not use jquery.

[philschatz]

Thank you for the suggestion. The downside of using native promises seems to be that a user would get back a different type of Promise depending on how old the browser was, rather than if they chose to include jQuery in their project, and have to do additional detection on their part.

What if the constructor took an optional argument that disables the autodetection (like autodetectPromise: false)? Then, as part of a 1.0 release this could be revisited (giving time for browsers and libs like jquery to catch up).

[mokkabonna]

Yeah I actually thought of this but forgot to mention it. I assume the priority is to be backwards compatible. So an option like that is probably the best idea.

Alternatively something like this:

new Octokat({
  Promise: mypromiseLib
})

Similar to this: octokit/octokit.js#262

That way you can supply any promise lib you want as long as it is ES 2015 (still want to call it ES6 :)) compatible.

But for me any approach will do.

[philschatz]

Thanks for the feedback! Sorry it took so long to respond. #81 splits octokat into smaller pieces so users can opt-in to different features (like camelCase, Hypermedia, sending binary files) and that includes the Promise resolver (see plugins/promise/library-first, plugins/promise/native-first, and plugins/promise/native-only).

I hope that helps address this annoying "feature" 😄 .

[philschatz]

(Apologies for the late reply) Octokat now uses native promises before 3rd-party libraries (and will likely drop support for those soon). Please reopen this issue if you still have a problem.