Use promises instead of callbacks

[tomwayson]

Carrying over the conversation from #7 (comment)

I agree promises are nice, but, I haven't figured out a good way to know which flavor of promises (if any) exist in the client app. I could say this library depends on promise polyfill, I suppose, but I don't want to trip anybody up, so I've catered to the lowest common denominator and left "promisifying" it up to framework-specific wrapper libraries like https://github.com/tomwayson/angular2-esri-loader that can be sure what kind of promises exist in the app.

If anyone knows of a good example of a framework-agnostic JS lib that is smart about how it uses promises (i.e. doesn't force the app to load a promise polyfill or library if it already has one), I'd certainly consider changing the API over to using promises.

[davetimmins]

I hadn't seen that Angular version before, but that was along the lines of what I was thinking so probably enough to stick with that approach until promises are natively supported.

[tomwayson]

Going from a callback based API to a promise based API is actually something that we're looking into for the next version of Cedar, so I floated this question on SO and got a good response.

I'm not sure when I'll get a chance to pitch an API for this library based on that^^^. Hopefully we'll move forward w/ that in Cedar and I'll be able to bring some of those ideas here.

In the meantime, I welcome suggestions here.

cc @benstoltz

[tomwayson]

The existence of esri-promise makes me wonder if it's worth releasing a promise based version of esri-loader that defaults to using built in promises. Apps that need to support IE can add a polyfill.

We can push the whole notion of allowing consuming apps to specify their own Promise implementation (i.e. if it's an Ember app, allow them to us RSVP, if it's an angular app, allow them to use core-js or whatever Angular uses these days), which has been mostly what has been holding me from this, can be it's own feature and added to a subsequent release.

[andygup]

@tomwayson FWIW angular 4+ uses ES2017 Promises.

[nicksenger]

Posted something similar in the esri-promise issue thread, but one concern with bringing in promises is that the JS API already uses dojo's promise implementation, so unless esri-loader also uses dojo/deferred, there will likely be 2 different types of promises floating around in the app.

I guess for many apps this is probably already the case when using the JS API, but something to consider

[andygup]

Yep, actually there could potentially be three different types of promises: dojo/deferred, plus whatever eari-loader ends up using, plus whatever approach is appropriate for each wrapper library...

[tomwayson]

This is why I don't want esri-loader to introduce a dependency on any promise library other than what is built into (real) browsers.