Return promise on requests

[m4dz]

When running a request (run, create, destroy…) it may sometimes be useful to get a Promise rather than deal with callbacks. I think we can easily support both, and then let the playRequest helper returns a Promise too.

@aenario, sounds good to you?

[flyingrub]

could simplify https://github.com/cozy/cozy-browser-sdk/issues/14 too

[frankrousseau]

Ok but keep in mind that the last time someone experimented with Promises we met many issues again (ugly code, async chaining which was not clear and uncatched errors).

[aenario]

@frankrousseau , as the aforementioned someone :smiley_cat: , I agree we should probably wait for async / await to use promise in our own code. However, it makes sense for this library to propose both modes.

However, we shall not include a Promise implementation in there and instead use window.Promise if there is one.

[m4dz]

For our code, I agree too that we should wait for async/await as long as we can work w/o them currently. For our libs, maybe the use of window.Promise along the callbacks can be a nice solution. Also, use a native Promise is the best solution as long as the support is complete (but IE, and we probably won't support IE anymore with the large progression of Edge and our current customers).

Just to be clear, here is the context: in Cozic, we want to route to a playlist, but we need to wait the playlists' collection is fetched before. The fetch occurs at app init, so we must wait for it before routing. It's a perfect fit for a Promise.done call :smile:.

[frankrousseau]

@aenario I was not talking about you. But in your case we suffered from the uncatched error issues.

[flyingrub]

it seems we can close this one @aenario ?

[m4dz]

Bu curiosity, why closing this one @aenario ?

[aenario]

Because it was done in https://github.com/cozy/cozy-browser-sdk/commit/2c9839fb4697c4100d22b0d1cc058df91f608454