이제 Require.js는 Javascript를 프로그래밍하는 데 제가 가장 좋아하는 방법입니다. 코드를 더 작은 조각으로 나누어 관리하기가 더 쉽습니다. Require.js Optimizer는 더 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 분산시키고, 종속성을 통해 연결하고, 최종적으로 컴파일 및 패키징 중에 병합하는 데 도움이 될 수 있습니다. 이러한 이유로 우리는 require.js를 사용하게 됩니다.
이제 require.js의 멋진 기능을 살펴보겠습니다!
CommonJS와 호환
AMD(비동기 모듈 정의 사양)는 CommonJS 작업 그룹에서 등장했습니다. CommonJS는 Javascript 생태계를 만드는 것을 목표로 합니다. CommonJS의 중요한 부분은 AMD의 전신인 Transport/c이며, require.js는 이 사양을 구현한 것입니다.
CommonJS 모듈과 AMD 모듈의 구문 차이는 주로 AMD가 브라우저의 비동기 기능을 지원해야 한다는 사실에 기인합니다. CommonJS 모듈은 동기식으로 실행되어야 합니다. 예:
여기서 일어나는 일은 일반 AMD 모듈인 경우와 마찬가지로 require.js가 실제로 function.toString 콜백 함수를 수행하여 모듈의 내용을 구문 분석하고 올바른 종속성을 찾는 것입니다. 이 방식으로 모듈을 작성하기로 선택하면 AMD 사양에 어긋나기 때문에 다른 AMD 모듈 로더와 호환되지 않을 가능성이 높지만 이 형식이 존재한다는 것을 아는 것이 좋습니다!
CDN 대체require.js의 또 다른 숨겨진 보석은 CDN이 올바르게 로드되지 않을 때 로컬 해당 라이브러리 로드로 폴백을 지원한다는 것입니다. require.config를 통해 이를 달성할 수 있습니다:
의존성이 없나요? 객체 리터럴? 괜찮아요!
종속성 없이 모듈을 작성하고 일부 기능 함수가 포함된 객체를 반환하는 경우 간단한 구문을 사용할 수 있습니다.
순환 종속성
어떤 경우에는 moduleA 모듈이 필요할 수 있으며 moduleA의 기능은 일부 애플리케이션에 따라 달라져야 합니다. 이것이 순환 의존성입니다.
모듈의 주소를 알고 싶다면 이렇게 하면 됩니다...
기본 URL
보통 단위 테스트를 수행할 때 소스 코드는 src와 유사한 폴더에 배치되는 동시에 테스트도 테스트와 유사한 폴더에 배치될 수 있습니다. 테스트 구성을 올바르게 설정하는 것이 어려울 수 있습니다.
예를 들어, 테스트 폴더에 index.html 파일이 있고 테스트/spec/*.js를 로컬로 로드해야 합니다. 그리고 모든 소스 코드가 src/js/*.js에 있고 해당 폴더에 main.js가 있다고 가정합니다.
index.html에서 require.js 로딩 시 data-main을 설정하지 마세요.
여기서 main.js가 로드되는 것을 볼 수 있습니다. 단, 메인 스크립트 태그에는 데이터를 불러오지 않기 때문에 반드시 베이스를 지정해 주셔야 합니다. 데이터가 주로 baseURL에 대한 것인 경우 기본 파일의 위치에서 유추됩니다. baseUrl을 사용자 정의하면 테스트 코드와 애플리케이션 코드를 별도로 쉽게 저장할 수 있습니다.
JSONP
다음과 같이 JSONP 터미널을 처리할 수 있습니다.
요청이 많아 AMD가 아닌 타사 라이브러리를 사용해야 합니다. 예를 들어 Backbone과 Underscore는 AMD 사양에 적합하지 않습니다. 그리고 jQuery는 실제로 자신을 jQuery라는 전역 변수로 정의하므로 jQuery와는 아무런 관련이 없습니다.
다행히도 심 구성을 사용하여 이 문제를 해결할 수 있습니다.