Exemple d'exigence d'appel de js en JavaScript

Cet article vous apporte principalement un exemple de partage de Require call js en JavaScript. L'éditeur pense que c'est plutôt bien, alors je vais le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur pour y jeter un œil, j'espère que cela pourra aider tout le monde.

Quand j'ai commencé à écrire des fonctions JavaScript, cela ressemblait généralement à ceci :

function fun1() {
 // some code here
}
function fun2() {
 // some other code here
}
...

Les fonctions sont toutes écrites dans l'environnement global. Lorsque le projet est petit, il n'y a généralement pas de conflits. .

Mais après qu'il y ait eu trop de codes, j'ai progressivement découvert que les noms de fonctions (vocabulaire anglais) n'étaient pas suffisants. Ainsi, le concept d’espace de noms a été introduit et le code modularisé a commencé.

Fonction sous l'espace de noms

Dans l'espace de noms, mon code s'écrit comme ceci :

var com = com || {};
com.zfanw = com.zfanw || {};
com.zfanw.module1 = (function() {
 // some code here
 return {
 func1: func1,
 ...
 };
}());
com.zfanw.module2 = (function() {
 // some other code here
 return {
 func1: func1,
 ...
 };
}());
...

Conformément au principe orienté objet, exécuter le function Habituellement j'écris comme ceci :

com.zfanw.module1.func1.apply({},['arg1',arg2]);
...

Bien sûr, afin d'économiser les caractères de saisie, j'importerai également 1 interface API publique dans la fermeture : www.jb51.net

(function($, mod1) {
 // some code here
 mod1.func1.apply({},['arg1',arg2]);
}(jQuery, com.zfanw.module1)）;
...

À ce stade, la possibilité de conflits de code est très faible, mais les problèmes de dépendance au code, de gestion des fichiers multi-scripts et de blocage ont progressivement fait surface - la méthode des espaces de noms a commencé à devenir urgente.

Donc Require.js2 apparaît.

Require.js

Comprenez d'abord le concept de module dans require.js 3 :

Un module est différent d'un fichier de script traditionnel dans le sens où il définit un fichier de script bien étendu. objet qui évite de polluer l'espace de noms global. Il peut lister explicitement ses dépendances et gérer ces dépendances sans avoir besoin de faire référence à des objets globaux, mais à la place, recevoir les dépendances comme arguments de la fonction qui définit le module.

En termes simples, il y a deux points : premièrement, la portée du module est autonome et ne pollue pas l'espace global ; deuxièmement, le module spécifie les dépendances, et les dépendances sont importées via le passage de paramètres sans qu'il soit nécessaire de référencer des objets globaux – les dépendances le font également. pas polluer l’espace mondial.

Définir les modules

Différente de la méthode d'espace de noms long ci-dessus, require.js utilise la méthode globale définir pour définir les modules, sous la forme suivante :

define(id?, dependencies?, factory); // ? 表示可选项

Permettez-moi de diviser les modules en deux types.

Modules sans dépendances

Si un module ne dépend pas d'autres modules, il est très simple à définir. Par exemple, le module hello est placé dans le fichier hello.js :

define(function() {
 // some code here
 return {
 // some public api
 };
});

Modules avec dépendances

Les modules avec dépendances sont un peu plus compliqués Lors de la définition, il faut lister les dépendances du module :

define(['jquery'], function($) { // 比如这个模块，代码的执行依赖 jQuery，require.js 会先加载 jquery 模块代码，并加以执行，然后将依赖模块 以 $ 的参数形式传入回调函数中，回调函数将执行结果注册为模块
 // maybe some code here
 return {
 // some public api
 };
});

Ici, 'jquery' dans la dépendance est le chemin du module par rapport à baseUrl, qui est équivalent à l'ID du module.

Maintenant, revenez en arrière et regardez le code qui importe l'API publique dans la fermeture écrite ci-dessus, et comparez-le avec la fonction de définition :

(function($, mod1) {
 // some code here
 mod1.func1.apply({},['arg1',arg2]);
}(jQuery, com.zfanw.module1)）;

Dans ce code, J'ai également importé jQuery. En conclusion, j'ai également accédé à jQuery via le paramètre externe $. On peut dire que sa façon de "définir les dépendances" est très similaire à la méthode de définition. La différence est que la jquery importée par définir n'est pas une variable globale, elle ne polluera donc pas l'environnement global.

À propos du nom du module

La fonction de définition a trois paramètres. Le premier identifiant est le nom du module. Le format de ce nom est relatif au chemin de baseUrl à l'exclusion du format de fichier. , baseUrl est le répertoire js, a Le module est placé dans js/libs/hi.js, alors si le nom est défini comme ceci :

define('libs/hi', ['jquery'], function($){......});

L'avantage de cette forme de définition est qu'il n'y a pas possibilité de conflit de modules, car les fichiers portant le même nom ne sont pas autorisés dans le même répertoire. Mais donc require.js recommande de ne pas définir le nom du module, car après avoir défini le nom du module 'libs/hi', le module doit être placé dans le fichier hi.js dans le répertoire js/libs si vous souhaitez le déplacer. l'emplacement, le nom du module Suivez les modifications. Quant au nom du module généré lors d'une optimisation ultérieure à l'aide de r.js, c'est une autre affaire.

Utiliser les modules

Après avoir défini différents modules avec "dépendances" et "sans dépendances", comment devons-nous les utiliser ? Require.js fournit une fonction, require (équivalent à requirejs). La fonction

require charge les dépendances et exécute les rappels Contrairement à définir, elle n'enregistre pas le résultat du rappel 4 en tant que module :

require(['jquery'], function($) { // 这个函数加载 jquery 依赖，然后执行回调代码
 console.log($);
});

Donnez un exemple simple. J'ai un dossier avec la structure de fichiers suivante :

index.html
 js/
  main.js
  require.js
  jquery.js

Ici, jquery.js a été enregistré en tant que module AMD, et require.js est référencé dans le fichier HTML comme ceci :

<script src="js/require.js" data-main="js/main"></script>

require.js vérifiera la valeur de l'attribut data-main, voici js/main, et selon les paramètres, il chargera le fichier main.js dans le répertoire js.

Dans le fichier main.js, je ne fais qu'une chose, utiliser la méthode jQuery pour obtenir la largeur de la fenêtre actuelle :

require(['jquery'], function($) {
 var w = $(window).width();
 console.log(w);
});

Exécuter le code est aussi simple que cela.

Modules standards non AMD

Mais les choses sont loin d'être aussi bonnes que nous l'imaginions. AMD n'est qu'une spécification communautaire, pas un standard, et avant son apparition, il existait déjà diverses bibliothèques populaires. existent, sans parler de notre propre premier code, nous sommes donc obligés de rencontrer un tas de modules non conformes aux spécifications AMD. Afin de permettre à require.js de les charger et d'identifier et de charger automatiquement les dépendances, nous avons deux options. Premièrement, donnez-leur à tous une fonction appelée définir et deuxièmement, utilisez l'option de configuration shim fournie par Require.js pour enregistrer le pays.

比如我手上一个项目，因为某种原因，还在用 jQuery 1.4.1 版本，而 jQuery 是从1.7版本开始才注册为 AMD 模块的，我要在 require.js 中使用，就需要先做 shim：

require.config({
 shim: {
  'jquery-1.4.1': { // <= 这个是相对于 main.js 的路径www.45it.com
   exports: &#39;jQuery&#39; // <= 这个值需要稍加注意，稍后会提及
  },
  &#39;libs/jquery-throttle-debounce.min&#39;: { // <= jQuery 插件
   deps: [&#39;jquery-1.4.1&#39;] //无需 exports，因为我们只是在增强 jQuery 功能
  }
 },
});
require([&#39;jquery-1.4.1&#39;, &#39;libs/jquery-throttle-debounce.min&#39;], function($){
 console.log($.debounce);
});

写完 shim，发现 jquery-1.4.1、libs/jquery-throttle-debounce.min 这样的名称有点长。这里我们又有两种选择，一是直接打开修改 js 文件名，或者使用 require.js 提供的配置项 paths 给模块 ID 指定对应的真实文件路径：

require.config({
 paths: {
  &#39;jquery&#39;: &#39;jquery-1.4.1&#39;, // <= 模块 jquery 指向 js/jquery-1.4.1.js 文件
  &#39;debounce&#39;: &#39;libs/jquery-throttle-debounce.min&#39;
 },
 shim: {
  &#39;jquery&#39;: {
   exports: &#39;$&#39;
  },
  &#39;debounce&#39;: {
   deps: [&#39;jquery&#39;]
  }
 }
});
require([&#39;jquery&#39;, &#39;debounce&#39;], function($){
 console.log($.debounce);
});

这样，引用起来就方便多了。

另外，需要注意 shim 中的 exports 项，它的概念更接近 imports，即把全局变量导入。我们如果把 exports 值改成非全局变量名，就会导致传入回调的对象变成 undefined，举个例子：

require.config({
 paths: {
  'jquery': 'jquery-1.4.1',
 },
 shim: {
  'jquery': {
   exports: 'hellojQuery' // 这里我把 exports 值设置为 jQuery/$ 以外的值
  }
 }
});
require(['jquery'], function($){
 console.log($);// 这里，会显示 undefined
});

其他模块在做 shim 时同理，比如 underscore 需要 exports 成 _。

Require.js 的好处

说了这么多，Require.js 到底有什么好处？

并行加载

我们知道，<script></script> 标签会阻塞页面，加载 a.js 时，后面的所有文件都得等它加载完成并执行结束后才能开始加载、执行。而 require.js 的模块可以并行下载，没有依赖关系的模块还可以并行执行，大大加快页面访问速度。

不愁依赖

在我们定义模块的时候，我们就已经决定好模块的依赖 – c 依赖 b，b 又依赖 a。当我想用 c 模块的功能时，我只要在 require函数的依赖里指定 c：

require(['c'], function(c) {...});

至于 c 依赖的模块，c 依赖的模块的依赖模块… 等等，require.js 会帮我们打理。

而传统的 script 办法，我们必须明确指定所有依赖顺序：

<script src="js/a.js"></script>
 <script src="js/b.js"></script>
 <script src="js/c.js"></script>

换句话说，传统的 script 方法里，我们极可能要靠记忆或者检查模块内容这种方式来确定依赖 – 效率太低，还费脑。

减少全局冲突

通过 define 的方式，我们大量减少了全局变量，这样代码冲突的概率就极小极小 – JavaScript 界有句话说，全局变量是魔鬼，想想，我们能减少魔鬼的数量，我想是件好事。

关于全局变量

有一点需要说明的是，require.js 环境中并不是只有 define 和 require 几个全局变量。许多库都会向全局环境中暴露变量，以 jQuery 为例，1.7版本后，它虽然注册自己为 AMD 模块，但同时也向全局环境中暴露了 jQuery 与 $。所以以下代码中，虽然我们没有向回调函数传入一份引用，jQuery/$ 同样是存在的：

require(['jquery'], function(){
 console.log(jQuery);
 console.log($);
});

相关推荐：

a标签不能调用js方法的问题

JS调用PHP和PHP调用JS的方法示例

iframe子父页面调用js函数示例

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!