KISSY loader의 디자인

KISSYhttp://github.com/kissyteam/kissy가 무엇인지, 로드러가 Yui를 사용한 사람은 Yui-loader에 대해 낯설지 않을 것이다. Yui doc에서 로드러에 대해 이렇게 묘사한다.
The YUI Loader Utility is a client-side JavaScript component that allows you to load specific YUI components and their dependencies into your page via script. YUI Loader can operate as a holistic solution by loading all of your necessary YUI components, or it can be used to add one or more components to a page on which some YUI content already exists.
따라서 쉽게 말하면 loader는 js 스크립트의 의존 관계를 처리하는 마운트기로서 수요에 따라 마운트, 지연 마운트, 마운트와 관련된 js 등 기능을 실현했다. 그 중에서 수요에 따라 마운트하는 것은 웹 앱 개발의 복잡도를 크게 간소화했고 지연 마운트는domReady의 시간을 크게 앞당기고 UI 렌더링 속도를 빠르게 향상시켰다.관련 js를 불러오면 개발자가 스크립트 정렬에 신경 쓰지 않고 라이브러리의 사용을 간소화합니다.과립화 디자인의 라이브러리는 라이브러리의 용이성을 제어하기 위해loader가 필요합니다.yui2에서yui3까지 이런 추세가 더욱 뚜렷합니다.따라서 KISSY가 과립화의 길을 걷기 시작했을 때 loader는 거의 필수 구성 요소가 되었다.페이지에서 스크립트를 불러오는 방식은 페이지에서script 라벨로 외부 스크립트를 도입하면 막힌 불러옵니다. 스크립트가 불러오는 전후에 상관없이 페이지는 항상 위에서 아래로 차례로script 스크립트를 실행합니다.비동기적으로 스크립트를 불러오는 경우, 스크립트 불러오기가 완료되면 바로 스크립트 내용을 실행합니다.따라서 비동기 스크립트의 불러오는 순서와 실행 순서는 상관없고 스크립트가 불러오는 시간과 관계가 있습니다.비동기 스크립트의 의존 관계를 처리하려면 스크립트 불러오기 시작할 때를 제외하고 불러오기 완료된 리셋을 정렬해야 합니다.따라서 스크립트의 논리는 정렬만 사용할 수 있도록 리셋 함수에 기록해야 한다.KISSY가 제공하는 간단한 샌드박스는 이런 리셋 포장을 시뮬레이션할 수 있다.다중 로더가 병존합니까?만약에 페이지가 복잡하다면 우리는 모든 모래상자에 loader가 있기를 자연스럽게 기대한다. loader 간의 마운트는 병행할 수 있고 모든 loader는 각자의 의존만 처리할 수 있다. 이런 디자인은 페이지 논리의 결합을 해결하기 위해서이다. 페이지의 모든 app 간의 결합을 최소화하고 전체 페이지는 하나의 app의 마운트 장애로 인해 다른 app의 운행에 영향을 주지 않는다.yui는 바로 이런 디자인이다. 이런 디자인에서 가장 자주 사용하는 장면은 포털의 첫 페이지에 사용된다. 페이지에 고정된 관리자가 없고 모든 사람이 수시로 삭제 모듈을 추가할 수 있다. 페이지의 최종 렌더링 결과는 특정한 앱의 영향을 받지 않는다.따라서 복잡할수록 변화가 빈번한 페이지에서 도로ader는 선진적인 디자인이고 일반 페이지에서 도로ader 메커니즘은 닭갈비와 같다.KISSY의 디자인 취지는 간단하고 사용하기 쉽기 때문에 단일 로더 모델은 현재 국내 포털의 모든 요구를 충족시킬 수 있고combo를 설정하는 전제에서 단일 로더의 성능은 다중 로더의 장면을 훨씬 능가한다.모래상자 사이의 직렬 라이브러리의 디자인은 모래상자를 떠날 수 없다. 모래상자는 논리적 결합을 하는 데 사용될 뿐만 아니라loader 메커니즘에서 포장 리셋과 직렬 리셋을 실행하는 조율자 역할도 한다.위에서 말한 바와 같이 비동기 스크립트는 리셋 형식으로 제시해야 한다. 그러면 loader는 스크립트 의존에 대해 정렬을 해야 한다. 여기서 말한 스크립트 의존은 실제적으로 각 스크립트 리셋 함수의 집행 순서이고 엄격한 의미의 스크립트 로드(완성) 순서가 아니다. 즉, 엄격하게 말하면 스크립트 로드 순서는 loader와 필연적인 관계가 없다.또한 가장 중요한 것은 키시가 약한 모래상자로 설계되어 리셋을 더욱 뚜렷하고 편리하게 관리할 수 있는 직렬 연결이 가능하지만 약한 모래상자 때문에 키시는 유이 모래상자 중의 독립된 실례 디자인이 가져온 유연성을 실현하지 못한다.간단한 예를 들어 YUI의 loader는 끼워 넣을 수 있다.

YUI().use('mod1
'
,function
(Y){
    YUI().use('mod2
'
,function
(Y){
        //your code
    });
});

모래상자 사이의 scope는 서로 간섭하지 않고 매우 안전하다.KISSY는 하나의 전역 대상(비구조기)으로서 이 점을 할 수 없다. 왜냐하면 여러 scope가 같은 전역 KISSY 대상의 영향을 받기 때문이다.그러나 이것은 방금 말한 도로더의 이해득실과 관련이 있다. 그리고 내가 YUI를 사용하는 실천에서도 이렇게 코드를 쓴 적이 없다. 약한 샌드박스를 사용하면 원래 간단한 논리와 날씬한 몸매를 유지해야 하기 때문에 약한 샌드박스의 간결하고 읽기 쉽도록 유지하는 것이 강한 샌드박스로 원래 혼란스러웠던 논리를 제거하는 것보다 훨씬 시원스럽다.따라서 KISSY는 전역작에서 로더로 사용할 수 있고 순수한 직렬 논리에서 약한 모래상자의 본질을 유지한다.예를 들어, loader로 사용:

var
 S = KISSY;
S.add('mod1
'
,function
(S){
    //scope 1

},{requires:['mod2
'
]});
S.add('mod2
'
,function
(){
    //scope 2

});
S.ready(function
(S){
    //scope 3

});

간단한 모래상자로 사용:

S.ready(function
(S){
    S.add('mod1
'
,function
(){
        //scope 1

    });
    S.ready(function
(S){
        //scope 2

    });
});

이런 코드는 이해하기 쉽다. 그러나 YUI에서 캐리어 모듈과 리셋을 도입하는 것은 두 가지 다른 개념이다. 만약에 캐리어 모듈이 인용을 잊어버리면 의존 관계가 사실상 끊어진다. 이런 디자인은 초보자의 사고 혼란을 초래하기 쉽다. 왜 스크립트를 불러왔지만 스크립트 코드는 사용할 수 없습니까?예를 들면 다음과 같습니다.

<script src='yui/node/node.js'
 />
<script>
YUI().use('core'
,function
(Y){
    //Y.Node     ，   use('node'
)   
});
</script>

개발자로서 왜 내가 노드를 도입했는지 모르겠다.js, 또use('node'), 왜 이런 짓을 많이 해요?Yui가 이렇게 디자인한 것은 주로 복잡한 업무 논리를 대상으로 하는 것이다. 즉, 페이지 업무 논리 자체의 복잡도가 한 차원에 도달한 후에 더욱 깊은 차원의 결합이 필요하다.따라서 YUI는'로드 모듈'을 1층의 결합으로 하고'리셋 도입'을 2층의 결합으로 한다. 복잡한 업무 논리 장면에서 비교할 수 없는 우월성을 가진다. 이것은 순수한'구조'가 한 일을 벗어나 더욱 의미화된 업무 논리로 한 걸음 나아갔기 때문에 YUI를 사용하는 과정에서 깊이 체득했다.KISSY의 간결한 디자인 원칙 아래 간단한 장면에서 약간 군더더기를 보이는 이런 닭갈비 디자인을 완전히 절약할 수 있다. 복잡한 업무 논리는 만날 수 있지만 매일 만나지 않는다.더욱이 KISSY는 KISSY를 제공한다.app는 업무 논리에 대한 지원으로 충분합니다.따라서 프레임 차원의 샌드박스는 보고 얻은 간결함을 유지해야 하며 KISSY의 디자인 이념에 부합된다.페이지 렌더링 프로세스 페이지는loader를 사용하여 불러오는 과정에서 렌더링 과정에 약간의 상태 변화가 있을 수 있습니다. 그 중에서 비동기적으로 불러오는 스크립트는 특수 처리를 필요로 하고 이 단계를 제외한 스크립트의 실행은 KISSY가 처음에 디자인한 그대로 유지됩니다.따라서 여기에 애프터 Ready의 상태를 추가했는데 실행 과정은 대체적으로 이렇다. 따라서 KISSY loader의 초기 형태도 묘사가 많지 않다. 간단한 모래상자, 단일 loader, 보고 얻은 모듈을 불러온다. 그리고 최종적으로 필요한 것은 핵심 구성 요소든 프로젝트 파일이든 일률적으로 모듈로 처리한다. 이것은 YUI와 다른 부분이다.이렇게 하면combo가 매우 시원할 것입니다. 수많은 파일을 입자화하든지, 페이지에 피드 파일을 추가하든지, http 요청 (css 하나, js 하나) 이 세 개밖에 없습니다.두 개의 데모 http://jayli.github.com/test/src/kissy/ ... oader.html http://jayli.github.com/test/src/kissy/ ... oader.html 를 제공합니다. 현재 js만 지원합니다. 주말에 css 지원도 추가합니다.
 
출처:http://www.uedmagazine.com/ued/comments.php?y=10&m=08&entry=entry100814-104521