JS에서 모듈성은 어떻게 구현됩니까?

Js의 초기 포지셔닝으로 인해(처음에는 지나치게 복잡한 시나리오에 사용될 것이라고 기대하지 않았습니다), 애플리케이션이 더욱 복잡해짐에 따라 모듈화는 해결해야 할 문제가 됩니다. Feimai의 심층 원칙에 맞춰 모듈화의 베일을 들어올리는 것이 필요합니다. 이 글에서는 Js에서 모듈화가 어떻게 구현되는지를 주로 소개하고, 특정 참고 가치가 있는 모듈화의 작동을 자세히 소개합니다. 관심 있는 분들은 더 많은 정보를 얻으실 수 있으니, 모두에게 도움이 되기를 바랍니다.

1. 모듈화로 해결해야 할 문제

어떤 것을 심층적으로 분석하려면 목적을 가지고 살펴보는 것이 필요합니다. 모듈화로 해결해야 할 문제는 한 문장으로 요약됩니다

글로벌 오염 없이 프로젝트 코드의 더 나은 구성

간단한 예를 들기 위해 이제 다음 코드가 있습니다.

function doSomething () {
 const a = 10;
 const b = 11;
 const add = function (a + b) {
  return a + b
 }
 add (a + b)
}

실제 응용 시나리오에서 , doSomething 은 아주 많은 일을 해야 할 수도 있고 추가 기능은 더 복잡하고 재사용될 수 있으므로 추가 기능을 별도의 파일로 분리하기를 바랍니다. 따라서:

// doSomething.js 文件
const add = require('add.js');
const a = 10;
const b = 11;
add(a+ b);

// add.js 文件
function add (a, b) {
 return a + b;
}
module.exports = add;

이 목적은 분명합니다. 프로젝트 코드를 더 잘 구성하려면 두 파일의 require 및 module.exports를 확인하세요. 현재 관점에서 이는 CommonJS 사양의 키워드에서 나온 것입니다(나중에 사양에 대한 전용 장이 있을 예정입니다). 이는 가져오기 및 내보내기를 나타냅니다. 사양에 관계없이 이는 실제로 모듈화 과정에서 해결해야 할 문제입니다. 또한, add 모듈을 재사용해야 하지만 add 도입 시 전역 오염을 일으키고 싶지 않습니다.

2. 가져온 모듈을 실행하는 방법

위의 예에서는 코드를 두 개의 모듈로 분할했습니다. 파일에서 전역 오염을 일으키지 않고 예제의 코드가 정상적으로 실행될 수 있도록 require를 구현하는 방법은 무엇입니까?

require가 이미 모듈 파일에서 코드 문자열을 읽을 수 있다고 가정하고 모듈 파일 코드의 로딩 프로세스를 무시하고 require는 다음과 같이 구현할 수 있습니다.

function require (path) {
  // lode 方法读取 path 对应的文件模块的代码字符串
  // let code = load(path);
  // 不考虑 load 的过程，直接获得模块 add 代码字符串
  let code = 'function add(a, b) {return a+b}; module.exports = add';
  // 封装成闭包
  code = `(function(module) {$[code]})(context)`
  // 相当于 exports，用于导出对象
  let context = {};
  // 运行代码，使得结果影响到 context
  const run = new Function('context', code);
  run(context, code);
  //返回导出的结果
  return context.exports;
}

몇 가지 사항이 있습니다:

1) 원인 전역 오염의 경우 코드 문자열을 클로저 형식으로 캡슐화해야 하며 module.exports 키워드를 내보내야 합니다. 모듈은 외부 세계와 접촉하는 유일한 전달자입니다. 클로저 익명 함수의 매개변수 및 참조자가 전달한 컨텍스트

2) new Function을 사용하여 코드 문자열을 실행하는 것은 일반적으로 new Function에 익숙하지 않은 것으로 추정됩니다. 함수를 정의하려면 Function 클래스를 사용하여 함수를 직접 생성할 수 있다는 것을 알아야 합니다. 구문은 다음과 같습니다.

var function_name = new function(arg1, arg2, ..., argN, function_body)

위 형식에서 각 arg는 매개 변수이고 마지막 매개 변수는 함수 본문(실행할 코드)입니다. ). 이러한 매개변수는 문자열이어야 합니다. 즉, eval과 유사하게 문자열 코드를 실행하는데 사용할 수 있고, eval과 비교하여 특정 변수의 값을 문자열 코드에 매개변수 형태로 전달할 수도 있습니다

3) 만약 표준 내보내기 키워드는 내보내기만 하는데 실제 사용에서는 module.exports를 사용해야 하는 이유에 대해 의문을 품은 적이 있습니까(Node 코드를 작성한 사람은 이에 익숙해야 함). 그렇다면 이 코드에서 답을 찾을 수 있습니다. 내보내기를 사용하면 컨텍스트를 다시 할당해도 컨텍스트에 아무런 영향을 미치지 않습니다(매개변수의 주소가 전달됨). 믿을 수 없다면 코드를 다음 형식으로 변경하고 다시 실행하세요.

데모 결과

3. 코드 로딩 방법

코드 실행 문제를 해결하려면 모듈 파일 코드 로딩 문제도 해결해야 합니다. 위의 예에 따르면 우리의 목표는 모듈을 로드하는 것입니다. 문자열 형식의 파일 코드

노드 컨테이너에서는 모든 모듈 파일이 로컬에 있으므로 로컬 디스크에서 모듈 파일을 읽어서 문자열 코드를 로드한 후 위의 프로세스를 따르기만 하면 됩니다. Node의 내장 모듈이 아닌 코어 모듈과 C++ 모듈의 로딩 및 실행 방법이 거의 동일하다는 사실이 입증되었습니다(새로운 기능은 아니지만 비슷한 방법입니다)

RN/Weex 컨테이너에서는 원격 Bundle.js를 로드해야 하는 경우 Native의 기능을 통해 원격 js 파일을 요청한 다음 이를 문자열 코드로 읽어서 로드할 수 있습니다. (이 논리에 따르면 Node는 원격 js 모듈을 읽을 수 있는 것처럼 보입니다. 대부분의 경우에는 이 작업을 수행할 필요가 없습니다.)

브라우저 환경에서는 모든 JS 모듈을 원격으로 읽어야 합니다. 안타깝게도 브라우저에서 제공하는 기능에 따라 원격 JS 파일을 다음 형식으로 직접 읽을 수 없습니다. ajax를 통한 파일 스트림은 문자열 코드입니다. 전제 조건을 충족할 수 없으면 위의 작업 전략이 작동하지 않으며 다른 방법을 찾을 수 밖에 없습니다

이것이 CommonJs 사양이 있는 이유이고, AMD/CMD 사양도 있는 이유

그럼 어떻습니까? 브라우저에서 완료되었나요? 브라우저에서 Js 컨트롤을 통해 원격 Js 모듈 파일을 동적으로 로드하려면 <script> 노드를 동적으로 삽입해야 합니다.<pre class="brush:php;toolbar:false">// 摘抄自 require.js 的一段代码 var node = config.xhtml ? document.createElementNS(&amp;#39;http://www.w3.org/1999/xhtml&amp;#39;, &amp;#39;html:script&amp;#39;) : document.createElement(&amp;#39;script&amp;#39;); node.type = config.scriptType || &amp;#39;text/javascript&amp;#39;; node.charset = &amp;#39;utf-8&amp;#39;; node.async = true; node.setAttribute(&amp;#39;data-requirecontext&amp;#39;, context.contextName); node.setAttribute(&amp;#39;data-requiremodule&amp;#39;, moduleName); node.addEventListener(&amp;#39;load&amp;#39;, context.onScriptLoad, false); node.addEventListener(&amp;#39;error&amp;#39;, context.onScriptError, false);&lt;p&gt;要知道，设置了 &lt;script&gt; 标签的 src 之后，代码一旦下载完成，就会立即执行，根本由不得你再封装成闭包，所以文件模块需要在定义之初就要做文章，这就是我们说熟知的 AMD/CMD 规范中的 define，开篇的 add.js 需要重新改写一下&lt;/script&gt;&lt;/p&gt; &lt;pre class=&quot;brush:php;toolbar:false&quot;&gt;// add.js 文件 define ('add'，function () {   function add (a, b) {    return a + b;   }   return add; })</pre> <p>而对于 define 的实现，最重要的就是将 callback 的执行结果注册到 context 的一个模块数组中：</p> <pre class="brush:php;toolbar:false">  context.modules = {}   function define(name, callback) {     context.modules[name] = callback &amp;&amp; callback()   }</pre> <p>于是 require 就可以从 context.modules 中根据模块名载入模块了，是不是有了一种自己去写一个 “requirejs” 的冲动感</p> <p>具体的 AMD 实现当然还会复杂很多，还需要控制模块载入时序、模块依赖等等，但是了解了这其中的灵魂，想必去精读 require.js 的源码也不是一件困难的事情</p> <p>四、Webpack 中的模块化</p> <p>Webpack 也可以配置异步模块，当配置为异步模块的时候，在浏览器环境同样的是基于动态插入 <script> 的方式载入远程模块。在大多数情况下，模块的载入方式都是类似于 Node 的本地磁盘同步载入的方式</script>

嫑忘记，Webpack 除了有模块化的能力，还是一个在辅助完善开发工作流的工具，也就是说，Webpack 的模块化是在开发阶段的完成的，使用 Webpack 构筑的工作环境，在开发阶段虽然是独立的模块文件，但是在运行时，却是一个合并好的文件

所以 Webpack 是一种在非运行时的模块化方案（基于 CommonJs），只有在配置了异步模块的时候对异步模块的加载才是运行时的（基于 AMD）

五、模块化规范

通用的问题在解决的过程中总会形成规范，上文已经多次提到 CommonJs、AMD、CMD，有必要花点篇幅来讲一讲规范

Js 的模块化规范的萌发于将 Js 扩展到后端的想法，要使得 Js 具备类似于 Python、Ruby 和 Java 那样具备开发大型应用的基础能力，模块化规范是必不可少的。CommonJS 规范的提出，为Js 制定了一个美好愿景，希望 Js 能在任何地方运行，包括但不限于：

• 服务器端 Js 应用

• 命令行工具

• 桌面应用

• 混合应用

CommonJS 对模块的定义并不复杂，主要分为模块引用、模块定义和模块标识

1. 模块引用：使用 require 方法来引入一个模块

2. 模块定义：使用 exports 导出模块对象

3. 模块标识：给 require 方法传入的参数，小驼峰命名的字符串、相对路径或者绝对路径

模块示意

CommonJs 规范在 Node 中大放异彩并且相互促进，但是在浏览器端，鉴于网络的原因，同步的方式加载模块显然不太实用，在经过一段争执之后，AMD 规范最终在前端场景中胜出（全称 Asynchronous Module Definition，即“异步模块定义”）

什么是 AMD，为什么需要 AMD ？在前述模块化实现的推演过程中，你应该能够找到答案

除此之外还有国内玉伯提出的 CMD 规范，AMD 和 CMD 的差异主要是，前者需要在定义之初声明所有的依赖，后者可以在任意时机动态引入模块。CMD 更接近于 CommonJS

两种规范都需要从远程网络中载入模块，不同之处在于，前者是预加载，后者是延迟加载

相关推荐：

javascript高级模块化require.js的具体使用方法实例分享

Laravel 的模块化开发框架 Notadd RC1

JavaScript使用高级模块化require.js的具体方法详解

위 내용은 JS에서 모듈성은 어떻게 구현됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!