Récemment, je pense à la façon de fusionner les fichiers JS frontaux. Bien sûr, il n'inclut pas les fichiers qui ne peuvent pas être fusionnés, mais les fichiers que nous pouvons fusionner. Après y avoir pensé, il ne devrait y avoir que trois façons.
Les trois méthodes sont les suivantes:
1. Un grand fichier, tous JS fusionnent en un seul grand fichier, et toutes les pages y font référence.
2. Chaque page est un grand fichier, et chaque page fusionne pour générer le grand fichier de votre propre JS.
3. Fusionner plusieurs fichiers grands partagés, fusionner plusieurs fichiers JS partagés en fonction de la pratique, et chaque page fait référence à plusieurs fichiers grands partagés.
De plus, à mon avis, Merge a deux objectifs:
1. Pour réduire le nombre de demandes.
2. Considérations de sécurité du code (plus les fichiers sont divisés, plus il est facile de voir clairement).
PS: Notez que ce dont je parle n'est pas de confusion de compression, fusionnez simplement
1. Un grand fichier
Cette façon consiste à fusionner tous les JS dans un grand fichier quelle que soit la situation, et toutes les pages y font référence, même si un code peut ne pas être utilisé.
avantage:
(1). Il est simple à fusionner et facile à utiliser.
(2). D'autres pages peuvent être chargées en utilisant l'optimisation du cache.
défaut:
(1). La page peut être chargée en codes qui ne sont pas utilisés dans cette page.
Scénarios non applicables:
(1). Cette méthode ne convient certainement pas aux grandes applications Web, et quelle que soit la quantité de code unique, la complexité de l'entreprise ne nous permet pas de le faire (je n'ai jamais vu ce site Web faire cela).
Scénarios applicables:
(1). Les applications hybrides, qu'il s'agisse d'applications hybrides de Mobile ou d'applications hybrides de PC (applications de bureau, similaires à Youdao Team Development Framework HEX + Chromium + NodeJS), sont très appropriées et il n'y aura pas de problèmes de vitesse de demande. La sécurité du code de ces applications située dans le code client est plus importante.
PS: Bien sûr, la chose la plus importante est la sécurité du backend. Peu importe si le frontend est fissuré, si le backend améliore la vérification des entrées et si elle empêche la dépassement de l'autorité, le backend est la clé, ce qui signifie que le dicton "ne faites confiance à aucune entrée de l'utilisateur".
2. Fichiers grands sur chaque page
Fusionnez chaque page pour générer un grand fichier de votre propre JS et générer plusieurs fusions JS.
avantage:
(1). Chaque page utilise le JS le plus précis et il n'y aura pas de code non pertinent.
défaut:
(1). Il existe de nombreuses pages, plusieurs JS seront générés, ce qui entraîne une grande quantité de redondance dans le code JS commun.
(2). La pièce partagée ne peut pas être chargée en utilisant l'optimisation du cache.
(3). La fusion et l'utilisation seront relativement compliquées.
Je pense toujours que quelque chose ne va pas avec cette méthode. Les petites applications peuvent le gérer directement avec un grand fichier, et les grandes applications ne le feront pas, et elles ne peuvent pas être utilisées sur des applications hybrides. Dans ce cas, où la taille du package d'installation est importante, le code redondant ne peut pas être toléré. Quand je pensais à divers scénarios, j'ai trouvé qu'il pouvait être résolu en utilisant les méthodes ci-dessus ou ci-dessous, et c'était mieux, donc je pense que cette méthode est inutile.
3. Fusionner plusieurs fichiers grands partagés
Selon la pratique, fusionnez plusieurs fichiers grands partagés (tels que la classification de la bibliothèque de dépendances) et fusionnez les fichiers JS requis (tels que la classification commerciale), chaque page fait référence à un ou plusieurs fichiers grands partagés et les fichiers JS de cette page.
avantage:
(1). La partie partagée est chargée et les références à chaque page sont aussi élevées que possible sans redondance.
défaut:
(1). Il y aura plus ou moins certaines pages qui feront référence au code indésirable, et le partage n'est pas un partage complet.
Scénarios applicables:
(1). Les grandes et petites applications conviennent plus. Chaque page peut avoir de nombreuses pièces communes et la fusion de fichiers raisonnable sera très critique.
Résumer
Ce document n'est qu'une pensée et n'est qu'une discussion générale. Il existe de nombreuses méthodes de fusion de fichiers, qui sont générées dynamiquement par backend ou directement générées par les outils (grunt + requirejs). Les trois méthodes de fusion ci-dessus sont également déterminées par nos besoins pratiques.
La fusion est très importante, mais il n'est pas recommandé que tous les documents soient fusionnés. Certains documents ne peuvent pas être fusionnés. Certains sont meilleurs pour les documents individuels, mais cela dépend du scénario spécifique.
Les trois façons de fusionner le fichier JS frontal sont tout le contenu que je partage avec vous. J'espère que vous pourrez vous faire référence et j'espère que vous pourrez soutenir Wulin.com plus.