WITHMIA v1.0.6 — Une transition parfaite
Fini le double chargement de page après la connexion : une transition visuelle soignée en overlay inline, un mode sombre complet dans l'onboarding et la correction définitive de la boucle de redirection à l'authentification.
Équipe WITHMIA
WITHMIA
La v1.0.5 a sécurisé l’infrastructure avec les tests, la CI/CD et la facturation. La v1.0.6 s’attaque à ce que l’on voit et ressent vraiment : une connexion sans interruption, sans flash blanc, sans rechargement visible. C’est un changement d’architecture qui supprime un chargement complet de l’application et le remplace par une transition visuelle fluide.
Le problème : tout charger deux fois après la connexion
Jusqu’à la v1.0.5, le parcours d’authentification avec Google se déroulait ainsi :
- L’utilisateur clique sur « Se connecter avec Google »
- Google authentifie et renvoie vers
/auth/google - Le serveur rend
auth-loading.blade.php— une page intermédiaire qui affiche la vidéo de transition - Cette page charge l’application React dans une iframe pour stocker le token
- Puis elle exécute
top.location.replace()vers le tableau de bord - Le navigateur charge l’application entière une seconde fois
Résultat : un flash blanc bien visible entre la transition et le tableau de bord. L’application se chargeait deux fois à chaque connexion.
La solution : redirection directe + overlay inline
La v1.0.6 supprime totalement auth-loading.blade.php et remplace tout le parcours par une conception à chargement unique :
Le nouveau parcours
- L’utilisateur clique sur « Se connecter avec Google »
- Google authentifie et renvoie vers
/auth/google - Le serveur effectue une
redirect()directe vers le tableau de bord avec?transition=1&auth_token=... app.blade.phpdétecte?transition=1et affiche l’overlay de transition en inline au-dessus de<div id="app">- React se monte en dessous de l’overlay
- Dès que React est prêt, l’overlay disparaît en fondu (1,5 s minimum à l’écran + 0,6 s d’animation)
Un seul chargement de page. Zéro flash blanc. Une transition soignée.
Ce qui change techniquement
| Composant | Avant (v1.0.5) | Maintenant (v1.0.6) |
|---|---|---|
| GoogleAuthController | return view('auth-loading', ...) | return redirect($url . '&transition=1') |
| OnboardingController | return view('auth-loading', ...) | return redirect($url . '&transition=1') |
| routes/web.php | Rend auth-loading comme vue | Redirection directe avec ?transition=1 |
| Overlay | Page séparée (auth-loading.blade.php) | Inline dans app.blade.php avec du CSS |
| Chargements de page | 2 (iframe + replace) | 1 (redirection directe) |
Mode sombre complet dans l’onboarding
Le parcours d’onboarding respecte désormais entièrement le mode sombre du système :
- Détection automatique — lecture de
prefers-color-scheme: darkdu système d’exploitation - Persistance — si une préférence est déjà enregistrée dans le localStorage, c’est elle qui prime
- Fond et texte — tout l’écran d’onboarding s’adapte : fonds
#0F0F0F, textes clairs, champs aux bordures discrètes - Sans flash blanc —
<html>reçoitdata-theme="dark"avant même que React ne rende quoi que ce soit
Correction de la boucle de redirection à l’authentification
Nous avons identifié et corrigé plusieurs causes d’une boucle de redirection qui touchait certains utilisateurs :
Causes identifiées et corrigées
- Closures paresseuses dans HandleInertiaRequests — elles étaient évaluées même lorsque l’utilisateur n’était pas authentifié, provoquant des erreurs qui déclenchaient des redirections
- AuthenticationException avec 302 — remplacée par une redirection propre au lieu d’une réponse qu’Inertia ne savait pas traiter
- Middleware auth.clean supprimé — il interférait avec la gestion des tokens Railway
- Railway auth sur les routes API — ajout de
railway.authaux routes utilisateur de l’API pour que le token fonctionne correctement - auth_token conservé dans l’URL — nous avons cessé de retirer
auth_tokende l’URL trop tôt, ce qui permet à l’application de le récupérer correctement
L’overlay de transition : une finition professionnelle
L’overlay inline dans app.blade.php reproduit exactement le design de l’ancien auth-loading :
- Vidéo d’arrière-plan — le même MP4 corporate, muted + autoplay + loop
- Dégradé adaptatif — un
linear-gradientqui bascule entre mode clair et mode sombre - Signature « WITH YOU, WITHMIA » — large interlettrage, graisse semibold, avec un dégradé d’opacité
- Timing intelligent — 1,5 seconde minimum à l’écran (le temps que suit
window.__loadingStart), puis un fondu de 0,6 seconde avecpointer-events: nonepour ne jamais bloquer l’interaction - Nettoyage de l’URL —
history.replaceState()retiretransitionetauth_tokende l’URL après le montage
Prise en charge du mode sombre dans l’overlay
/* Light mode */
background: linear-gradient(135deg, #f8f9fa 0%, #e8f4f8 50%, #f0f7ff 100%);
/* Dark mode (prefers-color-scheme: dark ou data-theme="dark") */
background: linear-gradient(135deg, #0a0a0a 0%, #111827 50%, #0f172a 100%);
color: white;Correctif : une source de vérité unique pour le thème
Nous avons découvert que deux systèmes de thème se disputaient le contrôle de la classe dark sur <html> :
- WITHMIA ThemeContext — lit
withmia_theme_modedans le localStorage (le vrai système, synchronisé avec la base de données) - Laravel starter kit (
initializeTheme) — litappearancedans le localStorage, dont la valeur par défaut était'system'
Si l’utilisateur avait son thème WITHMIA sur light mais son système d’exploitation en mode sombre, initializeTheme() ajoutait la classe dark à <html> après que l’overlay se soit affiché en mode clair → un flash sombre par-dessus le clair.
La solution
initializeTheme() lit désormais withmia_theme_mode comme source de vérité principale, avec repli sur appearance puis sur 'light'. Le gestionnaire handleSystemThemeChange a également été mis à jour.
// Avant
const savedAppearance = (localStorage.getItem('appearance') as Appearance) || 'system';
// Maintenant
const savedAppearance = (localStorage.getItem('withmia_theme_mode') as Appearance)
|| (localStorage.getItem('appearance') as Appearance)
|| 'light';Ménage : auth-loading supprimé
Le fichier auth-loading.blade.php (216 lignes) a été supprimé du codebase. Plus aucun contrôleur, route ou vue n’y fait référence.
La route /auth-loading existe toujours comme redirection de compatibilité — si quelqu’un a l’URL en cache, il est simplement redirigé vers sa destination avec &transition=1.
Récapitulatif technique
| Changement | Fichiers | Impact |
|---|---|---|
| Supprimer le double chargement | GoogleAuthController, OnboardingController, routes/web.php | view() → redirect() |
| Overlay inline | app.blade.php | Détection de ?transition=1, overlay CSS avec vidéo |
| Fondu de sortie côté React | app.tsx | 1,5 s minimum + 0,6 s d’animation, nettoyage de l’URL |
| Mode sombre dans l’onboarding | onboarding.tsx | Respecte prefers-color-scheme et le localStorage |
| Correctif boucle de redirection | HandleInertiaRequests, routes/web.php, GoogleAuthController | 5 correctifs indépendants |
| Types de retour | GoogleAuthController, OnboardingController | RedirectResponse en type de retour |
| Source de vérité du thème | use-appearance.tsx | withmia_theme_mode comme source principale |
| Ménage | auth-loading.blade.php | Fichier supprimé (-216 lignes) |
La suite
L’expérience de connexion étant peaufinée, le cap revient aux fonctionnalités produit :
- PWA / application mobile — la priorité pour une Amérique latine mobile-first
- Enquêtes CSAT — la satisfaction client intégrée à la conversation
- AI resolution analytics — les indicateurs de résolution par l’IA
- Diffusion WhatsApp — les campagnes de masse
WITHMIA v1.0.6, c’est la version qui rend parfaites les 3 premières secondes de votre expérience. Une connexion, un chargement, zéro interruption.
Étiquettes
Commentaires
Restez respectueux. Votre e-mail ne sera pas publié.