[Résolu] Utilisation de fetch

Bonjour à tous
Dans le cadre du passage de l'un de mes sites en "JavaScript à la mode", j'essaie de comprendre comment utiliser fetch.
La documentation dit

a écrit :
Ce genre de fonctionnalité était auparavant réalisé avec XMLHttpRequest. Fetch fournit une meilleure alternative

Avant de savoir si c'est "meilleur" j'aimerais d'abord comprendre comment on s'en sert, et c'est loin d'être le cas.

Depuis des années, chaque fois que je veux obtenir des données depuis mon site, j'utilise une fonction

function GetRemoteData(url, data, whenDone, args){
	const xhr = new XMLHttpRequest();
	xhr.onreadystatechange = function() {
		if(this.readyState == 4 && this.status == 200) {
			whenDone(this.responseText, args);
		}
	}
	xhr.open('post', url);
	xhr.send(JSON.stringify(data));
}

C'est effectivement un peu complexe comme code, mais je n'y touche jamais (la dernière modif a été de remplacer "var" par "const").
Je me contente d'appeler la fonction en écrivant

GetRemoteData(url, data, whenDone[, args]);

où "url" est la page (.php général) à appeler, "data" les données sous la forme d'un objet qui sera transmis en JSON à la page en question, "whenDone" la fonction appelée lorsque la requête est terminée avec le résultat comme paramètre et éventuellement des paramètres supplémentaires dans "args". En fait dans 95% des cas la fonction à appeler est une méthode d'objet et je n'ai pas besoin d'arguments car la méthode retrouve les infos dans les propriétés de l'objet.

J'ai essayé d'écrire cette fonction en utilisant fetch, je n'arrive à rien et plus je lis la documentation moins je comprends.
Peut être devrais-je arrêter à mon âge d'essayer de comprendre les nouvelles techno ?
Modifié par PapyJP (08 Nov 2022 - 17:49)

Bonjour,

Il me semble qu'on peut se contenter de ça :

async function GetRemoteData(url, data, whenDone, args)
{
	fetch(url, {method: 'POST', body: JSON.stringify(data)})
	.then(r => r.text())
	.then(r => whenDone(r, args));
}

On peut aussi bien sûr rajouter du traitement d'erreurs.

Amicalement,
Modifié par parsimonhi (09 Nov 2022 - 23:25)

PapyJP a écrit :

Je suis très perturbé par cette syntaxe qui ne m'est pas familière et ne correspond à rien de que j'ai pratiqué depuis 65 ans et qui est pour beaucoup dans le fait que je n'ai pratiquement rien compris dans les documents que j'ai lus.

Tant que tu n'as pas lu et assimilé les promesses et le traitement asynchrone, tu ne pourras pas comprendre les concepts.

PapyJP a écrit :

Tout d'abord écrire fetch() .then() .then(); me semble farfelu. Je ne comprends pas quand les ".then()" s'exécutent.

niuxe a écrit :

Pour faire court, fetch() va te retourner un objet Promise (une réponse). Toutefois, il faut savoir que certaines méthodes comme .json() vont te retourner une promesse.

Tu n'as pas bien lu ma réponse et les liens que je t'ai partagés à ton sujet. J'ai été précis et concis. J'ai préféré partager les liens. Ainsi, tu as une documentation optimale pour comprendre les concepts liés à fetch.
Je pense qu'une relecture s'impose :
- les promesses

PapyJP a écrit :

Est-ce que cela correspond aux "await" de ce que j'ai écrits, c'est à dire qu'un ".then" s'exécute à la complétion de l'opération qui le précède ?
Ensuite les "r" semblent venir de nulle part. Est-ce que "r" veut dire "résultat de l'action précédente?

Je pense qu'une relecture s'impose aussi :
- closures

PapyJP a écrit :

Par ailleurs je n'ai pas non plus compris comment on faisait pour traiter les refus, soit par exemple une erreur 404 sur l'exécution du fetch, ou bien pas de texte dans la réponse, ou encore -- si on utilise .json() au lieu de .text() -- si le texte reçu n'est pas du json.

Je pense qu'une relecture s'impose :
- les promesses
- Error

PapyJP a écrit :

Un peu d'explication pourrait m'aider dans la compréhension de ce qui se présente comme étant du JavaScript mais a l'apparence d'un nouveau langage.

La syntaxe a légèrement changé. Mais les fondements du langage restent les mêmes.


@parsimonhi: async/await ==> tu as plus de souplesse et un code plus concis (ça t'évite les grappes de codes imbriqués dans des promesses). async/await = ES2017 (de mémoire)
Modifié par niuxe (10 Nov 2022 - 18:43)

PapyJP a écrit :
Il me semble que j’ai compris les mécanismes qui sont relativement simples.

C'est le principal. Cependant, derrière ce mécanisme simple, il y a beaucoup de concepts/théories à aborder. Tant que ça n'est pas acquis, la compréhension de l'api fetch ne peut être appréhender correctement.

Pourquoi fetch ?
L'objet XMLHttpRequest vient d'un autre temps. fetch va rendre ton code nettement plus homogène (pas forcément plus concis) et plus lisible.
Modifié par niuxe (10 Nov 2022 - 18:04)

PapyJP a écrit :
Tout d'abord écrire fetch() .then() .then();; me semble farfelu.

Je viens de comprendre pourquoi tu n'assimiles pas bien la suite des méthodes then(). En POO, lorsque tu veux enchainer les appels aux méthodes d'un objet, tu dois soit, lui retourner lui-même (this), soit retourner une instance d'un objet.

class A{
        constructor(){
            console.log('A');
        }

        run(){
            console.log('run A');
            return this;
        }

        get(){
            console.log('get A');
            return this;
        }
    }

    class B{
        constructor(){
            console.log('B');
            this.a = new A()
        }

        run(){
            console.log('run B');
            return this.a
        }
    }

    let aa = new A();
    aa.get().run().get().run();

    let bb = new B()
    bb.run().get()

niuxe a écrit :
Pour faire court, fetch() va te retourner un objet Promise (une réponse). Toutefois, il faut savoir que certaines méthodes comme .json() vont te retourner une promesse.

Modifié par niuxe (10 Nov 2022 - 18:28)

J’ai fini par comprendre ce qui m’empêchait d’aller plus loin, c’est de fait que les .then ne soient pas directement accolés à l’objet.

Quand j’ai appris ce langage il y a… très longtemps une fin de ligne signalait la fin d’une instruction (avec ou sans ";")
On n’utilisait".property" ou ".method()" que dans le portée d’une instruction "with".

with(myObject) {
   .a = ….;
   var b = .myMethod(…);
   ……
}

et il n’était pas question de ne pas accoler l’utilisation d’une propriété ou d’une méthode au nom de l’objet.

Apparemment on considère aujourd’hui que "a.b.c" peut s’écrire "a
.b
.c"
Ce n’est peut-être pas une nouveauté mais pour moi c’est le contraire de ce que j’ai pratiqué depuis 30 ans.

Quand je disais que c’était une histoire de syntaxe…
Modifié par PapyJP (11 Nov 2022 - 09:08)

Suite à cette discussion à laquelle je vous remercie d'avoir participé, j'ai d'abord vérifié comment se comporte le moteur JavaScript par rapport au "."
Ma conclusion est que "." se comporte comme un opérateur, on peut mettre des espaces ou des newlines de part est d'autre.
De même qu'on écrit

let a = b+c;
let a = b +c;
let a = b + c;
let a = b
+
c;

on peut écrire

let a = myObject.b;
let a = myObject .b;
let a = myObject . b;
let a = myObject
 . 
b;

(même si le dernier exemple n'est pas à recommander, car autant un "+" tout seul sur un ligne se lit aisément il n'en est pas de même pour un "."

C'est peut-être évident pour vous, mais c'est une découverte pour moi.

J'ai écrit (et testé) la fonction sous la forme suivante

async function GetRemoteData(url, data, whenDone, args){
	fetch(url, {method: 'POST', body: JSON.stringify(data)})
		.then(response => response.text())
		.then(text => whenDone(text, args));
}

l'indentation et l'utilisation de "response" et "text" correspondent à mes "bonnes pratiques" d'écriture de code : si je dois relire ce code dans 2 ans je devrais le comprendre sans difficulté.

Reste à écrire les traitements d'erreur.
J'ai essayé sans succès d'écrire

async function GetRemoteData(url, data, whenDone, args){
	fetch(url, {method: 'POST', body: JSON.stringify(data)})
		.then(response => {
			if(responses.ok) return response.text();
			else alert(response.error());
		})
		.then(text => whenDone(text, args));
}

Qu'est-ce qui cloche dans ce code ?

Bonjour,

1) Il y a un "s" en trop dans l'expression "responses.ok".

2) La méthode error() n'est pas "disponible ici de toute façon ( voir https://developer.mozilla.org/en-US/docs/Web/API/Response/error ). Mais tu peux par exemple utiliser response.status ou response.statusText, ou encore fabriquer tes propres messages d'erreur selon le status de response. Par exemple :

async function GetRemoteData(url, data, whenDone, args){
	fetch(url, {method: 'POST', body: JSON.stringify(data)})
		.then(response => {
			if(response.ok) return response.text();
			else {
				alert("Error: "+response.statusText);
				return false;
			}
		})
		.then(text => whenDone(text, args));
}

3) J'ai pour habitude de faire en sorte que la ligne else alert(...) retourne comme la ligne if(...) qui est juste au dessus quelque chose en plus du alert(...) (genre un simple return false ou ce que tu veux d'autre), afin que le .then(text => whenDone(text, args)); puisse savoir sans ambiguïté qu'il y a eu une erreur à l'étape précédente en testant si text vaut false ou ce que tu as voulu d'autre. Ou alors tu peux utiliser le mécanisme throw ... catch. Comme je sens qu'on va y arriver dans pas longtemps de toute façon, voici un exemple :

async function GetRemoteData(url, data, whenDone, args){
	fetch(url, {method: 'POST', body: JSON.stringify(data)})
		.then(response => {
			if(!response.ok) throw response.statusText;
			return response.text();
		})
		.then(text => whenDone(text, args))
		.catch(error => alert("Error: "+error));
}

Amicalement,
Modifié par parsimonhi (11 Nov 2022 - 15:53)

Merci. Je commence à y voir plus clair.

Sauf le .catch()
Écrit comme ça ça semble être une méthode du dernier objet retourné par le .then qui le précède lequel ne retourne rien me semble-t-il, ou alors c’est le return de la fonction whenDone mais là aussi ce n’est pas sensé retourner quelque chose.
Encore une subtilité d’écriture qui m’échappe.
Modifié par PapyJP (11 Nov 2022 - 15:04)

Merci à vous, c'était super intéressant (j'ai toujours eu du mal avec l'asynchrone). Votre discution donne une autre perspective que celle des tutoriels, une approche complémentaire en quelque sorte. Made in cocorico, ce qui n'est pas dommage, ça change de stackoverflow.