전단 모듈화 개발의 가치

인터넷의 급속한 발전에 따라 전단 개발은 갈수록 복잡해진다.본고는 실제 프로젝트에서 직면한 문제에서 출발하여 모듈화가 어떤 문제를 해결할 수 있는지, 그리고 Sea를 어떻게 사용하는지 설명하고자 한다.js는 전단의 모듈화 개발을 진행한다.

짜증나는 명명 충돌

우리는 간단한 습관에서 출발한다.나는 프로젝트를 할 때 종종 통용되고 밑바닥의 기능을 추상화하여 하나의 함수로 독립시킨다. 예를 들어

function each(arr) { //   } function log(str) { //   }

그리고 이 함수들을util에 통일적으로 놓았다.js리.필요할 때 이 파일을 가져오면 됩니다.이 모든 것은 매우 잘 일했고, 동료들도 내가 이렇게 편리한 도구 꾸러미를 제공해 준 것에 매우 감격했다.
팀이 커지자 불평이 나오기 시작했다.
샤오양: 저는 각각의 방법이 대상을 두루 훑어보는 것을 정의하고 싶지만, 페이지의 유틸리티.js에서 이미 하나를 정의했습니다. 저는 each Object라고 할 수 밖에 없습니다. 어쩔 수 없습니다.
샤오고: 내가 로그 방법을 사용자 정의했는데 왜 샤오밍이 쓴 코드에 문제가 생겼지?누가 도와줘요?
불평이 갈수록 많아지다.팀은 격렬한 토론을 거쳐 자바의 방식을 참조하여 명칭 공간을 도입하여 해결하기로 결정했다.그래서 util.js의 코드가 바뀌었어요.

var org = {}; org.CoolSite = {}; org.CoolSite.Utils = {}; org.CoolSite.Utils.each = function (arr) { //   }; org.CoolSite.Utils.log = function (str) { //   };

위의 코드가 이 글을 쓰기 위해 고의로 날조한 것이라고 생각하지 마라.명명 공간의 개념을 전방에서 발양하고 야후를 밀어라!의 YUI2 프로젝트입니다.다음은 Yahoo에서 온 실제 코드입니다!개원 프로젝트

if (org.cometd.Utils.isString(response)) {
  return org.cometd.JSON.fromJSON(response); } if (org.cometd.Utils.isArray(response)) { return response; }

명명 공간을 통해 확실히 충돌을 크게 완화시킬 수 있다.그러나 위의 코드를 볼 때마다 동정을 참을 수 없었다.간단한 방법을 사용하기 위해서는 이렇게 긴 명명 공간을 기억해야 하기 때문에 기억의 부담을 증가시키고 많은 인코딩의 즐거움을 박탈한다.
YUI 팀은 프런트엔드 업계의 벤치마킹으로서 이 문제를 해결하기로 결심했습니다.YUI3 프로젝트에 새로운 네임스페이스 메커니즘이 도입되었습니다.

YUI().use('node', function (Y) { // Node   //   Y   var foo = Y.one('#foo'); });

YUI3는 샌드박스 메커니즘을 통해 명명 공간이 너무 긴 문제를 잘 해결했다.그러나 새로운 문제도 가져왔다.

YUI().use('a', 'b', function (Y) { Y.foo(); // foo   a   b  ？ //   a   b   foo  ， ？ });

간단해 보이는 명명 충돌이 실제로 해결되기는 쉽지 않다.어떻게 더 우아하게 해결합니까?우리는 잠시 시계를 표시하지 않고 먼저 또 다른 흔히 볼 수 있는 문제를 보았다.

번거로운 파일 의존

위의 이야기를 계속하다.유틸리티 기반.js, 저는 UI층 유니버설 구성 요소를 개발하기 시작했습니다. 그러면 프로젝트 팀 동료들은 반복적으로 바퀴를 만들 필요가 없습니다.
그중에서 가장 사랑받는 구성 요소 중 하나는 다이얼로그다.js, 사용 방식은 간단합니다.

<script src="util.js"></script> <script src="dialog.js"></script> <script>  org.CoolSite.Dialog.init({ /*   */ }); </script>

그러나 내가 어떻게 문서를 쓰든, 그리고 아무리 정중하게 메일을 보내도, 때때로 동료가 왜 다이얼로그를 하는지 물어본다.js에 문제가 있습니다.한 차례의 조사를 통해 오류를 초래한 원인을 발견하면 항상

<script src="dialog.js"></script> <script>  org.CoolSite.Dialog.init({ /*   */ }); </script>

대화상자에 있습니다.js 전에 util을 도입하지 않았습니다.js, 따라서dialog.js가 정상적으로 작동하지 않습니다.마찬가지로 내 위의 이야기가 허구라고 생각하지 마라. 내가 머물렀던 회사에서 지금까지도 유사한 스크립트 오류가 있다. 특히 각종 신속하게 제작된 마케팅 페이지에서.
위의 파일은 아직 제어 가능한 범위 내에 의존하고 있다.프로젝트가 갈수록 복잡해지면, 많은 파일 간의 의존은 항상 사람을 미치게 한다.아래의 이 문제들은 나는 매일 진실하게 발생하고 있다고 믿는다.

유니버설 그룹은 전단 기초 라이브러리를 업데이트했지만 전체 사이트의 업그레이드를 추진하기 어렵다.

업무팀은 새로운 유니버설 구성 요소를 사용하고 싶었지만 몇 줄의 코드를 통해 간단하게 해결할 수 없다는 것을 발견했다.

오래된 제품이 새로운 기능을 갖추어야 하기 때문에 최종 평가는 오래된 라이브러리를 바탕으로 계속 개발할 수 밖에 없다.

회사가 업무를 통합하고 모 두 제품 라인을 합병해야 한다.그 결과 프런트엔드 코드 충돌이 발견되었다.

……

이상의 많은 문제는 문서 의존이 잘 관리되지 않았기 때문이다.전단 페이지에서 대부분의 스크립트의 의존은 현재도 여전히 인육적인 방식으로 보장되고 있다.팀이 시간을 비교하면 이것은 아무런 문제가 없을 것이다.팀이 커지고 회사 업무가 복잡해지면 의존 문제가 해결되지 않으면 큰 문제가 된다.
파일의 의존은 현재 대부분의 라이브러리 프레임워크, 예를 들어 외국의 YUI3 프레임워크, 국내의 KISSY 등 라이브러리에서 현재 설정 방식을 통해 해결되고 있다.

YUI.add('my-module', function (Y) { // ... }, '0.0.1', { requires: ['node', 'event'] });

위의 코드는 requires 등의 방식으로 현재 모듈의 의존을 지정합니다.이것은 어느 정도 의존 문제를 해결할 수 있지만 우아하지 않다.모듈이 많고 의존이 복잡할 때 번거로운 배치는 적지 않은 위험을 가져올 수 있다.
명명 충돌과 파일 의존은 전단 개발 과정에서 두 가지 대표적인 문제이다.다음은 모듈화 개발을 통해 어떻게 해결하는지 봅시다.설명을 편리하게 하기 위해서 우리는 Sea를 사용합니다.js를 모듈화 개발 프레임워크로 삼다.

Sea를 사용합니다.js가 해결합니다.

Sea.js는 성숙한 개원 프로젝트로 핵심 목표는 전단 개발에 간단하고 극한의 모듈화 개발 체험을 제공하는 것이다.여기는 소개가 많지 않고 관심 있는 사람은 방문seajs.org하여 공식 문서를 볼 수 있습니다.
Sea를 사용합니다.js, 파일을 작성할 때 CMD(Common Module Definition) 모듈 정의 규범을 준수해야 합니다.하나의 파일은 하나의 모듈이다.앞의 예에서의util.되다

define(function(require, exports) { exports.each = function (arr) { //   }; exports.log = function (str) { //   }; });

exports를 통해 외부에 인터페이스를 제공할 수 있다.이렇게, dialog.js의 코드가

define(function(require, exports) { var util = require('./util.js'); exports.init = function() { //   }; });

관건이 왔다!우리는 require('./util.js')를 통과하면 util을 받을 수 있다.js에서 exports를 통해 노출된 인터페이스.이곳의 리퀴어는 바다라고 생각할 수 있다.js는 자바스크립트 언어에 추가된 문법 키워드로 require를 통해 다른 모듈에서 제공하는 인터페이스를 얻을 수 있습니다.
이것은 사실 조금도 신기하지 않다.프런트엔드 엔지니어로서 CSS 코드가 낯설지 않을 것입니다.

@import url("base.css"); #id { ... } .class { ... }

Sea.js에 추가된 require 문법 키워드는 CSS 파일의 @import과 같이 원본 코드에 의존 도입 기능을 부여합니다.
만약 네가 백엔드 개발 엔지니어라면, 더욱 낯설지 않을 것이다.Java, Python, C# 등의 언어는 include, import 등의 기능을 가지고 있다.JavaScript 언어 자체에도 유사한 기능이 있지만 아직 초안 단계이기 때문에 ES6 표준이 주류 브라우저의 지원을 받아야 사용할 수 있습니다.
이렇게 하면 페이지에서 dialog를 사용합니다.js는 매우 간단해질 것이다.

<script src="sea.js"></script> <script> seajs.use('dialog', function(Dialog) {  Dialog.init(/*   */); }); </script>

우선 페이지에 sea를 도입해야 한다.js 파일, 이것은 일반적으로 페이지 전체를 통해 제어되며, 업데이트와 유지보수도 편리하다.페이지에서 구성 요소를 사용하려면 seajs.use 방법을 통해 호출합니다.
상기 코드를 잘 생각해 봐, 나는 네가 이미 Sea를 보았다고 믿는다.js가 가져온 두 가지 장점:

exports를 통해 인터페이스를 노출한다.이것은 명명 공간이 필요하지 않고 전역 변수도 필요하지 않다는 것을 의미한다.이것은 철저한 명명 충돌 해결 방안이다.

require를 통해 의존을 도입한다.이것은 의존을 내장할 수 있다. 개발자는 현재 모듈의 의존, 다른 일에만 관심을 가져야 한다. Sea.js는 자동으로 처리됩니다.모듈 개발자에게 이것은 매우 좋은 관심도 분리로 프로그래머들이 인코딩의 즐거움을 더욱 많이 누릴 수 있다.

작은 매듭

이름 충돌과 의존 관리를 해결하는 것 외에 Sea를 사용합니다.js는 모듈화 개발을 진행하면 많은 장점을 가져올 수 있다.

모듈의 버전 관리.별명 등 설정을 통해 구축 도구와 결합하여 모듈의 버전 관리를 비교적 쉽게 실현할 수 있다.

서비스 편의성 향상모듈화는 모든 파일의 직책을 단일하게 할 수 있어 코드의 유지보수에 매우 유리하다.Sea.js는 또한 nocache, debug 등 플러그인을 제공하고 온라인 디버깅 등 기능을 가지고 있어 효율을 비교적 뚜렷하게 향상시킬 수 있다.

프런트엔드 성능 최적화.Sea.js는 비동기적으로 모듈을 불러옵니다. 이것은 페이지 성능에 매우 유익합니다.Sea.js는 또한combo,flush 등 플러그인을 제공하여 서버에 맞추어 페이지 성능을 잘 조정할 수 있습니다.

환경 간 공유 모듈.CMD 모듈 정의 사양 및 Node.js의 모듈 규범은 매우 비슷하다.바다를 통과하다.js의 Node.js 버전으로 모듈의 크로스 서버와 브라우저 공유를 쉽게 실현할 수 있습니다.

모듈화 개발은 신선한 것이 아니지만 웹 분야에서 전단 개발은 새로운 일자리로 비교적 원시적인 화전 시대에 처해 있다.최근 2, 3년 동안 Dojo, YUI3, Node를 따라.js 등 지역사회의 보급과 유행으로 전단의 모듈화 개발 이념이 점차적으로 사람들의 마음속에 깊이 자리잡았다.
전단의 모듈화 구축은 두 종류로 나눌 수 있다.일류는 Dojo, YUI3, 국내의 KISSY 등 라이브러리를 대표하는 대성당 모델이다.대성당 모델에서 모든 구성 요소는 과립화되고 모듈화되며 각 구성 요소 간에 층층이 등급을 나누고 고리가 서로 연결된다.또 다른 종류는 jQuery, RequireJS, 국내 Sea.js, OzJS 등 라이브러리를 바탕으로 하는 시장 모델.시장 모델에서 모든 구성 요소는 서로 독립적이고 직책이 단일하며 각 구성 요소는 조합을 통해 느슨하게 결합하여 협동하여 개발을 완성한다.
이 두 가지 모듈화 구축 방식은 각각 응용 장면이 있다.장기적으로 보면 작지만 아름다움은 관용성과 경쟁력을 갖추고 활력 있는 생태권을 형성할 수 있다.
한 마디로 하면 모듈화는 전단 개발에 많은 이익을 가져다 줄 수 있다.만약 네가 아직 시도하지 않았다면, Sea를 사용해 봐도 무방하다.js 시작.
전환:https://github.com/seajs/seajs/issues/547