이 기사에서는 웹 모듈화가 유용한 이유를 설명하고 현재 웹 모듈화를 구현하는 데 사용할 수 있는 몇 가지 메커니즘을 소개합니다. 다음은 RequireJS에서 사용하는 함수 래핑 형식의 디자인 철학을 설명하는 또 다른 기사입니다.
Issue §1
웹사이트가 점차 웹앱으로 변모하고 있다
코드 복잡도가 점차 높아진다
어셈블리가 어려워진다
JS 파일 개발 /분리하려는 모듈
배포 시 코드를 여러 HTTP 요청으로 최적화할 수 있습니다.
솔루션 §2
프런트엔드 개발자에게는 다음과 같은 솔루션이 필요합니다.
이러한 API 중 일부는 #include/import/require
중첩된 종속성을 로드하는 기능이 있습니다.
개발자가 사용하기 쉽고 최적화 도구가 있습니다. 배포
스크립트 로딩 API § 3
먼저 스크립트 로딩 API를 정리합니다. 여기에는 몇 가지 옵션이 있습니다:
Dojo: dojo.require("some.module") LABjs: $LAB.script("some/module.js") CommonJS: require("some/module")
모두 some/path/some/module.js를 로드하는 데 매핑됩니다. 이상적으로는 CommonJS의 구문을 선택하는 것이 더 일반화될 가능성이 있고 코드를 재사용하기를 원하기 때문입니다.
현재 우리는 기존 일반 텍스트 JavaScript 파일을 로드할 수 있는 몇 가지 구문이 있기를 바라고 있습니다. 이를 통해 개발자는 스크립트 로딩의 이점을 누리기 위해 모든 JavaScript를 다시 작성할 필요가 없습니다.
하지만 브라우저에서 더 잘 작동하는 것이 필요합니다. CommonJS의 require()는 해당 모듈이 즉시 반환될 것으로 예상하는 동기 호출입니다. 하지만 브라우저에서는 잘 작동하지 않습니다.
비동기 및 동기§ 4
다음 예는 브라우저의 기본적인 문제를 보여줍니다. Employee 개체가 있고 Employee 개체에서 파생된 Manager 개체를 원한다고 가정합니다. 예제를 얻으려면 스크립트를 사용하여 API를 로드하고 다음과 같이 코딩할 수 있습니다.
var Employee = require("types/Employee");function Manager () { this.reports = []; }//Error if require call is asyncManager.prototype = new Employee();
위의 설명에 표시된 대로 require()가 비동기식인 경우 이 코드는 작동하지 않습니다. 그러나 브라우저에서 스크립트를 동기적으로 로드하면 성능이 저하됩니다. 그럼 무엇을 해야 할까요?
스크립트 로딩: XHR§ 5
XMLHttpRequest(XHR)를 사용하여 스크립트를 로딩하는 것은 매우 매력적입니다. XHR을 사용하는 경우 위의 텍스트를 터치할 수 있습니다. 즉, 정규식을 사용하여 require() 호출을 찾아 이러한 스크립트를 로드했는지 확인한 다음 eval() 또는 스크립트 요소를 사용하여 텍스트 콘텐츠를 사용자에게 전달할 수 있습니다. XHR 로딩 스크립트.
모듈을 평가하기 위해 eval()을 사용하는 것은 좋지 않습니다.
개발자들은 eval()을 사용하는 것이 좋지 않다고 들었습니다.
일부 환경에서는 eval()을 지원하지 않습니다.
디버깅이 어렵습니다. Firebug 및 WebKit의 검사기에는 평가되는 텍스트의 이름을 지정하기 위한 //@sourceURL= 규칙이 있지만 이 기능은 모든 브라우저에서 지원되지 않습니다.
브라우저마다 컨텍스트를 다르게 평가합니다. IE의 execScript가 이를 수행할 수도 있지만 이는 더 많은 움직이는 부분을 의미하기도 합니다.
텍스트 내용이 포함된 스크립트 태그를 사용하여 파일 텍스트로 설정하는 것도 좋지 않습니다.
디버깅할 때 발생하는 오류 줄 번호가 소스 파일 번호와 일치하지 않습니다.
XHR에는 도메인 간 요청을 할 때 여전히 문제가 있습니다. 일부 브라우저는 이제 도메인 간 XHR을 지원하지만 전부는 아닙니다. 그리고 IE는 도메인 간 요청을 구현하기 위해 XDomainRequest라는 다른 API 개체를 만들기로 결정했습니다. 변경해야 할 사항이 많아지고 실수하기가 더 쉽습니다. 특히, 교차 출처 요청이 허용되도록 하려면 비표준 HTTP 헤더를 보내지 않거나 또 다른 "실행 전" 요청을 요구하지 않도록 해야 합니다.
Dojo는 eval()을 통해 XHR 기반 로더를 사용합니다. 그러나 작동하기는 하지만 항상 개발자들에게 문제가 되었습니다. Dojo에는 xdomain 로더가 있지만 함수 래퍼를 사용하여 필수 모듈을 수정해야 하므로 스크립트 src="" 태그를 사용하여 모듈을 로드할 수 있습니다. 프로그래머에게 어려움을 더하는 극단적인 경우와 변형도 많이 있습니다.
새 스크립트 로더를 만들면 더 잘할 수 있습니다.
스크립트 로딩: Web Workers § 6
Web Workers는 스크립트를 로드하는 또 다른 방법일 수 있지만:
크로스 플랫폼에 적합하지 않습니다
이는 메시징 API이며 스크립트는 DOM과 상호 작용해야 할 수 있습니다. 작업자를 사용하여 스크립트 텍스트를 가져온 다음 텍스트를 기본 창으로 다시 전달한 다음 eval/script를 사용하여 스크립트를 실행합니다. . 이 접근 방식은 위에서 언급한 XHR의 모든 문제를 수반합니다.
스크립트 로딩: document.write()§ 7
Document.write()는 스크립트를 로드하는 데 사용할 수 있으며 다른 도메인에서 스크립트를 로드하고 브라우저의 일반적인 스크립트 방식을 매핑할 수 있습니다. 간단한 디버깅에 사용할 수 있도록 사용됩니다.
하지만 비동기 vs 동기 예제에서는 스크립트를 직접 실행할 수 없습니다. 이상적으로는 스크립트를 실행하기 전에 require()를 통해 관련 종속성을 알고 이러한 종속성이 먼저 로드되는지 확인하는 것입니다. 하지만 스크립트가 실행되기 전에는 접근할 수 없습니다.
而且,document.write()在页面载入后就不工作了。对于你的网站,一个好的方法是在用户需要进行下一步操作时来载入脚本。
最后,通过document.write()载入脚本或阻塞页面的渲染。要让你的网站有最佳表现,这个方法是不可取的。
脚本载入:head.appendChild(script)§ 8
我们可以在需要时创建脚本并将它们添加到头部:
var head = document.getElementsByTagName('head')[0], script = document.createElement('script'); script.src = url; head.appendChild(script);
上面的脚本片段多了一点东西,不过那正是基本的思想。这种方法比document.write要好,因为它不会阻塞页面的渲染并且在页面载入后仍能工作。
但是,它仍然有同步VS异步例子的问题:理想情况下,在执行脚本前我们能够通过require()知道相关依赖项,并且确保这些依赖项被首先载入。
函数封装 § 9
在执行我们的脚本前,我们需要知道相关依赖项并确保已经将其载入。做这件事的最好方法是通过函数封装来构造我们的模块载入API。像这样:
define( //The name of this module "types/Manager", //The array of dependencies ["types/Employee"], //The function to execute when all dependencies have loaded. The //arguments to this function are the array of dependencies mentioned //above. function (Employee) { function Manager () { this.reports = []; } //This will now work Manager.prototype = new Employee(); //return the Manager constructor function so it can be used by //other modules. return Manager; } );
这是ReguireJS的句法。如果你想载入没有定义成模块的纯文本的JavaScript的话,有一种简单的句法:
require(["some/script.js"], function() { //This function is called after some/script.js has loaded. });
选择这种句法是因为,它足够简洁并且允许载入者使用head.appendChild(script)载入类型。
出于在浏览器中良好工作的需要,它有不同于普通的CommonJS句法。有建议说普通的CommonJS句法可以使用head.appendChild(script)的载入类型,如果服务器进程有封装的函数可以将模块转换成传输格式的话。
我相信不强制使用一个运行时服务器进程来转换代码是很重要的事:
一是调试变的很怪异,因为服务器在注入封装函数时会导致源文件的行号关闭。
二是需要做更多的工作。前端开发应该尽可能的使用静态文件。
关于设计的力量和功能封装格式的使用案例的更多细节,被叫做异步模块定义(Asynchronous Module Definition (AMD)),请前往为什么是AMD?
原文地址:http://www.php.cn/website-design-ask-340211.html
以上就是为什么要web网页模块化?的内容,更多相关内容请关注PHP中文网(www.php.cn)!