리콰이어JS

리콰이어JS는 이 장에서 개발한 DiContainer와 구문이 흡사하다(사실 우리가 리콰이어JS를 베낀 것이다). DiContainer의 register 함수는 리콰이어JS의 전역 함수 define에, get(모듈명) 함수는 리콰이어JS의 require(모듈 URL)에 각각 대응된다.

“모듈 URL이라고?” 그렇다. 리콰이어JS는 특이하게 스크립트 위치를 모듈명으로 쓴다. 예를 들어 리콰이어JS 컨테이너에서는 AttendeeFactory를 이렇게 주입한다.

---

define(['./Service', './Messenger'], function(service, messenger) {
return function(attendeeId) {
  return new Attendee(service, messenger, attendeeId);
}
});

---

AttendeeFactory는 모듈명(['Service', 'Messenger'])이 아니라 상대 URL(['./Service', './Messenger'])을 바라본다.

그럼 우리가 정의한 AttendeeFactory 이름은 어떻게 할까? 이 코드가 작성된 파일 URL(아마도 ./AttendeeFactory.js)은 모듈명으로도 쓸 수 있어서 고민할 필요가 없다. 이런 리콰이어JS 특성 덕분에 이름 충돌이 저절로 예방되어 편하다. 리콰이어JS의 기본 사상은 ‘파일 하나당 모듈 하나’다.

(DiContainer.register 같은 구문으로) 명시적으로 모듈을 명명해도 되지만, 이 라이브러리의 기본 사상과 맞지는 않는다.

리콰이어JS는 DI 모듈을 URL과 연결하여 스크립트 로딩을 최적화한다. 사실 리콰이어JS 자체가 서버에서 브라우저로 모듈을 가져오는 문제(http://wiki.commonjs.org/wiki/Modules/Transport의 Transport C 참고)를 해결하기 위해 커먼JS(CommonJS) 위원회에 상정된 몇 가지 제안 중 하나에서 시작됐다. 당시 커먼JS는 리콰이어JS를 공식 채택하지 않았지만, 아이러니하게도 아직 살아남아 가장 널리 사용되는 기술이 됐다.

더 자세한 기능은 http://requirejs.org를 참고하자.