ng-conf 2022

라코마코·2022년 9월 30일
0

Angular

목록 보기
5/6
post-thumbnail

원본: https://lmfinney.wordpress.com/2022/09/22/ng-conf-2022-report/

앵귤러 관련 아티클을 읽다가 발견한 글인데 앵귤러가 가고자 하는 명확한 방향이 들어나고 있어서 좋은 글입니다.

내용이 많아서 제가 가장 흥미로웠던 것들 위주로 정리합니다.

Developer Experience

앵귤러 프로젝트를 리드해온 Igor Minor가 퇴사한 후 (Igor Thank you angular) 앵귤러 팀은 새롭게 구성되었습니다.

새로운 앵귤러 팀의 최대 관심사는 Developer Experience(DX)입니다.

DX는 개발자 관점에서 편하게 코드를 작성하는 경험 정도로 생각하시면 됩니다.

DX를 향상시키기 위한 일환으로 stand-alone component, inject function등이 추가되었다고 합니다.

모던 프레임워크들이 서로 장점을 배끼듯이 Angular 팀도 DX를 향상 시키기 위해서 많은 프레임워크의 장점을 참조하고 있다고 합니다.


( 위에 것들에 많은 영감을 받고 있다고 하네요 )

미래에는 이런것들을 작업할 예정이라고 합니다.

  1. 공식 문서 리팩토링
  2. Hydration (SSR을 더 본격적으로 지원할 생각인가..?)
  3. 더 좋은 debgger 툴 ( di tree, 디버깅시 ngzone에 빠지지 않도록 지원해줄 예정인가 봅니다. )
  4. Vite에 영감을 받은 새로운 builder (esbuild)
  5. Reactivity
  6. directive composition api
  7. functional api

RXJS

영상 외 오프라인 회장에서 Angular내에서 RxJS의 역할과 관련한 많은 이야기가 오고 갔나 봅니다.

RxJS는 Angular에서 빠질수가 없습니다.

HttpClient 도 RxJS로 되어있고 Router도 RxJS로 이루어져있습니다.

Promise 전파처럼 RxJS도 한번 로직이 RxJS로 랩핑되어 있으면 RxJS를 사용해야 자연스러운 코드가 완성됩니다.

Angular에서 RxJS는 빠질래야 빠질수가 없는데 또한 Angular의 러닝커브를 높히는 역할도 같이 수행하죠.

아무래도 async await이 더 직관적이기도 하고 higher order observables 처음 보면 이해하기 쉽지 않습니다.

호불호가 확실한 라이브러리여서 Angular Developer Survey 에서도 의견이 확 갈린다고 합니다.

잡소리가 길었는데.. Angular에서 Reactive Programming 작성을 위해서 RxJS만 쓰도록 할 의도는 없었다고 합니다.

Angular 팀에서 HttpClinet를 작성할땐 Promise Based API(fetch api)가 없었다고 합니다. 만약 fetch 가 있었다면 Observables를 사용하지 않았을수도 있다고 합니다.

Zone.JS

위 글을 본적이 있으신가요?

Angular Future Road Map에 있는 기능중 하나입니다.

Framework에서 Zone.JS를 제거하는 기능을 추가할 예정이라고 합니다.

Zone.JS는 앵귤러를 관통하는 핵심 코어 기능입니다.

angular는 view state가 mutable 하다는 전제하에 개발 하였고 이때 view state의 변화를 감지하기 위해서 Zone.JS를 도입했습니다.

Zone.JS는 브라우저 이벤트를 Monkey Patch 하여 view state가 일어날만한 이벤트가 동작했을때 Angular의 Change Detection을 일으킵니다.

리액트처럼 setState와 같은 명시적인 방법으로 Change Detection을 일으키는것이 아니라 브라우저 이벤트를 통해서 일으키고 개발자에겐 " it just works! " 라는 경험을 주고 싶어서 Zone.JS를 도입하였다고 합니다.

하지만 Zone.JS를 도입하는데 많은 비용이 들었다고 합니다.

(Zone.JS를 도입하는데 들어간 비용)

  1. 16kb gzip 크기
  2. 50kb 브라우저가 파싱한 JS 파일 크기
  3. Monkey Patching을 먼저 적용해야 하기 때문에 "반드시!!!!!!!!!!!!" Zone.JS가 실행된 후 어플리케이션이 실행되어야함.

용량과, 반드시 Zone.JS가 실행된 후 어플리케이션 실행이 되어야 한다는 단점이 있지만 감당 가능합니다.

하지만 여기서 놓친점이 있는데 ChangeDetection은 루트부터 말단 leaf Component까지 모두 돌면서 CD가 되었는지 감시합니다.

비용이 생각보다 크기 때문에 최적화를 하기 위해선 OnPush 전략을 적용해야합니다.

(이 외에도 thrid party SDK를 Angular Zone 내에서 실행시켰을때 Zone.JS가 third party 라이브러리의 이벤트도 감지하여 CD를 일으킬수 있다고 합니다.)

이제 OnPush가 적용되었기 때문에 개발자들은 언제 어떻게 어느 시점에서 CD가 도는지 인지하고 있어야 하고, 때로는 고통 받아야 합니다.

자동으로 CD 해주기 위해서 도입하였지만.. 개발자는 CD가 도는지 항상 의심의 눈초리로 코드를 보게 되었습니다.

Zone.JS를 도입한 이유가 "it just works" 라는 DX를 주기 위함인데 오버헤드가 커져버리게 되었다고 합니다.

이러한 결정에 따라 Zone.JS를 선택적으로 제거할 수 있는 기능을 추가할 예정인가 봅니다.

Zone.JS가 없으면 어떻게 CD를 일으킬지 궁금합니다. (Vue나 React처럼 API가 나올까요?)

0개의 댓글