- 공유 의존성은 런타임에 로드되는 앱의 빌드타임에 공유 의존성에 정의된 모듈을 별도 청크로 분리하여 번들링함.
- 런타임에서 앱이 로드 될 때, 해당 공유 의존성을 사용하면서 먼저 로드되는 앱의 런타임에 미리 분리된 청크를 로드하여 의존성을 사용함.
- 무조건 호스트앱의 의존성 청크가 로드되리라는 법은 없고, 리모트앱이 먼저 로드된다면 리모트앱의 의존성 청크가 로드되기도 함.
- 런타임에 로드되는 앱의 빌드타임에 공유 의존성에 정의된 모듈을 별도 청크로 분리하여 번들링함.
- 런타임에서 앱이 로드 될 때, 해당 공유 의존성을 사용하면서 먼저 로드되는 앱의 런타임에 미리 분리된 청크를 로드하여 의존성을 사용하게 함.
- 이어 로드되는, 해당 공유 의존성을 사용하는 앱의 먼저 불러온 공유의존성은 따로 로드하지 않고, 이미 로드된 청크에서 의존성을 사용할 수 있게함.
- 만약 먼저 불러온 공유 의존성이 로드된 마이크로앱에서 사용한다고 정의한 의존성과 버전이나 share scope이 맞지 않을 경우 해당 앱은 자신의 빌드 번들에서 공유 의존성에 대한 번들을 꺼내서 씀
- 런타임에서 마이크로앱 간 많이 쓰이는 의존성에 대해 해당 의존성을 런타임에 딱 한번만 로드하면 됨. 따라서 모든 마이크로앱에서 해당 의존성을 가질 필요가 없다.
- 앱 전역에서 단일 인스턴스 보장가능
- 런타임에서 앱이 합체되는 마이크로프론트엔드에서는 배포/개발은 결국 따로하지만 브라우저는 하나의 앱임. 백엔드의 마이크로서비스와 다르게 완전히 격리된 환경에서 각 마이크로앱이 구동되는게 아님!
- 앱 최상위에서 Context Provider를 두고 같이 공유해야하는 경우 사용 가능
- 하나의 앱의 모든 부분이 일관된 동작을 하도록 하려면 앱 전역에서 의존성 인스턴스를 딱 하나로만 맞춰줘야 하는 경우가 생김
- var, window와 같은 전역 변수를 사용하는 라이브러리
- 라이브러리 내에서 런타임에 let으로 변수 재할당, var과 같은 전역변수를 사용하는 경우. 인스턴스가 2개 이상이면 동시성 이슈가 있을 수 있음
- 스타일과 관련된 라이브러리 일부
- css-in-js 라이브러리의 인스턴스가 여러개라면, 같은 스타일이 두 번 적용된다거나 하는 문제 때문에 스타일링이 의도대로 되지 않을 수
- 런타임에 문제가 없더라도, 앱의 일관된 동작을 보장하기 위해 스타일 관련한 라이브러리의 인스턴스를 앱 전체에서 하나로 맞춰야할 수 있음
- 앱 최상위에 Context Provider등을 두고 써야 하는 라이브러리
다만 공유 의존성 사용 시 트리쉐이킹 불가능