⚡ AJAX – Le Web Asynchrone

Le Problème : Le Web Synchrone (Bloquant)

Avant AJAX (début des années 2000), pour obtenir 1 seule nouvelle donnée (ex: la météo), le navigateur devait recharger la page entière. L'utilisateur voyait un écran blanc, le serveur devait tout recalculer (header, footer, menus...). C'était lent et consommateur de ressources.

Le JavaScript "Synchrone" est également "bloquant". Le thread principal du navigateur ne fait qu'une chose à la fois. Si une tâche est longue, l'UI est gelée.

// 1. Le bouton est cliqué
button.addEventListener('click', () => {
    // 2. Tâche *bloquante* (l'UI est GELÉE)
    alert("Vous ne pouvez rien faire...");
    
    // 3. (Seulement après 5s...) L'UI est libérée
    console.log("Fin");
});

La Solution : Le Web Asynchrone (Non-Bloquant)

AJAX (Asynchronous JavaScript and XML) est une *technique* (pas un langage) qui permet au JavaScript de faire une requête HTTP au serveur *en arrière-plan*, sans geler l'UI et sans recharger la page.

Le navigateur "délègue" la tâche (ex: fetch) et continue sa vie (l'UI reste fluide). Quand le serveur répond, il exécute une fonction "callback" (ou résout une Promise).

// 1. Le bouton est cliqué
button.addEventListener('click', () => {
    // 2. Tâche *non-bloquante* (déléguée)
    // L'UI reste 100% réactive
    fetch('/api/data')
        .then(res => res.json())
        .then(data => {
            // 4. (Bien plus tard) Ce code s'exécute
            console.log(data);
        });
    
    // 3. Ce code s'exécute IMMÉDIATEMENT
    console.log("Requête lancée, l'UI est fluide.");
});

Le "X" (XML) vs "J" (JSON)

Le nom est historique. Le "X" signifie XML. À l'époque, les données étaient échangées en XML (verbeux). Aujourd'hui, 99% des requêtes AJAX utilisent JSON, car il est léger et se "mappe" parfaitement avec les objets JavaScript (JSON.parse, JSON.stringify).

Exemple (GET)

Le "double .then()" est le piège classique. Le premier .then() reçoit la *réponse* (statut, headers), le second .then() reçoit le *corps* parsé.

fetch('https://api.example.com/data')
    // 1. La Promise est résolue avec un objet "Response"
    .then(response => {
        // 2. ON DOIT VÉRIFIER LES ERREURS HTTP MANUELLEMENT
        if (!response.ok) { // response.ok = true si status 200-299
            throw new Error("Erreur HTTP: " + response.status);
        }
        // 3. .json() retourne une *autre* Promise
        return response.json(); 
    })
    // 4. La 2ème Promise est résolue avec les données
    .then(data => {
        console.log(data);
    })
    // 5. Gère les erreurs RÉSEAU (ou le 'throw' ci-dessus)
    .catch(error => {
        console.error("Erreur Fetch:", error);
    });

Exemple (POST avec JSON)

Pour envoyer des données, on passe un 2ème argument (objet options) à fetch.

const userData = {
    username: "alice",
    role: "admin"
};

fetch('https://api.example.com/users', {
    // 1. Méthode HTTP
    method: 'POST',
    
    // 2. Headers (Comment on envoie)
    headers: {
        'Content-Type': 'application/json',
        // (On ajoutera 'X-CSRFToken' ici pour Django)
    },
    
    // 3. Corps de la requête (converti en string)
    body: JSON.stringify(userData)
})
.then(response => response.json())
.then(data => {
    console.log("Réponse du serveur:", data);
})
.catch(error => {
    console.error("Erreur:", error);
});

Exemple (GET)

Notez comme la logique est plate, sans "pyramide" .then().

// 1. La fonction DOIT être 'async'
async function getData() {
    // 2. 'try...catch' est obligatoire
    try {
        // 3. 'await' met en pause la fonction, pas le navigateur
        const response = await fetch('https://api.example.com/data');
        
        // 4. On vérifie toujours .ok !
        if (!response.ok) {
            throw new Error("Erreur HTTP: " + response.status);
        }
        
        // 5. 'await' pour la 2ème Promise (.json())
        const data = await response.json();
        
        console.log(data);
        return data;

    } catch (error) {
        // 6. Gère les erreurs Réseau ET le 'throw'
        console.error("Erreur:", error);
    }
}

Exemple (POST avec JSON)

La logique reste identique.

async function postData(userData) {
    try {
        const response = await fetch('https://api.example.com/users', {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json'
            },
            body: JSON.stringify(userData)
        });

        if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        }

        const data = await response.json();
        console.log("Réponse:", data);
        
    } catch (error) {
        console.error("Impossible de poster:", error);
    }
}

Erreur Réseau (.catch())

La Promise fetch() est rejetée. Le .catch() (ou try...catch) est activé.

Causes :

• CORS : Le serveur n'autorise pas la requête (le cas le plus fréquent).
• Réseau : Pas de Wi-Fi, DNS introuvable, serveur éteint.
• Annulation : La requête a été annulée (ex: AbortController).

try {
    // Le serveur 'non-existent-domain.xxx' n'existe pas
    await fetch('https://non-existent-domain.xxx');
} catch (error) {
    // On entre ICI
    console.error(error); // TypeError: Failed to fetch
}

Erreur HTTP (response.ok)

La Promise fetch() est réalisée (fulfilled) ! Le .catch() n'est PAS activé.

Causes :

• 404 Not Found (L'URL est fausse)
• 403 Forbidden (Pas les droits)
• 500 Internal Server Error (Le serveur a planté)

On DOIT vérifier response.ok (qui vaut true si status est 200-299).

Le "Golden Pattern"

async function getData() {
    try {
        const response = await fetch('/api/url-valide-mais-erreur-500/');

        // 1. Gérer l'erreur HTTP
        if (!response.ok) {
            // Tenter de lire l'erreur JSON du serveur (si elle existe)
            const errorData = await response.json().catch(() => null);
            const message = errorData?.detail || `Erreur HTTP ${response.status}`;
            throw new Error(message);
        }

        const data = await response.json();
        console.log(data);

    } catch (error) {
        // 2. Gérer l'erreur Réseau OU le 'throw' ci-dessus
        console.error("Échec de l'opération:", error.message);
    }
}

Le Problème : Same-Origin Policy (SOP)

Par défaut, pour des raisons de sécurité, les navigateurs interdisent à un script (ex: https://mon-site.com) de faire un fetch vers une "Origine" différente (ex: https://api-externe.com).

Une "Origine" = Protocole + Domaine + Port.

CORS (Cross-Origin Resource Sharing) est le mécanisme qui permet au *serveur* (api-externe.com) de dire au navigateur : "C'est bon, j'autorise mon-site.com à me parler."

L'erreur fatale : ...has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present...

SOLUTION : C'est TOUJOURS au serveur (backend) de corriger. Le frontend ne peut rien faire (sauf proxy).

1. Requête Simple (ex: GET)

Le navigateur envoie la requête GET.

Le serveur doit répondre en incluant cet en-tête :

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: https://mon-site.com
(ou: Access-Control-Allow-Origin: *)

2. Requête "Preflight" (ex: POST, PUT, DELETE)

Pour les requêtes "complexes" (POST, PUT, ou avec Content-Type: application/json), le navigateur envoie d'abord une "demande de permission" : la requête OPTIONS (Preflight).

Étape A : Le navigateur demande (Preflight)

OPTIONS /api/users
Host: api-externe.com
Origin: https://mon-site.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

Étape B : Le serveur autorise

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://mon-site.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type

Si cette réponse est OK, le navigateur envoie *automatiquement* la vraie requête POST.

Côté JavaScript (Frontend)

Le token CSRF est dans un cookie (csrftoken) ou dans le template ({{ csrf_token }}). Le plus simple est de le lire depuis le cookie et de l'ajouter à *chaque* fetch POST.

Snippet N°1 : Récupérer le Cookie CSRF

(Ce code est à inclure dans votre JS global)

function getCookie(name) {
    let cookieValue = null;
    if (document.cookie && document.cookie !== '') {
        const cookies = document.cookie.split(';');
        for (let i = 0; i < cookies.length; i++) {
            const cookie = cookies[i].trim();
            if (cookie.substring(0, name.length + 1) === (name + '=')) {
                cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                break;
            }
        }
    }
    return cookieValue;
}
const csrftoken = getCookie('csrftoken');

Snippet N°2 : Envoyer le fetch avec le Token

async function postToDjango(data) {
    const response = await fetch('/api/ma-vue/', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            // 1. AJOUTER LE TOKEN ICI
            'X-CSRFToken': csrftoken 
        },
        body: JSON.stringify(data)
    });
    return response.json();
}

Côté Django (Backend - views.py)

La vue doit gérer le JSON. request.POST ne fonctionne pas avec application/json (il ne marche qu'avec FormData ou x-www-form-urlencoded).

from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST
import json

# @require_POST # S'assurer que c'est bien du POST
def ma_vue_json(request):
    
    # 1. Ne s'attendre qu'à du POST
    if request.method == 'POST':
        try:
            # 2. Lire le JSON depuis request.body
            data = json.loads(request.body)
            
            # 3. Traiter les données
            username = data.get('username')
            if not username:
                return JsonResponse({'status': 'erreur', 'message': 'Username manquant'}, status=400)

            # ... faire quelque chose avec 'username' ...
            
            # 4. Renvoyer une réponse JSON
            return JsonResponse({'status': 'succès', 'message': f'Utilisateur {username} traité'})
        
        except json.JSONDecodeError:
            return JsonResponse({'status': 'erreur', 'message': 'JSON invalide'}, status=400)
    
    # 5. Rejeter les autres méthodes
    return JsonResponse({'status': 'erreur', 'message': 'Méthode GET non autorisée'}, status=405)

# Note: csrf_exempt désactive le token. À N'UTILISER QU'EN DÉSESPOIR DE CAUSE
# ou pour des API publiques.