Beispiel für den Require-Aufruf von js in JavaScript

Dieser Artikel enthält hauptsächlich ein Beispiel für die Freigabe von Require-Aufrufen von js in JavaScript. Der Herausgeber findet es ziemlich gut, deshalb werde ich es jetzt mit Ihnen teilen und es allen als Referenz geben. Folgen wir dem Herausgeber und schauen wir uns das an. Ich hoffe, es kann allen helfen.

Als ich anfing, JavaScript-Funktionen zu schreiben, sah es normalerweise so aus:

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

Die Funktionen sind alle in der globalen Umgebung geschrieben, es gibt normalerweise keine Konflikte .

Aber nachdem es zu viele Codes gab, stellte ich nach und nach fest, dass die Funktionsnamen (englischer Wortschatz) nicht ausreichten. Daher wurde das Konzept des Namespace eingeführt und der modularisierte Code begann.

Funktion unter dem Namespace

Im Namespace ist mein Code so geschrieben:

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,
 ...
 };
}());
...

Führen Sie gemäß dem objektorientierten Prinzip die aus Funktion Normalerweise schreibe ich so:

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

Um Tippzeichen zu sparen, importiere ich natürlich auch 1 öffentliche API-Schnittstelle im Abschluss: www.jb51.net

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

Zu diesem Zeitpunkt war die Möglichkeit von Codekonflikten sehr gering, aber die Probleme der Codeabhängigkeit, der Dateiverwaltung mit mehreren Skripten und der Blockierung traten nach und nach an die Oberfläche – die Namespace-Methode wurde immer dringlicher.

So erscheint Require.js2.

Require.js

Verstehen Sie zunächst das Konzept des Moduls in require.js 3:

Ein Modul unterscheidet sich von einer herkömmlichen Skriptdatei darin, dass es eine gut abgegrenzte Datei definiert Objekt, das eine Verschmutzung des globalen Namespace vermeidet. Es kann seine Abhängigkeiten explizit auflisten und einen Zugriff auf diese Abhängigkeiten erhalten, ohne auf globale Objekte verweisen zu müssen, sondern erhält die Abhängigkeiten stattdessen als Argumente für die Funktion, die das Modul definiert.

Vereinfacht gesagt gibt es zwei Punkte: Erstens ist der Modulbereich in sich geschlossen und verschmutzt den globalen Raum nicht. Zweitens gibt das Modul Abhängigkeiten an, und Abhängigkeiten werden durch Parameterübergabe importiert, ohne dass auf globale Objekte verwiesen werden muss nicht den globalen Raum verschmutzen.

Module definieren

Anders als die oben beschriebene Methode für lange Namespaces verwendet require.js die globale Methode define, um Module in der folgenden Form zu definieren:

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

Lassen Sie mich die Module in zwei Typen unterteilen.

Abhängigkeitsfreie Module

Wenn ein Modul nicht von anderen Modulen abhängt, ist es sehr einfach zu definieren. Beispielsweise wird das Modul hello in der Datei hello.js platziert:

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

Module mit Abhängigkeiten

Module mit Abhängigkeiten sind etwas komplizierter. Beim Definieren müssen wir die Abhängigkeiten des Moduls auflisten:

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

Hier ist „jquery“ in der Abhängigkeit der Pfad des Moduls relativ zu baseUrl, was der Modul-ID entspricht.

Gehen Sie nun zurück und schauen Sie sich den Code an, der die öffentliche API in den oben beschriebenen Abschluss importiert, und vergleichen Sie ihn mit der Definitionsfunktion:

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

In diesem Code Ich habe auch jQuery importiert. Im Abschluss habe ich auch über den externen Parameter $ auf jQuery zugegriffen. Man kann sagen, dass die Art und Weise, wie Abhängigkeiten definiert werden, der Definitionsmethode sehr ähnlich ist. Der Unterschied besteht darin, dass die von define importierte JQuery keine globale Variable ist und daher die globale Umgebung nicht verschmutzt.

Über den Modulnamen

Die erste ID ist der Modulname. Das Format dieses Namens ist beispielsweise relativ zum Pfad von baseUrl , baseUrl ist das js-Verzeichnis, a Das Modul wird in js/libs/hi.js abgelegt. Wenn der Name dann wie folgt definiert ist:

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

Der Vorteil dieser Definitionsform besteht darin, dass Module nicht in Konflikt geraten können weil Dateien mit demselben Namen nicht im selben Verzeichnis erlaubt sind. Daher empfiehlt require.js, den Modulnamen nicht festzulegen, da das Modul nach dem Festlegen des Modulnamens „libs/hi“ in der Datei hi.js im Verzeichnis js/libs abgelegt werden muss den Speicherort, den Modulnamen. Folgen Sie den Änderungen. Was den Modulnamen betrifft, der während der späteren Optimierung mit r.js generiert wird, ist das eine andere Sache.

Module verwenden

Nachdem wir verschiedene Module mit „Abhängigkeiten“ und „ohne Abhängigkeiten“ definiert haben, wie sollten wir sie verwenden? Require.js bietet eine Funktion, require (entspricht requirejs). Die

require-Funktion lädt Abhängigkeiten und führt Rückrufe aus. Im Gegensatz zu define registriert sie das Rückrufergebnis 4 nicht als Modul:

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

Geben Sie ein einfaches Beispiel. Ich habe einen Ordner mit der folgenden Dateistruktur:

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

Hier wurde jquery.js als AMD-Modul registriert und require.js wird in der HTML-Datei wie folgt referenziert:

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

require. js überprüft den Wert des data-main-Attributs, hier ist js/main, und lädt entsprechend den Einstellungen die Datei main.js in das js-Verzeichnis.

In der Datei main.js mache ich nur eines: Ich verwende die jQuery-Methode, um die Breite des aktuellen Fensters zu ermitteln:

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

So einfach ist das Ausführen des Codes.

Nicht-AMD-Standardmodule

Aber die Dinge sind bei weitem nicht so gut, wie wir es uns vorgestellt haben. AMD ist nur eine Community-Spezifikation, kein Standard, und bevor es erschien, gab es bereits verschiedene beliebte Bibliotheken existieren, ganz zu schweigen von unserem eigenen frühen Code, daher werden wir zwangsläufig auf eine Reihe von Nicht-AMD-Spezifikationsmodulen stoßen. Damit require.js sie laden und Abhängigkeiten automatisch identifizieren und laden kann, geben wir ihnen zunächst eine Funktion namens „define“ und verwenden zweitens die von Require.js bereitgestellte Konfigurationsoption shim, um das Land zu speichern.

比如我手上一个项目，因为某种原因，还在用 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函数示例

Das obige ist der detaillierte Inhalt vonBeispiel für den Require-Aufruf von js in JavaScript. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!