GolDeeper

NgModules

기본적으로 아래 두 개념을 알아두셔야 합니다.

• Bootstrapping.
• JavaScript Modules vs. NgModules.

NgModules 은 주입기(injector)와 컴파일러로 구성며, 관련있는 것들을 조직화 하는것을 돕습니다.

NgModule은 @NgModule 데코레이터로 마킹된 하나의 클래스 입니다. 

@NgModule은 런타임에 주입기를 어떻게 생성하고, 컴포넌트의 템플릿을 어떻게 컴파일 할지 기술하는  메타데이터 객체를 갖습니다. 

이것은 모듈이 소유한 컴포넌트, Directives(HTML의 속성으로 확장된 ng-app), pipes( {{value | pipe_function}} ), exports 속성을 통해서 일부를 public으로 만들어 , 외부 컴포넌트가 사용할 수 있도록 합니다.

물론 @NgModule를 사용하여 어플리케이션 의존성 주입기에 service provider로 추가할 수 있습니다.

예제로 pages cover에 관련된 NgModuels의 모든 기술들을 보여줍니다. live example / download example 를 참고하세요.

각 기술에 대한 설명은, 아래 있는 NgModules 섹션을 눌러 참고하세요.

Angular modularity (앵귤러 모듈화 링크)

모듈은 외부 라이브러리로부터의 확장과 어플리케이션 조직화하기에 훌륭한 방법입니다.

앵귤러 라이브러리는 NgModule이고,  FormsModule, HttpClientModule, 그리고 RouterModule 를 예로 들 수 있습니다.

많은 third-party 라리브러리는 NgModule로써 사용가능합니다 예를 들어  Material Design, Ionic, 와 AngularFire2가 있습니다.

NgModule은 컴포넌트, directive, 그리고 재사용 가능한 기능 단위의 pipe, 비지니스 도메인 어플리케이션, *workflow 또는 유틸의 common collection을 하나로 병합해 놓았습니다.

*workflow
workflow는 extensibleService를 확장합니다. 

말인 즉슨 모든 workflow는 extensibleService로부터 제공하는 method와 속성을 상속합니다.

확장은 자기만의 step을 추가하거나, 존재하는 step을 제거하거나, custom 데이터를 조작하는 로직을 주입할 수 있도록 허용합니다.

또한 모듈은 어플리케이션에 service를 추가할 수 있습니다. 

내부적으로 개발자가 스스로 개발 한 것이나 외부의 소스로써 Angular router 나 HTTP client같은것도 추가할 수 있습니다.

모듈은 어플리케이션이 시작될 때  router(라우터)에 의해 eagerly로 로딩되거나 비동기(asynchronously)한 lazy 로딩을 합니다. 

NgModule 메타데이터는 다음과 같습니다 :

• 모듈에 포함된 컴포넌트, directiv, pipe를 선언합니다.
• 다른 모듈의 컴포넌트 템플릿이 사용할 수 있도록 컴포넌트, directive, pipe를 public으로 만듭니다.
• 컴포넌트, directive, pipe를 갖는 다른 모듈을 임포트합니다.
• 다른 어플리케이션 컴포넌트가 사용할 수 있도록 service를 제공합니다.

// imports
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';

import { AppComponent } from './app.component';
import { ItemDirective } from './item.directive';


// @NgModule decorator with its metadata
@NgModule({
  declarations: [
    AppComponent,
    ItemDirective
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

가장 위에 있는 임포트 문에서. 그 다음 섹션은 어디에 @Ngmodule가 어떤 컴포넌트와 directive가 속해져있는지 명세하고 이것(선언)으로 다른 모듈이 사용하기 쉽도록 합니다(imports). 이 페이지는  Bootstrapping은 NgModule의 구성을 포함하여 빌딩되었습니다. 만약 @NgModule의 구성에 대해 더 알고 싶다면,  Bootstrapping을 읽어보세요.

아이오닉은 src/index.html로 앱을 시작합니다.

<!-- 아이오닉의 루트 컴포넌트로 app을 불러온다. -->  
<ion-app></ion-app>

<!-- 빌딩 과정에서 polyfills js를 생성한다. -->
<!-- 브라우저 API를 보충하는 역할이다. -->
<!-- polyfills는 브라우저에서 지원하지 않는 API일 지라도 개발자가 사용할 수 있도록 도와준다. -->
<script src="build/polyfills.js"></script>

<!-- 빌딩 과정에서 vendoer.js를 생성한다. --> 
<!-- node_modules의 모든 의존성(dependencies)를 포함한다. --> 
<script src="build/vendor.js"></script>

<!-- 빌딩 과정에서 bundle js를 생성한다. --> 
<!-- 모들 파일을 1개의 묶음 파일로 만드는 과정 --> 
<script src="build/main.js"></script>

./src/

src 디렉토리에서 Ionic 앱을 구동하는 대부분의 코드를 작성합니다.

ionic serve

를 실행시키면, src/ 안에 있는 코드는 transpiled (언어를 다른 언어로 번역) 됩니다. 

아이오닉에서는 타입스크립트(TypeScript)를 작성하면, 브라우저가 이해할 수 있는  ES5로 transpile 합니다. 

src/app/app.module.ts 

앵귤러의 모듈의 구성과 해당 모듈의 링크를 나타냅니다.

@NgModule({
  declarations: [MyApp, HomePage, ListPage],
  imports: [BrowserModule, IonicModule.forRoot(MyApp)],
  bootstrap: [IonicApp],
  entryComponents: [MyApp, HomePage, ListPage],
  providers: [StatusBar, SplashScreen, {provide: ErrorHandler, useClass: IonicErrorHandler}]
})
export class AppModule {}

@NgModule 데코레이터로 나타내고, 각 구성 항목을 연결하게 됩니다.

runtime에 메타데이터 객체(컴포넌트 템플릿을 컴파일하는 방식과 주입기를 생성하는 방식을 작성하는 객체)를 사용합니다. 

*참고

아래 개념을 기본적으로 알고 있어야 합니다.

• Bootstrapping.
• JavaScript Modules vs. NgModules. - 이 블로그에서 번역한 NgModule

1. 구현하기

2. 리뷰하기 

2.1 육하원칙 : 학습한 내용. REST Api

2.3. 장단점

2.4. 고민한 내용

HTTP api

2.5. 참고 내용
스프링에서 REST 서비스 만들기 (spring io)

그런 REST API로 괜찮은가 (youtube 영상)

데뷰에서 day1에 진행했던 내용입니다.

위키피디아 (한글이 없네여 ㅠㅠ)

2.6. 보충할 점 (구현한 서비스에 대하여)

사용자 구분 없이 서비스를 제공하기 때문에,

여러 사용자가 사용하기엔 무리가 있음.

session을 이용해서 진행하는 방식으로 구분이 필요함.

3. 배경지식

REST는 HTTP를 기반으로 제약 조건과 속성을 정의한 아키텍쳐 스타일 입니다. 
인터넷에서 컴퓨터 시스템간의 통신(상호 운용성)을 제공합니다.
SOAP(Simple Object Access Protocol) 웹 서비스는 정의 되지 않은 임의의 연산을 노출해야 하지만,

REST를 준수한 웹 서비스는 미리 지정된 stateless 연산을 사용하므로 Web resource의 문자적 표현을 변화하거나 접근할 수 있습니다.

Web resources는 URL를 통하여 파일이나 document로  World Wide Web에서 정의하였습니다.

지금은 웹상에서 어떠한 방식으로든 식별가능하고, 이름을 붙이거나, 주소화되거나, 조작가능한 객체와 같이 일반적으로나 추상적으로 정의하는 모든것을 일컫습니다.

RESFful 웹 서비스에서는, XML, HTML, JSON과 같은 방식으로 resource의 URI가 client의 요청에 대한 응답이 될 수 있습니다.

응답은 저장된 resource의 변화가 이루어 졌는지 확인되어야 하며, recourse와 관련된 hypertext 링크를 제공해야 한다.

 HTTP에서는 주로 GET, POST, PUT, DELETE나 CRUD, HTTP methods처럼 이미 정의된 다른 연산을 사용한다.

stateless protocol과 standard operations를 사용함으로써, REST 시스템는 빠른 성능, 신뢰성, 그리고 진화를 목표로 하고있다.

진화는 관리 가능하고 사이드 이팩트 없는 컴포넌트를 재사용하여 운영중에도 진화가 가능하다.

2000년도에  Roy Fielding의 박사 논문을 통하여 representational state transfer가 소개되었다.

Fielding의 논문에서는 REST의 원칙을 "HTTP object model"로써 설명한 것으로 알려져 있다.

또한, HTTP1.1과 URI의 standard로 설계하는데 사용되었다.

아래와 같은 것이 설계된 웹 어플리케이션의 작동이라고 할 수 있다 :

Web resources(a virtual state-machine)의 네트워크 에서 '/uers/tom '과같은 링크를 클릭했을 때, GET이나 DELETE (state transitions: 상태 전이)가 진행되어

다음 상태의 resource가 결과로 나타나는 것을 나타낼 수 있다.