Notes perso de lecture rapide et en diagonale.

rien d'essentiel ne doit dépendre de javascript, en particulier les formulaires.

• JS peut être désactivé
• le navigateur peut être obsolète (oui, windows, c'est de toi que je parle)
• des extensions peuvent bloquer le script
• le client a peut être une connexion lente qui va timeout
• le client a peut être une connexion intermittente (genre le train)
• il peut y avoir un firewall qui bloque certaines choses.
• etc

En gros, JS devrait être réservé à des choses qu'on ne peut pas faire autrement et/ou non essentielles.

Pour les formulaires, on peut partir d'un formulaire normal fonctionnant normalement et l'améliorer via JS: capturer l'événement onsubmit et gérer l'envoi au serveur via des promises et fetch, traiter les erreurs etc.

Si JS ne fonctionne pas, le formulaire continuera de faire son job avec le comportement par défaut de submit mais de façon moins sexy, c'est tout.

Et si les envois et retours se font en JSON et tout le merdier ?

Problème de type de retour et de format de réception

L'auteur propose d'utiliser le header côté serveur pour identifier qui de JS ou de HTML est à l'origine de la requête (avec Sec-Fetch-Mode par exemple ) et ainsi adapter le comportement du serveur (traitement des données et composition de la réponse)

En gros:

• si ça vient de JS ➜ gère le JSON et renvoie du JSON pour que JS gère la réponse
• si ça vient de HTML ➜ gère le formulaire normalement et renvoie une nouvelle page HTML composée côté serveur.