Promesses et callback

L'API en question consiste à permettre de charger une image mais, si elle n'existe pas, d'en être informer (pour utiliser une image par défaut par exemple).

/**
 * @param {String} url de l'image
 * @param {Function} ok Callback appelé si l'image est chargée.
 * @param {Function} ko Callback appelé si l'image n'est pas 
 * chargée.
 */
const loadImage = function (url, ok, ko) {
    const image = new Image();
    image.onload = ok;
    image.onerror = ko;
    image.src = url;
};

API construite à l'aide de callbacks.

loadImage('myImage.jpg', () => {
    console.log('this is ok');
}, () => {
    console.log('this is pas ok');
});

Utilisation de l'API à callback

/**
 * @param {String} url Url de l'image
 * @return {Promise} Promesse résolue si l'image est chargée, 
 * en erreur si l'image ne l'est pas.
 */
const loadImage = function (url) {
    return new Promise((resolve, reject) => {
        const image = new Image();
        image.onload = resolve;
        image.onerror = reject;
        image.src = url;
    });
}

Définition de l'API par promesse

loadImage('myImage.jpg').then(() => {
    console.log('this is ok');
}).catch(() => {
    console.log('this is pas ok');
});

Utilisation de l'API par promesse

La première version est ce que j'écris depuis plus de dix ans (les fonctions flèches et le const en moins) ; la seconde est ce qu'on voit de plus en plus couramment, assez souvent d'ailleurs par un simple effet de suivisme ou de mode selon moi.

Laquelle de ces techniques est la meilleure dans ce cas précis ? J'aurai tendance à dire la première sans en être sur. La meilleure reste celle qui vous convient le mieux en tant que codeur et/ou utilisateur.

Et oui, les promesses ont un champ d'action et des avantages que n'offrent pas des APIs à callbacks.