Skip to content
This repository has been archived by the owner on Nov 24, 2018. It is now read-only.

Latest commit

 

History

History
59 lines (48 loc) · 5.72 KB

171123_TIL.md

File metadata and controls

59 lines (48 loc) · 5.72 KB

17.11.23.(목)

DONE

  • Angular 수업 마무리

    • Module
      ____관심사가 비슷한 요소들을 모듈로 묶는다. 관심사가 비슷하다는 건 공통의 뷰 구성에 관여한다는 의미이다.
      ____root module은 BrowserModule을, sub module은 CommonModule을 import하며 브라우저모듈은 커먼모듈을 포함한다.
      ____데코레이터 함수에 전달되는 메타데이터 객체를 구성하는 프로퍼티 중 bootstrap은 root module에 사용된다.
    • Routing, Navigation
      ____SPA에서 url 엔드포인트가 바뀌어도 페이지를 새로 로드하지 않고, 일부 구성요소만을 추가 렌더링하기 위해 제공하는 기능. <router-output> 태그를 템플릿 내부에서 사용하면, 해당 태그는 path에 따라서 다른 컴포넌트를 의미한다.
      ____Navigation은 사용자가 url을 직접 입력하지 않아도 지정한 path에 접근하여 <router-output> 요소를 볼 수 있게한다. 일반적으로 <a>태그의 href 어트리뷰트에 path를 지정하고, 이벤트에 바인딩하기도 한다.
    • Router State, Guard
      ____Router에 의해서만 url path에 접근이 가능하도록 제한할 목적으로 Guard를 사용한다. (e.g.,로그인 인증) 상태 정보가 Router에 기록되고, 해당 정보에 따라서 path에 접근할 수 있으며 url 입력으로는 접근이 제한된다.
  • John Papa blog에서 모듈 관련 내용 발췌

    • service 주입 시 인젝터 트리 탐색 절차: host component를 시작으로 component tree를 탐색하고, 마지막으로 자신을 선언한 모듈을 탐색한다.
      ____injector tree 탐색을 최소화 하기위해서는 component마다 provider를 사용해야할 것 같지만, provide service는 일반적으로 애플리케이션 전역에서 공유되므로 root module에서 provide 하는것이 바람직하다.
      ____injector는 컴포넌트 레벨당 존재하고, 루트모듈에도 존재한다. 모듈 레벨 인젝터는 존재하지 않으며 서브모듈 provider는 루트모듈 provider를 참조한다(?)

    Angular first looks in this component's injector for our service. Since we did not provide the service in the @Component decorator's providers property, Angular keeps going up the component tree until it finds the service. We never provided it in a component, so it ultimately looks in its root injector and finds our service. If the service has already been instantiated, we get that service instance. If not, a new instance is created. This is how we locate and inject services. Providers are perhaps one of the most involved and challenging Angular Module concepts. For a general rule of thumb, provide services you intend to be shared across your app, as a single multi-use instance, in the app root module.

    • 서브모듈로 분리하는 이유
      • feature area를 애플리케이션 전역에서 사용하기 위해서.
      • lazy loading으로 성능을 높이기 위해서
    • Routing Module 분리 팁
      • 라우팅 모듈에서, 사용한 컴포넌트 클래스의 배열을 별도의 변수의 할당 및 export하면 루트 모듈에서 컴포넌트를 또한번 줄줄이 import 하지 않아도 된다.
    • Feature module이란 무엇인가?
      • 하나의 뷰를 구성하는 컴포넌트, 해당 뷰에서 동작하는 기능의 집합
        • 전역에 항상 존재하는 것: Root Feature(=core feature)
        • 전역에서 인스턴스를 생성함으로써 공유되고, 추가될 수 있는 것: Shared Feature
          ____Shared Feature는 별도의 모듈로 분리하고 root module에 import
        • router를 통해 도달하는 별개의 feature area: Charaters Feature
          ____라우터모듈이 여기에 해당하며, shared module import가 별도로 필요
        • bootstrap 시 한번 로드하고 사라지지 않는, 분리하고 분리해도 root module에 남아있는 것: Core Feature
  • Angular Tour of Hero tutorial

    • *.service.ts 인스턴스를 주입하여 메소드 사용 시, 컴포넌트 클래스에서 별도의 메소드를 추가하여 사용하는 것이 좋다.
    • "Angular only binds to public component properties."
    • async service method: Observable !!
      ____비동기통신 함수를 서비스로 빼놓은 경우, 옵저버블 객체를 반환하도록 작성한다. subscribe 구문은 이후에 서비스를 주입받는 컴포넌트 클래스에서 작성한다.

TODO

  • 다음 번역: Angular Template Syntax

  • Namu프로젝트 레이아웃 구성에 필요한만큼만 Material design guide 읽기

  • 궁금한것들

    • Observable 형태로 도착한 것을 .subscribe 체이닝 시 첫번째 콜백함수로 받을 수 있는데, http client를 주입해서 만든 메소드의 return 값을 컨트롤할 방법은 없는지?(조건부 반환이라 타입이 불분명하다..) 자체해결
    • 서비스 import와 provider 차이 불분명
    • pathMatch: full 무엇..?
    • router snapshot 다시 볼 것.

review

  1. 코딩을 게을리하고 프레임워크 작동원리에 심취하니까 실력이 제자리걸음이었다. 언제나 반반을 유지하는게 중요하다고 느끼는 날이었다...만 다음 주부터는 프로젝트 때문에 백날 코딩만 할 터이니 반대로 원리 파악을 놓지 않도록 해야겠다.

  2. 코딩만 게을리한게 아니라 하루를 정리하는 log, TIL 커밋의 시간(이라 쓰고 잔디심기라 읽는다)도 어물쩍 넘어가기 일쑤였다. 하루의 마무으리를 잘합시다..

  3. ideaVim을 깔아버렸다. 게임 대신 괴랄한 에디터 써보기(!?)