JS는 구현 code_javascript 기술 로딩을 완벽하게 포함한다는 것을 깨닫습니다.

js에 include가 필요한 이유는 무엇입니까? a.js가 공통 common.js를 사용해야 하는 경우를 생각해 보겠습니다. 물론 a.js를 사용하는 페이지에서는 a.js를 사용하는 5페이지 스크립트를 5번 작성해야 하나요? 그리고 앞으로 a.js가 common2.js를 참조해야 한다면 다시 5페이지를 수정하실 건가요? 기존 js의 몇 가지 문제는 이 글을 쓰기 전에 인터넷에서 몇 가지 정보를 검색한 결과 이전에 작성한 include에 두 가지 문제가 있음을 발견했습니다. 이 역시 해결해야 할 두 가지 중요한 문제입니다. . 1. 상대 경로 문제: a.js에서 include("../js/common.js")를 사용합니다. include 함수는 a.js에 대한 상대 경로인 상대 경로를 사용해야 합니다. HTML에서 를 사용하여 a.js를 삽입하는 경우 상대 경로일 수도 있고 절대 경로일 수도 있습니다. include 함수가 실제로 common.js의 절대 경로 또는 html의 상대 경로를 결정할 수 있는 방법은 무엇입니까? 인터넷에서 이 문제를 해결하려면 일부 js 변수를 추가해야 하는데, 이는 불편합니다. 2. 인용 문제. 인터넷에서 include 함수 구현은 거의 항상 다음 두 가지 방법을 사용하여 common.js document.write(" ") or var s = document.createElement("script"); s.src = ...; head.insertAfter(s,...) 문서별 스크립트 출력 .write는 .js에 나중에 로드되며 createElement("script")에 의해 생성된 스크립트는 비차단적으로 로드됩니다. 따라서 common.js가 로드되기 전에 a.js에서 common.js 함수를 호출하면 오류가 보고됩니다. 구현 위의 두 가지 문제를 해결하기 위해 js include를 구현할 수 있습니다. 첫 번째 질문, 내 방법은 먼저 html에서 a.js의 절대 경로를 가져온 다음(상대 경로인 경우 절대 경로로 변환), 그런 다음 common.js의 경로를 절대 경로로 변환하는 것입니다. 길. 두 번째 질문은 동기식 ajax를 사용하여 common.js를 요청하면 참조 문제가 발생하지 않는다는 것입니다. 구현 코드는 다음과 같습니다.

코드 복사 코드는 다음과 같습니다. // 상대 경로에 따라 절대 경로 가져오기 function getPath(relativePath,absolutePath){ var reg = new RegExp("\.\./","g") var ulayCount = 0; // 상대경로로 반환 상위레벨 개수. var m = 상대 경로.일치(reg); if(m) ulayCount = m.length; var lastIndex = 절대 경로.길이-1 for(var i=0;i lastIndex =absolutePath.lastIndexOf("/",lastIndex); } return 절대 경로.substr(0,lastIndex 1) 상대 경로.replace(reg,""); 🎜>} function include(jssrc){ // 먼저 현재 a.js의 src를 가져옵니다. a.js에서 include를 호출하고 a.js의 참조인 마지막 스크립트 태그를 직접 가져옵니다. var scripts = document.getElementsByTagName("script"); var lastScript = scripts[scripts.length-1] var src = lastScript.src; if(src.indexOf(" http://")!=0 && src.indexOf("/") !=0){ // a.js는 상대 경로를 사용하므로 먼저 절대 경로로 바꿉니다. var url = location .href; var index = url.indexOf("?"); if(index != -1){ url = url.substring(0, index-1); src = getPath(src,url); } var jssrcs = jssrc.split("|") // for(var i= 0; i // js를 로드하려면 juqery의 동기식 ajax를 사용하세요. // 현재 js 뒤에 js를 동적으로 추가하려면 js 참조 문제가 있을 수 있습니다. // 비차단 다운로드이고 참조 문제를 일으킬 수 있는 스크립트를 동적으로 생성합니다. $.ajax({type:'GET',url:getPath(jssrc,src),async:false,dataType:'script '} ); } }

a.js에서 직접 include("../js/common.js")를 사용하세요.

여러 요청의 문제 위의 include를 사용하는 것은 꽤 괜찮아 보이지만 또 다른 심각한 문제가 있습니다. 문제는 하나 이상의 ajax 요청이 전송된다는 것입니다. 우리는 WEB 성능에 대한 요청을 줄이기 위해 js를 병합하는 경우가 많습니다. 그런데 include를 사용한 후 요청이 더 많아졌습니다. 이 문제가 해결되지 않으면 LAN 제품이 아닌 이상 공식 제품에 include를 사용하지 않는 분들이 많을 거라 생각합니다.

저는 이 다중 요청 문제를 어떻게 해결할 수 있을지 오랫동안 고민해왔는데, 마침내 클라이언트 js만으로는 해결할 수 있는 방법이 없다는 것을 깨달았습니다. 그래서 이를 해결하기 위해 서버사이드 코드를 사용해보자고 생각했습니다 "js와 CSS의 병합, 압축, 캐시 관리"를 소개하는 기사가 있을 때, 서버사이드 코드를 사용하여 js를 병합한 일이 아직도 기억납니다. 프로그램이 시작되었습니다.

그래서 여러 요청을 포함하는 솔루션도 추가했습니다. 프로그램이 시작되면 모든 js를 검색해 보세요. include가 사용된 것을 발견하면 include에서 common.js의 소스 코드로 include 함수를 바꾸세요. 이렇게 하면 a.js 실행시 include 기능은 없지만 실제로 common.js

Postscript 丫의 내용을 담고 있는 js 파일이 생성됩니다. 결국, 왜 모든 포함을 교체했는가? 앞서 말한 내용은 헛되지 않습니다.

개인적으로 모든 제품은 개발 환경과 제품 환경을 구분해야 한다고 생각합니다(보통 구성 파일을 통해). 개발 환경에서는 개발 효율성이 최우선이어야 하고, 제품 환경에서는 성능이 최우선이어야 합니다. 최우선 순위. 따라서 여기에서의 include는 다르게 취급되어야 합니다. 개발 환경에서는 개발 및 유지 관리 효율성을 높이기 위해 js include가 사용되는 반면, 프로덕션 환경에서는 모든 include가 실제 js 파일의 내용으로 자동 대체됩니다. [작성자] : 베어루이(AK-47)