Angular 9와 Ivy

해당 포스팅은 https://blog.angular.io/version-9-of-angular-now-available-project-ivy-has-arrived-23c97b63cfa3 를 해석하고 개인적으로 찾아본 내용을 추가한 글입니다.

 

 

Angular 9으로 업데이트 되면서 가장 큰 변화는 Ivy 컴파일러를 기본 렌더링엔진으로 변경되었다.

Ivy는 사이즈감소, 속도 증가, 유연성 증가에 초점을 두어 개발되었다는데, 이를 위해 모든 컴포넌트가 돔트리를 구성하는 지시자를 컴파일하는 증가형 돔을 사용하였다.

Virtual DOM과 Incremental DOM에 대한 내용은 아래 두 블로그에 자세히 나와있어 링크 참조 바랍니다.

https://alexband.tistory.com/58

https://blog.eunsatio.io/develop/Angular-Ivy-이해하기:-증가형-돔과-가상형-돔

 

Advantages

 

• Smaller bundle sizes
• Faster testing
• Better debugging
• Improved CSS class and style binding
• Improved type checking
• Improved build errors
• Improved build times, enabling AOT on by default
• Improved Internationalization

 

 

 

Smaller bundle sizes

아이비 컴파일러는 트리쉐이킹을 통해 사용되지 않는 angular의 일부를 제거하고 각 angular 컴포넌트에 대해 더 적은 코드를 생성하도록 설계되었다.

• 앵귤러의 기능을 많이 쓰지않는 작은 애플리케이션은 트리쉐이킹으로 얻는 이점이 크다.
• 많은 컴포넌트를 사용하는 큰 애플리케이션은 팩토리사이즈를 줄임으로 얻는 이점이 크다.
• 중간 사이즈앱은 트리쉐이킹의 이점이 적고 작은 팩토리를 활용하기엔 충분한 구성요소가 없기때문에 동등하거나 약간 작은 번들 크기를 볼 수 있다.

Small apps은 30%, Large apps은 25~40% 정도 번들사이즈가 감소하였고 Medium apps에서 가장 적은 감소를 보였다.

 

Faster testing

Ivy에서 TestBed(앵귤러앱과 라이브러리 유닛테스트 api, 단위 테스트의 구성요소 및 서비스 작성방식을 제공하고 유닛테스트 환경을 구성하고 초기화함.)의 구현을 보다 효율적으로 개선했다.

Ivy 이전 버전에선 TestBed가 구성요소에 대한 변경(ex: overrides)이 있는지 여부에 관계없이 각 테스트 실행간에 모든 구성요소를 다시 컴파일했지만

Ivy의 TestBed는 구성요소를 수동으로 재정의하지 않는한 테스트간에 구성요소를 다시 컴파일하지 않으므로 대다수의 테스트간에 재컴파일을 피할 수 있다.

이로 인해 프레임워크의 core acceptance tests는 약 40% 빨라졌고 사용자들의 애플리케이션은 약 40-50% 더 빠를것으로 예상한다.

 

Better debugging

Ivy는 더 많은 디버깅 툴을 제공한다. DevMode에서 Ivy runtime으로 애플리케이션을 실행시키면 디버깅을 위한 새로운 ng object를 사용할 수 있다.

• 컴포넌트, 디렉티브 등의 인스턴스에 접근할 수 있다.
• 수동으로 메소드를 호출하고 상태를 업데이트 할 수 있다.
• change detection의 결과를 보고 싶을 때  applyChanges  로 change detection을 trigger시킬 수 있다.

이전에는 스택 추적이 도움이 되지 못했지만  ExpressionChangedAfterItHasBeenCheckedError  와 같은 디버깅 문제에 대한 스택 추적을 개선하였다.

Ivy를 사용하면 변경된 표현식을 사용하여 템플릿 명령어로 직접 이동할 수 있는 스택추적을 할 수 있다.

위의 스택 추적에서  AppComponent_Template 을 클릭하면 생성된 코드에서 오류가 발생하는 특정 라인을 볼 수 있다.

 

Improved CSS class and style binding

이전에는 애플리케이션에 스타일에 대한 우선 순위가 있어 같은 스타일이 적용되어 있을 때 파괴적으로 대체되었지만 아이비를 사용하면 예측가능하게 스타일을 병합할 수 있다.

<my-component style="color:red;" [style.color]="myColor" [style]="{color: myOtherColor}" myDirective></div>

@Component({
  host: {
    style: "color:blue"
  },...
})
...

@Directive({
  host: {
    style: "color:black",
    "[style.color]": "property"
  },...
})
...

이전에는 마지막으로 정해진 컬러로 바인딩되었고 이 또한 변경시점에 따라 컬러가 달라질 수 있었다. myColor와 myOtherColor가 모두 undefined이라면 static인 'red'또한 무시되었다.

9버전에서는 타이밍에 의존하지 않게 명확하고 일관된 우선 순위를 통해 스타일을 관리할 수 있다. 가장 구체적인 스타일이 가장 높은 우선순위를 갖게 되어 [style.color]에 바인딩한것과 [style]에 바인딩한 것이 충돌하면 [style.color]에 바인딩한것이 더 높은 우선순위를 갖는다.

하지만 이전버전과의 호환성을 위해 [ngStyle] 및 [ngClass] 바인딩 동작은 이전과 동일하게 유지했다. 바인딩값이 업데이트되면 새로운 값은 충돌된 바인딩을 오버라이드 한다. (새로운 값으로 대체된다.)

 

Styling precedence (highest to lowest)

1. Template bindings
   1. Property binding (for example, <div [class.foo]="hasFoo"> or <div [style.color]="color">)
   2. Map binding (for example, <div [class]="classExpr"> or <div [style]="styleExpr">)
   3. Static value (for example, <div class="foo"> or <div style="color: blue">)
2. Directive host bindings
   1. Property binding (for example, host: {'[class.foo]': 'hasFoo'} or host: {'[style.color]': 'color'})
   2. Map binding (for example, host: {'[class]': 'classExpr'} or host: {'[style]': 'styleExpr'})
   3. Static value (for example, host: {'class': 'foo'}or host: {'style': 'color: blue'})
3. Component host bindings
   1. Property binding (for example, host: {'[class.foo]': 'hasFoo'} or host: {'[style.color]': 'color'})
   2. Map binding (for example, host: {'[class]': 'classExpr'} or host: {'[style]': 'styleExpr'})
   3. Static value (for example, host: {'class': 'foo'}or host: {'style': 'color: blue'})

Improved type checking

9버전에서 Angular 컴파일러는 더 많은 애플리케이션의 타입을 체크할 수 있으며 더 많은 strict rule을 적용할 수 있다. 이로 인해 개발초기에 더 빨리 버그를 발견할 수 있다.

Full mode에선 Basic mode에 있는 기능과 함께 추가 타입 검사를 위해 두가지 기본 플래그를 제공한다.

• fullTemplateTypeCheck
  • 템플릿의 EmbededView( ngIf, ngFor, ng-template) 체크.
  • Pipe의 return type 체크
  • 지시문과 파이프에 대한 로컬참조 체크(any타입을 갖는 일반 파라미터 제외)
• strictTemplates - 타입체크에 가장 엄격한 타입시스템 규칙이 적용됨

더 자세한 내용: Template type checking guide

 

Improved build errors

Ivy컴파일러는 빠르고 강력한 type safety를 지원해줄뿐만 아니라 에러메세지를 더 쉽게 보여준다.

8버전 이하 View Engine에서의 컴파일 에러

9버전 Ivy에서의 같은 에러

 

Improved build times, enabling AOT(Ahead-of-Time compiler) by default

Angular의 컴포넌트와 HTML템플릿은 브라우저에서 직접 이해할 수 없으므로 브라우저에서 실행하기 전에 컴파일단계가 필요하다.

AOT - 빌드타임에 애플리케이션과 라이브러리를 컴파일함. (브라우저가 해당 코드를 다운로드하여 실행하기 전에 AOT컴파일러가 Angular HTML 및 TypeScript 코드를 효율적인 js코드로 변환하기 때문에 브라우저에서 렌더링이 더 빨라짐)

JIT - 런타임시 브라우저에서 애플리케이션을 컴파일함.

애플리케이션의 일반 typescript 컴파일을 통해 오버헤드 측면에서 컴파일러의 성능을 측정했을 때, angular.io 사이트의 경우 오버헤드가 0.8x에서 0.5x로 감소하여 약 40%가 향상되었다.

눈에 띄게 속도가 향상된 AOT빌드로 인해 처음으로 dev mode 빌드에 AOT를 사용하게 되었다. 즉 ng serve 시에도 프로덕션빌드와 동일한 컴파일 타임 검사 이점을 가지게 된다.

컴파일러와 런타임의 변경으로 컴포넌트가 자동으로 검색 및 컴파일이 되기 때문에 더이상 entryComponents가 필요하지 않다.

 

Improved internationalization(i18n)

앵귤러에서 다국어적용이 지원되는데 locale당 한번만 애플리케이션을 빌드하고 고도로 최적화되었고 현지화 된 애플이케이션을 받을 수 있다고 한다. 9.0에서는 빌드 프로세스 후반에 빌드 시간 i18n 대체물을 이동하여 이를 더욱 빠르게 하고 있다. 이 변경으로 최대 10배 더 빨라졌다. 하지만 대부분의 앵귤러 유저들은 i18n보단 ngx-translate를 쓴다고해서 자세히 알아보지는 않음