Bonjour, je suis en train de me former sur Angular sous IONIC en ce moment et je bute sur le concept des promises.

de ce que j'ai compris on utilise les promises quand a besoin d'aller chercher des données brutes mais on ne sait pas quand on les recevra ? quand on recevra les informations il fera un callback pour nous renvoyer les infos ?
du coup vu que c'est une requete asynchrone on ne bloque pas les instructions et on passe a la suite

quelqun de pédagogique peut confirmer mes dires ? merci

Alors, je ne suis pas spécialiste d'Angular, mais en javascript classique, oui, c'est l'idée.

Enfaite, la Promise permet d'éviter d'avoir un enfer de callback.

Imagine, prenons un évènement asynchrone par excellence, comme un call AJAX ou XHR:
Par défaut, javascript va passer dessus, et ne pas attendre la réponse pour continuer.

Maintenant, si jamais cette réponse était vitale pour la suite, par défaut on va tenter d'utiliser les callbacks (par exemple en ajax, définir une fonction pour le paramètre success, le paramètre error, ...)

Le soucis, c'est quand tu veux appeler des callbacks de callbacks, tu veux pouvoir faire un peu plus d'abstraction pour que ton code deviens pas illisible. De même si tu dois faire des enchainements, attendre le retours de différents calls, ... Ca devient très vite ingérable, et ce n'est pas optimisé (devoir vérifier que tout les retours sont arrivé avant de faire quelques choses peut devenir l'enfer ainsi).

Alors les Promises sont la solution:
Par exemple, il te suffit d'écrire une fonction toute simple qui retourne une nouvelle promise, dans cette promise tu met la logique faisant un call ajax, avec dans sa callback de success l'appel au paramètre "resolve" de la promise, et dans sa callback d'erreur le "reject".

Du coup, après avoir appelé ta fonction tu peux directement faire un .then() qui te permettra de gérer les cas de succès ou d'échec (via 2 fonctions en paramètres du then), de la promise, et donc un code potentiellement plus propre.

Maintenant il y a encore mieux, si tu push dans un tableau le retour des appels à cette fonction et même à d'autres function retournant une Promise, tu obtiens un tableau de promises, et grâce à ça, tu peux par exemple faire un:

Promise.all(tableauDePromises).then(
function(tableauDeRetourDesPromises){ /* ... en cas de succès */ },
function(erreurs){ /* ... en cas d'erreur a au moins une promise */ }
);

(il y a encore d'autres cas de figure possible amené par les Promises comme la fonction Promise.race, ... mais voilà le principal à mes yeux )

En NodeJS 8 et + (j'ai oublié la version ES pour le javascript client-side...), il y a une alternative au Promise aussi connu dans d'autres langages qui sont les mots-clefs "async" et "await" (qui en soit ne cache que l'usage d'une Promise en vrai... Mais c'est pour réduire encore la dose de code à écrire...)

(j'ajouterais en dernier, que tu peux simuler des comportements de Promises sans avoir besoin de serveur ou de call AJAX à l'aide de setTimeout() en t'en servant par exemple dans une Promise avec le resolve ayant lieu après quelques secondes)

ok je comprends mieux
je viens de découvrir qu'on peut ajouter async et await devant les fonctions pour déclarer le comportement.
est-ce vraiment utilse ? sur ce site :https://labs.encoded.io/2016/12/08/asyncawait-with-angular/
ils disent qu'on peut du coup stocker le resultat d'une promise dans une variable

Les mots clés async await sont juste du sucre syntaxique pour éviter d'avoir des .then() qui s'enchainent, ce qui rend le code nettement plus sympa a lire.

Une méthode notée async renverra toujours une promesse. Le await joue le rôle du .then()

exemple :

Moche

function multipleApiCalls() {
    apiCall().then(result => {
        apiCall2().then(result2 => {
            apiCall3().then(result3 => {
               console.log('quel enfer !!')
            })
        })
    });
}

Beau

async function multipleApiCalls() {
    const res = await apiCall();
    const res2 = await apiCall2();
    const res3 = await apiCall3();
    console.log('cest mieux !!!');
}

mais du coup je dois utiliser des promises ou des observables ?
quelle est la différence et l'utilité ?

c'est le concept de "flux de donnee" que j’assimile pas, je pense que l'exemple d'un fichier telechargé peut etre interessant a etudié
si je recupere mon fichier avec une promise cela ne pose aucun probleme ? je reçoit un fichier d'un coup ?
et avec une observable je reçoit les données au fur et a mesure ?

(J'ai oublié de préciser dans mon message précédent mais voit l'utilisation de l'async await comme écrire du code asynchrone de maniere synchrone, ca présente bien l'utilité de ces mots clés)

Autant les promesses que les obervables te permettent de gérer l'asynchronisme, tout ce que permet une promesse est aussi géré par les observables (il y a d'ailleurs une méthode toPromise() pour switcher de l'un a l'autre si nécessaire).

Quand tu utilises une promesse, faire .then() équivaut a faire un .subscribe() sur un observable.

Les observables sont beaucoup plus complets, le seul vraie avantage des promesses est justement la possibilité d'utiliser les mots clés async await, mais ils ne rendent pas non plus ces dernieres obsoletes.

Concretement, je te dirais d'utiliser les promesses dans le cas ou tu voudrais simplement consommer une api avec un appel http et recevoir la réponse.
Dans les autres cas, utilise des observables (cas typique d'utilisation, la gestion des événements click)

mais du coup quand j'utilises un pipe {{ maPromesse | async }} comment fait TypeScript pour chercher la valeur ? le .then est implicite ?

Exact

derniere ( peut etre ) question concernant le app.module.ts
durant les tutos on s'en sert pour declarer certaines choses
- un component --> on le declare dans entryComponents / declarations
- un service --> dans providers
d'ailleurs je n'ai toujours pas utilisé l'imports, a quoi sert t-il ?

Je sais ce qu'il faut y déclarer mais je ne comprends comment angular fait pour gérer.
je n'aime pas faire des choses betement sans comprendre vous voyez

imports fait partie du décorateur @NgModule, en gros, tu dois déclarer ici tous les autres modules dont tu as besoin dans ton module courant. De ce fait, tu auras directement accès aux composants, pipes et directives du module chargé.

mais du coup quand j'utilises un pipe {{ maPromesse | async }} comment fait TypeScript pour chercher la valeur ? le .then est implicite ?

async est ici une directive qui execute entre autre le .then() si c'est une promesse ou le .subscribe() si c'est un observable

c'est le concept de "flux de donnee" que j’assimile pas

Si ça t’intéresse je peux essayer de t'expliquer ce we (la je suis trop mort^^)

Le 05 janvier 2019 à 04:02:44 dark_drow a écrit :

mais du coup quand j'utilises un pipe {{ maPromesse | async }} comment fait TypeScript pour chercher la valeur ? le .then est implicite ?

async est ici une directive qui execute entre autre le .then() si c'est une promesse ou le .subscribe() si c'est un observable

c'est le concept de "flux de donnee" que j’assimile pas

Si ça t’intéresse je peux essayer de t'expliquer ce we (la je suis trop mort^^)

pas de prob merci

J'ai essayé de faire une mini présentation à des collègues il y a 3 mois et je leur ait présenté comme ça :

• Un Observable c'est une structure de données dans laquelle il y a une valeur qui va évoluer dans le temps sans vraiment que tu y touche
• Pour récupérer la valeur de cette "variable qui bouge" à chaque fois qu'elle change, on appelle .subscribe() et on récupère la valeur dans le callback
• Pour que l’Observable change de valeur il va généralement être abonné à un flux de donnée qui bouge (heure, position d'un avion dans le ciel, événement de clic, appel web...)

Là où la Promise va récupérer une valeur figée à un instant T et où on a la garantie que l'on ne passe qu'une fois dans le .then() ou le .catch(), l'Observable va passer dans le .subscribe() à chaque changement de valeur jusqu'à ce qu'il soit explicitement fermé par la source de donnée. Un observable qui se ferait fermer dès son premier changement de valeur serait l'équivalent logique d'une Promise (l'exemple que tu donnait faisait plus penser à Promise vs Stream)

Là ou c'est très fort, c'est que le subscribe() c'est la partie la moins intéressante de l'API des Observable (c'est le point de sortie) on peut surtout appliquer énormément de méthodes qui vont s'appliquer _avant_ que la valeur en question passe dans le subscribe(). Par exemple un filtre, ou un retry en cas d'erreur, ou concaténer avec le résultat d'un autre appel, afficher un message dans une interface web... On peut même concaténer plusieurs Observable et récupérer le changement de l'un des deux dans un subscribe() et plein de joyeusetés comme ça.

C'est un Framework à part entière pour gérer des états asynchrones et changeant, poussant une manière de programmer fonctionnelle et réactive (Functional reactive programming), Redux s'inspire un peu de ce genre de manière de penser aussi

Le 05 janvier 2019 à 11:45:18 dark_drow a écrit :
J'ai essayé de faire une mini présentation à des collègues il y a 3 mois et je leur ait présenté comme ça :

• Un Observable c'est une structure de données dans laquelle il y a une valeur qui va évoluer dans le temps sans vraiment que tu y touche
• Pour récupérer la valeur de cette "variable qui bouge" à chaque fois qu'elle change, on appelle .subscribe() et on récupère la valeur dans le callback
• Pour que l’Observable change de valeur il va généralement être abonné à un flux de donnée qui bouge (heure, position d'un avion dans le ciel, événement de clic, appel web...)

Là où la Promise va récupérer une valeur figée à un instant T et où on a la garantie que l'on ne passe qu'une fois dans le .then() ou le .catch(), l'Observable va passer dans le .subscribe() à chaque changement de valeur jusqu'à ce qu'il soit explicitement fermé par la source de donnée. Un observable qui se ferait fermer dès son premier changement de valeur serait l'équivalent logique d'une Promise (l'exemple que tu donnait faisait plus penser à Promise vs Stream)

Là ou c'est très fort, c'est que le subscribe() c'est la partie la moins intéressante de l'API des Observable (c'est le point de sortie) on peut surtout appliquer énormément de méthodes qui vont s'appliquer _avant_ que la valeur en question passe dans le subscribe(). Par exemple un filtre, ou un retry en cas d'erreur, ou concaténer avec le résultat d'un autre appel, afficher un message dans une interface web... On peut même concaténer plusieurs Observable et récupérer le changement de l'un des deux dans un subscribe() et plein de joyeusetés comme ça.

C'est un Framework à part entière pour gérer des états asynchrones et changeant, poussant une manière de programmer fonctionnelle et réactive (Functional reactive programming), Redux s'inspire un peu de ce genre de manière de penser aussi

merci de cette explication limpide, mais du coup il doit exister un nombre restreint de circonstance amenant a utiliser les promises ?