webpack import()를 통한 동적으로 로드된 모듈 분석

이 글은 webpack import()의 동적 로딩 모듈에 대한 분석을 공유합니다. 내용이 매우 좋습니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

import

webpack은 ES2015 로더 사양에 따라 동적 로딩을 위한 import() 메서드를 구현합니다.

이 함수는 요청 시 코드를 로드할 수 있으며, 로드된 패키지를 얻기 위해 약속 스타일 콜백을 사용합니다.

코드에서 import()된 모든 모듈은 별도의 패키지로 압축되어 청크가 저장된 디렉터리에 배치됩니다. 브라우저가 이 코드 줄을 실행하면 자동으로 이 리소스를 요청하고 비동기 로딩을 구현합니다.

다음은 간단한 데모입니다.

import('lodash').then(_ => {
  // Do something with lodash (a.k.a '_')...
 })

보시다시피 import() 구문은 매우 간단합니다. 이 함수는 참조 패키지의 주소인 하나의 매개변수만 허용합니다. 이 주소는 es6의 가져오기 및 CommonJS의 필수 구문에서 사용되는 주소와 정확히 동일합니다. 원활한 전환이 가능합니다 [Meizizi를 대체하는 정규식 작성].

그리고 Promise 캡슐화를 사용하므로 개발이 매우 편안해집니다. [비동기 기능을 래핑하는 것이 더욱 재미있습니다.]

그러나 위의 내용은 단지 겉모습일 뿐입니다.

그냥 겉모습일 뿐이에요.

개발 중에 문제가 발생했습니다. 시나리오는 다음과 같습니다. 개체는 모든 수준과 해당 페이지 구성 요소의 라우팅 정보를 저장합니다. 기본 번들 크기를 줄이기 위해 이러한 페이지를 동적으로 로드하려고 합니다.

또한 반응 로드 가능을 사용하여 구성 요소의 지연 로딩 캡슐화를 단순화합니다. 코드는 아래와 같습니다.

function lazyLoad(path) {
 return Loadable({
  loader: () => import(path),
  loading: Spin,
 });
}

그런 다음 나는 행복하게 코드에lazyLoad('./pages/xxx')를 쓰기 시작했습니다. 물론, 그것은 죽었습니다. 브라우저에서는 피쉬볼이나 두꺼운 국수가 없다고 했고, 이 멍청한 모듈이 어디에 있는지 몰랐습니다.

그래서 공식 문서를 확인해 보니 노란색 막대가 발견되었습니다.

음, 문제는 여기에 있는 것 같습니다.

이 현상은 실제로 webpack import() 구현과 관련이 높습니다. webpack은 모든 import() 모듈을 별도로 패키징해야 하므로 webpack은 프로젝트 패키징 단계에서 종속성을 수집합니다.

이때 webpack은 모든 import() 호출을 찾아 들어오는 매개변수를 다음과 같은 정규식으로 처리합니다.

import('./app'+path+'/util') => /^\.\/app.*\/util$/

즉, 가져오기 매개변수의 모든 변수는 [.*]로 대체됩니다. 이 규칙에 따라 webpack은 조건에 맞는 모든 패키지를 검색하여 패키지로 패키징합니다.

따라서 변수를 직접 전달하면 webpack은 (전체 컴퓨터 패키지 [문제 없음]) 패키징하고 농담하고 있다고 생각하고 WARNING: Critical dependency: the request of a 의존성은 표현입니다. Critical dependency: the request of a dependency is an expression。

所以import的正确姿势，应该是尽可能静态化表达包所处的路径，最小化变量控制的区域。

如我们要引用一堆页面组件，可以使用import('./pages/'+ComponentName)，这样就可以实现引用的封装，同时也避免打包多余的内容。

另外一个影响功能封装的点，是import()中的相对路径

import 문의 경로는 컴파일 후 webpack 명령 실행 디렉터리에 대한 상대 경로로 처리되기 때문입니다.
관련 권장 사항:

vue에서 토큰을 새로 고치는 방법

위 내용은 webpack import()를 통한 동적으로 로드된 모듈 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!