2
votes

Comment gérer le morceau Webpack mis à jour sur le serveur?

Nous avons une application React avec la division du code en utilisant React.lazy et Suspend. Tous les mardis, nous déployons une nouvelle version et donc nos morceaux changeront également.

Le problème que nous avons en ce moment est que si notre utilisateur n'a pas actualisé après le déploiement, son ancien main.js pointe toujours vers les anciens fichiers de blocs avec d'anciens hachages. Et il va planter quand ils essaieront de charger les anciens fichiers chunk.

Nous savons que nous pouvons pré-extraire des routes lorsque notre application est chargée, mais il y a beaucoup de routes à pré-lire (environ 20). Cela peut affecter les performances de notre page d'accueil, car nous avons quelques appels d'API sur la page d'accueil.

Y a-t-il de meilleures façons de gérer cela?

Merci d'avance.


1 commentaires

Nous parlons des hachages que Webpack génère dans le nom de fichier des morceaux? Pourriez-vous montrer les parties pertinentes de votre configuration Webpack?


3 Réponses :


0
votes

Qu'est-ce qui vous empêche de conserver plusieurs versions sur votre serveur? Disons que v1.commons.js est actuellement déployé. Désormais, lorsque vous créez une nouvelle version, v2.commons.js est créé et les deux fichiers sont servis par le serveur. Les anciens clients fonctionneront toujours avec l'ancienne version, mais en fonction de vos paramètres de mise en cache (heure d'expiration de la page), ils migreront bientôt vers la nouvelle version. Ensuite, vous pouvez supprimer l'ancienne version de votre serveur.


0 commentaires

0
votes
  • Utilisez le [hash] espace réservé dans la configuration de sortie de votre Webpack, par exemple nom de fichier: '[hachage] / [nom] .js' . De cette façon, chaque compilation donnera un nouvel ensemble de noms de fichiers.
  • Assurez-vous que la page qui fait référence à ces blocs (qu'elle soit générée avec webpack-html-plugin ou autre) est toujours servie à jour, jamais à partir du cache, via les en-têtes Cache-Control ou d'autres techniques similaires.

De cette façon, les clients très têtus (qui ignorent les en-têtes de contrôle du cache) utiliseront très probablement leur ancienne version de votre code, mais dès qu'ils s'actualiseront (pour obtenir la nouvelle page HTML), ils seront garantis tous le nouveau JavaScript aussi, puisque l'URL a changé.


0 commentaires

0
votes

Nous avons décidé de précharger chaque route en arrière-plan afin que nos clients n'aient pas besoin de charger paresseusement d'autres morceaux à un moment ultérieur.


0 commentaires