블로그 이미지
Peter Note
Web & LLM FullStacker, Application Architecter, KnowHow Dispenser and Bike Rider

Publication

Category

Recent Post

2021. 8. 5. 09:28 Angular/Concept

Nx.dev 기반개발에서 Angular 모듈을 Router기반으로 Lazy Loading하기와 Router를 사용하지 않고 Lazy Loading하는 방법에 대해 알아보자. 알단 Lazy Loading 설정을 하게되면 Angular 컴파일시에 자동으로 모듈단위 Code Splitting하여 번들링한다. 따라서 필요한 시점에 필요한 파일만 다운로드를 받기때문에  TTI(Time ot interactive)시간 즉, 애플리케이션 응답성능을 높일 수 있다. 참고로 Webpack 5 (핸재 beta) 에서 Federation Module 개념을 구현하였는데, Angular에서 이와 비슷한 기능을 Angular Module단위 개발로 제공한다.

 

NX 환경 설정

  • NodeJS v12.* 사용
  • @angular/cli와 @nwrl/ci 설치
  • create-nx-workspace 이용하여 nx 기반 환경 생성
  • yarn통한 node modules 설치
// NVM 설치 (https://github.com/nvm-sh/nvm)
$ nvm install 12.16.2
$ nvm alias default 12.16.2
$ nvm use 12.16.2

// 최신버전들 설치
$ npm i -g @angular/cli@latest
$ npm i -g @nrwl/cli@latest
$ npm i -g yarn@latest
$ npm install typescript@3.8.3 --save-dev --save-exact

// create-nx-workspace
$ npx create-nx-workspace@latest
  ? Worspace name   demo
  ...
$ cd demo
$ yarn install

 

 

Router 를 통한 Lazy Loading

  • nx 명령을 통해 Lazy loading할 library를 생성한다.
  • nx 명령을 통해 Lazy loading되어 보여질 component를 생성한다.
  • libs/lazyview/src/lib/lazyview.module.ts 에 RouterModule.forChild 설정
  • lazyview모듈을 로딩하는 "app-container" 애플리케이션의 tsconfig.app.json에 "include" path 설정
  • apps/app-container/src/app/app-routing.module.ts 안에 loadChildren 을 통해 lazyview 모듈을 import 한다.

libs/lazyview 밑에 라이브러리 생성

// 1) libs/lazyview 라이브러리 생성 - 라이브러리는 모듈단위
$ nx g lib --routing --lazy lazyview


// 2) 컴포넌트 생성
$ nx g c lazypage --project=lazyview


// 3) libs/lazyview/src/lib/lazyview.module.ts에 forChild 설정
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { RouterModule } from '@angular/router';
import { LazypageComponent } from './lazypage/lazypage.component';
@NgModule({
    imports: [
        CommonModule,

        RouterModule.forChild([
            { path: '', pathMatch: 'full', component: LazypageComponent }
        ]),
    ],
    declarations: [LazypageComponent],
})
export class LazyviewModule {}


// 4) apps/app-container/src/tsconfig.app.json 에 include/exclude 설정
{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "outDir": "../../dist/out-tsc",
        "types": []
    },
    "include": ["**/*.ts", "../../libs/lazyview/src/index.ts"],
    "exclude": ["src/test-setup.ts", "**/*.spec.ts", "src/environments/*.ts"]
}


// 5) app-routing.module.ts 에 loadChildren으로 '@micro-demo/lazyview' 설정
import { NgModule } from '@angular/core';
import { Routes, RouterModule } from '@angular/router';
const routes: Routes = [
    { path: '', pathMatch: 'full', redirectTo: '/welcome' },
    { path: 'lazyview', loadChildren: () => import('@micro-demo/lazyview').then((m) => m.LazyviewModule) },
    { path: 'welcome', loadChildren: () => import('./pages/welcome/welcome.module').then((m) => m.WelcomeModule) },
];
@NgModule({
    imports: [RouterModule.forRoot(routes)],
    exports: [RouterModule],
})
export class AppRoutingModule {}

"nx serve"  수행한 후 "http://localhost:4200/lazyview" 로 호출한다.

micro-demo-lazyview.js 파일을 code splitt되어 호출시 다운로드된다.

소스: https://github.com/ysyun/blog-5730-micro-demo

 

ysyun/blog-5730-micro-demo

https://mobicon.tistory.com/573 블로그 소스. Contribute to ysyun/blog-5730-micro-demo development by creating an account on GitHub.

github.com

 

 

 

참조

https://juristr.com/blog/2019/04/state-lazy-loading-components-angular/#manual-lazy-loading-of-modules

 

Lazy load Angular Components

Or better..how to lazy load Angular Modules. Learn about the state of lazy loading and lazy loading on steroids with Angular Elements

juristr.com

https://juristr.com/blog/2019/10/lazyload-module-ivy-viewengine/

 

Manually Lazy Load an Angular Module with ViewEngine and Ivy

Find out how to lazy load an NgModule compatible with ViewEngine and Ivy

juristr.com

https://juristr.com/blog/2019/08/ngperf-route-level-code-splitting/

 

Angular Performance: Route Level Code Splitting

Learn about route-level code splitting and lazy loading with Angular

juristr.com

https://medium.com/angular-in-depth/lazy-load-components-in-angular-596357ab05d8

 

Lazy load components in Angular

Lazy load Angular components with Ivy and Angular 9

medium.com

https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/

 

Webpack 5 Federation. A Game-changer to Javascript architecture.

Module federation — The Javascript equivalent of what Apollo did with GraphQL. Multiple Webpack builds work together, sharing the dependency graph at runtime. Multiple bundles working as an SPA

indepth.dev

 

posted by Peter Note
2021. 8. 5. 09:28 Angular/Concept

Angular router의 loadChildren 을 사용하지 않고 Lazy loading하는 방법을 알아본다. 

 

Angular Module 에 대한 Lazy Loading

Angular의 Lazy Loading 방식

  • NgModule 단위로 lazy loading한다.
  • Angular v8부터 import(<module path>).then(mod => mod.<moduleName>) 방식으로 로딩한다. import 구문을 사용하면 자동으로 code splitting이 된다.
  • Angular v7버전 이하는 ViewEngine 이라는 Template엔진을 사용했고, 8부터 선택적으로 9부터는 디폴트로 Ivy를 Template엔진으로 사용한다.
  • Module을 컴파일/로딩하고 Component를 인스턴스화하기위해 ComponentFactoryResolver를 사용하고, ViewContainer에 인스턴스화된 컴포넌트를 렌더링한다.

우선 manual lazy loading을 위한 모듈과 컴포넌트를 생성한다. 

// 라이브러리 생성, nx 또는 ng 둘 다 사용가능하다
$ nx g lib manuallazy

// 컴포넌트 생성
$ nx g c manual --project=manuallazy
CREATE libs/manuallazy/src/lib/manual/manual.component.scss (0 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.html (21 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.spec.ts (628 bytes)
CREATE libs/manuallazy/src/lib/manual/manual.component.ts (283 bytes)
UPDATE libs/manuallazy/src/lib/manuallazy.module.ts (266 bytes)

lazyload하는 service를 "app-container" 애플리케이션에 생성한다.

$ nx g s lazy-loader --project=app-container
CREATE apps/app-container/src/app/lazy-loader.service.spec.ts (378 bytes)
CREATE apps/app-container/src/app/lazy-loader.service.ts (139 bytes)

서비스에 loadModule 메소드를 추가한다. 8전부터 Ivy 사용만 대응한다. 7버전 이하는 NgModuleFactoryLoader를 사용한다. (참조)

import { Compiler, Injectable, Injector, NgModuleFactory, Type } from '@angular/core';

@Injectable({
    providedIn: 'root',
})
export class LazyLoaderService {
    constructor(private compiler: Compiler, private injector: Injector) {}

    loadModule(path: any) {
        (path() as Promise<Type<any>>)
            .then((elementModule) => {
                    try {
                        return this.compiler.compileModuleAsync(elementModule);
                    } catch (err) {
                        throw err;
                    }
            })
            .then((moduleFactory) => {
                try {
                    const elementModuleRef = moduleFactory.create(this.injector);
                    const moduleInstance = elementModuleRef.instance;

                    // instantiate component dynamically.
                } catch (err) {
                    throw err;
                }
            });
    }
}

 

 

컴포넌트 인스턴스화 및 ViewContainer에 렌더링하기

다음 순서로 컴포넌트를 인스턴스화 한다. 

  • ManuallazyComponent를 manuallazy 라이브러리에 생성한다.
  • MauallazyModule에 초기 인스턴스화할 Component를 리턴한다.
  • LazyLoaderService에서 ComponentFactoryResolver를 통해 인스턴스화하고 ViewContainer에 할당한다. 
  • "app-container" 애플리케이션의 tsconfig.app.json에 "include"에 MauallazyModule의 index.ts를 추가 설정한다. 
  • "app-container" 애플리케이션에서 LazyLoaderService를 loadModule을 호출한다. 

ManulComponent를 생성한다. 

$ ng g c manual --project=manuallazy

// libs/manuallazy/lib/src/manual/manual.component.html
<p>manual lazy component</p>

 

ManuallazyModule에 ComponentType을 리턴한다.

// libs/manuallazy/src/lib/manuallazy.module.ts

import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { ManualComponent } from './manual/manual.component';

@NgModule({
    imports: [CommonModule],
    declarations: [ManualComponent],
})
export class ManuallazyModule {
    bootstrapComponent(): any {
        return ManualComponent;
    }
}

 

LazyLoaderService에 컴포넌트를 로딩하는 "addComponent" 메소드을 추가한다. 

// apps/app-container/src/app/lazy-loader.service.ts
import {
    Compiler,
    Injectable,
    Injector,
    NgModuleFactory,
    Type,
    ViewContainerRef,
    ComponentRef,
    ComponentFactory,
    ComponentFactoryResolver,
} from '@angular/core';

@Injectable({
    providedIn: 'root',
})
export class LazyLoaderService {
    constructor(private compiler: Compiler, private injector: Injector, private resolver: ComponentFactoryResolver) {}

    loadModule(path: any, viewContainer: ViewContainerRef): void {
        (path() as Promise<Type<any>>)
            .then((elementModule) => {
                try {
                    return this.compiler.compileModuleAsync(elementModule);
                } catch (err) {
                    throw err;
                }
            })
            .then((moduleFactory) => {
                try {
                    const elementModuleRef = moduleFactory.create(this.injector);
                    const moduleInstance = elementModuleRef.instance;

                    // instantiate component dynamically.
                    this.addComponent(moduleInstance.bootstrapComponent(), viewContainer);
                } catch (err) {
                    throw err;
                }
            });
    }

    addComponent(cmpType: any, viewContainer: ViewContainerRef): ComponentRef<any> {
        const factory: ComponentFactory<any> = this.resolver.resolveComponentFactory(cmpType);
        let cmp: ComponentRef<any>;
        if (viewContainer) {
            viewContainer.clear();
            cmp = viewContainer.createComponent(factory);
        }
        return cmp;
    }
}

 

"app-container" 애플리케이션의 tsconfig.app.json 에 MauallazyModule의 index.ts 를 추가 설정한다.

// apps/app-container/src/tsconfig.app.json 
{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "outDir": "../../dist/out-tsc",
        "types": []
    },
    "include": ["**/*.ts", "../../libs/lazyview/src/index.ts", "../../libs/manuallazy/src/index.ts"],
    "exclude": ["src/test-setup.ts", "**/*.spec.ts", "src/environments/*.ts"]
}

 

"app-container" 애플리케이션에서 ManullazyModule을 호출한다. 

// apps/app-container/src/app/app.component.html 일부분
<li nz-menu-item nzMatchRouter>
  <a (click)="manualLazyLoading($event)">Monitor</a>
</li>
... 중략 ...
<div class="inner-content">
   <router-outlet></router-outlet>
   <div style="padding-top: 100px;" #InnerContent></div>
</div>


// apps/app-container/src/app/app.component.ts
import { LazyLoaderService } from './lazy-loader.service';
import { Component, ViewChild, ViewContainerRef } from '@angular/core';

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss'],
})
export class AppComponent {
    isCollapsed = false;
    @ViewChild('InnerContent', { read: ViewContainerRef }) innerContent: ViewContainerRef;

    constructor(private readonly lazyLoaderServie: LazyLoaderService) {}

    manualLazyLoading(event: MouseEvent): void {
        // import 할 때 위치투명하게 nx library를 호출한다.
        const manualLoad = () => import('@micro-demo/manuallazy').then((m) => m.ManuallazyModule);
        this.lazyLoaderServie.loadModule(manualLoad, this.innerContent);
    }
}

"Monitor" 메뉴를 클릭하면 "micro-demo-mauallazy.js"파일이 다운로드되고 ViewContainer위치에 컴퍼넌트를 렌더링한다

구현 소스: https://github.com/ysyun/blog-5730-micro-demo

 

ysyun/blog-5730-micro-demo

https://mobicon.tistory.com/573 블로그 소스. Contribute to ysyun/blog-5730-micro-demo development by creating an account on GitHub.

github.com

 

라우팅으로 통한 Angular 모듈 Lazy loading과 메뉴얼 Lazy loading 방식의 단점

  • 둘다 tsconfig.app.json과 같은 사전 설정작업이 필요하다.
  • "app-container"라는 Lazy loading된 모듈을 사용하는 애플리케이션과 함께 컴파일이 되어야 한다.

장점은 import구문을 통해 자동 Code Splitting 기능이다. 위이 단점을 해결하기 위해서 Web Components를 지원하는 @angular/elements를 사용한다. 이에 대한 글은 다음을 참조한다. 

https://mobicon.tistory.com/573

 

[Micro Frontend] Web Components 기반 마이크로 프론앤드

Angular v6부터 Web Components에 대한 지원으로 @angular/elements 기능이 추가되어 Custom HTML Tag을 만들 수 있도록 지원한다. 본 글은 해당 사이트의 글을 Nx.dev 환경과 통합하여 개발하는 과정을 설명한다...

mobicon.tistory.com

 

참조

https://juristr.com/blog/2019/10/lazyload-module-ivy-viewengine/

 

Manually Lazy Load an Angular Module with ViewEngine and Ivy

Find out how to lazy load an NgModule compatible with ViewEngine and Ivy

juristr.com

https://juristr.com/blog/2017/07/ng2-dynamic-tab-component/

 

Create a dynamic tab component with Angular

Learn about advanced topics such as dynamic components, ComponentFactoryResolver, ViewContainerRef, ngTemplateOutlet and much more...

juristr.com

https://juristr.com/blog/2019/04/state-lazy-loading-components-angular/#manual-lazy-loading-of-modules

 

Lazy load Angular Components

Or better..how to lazy load Angular Modules. Learn about the state of lazy loading and lazy loading on steroids with Angular Elements

juristr.com

 

posted by Peter Note
2020. 5. 22. 17:15 Angular/Concept

Angular에서 schematic은 복잡한 로직을 지원하는 템플릿 기반의 코드 생성기이다. @angular/cli에서 코드 생성은 schematics를 사용하는 것이다. 해당 패키지는 @schematics/angular 이다. 본글에서는 나만의 schematic을 만들어 본다. 하기 문서를 참조하여 NX 기반으로 개발한다.

 

https://medium.com/@tomastrajan/total-guide-to-custom-angular-schematics-5c50cf90cdb4

 

Total Guide To Custom Angular Schematics

Schematics are great! They enable us to achieve more in shorter amount of time! But most importantly, we can think less about mundane…

medium.com

 

Schematic 생성

 NX환경이 아니라면 @angular-devkit/schematics-cli 를 글로벌로 설치해서 schematics 명령을 사용해 초기 schematic파일을 자동 생성할 수 있다. 그러나 NX를 사용하면 @angular-devkit/schematics-cli설치 없이 nx명령으로 초기 파일을 생성할 수 있다. NX의 schematics을 사용하겠다는 정의는 루트의 angular.json에 정의되어 있다. 

    ...
    "schematics": {
        "@nrwl/angular:application": {
            "unitTestRunner": "jest",
            "e2eTestRunner": "cypress"
        },
        "@nrwl/angular:library": {
            "unitTestRunner": "jest"
        }
    },
    ...

 

명령어 예

//schematic-cli 설치
$ npm install -g @angular-devkit/schematics-cli

//schematics 명령 사용 경우
$ schematics blank hello


//NX 환경일 경우
$ nx g workspace-schematic hello
CREATE tools/schematics/hello/index.ts (250 bytes)
CREATE tools/schematics/hello/schema.json (348 bytes)

nx 명령을 생성된 schematic 파일은 tools/hello 폴더 밑에 존재한다. schema.json은 hello schematic의 정의 파일이고, index.ts가 동작하는 시작 파일이다. 

 

 

Schematic 키워드

  • Tree: virtual file system을 표현한다. base 라는 이미 존재하는 파일 묶음과 staging area 라는 base에서 변경될 것들 목록으로 구성된다. base 는 변경할 수 없고, staging area 만 변경가능 하다.
  • Rule: Tree를 받아서 변경점을 적용하고 새로운 Tree를 반환하는 함수이다. 메인 파일인 index.ts에 해당 함수를 정의한다.
  • Action: Action을 변환(Transformation)으로 표현되고, action 타입은 Create, Rename, Overwrite, Delete 4가지 유형이 있다.
  • 참조 원문

실제 사용자 정의 작업을 해야하는 Rule의 정의이다. 

export declare type Rule = (tree: Tree, context: SchematicContext) => Tree | Observable<Tree> | Rule | Promise<void> | Promise<Rule> | void;

 

모든 Schematic은 context안에서 구동되어야 하고, SchematicContext 객체로 표현된다. nx가 아닌 schematics 명령으로 생성된 index.ts 의 코드를 보자.

  • hello함수는 RuleFactory로써 Rule을 반환하는 고차함수(a higher-order function)를 반환한다.
  • hello함수안에서 나의 template이 어떻게 합쳐지고, 변경되어 지는 것인지 정의한다.
//schematic 명령으로 생성된 index.ts 내역

import { Rule, SchematicContext, Tree } from '@angular-devkit/schematics';

// You don't have to export the function as default. You can also have more than one rule factory
// per file.
export function hello(_options: any): Rule {
  return (tree: Tree, _context: SchematicContext) => {
    return tree;
  };
}

nx로 생성된 schematic 의 index.ts는 약간 틀린 구조이다. 

  • default함수로 RuleFactory를 정의한다.
  • Rule을 반환한다. 
import { chain, externalSchematic, Rule } from '@angular-devkit/schematics';

export default function (schema: any): Rule {
    return chain([
        externalSchematic('@nrwl/workspace', 'lib', {
            name: schema.name,
        }),
    ]);
}

 

 

Schematic 옵션 설정

  • nx로 생성했을 경우: schema.json 파일에 옵션을 설정한다.
  • schema.json의 properties 는 Schematic 수행시 prompt 로 작동하여 사용자 입력값을 처리한다. 
  • properties안에 사용자로 부터 입력받고자하는 옵션을 설정한다. 입력받을 수 있는 옵션은 schema.json에 정의되어 있다.
  • schema.json 전체 명세서

 

//nx 명령으로 생성된 schema.json 내역
{
    "$schema": "http://json-schema.org/schema",
    "id": "hello",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Library name",
            "$default": {
                "$source": "argv",
                "index": 0
            }
        }
    },
    "required": ["name"]
}

 

 

옵션의 Input "type"  

  • confirmation: boolean 옵션
  • input: text 또는 number 옵션
  • list: 미리 정의한 목록을 선택

schema.json에 정의하는 type

"style"을 정의한 예

//schema.json 예
"style": {
  "description": "The file extension or preprocessor to use for style files.",
  "type": "string",
  "default": "css",
  "enum": [
    "css",
    "scss",
    "sass",
    "less",
    "styl"
  ],
  "x-prompt": {
    "message": "Which stylesheet format would you like to use?",
    "type": "list",
    "items": [
      { "value": "css",  "label": "CSS" },
      { "value": "scss", "label": "SCSS   [ https://sass-lang.com/documentation/syntax#scss                ]" },
      { "value": "sass", "label": "Sass   [ https://sass-lang.com/documentation/syntax#the-indented-syntax ]" },
      { "value": "less", "label": "Less   [ http://lesscss.org                                             ]" },
      { "value": "styl", "label": "Stylus [ http://stylus-lang.com                                         ]" }
    ]
  },
},

x-prompt 필드를 통해 긴 입력 문구 조합이 가능하다. 

//x-prompt schema
{
    "oneOf": [
        { "type": "string" },
        {
            "type": "object",
            "properties": {
                "type": { "type": "string" },
                "message": { "type": "string" },
                "items": {
                    "type": "array",
                    "items": {
                        "oneOf": [
                            { "type": "string" },
                            {
                                "type": "object",
                                "properties": {
                                    "label": { "type": "string" },
                                    "value": { }
                                },
                                "required": [ "value" ]
                            }
                        ]
                    }
                }
            },
            "required": [ "message" ]
        }
    ]
}

 

 

Schematic 실행

Schematics CLI로 생성했을 경우

  • index.ts를 컴파일한다. 
  • 명령어: schematics <path-to-schematics-project>:<schematics-name> --<required-option>=<value>
//schematics 으로 생성한 폴더로 이동후 컴파일 수행
$ cd hello
$ npm run build

//schematics 수행
$ schematics .:hello
Nothing to be done.

nx 명령으로 생성했을 경우

  • 명령어: npm run workspace-schematic <customized schematic name> <option>
$ npm run workspace-schematic hello hi

> micro-demo@0.0.0 workspace-schematic /Users/dowonyun/mobicon/projects/bistel/src/2019/micro-demo
> nx workspace-schematic "hello" "hi"

>  NX  Executing your local schematic: hello

CREATE libs/hi/tslint.json (91 bytes)
CREATE libs/hi/README.md (158 bytes)
CREATE libs/hi/tsconfig.json (135 bytes)
CREATE libs/hi/tsconfig.lib.json (190 bytes)
CREATE libs/hi/src/index.ts (26 bytes)
CREATE libs/hi/src/lib/hi.ts (0 bytes)
CREATE libs/hi/jest.config.js (246 bytes)
CREATE libs/hi/tsconfig.spec.json (269 bytes)
UPDATE tsconfig.json (731 bytes)
UPDATE angular.json (16683 bytes)

 

 

참조

Angular Schematic 개념: https://angular.io/guide/schematics

 

Angular

 

angular.io

스키마 명세: https://github.com/angular/angular-cli/blob/7.0.x/packages/schematics/angular/application/schema.json

 

angular/angular-cli

CLI tool for Angular. Contribute to angular/angular-cli development by creating an account on GitHub.

github.com

 

posted by Peter Note
2019. 4. 10. 16:35 Angular/Architecture

두번째 Multi Application에 대한 Plugin 방식을 구성 테스트해 보자.

 

 

Library기반 Plugin 파일 만들기

플랫폼에 있는 플러그인이 아니라 플랫폼과 별개의 서비스에서 운영되는 플로그인을 플랫폼상에 렌더링하기 위해서는 UMD(Universal Module Definition) 방식으로 플러그인이 번들링 되어야 한다. UMD에 대해서는 본 블로그의 글을 참조한다.

$ ng g library plugin2 --publishable

 

plugin2 로 별도 번들링이 가능한 라이브러리 파일을 생성한다. 최종 npm scope를 jm으로 주었기 때문에 npm으로 설치했을 때 node_modules최종 명칭은 @jm/plugin2가 된다. libs/plugins/package.json의 설정 참조. build가 되는지 실행해 본다.

$ ng build plugin2

dist/libs/plugin2에 npm repository로 publish할 수 있는 형태의 다양한 포멧으로 번들링이 되었다. 해당 번들링은 ng-packagr를 기본으로 한 Angular Package Format에 따른다.

plugin2 라이브러리에 plugin2라는 이름의 컴포넌트를 생성하고 여기에 ngx-echart를 사용하는 샘플을 넣어보자.

// 컴포넌트 생성
$ ng g component plugin2 --project=plugin2

// echart 관련 라이브러리 및 echart angular wrapper 설치
$ npm i -S echarts ngx-echarts
$ npm i -D @types/echarts

plugin2/plugin2.component.html과 .ts에 ngx-echart의 예제 내용을 첨부한다. Plugin2Module에 bootstrap에 Plugin2Component를 설정한다.

// plugin2.component.html
<div echarts [options]="options" class="demo-chart"></div>

// plugin2.component.ts 
options 내용 설정: https://xieziyu.github.io/ngx-echarts/#/usage/basic 참조

// plugin2.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { NgxEchartsModule } from 'ngx-echarts';

import { Plugin2Component } from './plugin2/plugin2.component';

@NgModule({
  declarations: [Plugin2Component],
  imports: [
    CommonModule,
    NgxEchartsModule
  ],
  exports: [
    Plugin2Component
  ],
  bootstrap: [
    Plugin2Component
  ]
})
export class Plugin2Module {}

plugin2 컴포넌트를 사용하는 별도 애플리케이션을 생성해 보자.

 

 

별도 애플리케이션 생성하여 Plugin2 테스트 하기

Multi Application을 가정하여 Plugin2를 사용하는 App2 애플리케이션을 생성하여 Plugin2가 잘 나오는지 테스트 한다.

$ ng g application app2

app2 가 실행할 때 4300 port 를 사용토록 angular.json에 포트설정을 추가한다.

"serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "app2:build",
            "port": 4300
          },
 ... 중략 ...

 $ ng s app2 

apps/app2/src/app/app.module.ts 와 app.component.html을 수정한다. import 할 때"@jm/plugin2"로 사용함을 주의한다.

// app.component.html
<jm-plugin2></jm-plugin2>

// app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { Plugin2Module } from '@jm/plugin2';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    Plugin2Module
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

"ng s app2" 실행하고 http://localhost:4300 으로 호출하면 샘플 echart가 보인다.

 

 

Plugin2 번들링 하기

app2 애플케이션에 plugin2 컴포넌트가 잘 나오는 것을 확인 하였다. plugin2 번들링을 위해 한가지 설정 옵션을 변경하여 다시 번들링한다. build시에 에러가 발생하면 ng-packagr v5.0.1 이상을 설치한다.

//libs/plugin2/src/tsconfig.lib.json 에서 skipTemplateCodegen을 false로 변경한다
  "angularCompilerOptions": {
    "annotateForClosureCompiler": true,
    "skipTemplateCodegen": false,

// ng-packagr 관련 업데이트 
$ npm update ng-packagr
$ npm i -D tsickle

//다시 번들링한다. 
$ ng build plugin2
Building Angular Package
Building entry point '@jm/plugin2'
Compiling TypeScript sources through ngc
Bundling to FESM2015
Bundling to FESM5
Bundling to UMD
No name was provided for external module 'ngx-echarts' in output.globals – guessing 'ngxEcharts'
Minifying UMD bundle
Copying declaration files
Writing package metadata
Removing scripts section in package.json as it's considered a potential security vulnerability.
Built @jm/plugin2
Built Angular Package!
 - from: /Users/dowonyun/prototyping/jamong/libs/plugin2

skipTemplateCodegen를 false로 하면 ngfactory파일까지 생성되고 해당 파일은 Angular메타정보를 해석해 놓은 파일로 동적으로 파일을 로딩할 때 사용할 것이다. 다음으로 bundle 된파일을 다시 하나의 파일로 합치기 위해 package.json에 script를 등록한다.

// package.json
"scripts": {
   ... 중략 ...
   "build:plugin2": "rollup dist/libs/plugin2/esm2015/lib/plugin2.module.ngfactory.js --file dist/apps/api/plugin2.js --format umd --name plugin2"
}

// bundling 
$ npm run build:plugin2

dist/apps/api/plugin2.js 파일이 생성된다. 또는 ROOT에 rollup.config.js 파일을 생성하여 관리할 수도 있다.

//rollup.config.js
export default [
  {
    input: 'dist/libs/plugin2/esm2015/lib/plugin2.module.ngfactory.js',
    output: [
      {
        name: 'plugin2',
        file: 'dist/apps/api/plugin2.js',
        format: 'umd'
      }
    ]
  }
];

//build 명령
$ rollup -c

두가지의 명령을 수행한다.

  • ng build plugin2
  • npm run build:plugin2  또는 rollup.config.js를 설정하였다면 rollup -c

 

Plugin2 파일 API 서비스 추가

plugin2 파일을 동적으로 로딩하기 위해 다음과 같이 역할을 추가한다.

  • Dev Server는 Platform 서버 역할
  • API Server는 별개 애플리케이션 서버로 보고 Plugin-2 파일을 서비스하는 역할

이제 API Server에서 plugin2.js 파일을 읽어서 파일 내용을 전달하는 API를 추가한다. NetsJS는 NodeJS위에 구동되는 서버프레임워크로 Angular와 유사한 Syntax를 통해 MVC 패턴으로 개발한다.

  • GET으로 plugin2를 호출하면 파일을 읽는다.
  • 파일 내용을 return하면 끝!
// apps/api/src/app/app.controller.ts

import { Controller, Get } from "@nestjs/common";

import { Message } from "@jm/api-interface";
import { AppService } from "./app.service";

const path = require('path');
const fs = require('fs-extra');

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get("hello")
  getData(): Message {
    return this.appService.getData();
  }

  @Get("plugin2")
  getPlugin2() {
    const fileName = path.join(process.cwd(), 'dist/apps/api/plugin2.js');
    const plugin2 = fs.readFileSync(fileName, 'utf8');
    return plugin2;
  }
}

테스트를 해보자. API Server기본 context는 api로 http://localhost:3333/api/plugin2 로 호출한다. 번들링 파일 내용이 응답됨을 확인했다.

// API Server 기동
$ ng s api

 

 

원격 Plugin2을 Lazy Loading 하기

plugin2.js 파일을 다운로드 받아 로딩하기 위해 apps/jamong/src/app/app.component.html과 .ts에 로딩 구문을 추가한다.

// app.component.html
<button (click)="loadPlugin()">Load plugin</button>
<lazy-af *ngIf="plugin1Path" [moduleName]="plugin1Path"></lazy-af>

<p></p>

<button (click)="loadPlugin2()">Load plugin2</button>
<ng-template #Plugin></ng-template>

app.component.ts

  • plugin2.js 파일을 요청하기 위해 HttpClient를 사용
  • Plugin2ModuleNgFactory안의 Angular MetaData를 통해 관련 컴포넌트들 JIT 컴파일 수행
  • @herodevs/dynamic-af 패키지이 DynamicAFService 서비스를 injector받는다.
  • 이때 plugin2.js 소스내의 require하는 모듈을 위해 import * as from ''; 하여 아래 소스처럼 설정한다.
import { Component, ViewChild, ViewContainerRef, NgModuleFactory, Injector } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
import { DynamicAFService } from '@herodevs/dynamic-af';

import * as common from '@angular/common';
import * as commonHttp from '@angular/common/http';
import * as core from '@angular/core';
import * as router from '@angular/router';
import * as rxjs from 'rxjs';
import * as rxjsOperators from 'rxjs/operators';
import * as ngxEcharts from 'ngx-echarts';

@Component({
  selector: 'jm-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {

  @ViewChild('Plugin', {read: ViewContainerRef}) pluginVcr: ViewContainerRef;
  plugin1Path: string;
  loadedPlugins: any = {};

  constructor(
    private http: HttpClient,
    private injector: Injector,
    private lazyService: DynamicAFService
  ) { }

  loadPlugin() {
    this.plugin1Path = 'apps/jamong/src/app/plugin1/plugin1.module#Plugin1Module';
  }

  loadPlugin2() {
    const moduleFactory = this.loadedPlugins['api/plugin2'];
    if (!moduleFactory) {
      this.loadRemoteComponent();
    } else {
      this.lazyService.createAndAttachModuleAsync(moduleFactory, this.injector, { vcr: this.pluginVcr });
    }
  }

  private loadRemoteComponent() {
    let moduleFactory: NgModuleFactory<any>;
    this.http.get('api/plugin2', { responseType: 'text' })
      .pipe(
        catchError(this.handleError)
      ).subscribe((compiledSource: any) => {
        const exports = {};
        const modules = {
          '@angular/core': core,
          '@angular/common': common,
          '@angular/common/http': commonHttp,
          '@angular/router': router,
          'rxjs': rxjs,
          'rxjs/operators': rxjsOperators,
          'ngx-echarts': ngxEcharts
        };
        const require: any = (module) => modules[module];
        // tslint:disable-next-line: no-eval
        eval(compiledSource);
        moduleFactory = exports['Plugin2ModuleNgFactory'];
        this.loadedPlugins['api/plugin2'] = moduleFactory;
        this.lazyService.createAndAttachModuleAsync(moduleFactory, this.injector, { vcr: this.pluginVcr});
      });
  }

  private handleError(error: HttpErrorResponse) {
    if (error.error instanceof ErrorEvent) {
      // A client-side or network error occurred. Handle it accordingly.
      console.error('An error occurred:', error.error.message);
    } else {
      // The backend returned an unsuccessful response code.
      // The response body may contain clues as to what went wrong,
      console.error(`Backend returned code ${error.status}, body was: ${error.error}`);
    }
    return throwError(error);
  }
}

Load plugin2를 호출하였을 때 원격 처리 결과

위의 모든 소스는 GitHub에...

 

 

<참조>

- ngx-echarts

 

ngx-echarts demo

 

xieziyu.github.io

- Another Angular Plugin Example

 

iwnow/angular-plugin-example

Angular plugin with AOT and separate build. Contribute to iwnow/angular-plugin-example development by creating an account on GitHub.

github.com

- Rollup Configuration

 

Bundling Your JavaScript Library with Rollup

A step-by-step tutorial on how to bundle your JavaScript library using Rollup. You’ll also learn how to publish those bundles to NPM.

bagja.net

 

posted by Peter Note
2019. 4. 8. 17:45 Angular/Architecture

플랫폼위에 필요에 따라 플러그인 파일을 동적으로 다운로드 받아 운영하는 방식에 대한 기술 검토를 한다. 하나는 Single Application이면서 필요시점에 파일을 다운로든 받는 방식과 두번째는 다른 애플리케이션의 파일을 다운로드 받아 처리하는 방식이다. 

 

첫번째는 Single Application Plugin 방식으로 하나의 애플리케이션이 서비스되면서 필요시점에 파일을 다운로드 받아서 사용하는 방법이다. 

  • platform, shared 파일을 최초에 다운도로드 받아 처리한다. 
  • 화면-1로 페이지가 전화될 때 plugin-1 파일을 다운로드 받아 처리한다.
  • 즉, 플랫폼과 플러그인 파일이 같은 서버에 존재하는 경우이다.

 

두번째는 Multi Application Plugin 방식으로 여러 애플케이션을 하나의 플랫폼에서 운영하는 방식이다. 

  • Remote Server-1/2/3은 각기 다른 애플리케이션이라 본다. 
  • Proxy Server는 플랫폼 서비스를 담당하고, Remote Server로의 요청을 중간에서 처리하는 Proxy 역할을 수행한다. 이때 Auth에 대한 권한을 처리할 수도 있다. 
  • 화면-1에 대한 요청을 Proxy Server에 하면 Url context 구분을 통해 Remote Server-1 서비스에 Plugin-1 파일을 요청 처리한다.
  • 즉, 플랫폼과 플러그인 파일이 존재하는 서버 위치가 서로 틀리다.

 

Single Application Plugin 방식 구성

@angular/cli와 @nrwl/schematics를 통해 애플케이션을 생성한다.  Node 버전은 LTS최신 버전을 사용하고 yarn도 설치한다.

$ node --version
v10.15.3
$ npm i -g yarn @angular/cli @nrwl/schematics @nestjs/cli
+ @angular/cli@7.3.8
+ @nrwl/schematics@7.8.0
+ @nestjs/cli@6.2.1

create-nx-workspace 명령으로 jamong이라는 플랫폼을 생성한다. SCSS 기반에 NestJS를 포함한 FullStack을 선택하자.  jamong 폴더 밑으로 apps/jamong Frontend 애플리케이션이 생성되었다. apps/api는 Backend 애플리케이션이다. ng s 명령을 수행하여 frontend, backend 서버를 각각 실행한다. frontend는 apps/jamong/proxy.conf.json 파일안에 proxy 경로로 /api가 설정되어 있다.

$ create-nx-workspace jamong --npm-scope=jm
$ cd jamong
$ ng s jamong (또는 ng serve jamong)
$ ng s api (또는 ng s api)

http://localhost:4200 을 호출한다. Dev Server와 API Server연결은 다음과 같다. 

 

plugin1 컴포넌트와 모듈을 생성한다. module을 생성하고 component를 생성하면 plugin1.module.ts의 declarations안에 자동으로 Plugin1Component가 설정된다. module 파일에 bootstrap 설정을 한다.

$ ng g module plugin1 --project=jamong
CREATE apps/jamong/src/app/plugin1/plugin1.module.ts (191 bytes)
$ ng g component plugin1 --project=jamong
CREATE apps/jamong/src/app/plugin1/plugin1.component.scss (0 bytes)
CREATE apps/jamong/src/app/plugin1/plugin1.component.html (26 bytes)
CREATE apps/jamong/src/app/plugin1/plugin1.component.spec.ts (635 bytes)
CREATE apps/jamong/src/app/plugin1/plugin1.component.ts (273 bytes)
UPDATE apps/jamong/src/app/app.module.ts (454 bytes)

// plugin1.module.ts
@NgModule({
  declarations: [Plugin1Component],
  imports: [
    CommonModule
  ],
  bootstrap: [Plugin1Component]
})
export class Plugin1Module { }

plugin module의 파일을 별도 파일로 번들링하기 위해 angular.json에서 "projects"/"jamong"/"architect"/"build"/"options" 안에 "lazyModules"설정을 한다.

  "projects": {
    "jamong": {
      "root": "apps/jamong/",
      "sourceRoot": "apps/jamong/src",
      "projectType": "application",
      "prefix": "jm",
      "schematics": {
        "@nrwl/schematics:component": {
          "style": "scss"
        }
      },
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist/apps/jamong",
            "index": "apps/jamong/src/index.html",
            "main": "apps/jamong/src/main.ts",
            "polyfills": "apps/jamong/src/polyfills.ts",
            "tsConfig": "apps/jamong/tsconfig.app.json",
            "assets": ["apps/jamong/src/favicon.ico", "apps/jamong/src/assets"],
            "styles": ["apps/jamong/src/styles.scss"],
            "scripts": [],
            "es5BrowserSupport": true,
            "lazyModules": [
              "apps/jamong/src/app/plugin1/plugin1.module"
            ]
          },
    ... 중략 ...

"ng s jamong" restart하면 plugin1 모듈 파일이 별도 생성됨을 알 수 있다. 물리적은 파일로 build 하고 싶다면 "ng build jamong"을 수행한다. 

$ ng build jamong

다음으로 app2-jamong-src-app-plugin1-plugin1-module.js 파일을 Dynamic Loading하는 Loader인 lazy-af를 설치한다. lazy-af의 자세한 소스는 github에서 확인한다. lazy-af는 lazy.module.ts에 NgModuleFactoryLoader로 SystemJSNgModuleLoader를 설정해 사용한다.

$ npm install @herodevs/lazy-af

// https://github.com/herodevs/herodevs-packages/blob/master/projects/lazy/src/lib/lazy.module.ts
@NgModule({
  imports: [],
  declarations: [LazyAFComponent],
  exports: [LazyAFComponent],
  providers: [{ provide: NgModuleFactoryLoader, useClass: SystemJsNgModuleLoader }],
})
export class LazyModule {}

lazy-af관련 모듈을 apps/jamong/src/app/app.module.ts에 import 한다.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';

import { LazyModule } from '@herodevs/lazy-af';

import { AppComponent } from './app.component';
import { HttpClientModule } from '@angular/common/http';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule, 
    HttpClientModule,
    LazyModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {}

apps/jamong/src/app/app.component.html 과 .ts 와 plugin1/plugin1.component.html 과 .ts을 수정한다. 

// app.component.html
<button (click)="loadPlugin()">Load plugin</button>
<lazy-af *ngIf="plugin1Path" [moduleName]="plugin1Path"></lazy-af>

// app.component.ts
@Component({
  selector: 'jm-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {

  plugin1Path: string;

  loadPlugin() {
    this.plugin1Path = 'apps/jamong/src/app/plugin1/plugin1.module#Plugin1Module';
  }
}

// plugin1/plugin1.component.html
<div style="padding-top: 20px">
  Plugin 1
</div>
<div>Message: {{ hello$ | async | json }}</div>

// plugin1/plugin1.component.ts
import { Component } from '@angular/core';
import { Message } from '@jm/api-interface';
import { HttpClient } from '@angular/common/http';

@Component({
  selector: 'jm-plugin1',
  templateUrl: './plugin1.component.html',
  styleUrls: ['./plugin1.component.scss']
})
export class Plugin1Component {
  hello$ = this.http.get<Message>('/api/hello');
  constructor(private http: HttpClient) { }
}

수정을 반영하고 실행을 한다. 

  1. Load plugin 버튼을 클릭한다.
  2. apps-jamong***.js 파일을 다운로드 한다. 
  3. Angular F/W 모듈을 해석한후 Plugin1Component를 렌더링한다.

지금까지의 소스 - github

다음 글에서 Multi Application의 Plugin 방식을 살펴보자.

 

<참조>

- nx development

 

Nx: Angular CLI power-ups for modern development

With Nx, you can develop multiple full-stack applications holistically and share code between them all in the same workspace. Add Cypress, Jest, Prettier, and Nest into your dev workflow.

nx.dev

- Angular Code Syntax와 유사한 Node 서비스 개발 프레임워크 NestJS

 

NestJS - A progressive Node.js web framework

NestJS is a framework for building efficient, scalable Node.js web applications. It uses modern JavaScript, is built with TypeScript and combines elements of OOP (Object Oriented Progamming), FP (Functional Programming), and FRP (Functional Reactive Progra

nestjs.com

- Angular Module Loader - lazy-af

 

@herodevs/lazy-af

This component allows you to lazily load your Angular module whenever you want, instead of being restricted to lazy loading on route changes.

www.npmjs.com

 

posted by Peter Note
2019. 1. 9. 18:26 Angular/Architecture

Nx Workspace와 NgRx/Platform을 연결한 boilerplate를 만들어 본다. 


  - Nx Workspace 생성하기 

  - NgRx 개념이해  및 사용예 만들기

  - 다음 3가지 문서와 동영상을 참조한다.

    + Nx Workspace 무료 동강 수강

    + Nx Workspace 메뉴얼

    + NgRx와 Nx Workshop 강좌

    + State Management Type 정리

    + Nx Workspace 기반 예제소스




Nx Workspace 생성


하나의 저장소에 여러 애플리케이션을 개발할 수 있는 workspace를 최초 한번 생성한다.  

  - 현재 최신 버전의 스케매티과 CLI를 설치한다. v7.* 이다.

  - workspace 생성시 npmScope를 설정하여 workspace의 공통 library를 import할 때 prefix로 사용된다. 예로 @jm/<library name> 식이다. 

     또한 컴폰너트 selector의 prefix로 사용된다.

  - workspace 생성시 옵션은 scss, npm (또는 yarn)을 선택한다.

$ npm i -g @nrwl/schematics @angular/cli


// create -react-app과 유사, 첫번째 인자는 workspace 명칭이다. 

$ create-nx-workspace  jamong  --npm-scope=jm


nx workspace에서 사용(2019.1.8)기준 Redux 패턴의 구현체인 ngrx/platform 버전이 v6.*으로 설정되어 있기에 v7.0.0으로 변경한다. 

  - <workspace>/package.json에서 @ngrx/xxxx 의 버전을 ^7.0.0 으로 설정한다. 

$ cd jamong

$ vi package.json


// 수정후 다시 install 한다.

$ npm i


다음으로 샘플 애플리케이션을 생성한다. 

  - g는 generate, app은 application 이다. 

  - dashboard 명칭의 애플리케이션을 생성한다.

  - routing, unit test - jest, e2e - cypress, linting등을 선택한다.

$ ng g app dashboard

또는

$ ng generate application dashboard


// 작동여부 확인

$ npm start --project=dashboard


다음으로 애플리케이션안에 component를 자동생성할 때 옵션을 미리 설정해 놓는다. angular workspace의 schematics 설정 목록을 참조한다.

  - <workspace>/angular.json 파일의 dashboard 애플리케이션에 하기 항목을 추가한다. 

  - OnPush, viewEncapsulation 적용

생성시 적용될 수 있도록 맨 하단에도 동일한 설정을 한다. 

  "schematics": {

    "@nrwl/schematics:application": {

      "style": "scss",

      "changeDetection": "OnPush",

      "viewEncapsulation": "None"

    },

    "@nrwl/schematics:library": {

      "style": "scss",

      "changeDetection": "OnPush",

      "viewEncapsulation": "None"

    }

  },

  "defaultProject": "mi-dashboard"



샘플 컴포넌트를 생성한다.

  - --project옵션을 통해 어느 프로젝트안에 생성할지 선택한다.

  - / 로 path를 지정할 수 있다.

  - component 생성 명령 설명

$ ng g component layout/page --project=dashboard

CREATE apps/dashboard/src/app/layout/page/page.component.scss (0 bytes)

CREATE apps/dashboard/src/app/layout/page/page.component.html (23 bytes)

CREATE apps/dashboard/src/app/layout/page/page.component.spec.ts (614 bytes)

CREATE apps/dashboard/src/app/layout/page/page.component.ts (261 bytes)

UPDATE apps/dashboard/src/app/app.module.ts (555 bytes)


공통 라이브러리도 생성해 본다.

  - tag를 통해 소스 분석시 논리적 그룹을 주고, tag들 끼리의 의존관계를 설정할 수도 있다. 

  - library를 생성하면 <workspace>/angular.json, nx.json, tsconfig.json 파일에 자동으로 정보가 입력된다.

  - library 생성 명령 설명

$ ng g lib shared --tags=shared-lib

? In which directory should the library be generated?

? Which module should import the library?

? Would you like to add a routing configuration to the library? No

? Will this library be lazy loaded? No

? Would you like to generate an NgModule within the library? Yes

? Which Unit Test Runner would you like to use for the library? Jest (https://

jestjs.io/)

CREATE libs/shared/tsconfig.lib.json (705 bytes)

CREATE libs/shared/tslint.json (185 bytes)

CREATE libs/shared/src/index.ts (37 bytes)

... 생략


Unit Test는 Jest를 사용하고, e2e는 cypress를 사용하므로 Karma, Jasmine와 Protractor관련 내용은 삭제한다. 

  - package.json안에 karma, jamine관련 패키지 삭제 (jasmine-marbles 패키지는 제외)

  - karma.conf.json 파일삭제

  - yarn.lock, package-lock.json파일 삭제

  - node_modules를 제거하고 다시 npm install을 수행한다. 




NgRx/Platform 적용하기


Redux 패턴의 Angular 버전인 NgRx/platform을 적용한다. 엔터프라이즈 아키텍트를 적용하여 Store/State 접근방식을 SandBox를 통한 접근토록 만든다. libs/appState 에 공통적인 부분을 구현한다. Angular Enterprise Architecture Pattern을 참조한다.

  - Application Core Facade는 Parent Class로 Presentation Module에서 사용하는 Sandbox가 상속을 받는다.

  - "State Management" library를 생성한다. 여기에는 기본 설정항목과 None Visual Domain 영역에 대한 State관리를 관장한다. 

     이것은 forRoot가 된다.

  - Common UI는 Library별로 존재하며 State Management는 각 UI별로 구현한다. 

     이들은 forFeature가 된다.


Application을 위한 ngrx state를 생성한다. 

  - appState 명칭과 --module 옵션을 반드시 설정해야 한다. 

  - 해당 명령을 수행하면 ngrx/entity가 자동 설치되는데 v6.* 가 설치되므로 package.json에서 v7.*으로 변경하고 다시 npm install 수행한다. 

  - application레벨의 root state를 선택한다. (yes) => app.module.ts에 forRoot가 자동 설정된다.

  - facade도 yes를 선택한다.

  - 명령 옵션 목록

$ ng g ngrx appState --module=./apps/dashboard/src/app/app.module.ts

? Is this the root state of the application? Yes

? Would you like to add a Facade to your ngrx state Yes


생성 파일들


Redux에서는 action, reducer가 기본이고, (side) effect라는 부수효과는 reducer를 타기전 ajax 호출같은 async를 처리할 때 이용한다. selector는 state의 내용을 Domain 요구에 따라 조합해서 반환하는 서비스이다. 그럼 Facade는 무엇일까?

  - Redux패턴에서 state값을 조합해서 얻기위해 성능향상을 줄 수 있는 것이 reselector개념이고, 이를 selector에서 구현한다. 참조글

  - Redux패턴에서의 Facade 글을 참조한다. facade 서비스를 통해서 데이터를 가져온다. 데모 소스

  - Facade 서비스가 Presentation 컴포넌트에서 사용하는 Biz 로직을 담고 있는 SandBox이다. 

  


AppStateFacade는 forFeature에서 사용하는 common한 내용을 담는다. 즉 "Application core facade" 이다.

  - schematics을 커스텀으로 만들어 사용할 수 있다.

import { Injectable } from '@angular/core';


import { select, Store } from '@ngrx/store';


import { AppStatePartialState } from './app-state.reducer';

import { appStateQuery } from './app-state.selectors';

import { LoadAppState } from './app-state.actions';


@Injectable()

export class AppStateFacade {

  loaded$ = this.store.pipe(select(appStateQuery.getLoaded));

  allAppState$ = this.store.pipe(select(appStateQuery.getAllAppState));

  selectedAppState$ = this.store.pipe(

    select(appStateQuery.getSelectedAppState)

  );


  constructor(private store: Store<AppStatePartialState>) {}


  // 업무 메소드, Action을 생성하고 dispatch하는 문구가 존재한다.

  loadAll() {

    this.store.dispatch(new LoadAppState());

  }

}


forFeature에 대한 것은 libs 폴더 밑에 생성한다.

  - library 생성을 한다. 이때 옵션으로 --directory=<groupName>을 주면 라이브러리들을 directory명칭 밑으로 그룹핑할 수 있다. 

  - 생성된 library에 menu에 대한 feature 레벨 state를 생성한다. 

$ ng g lib menu --directory=state

? Which module should import the library?

? Would you like to add a routing configuration to the library? No

? Will this library be lazy loaded? No

? Would you like to generate an NgModule within the library? Yes

? Which tags would you like to add to the library? (used for linting)

? Which Unit Test Runner would you like to use for the library? Jest

CREATE libs/state/menu/tsconfig.lib.json (712 bytes)

CREATE libs/state/menu/tslint.json (188 bytes)

CREATE libs/state/menu/src/index.ts (41 bytes)  <== state 그룹 밑으로 menu library가 생성되었다. 

CREATE libs/state/menu/src/lib/state-menu.module.ts (164 bytes)

... 중략


다음으로 menu state를 생성한다. 

  - 반드시 library의 모듈을 수행하는 명령의 상대경로로 지정한다.

$ ng g ngrx menu --module=libs/state/menu/src/lib/state-menu.module.ts

? Is this the root state of the application? No

? Would you like to add a Facade to your ngrx state Yes

CREATE libs/state/menu/src/lib/+state/menu.actions.ts (731 bytes)

CREATE libs/state/menu/src/lib/+state/menu.effects.spec.ts (1147 bytes)

CREATE libs/state/menu/src/lib/+state/menu.effects.ts (842 bytes)

... 중략


state-menu.module.ts에 forFeature가 다음과 같이 자동 등록된다. forFeature는 lazy loading 또한 가능하다.

  - state에 대한 forFeature 등록

  - effect에 대한 forFeature 등록

import { NgModule } from '@angular/core';

import { CommonModule } from '@angular/common';

import { StoreModule } from '@ngrx/store';

import { EffectsModule } from '@ngrx/effects';

import {

  MENU_FEATURE_KEY,

  initialState as menuInitialState,

  menuReducer

} from './+state/menu.reducer';

import { MenuEffects } from './+state/menu.effects';

import { MenuFacade } from './+state/menu.facade';


@NgModule({

  imports: [

    CommonModule,

    StoreModule.forFeature(MENU_FEATURE_KEY, menuReducer, {

      initialState: menuInitialState

    }),

    EffectsModule.forFeature([MenuEffects])

  ],

  providers: [MenuFacade]

})

export class StateMenuModule {}


StateMenuModule을 app.module.ts에 등록한다. 

  - @jm/state/menu 경로로 import한다. 이는 <workspace>/tsconfig.json에 path가 자동 설정되기에 가능하다. 

import { StateMenuModule } from '@jm/state/menu';


@NgModule({

  declarations: [AppComponent, PageComponent],

  imports: [

    BrowserModule,

    NxModule.forRoot(),

    RouterModule.forRoot([], { initialNavigation: 'enabled' }),

    StoreModule.forRoot(

      { appState: appStateReducer },

      {

        initialState: { appState: appStateInitialState },

        metaReducers: !environment.production ? [storeFreeze] : []

      }

    ),

    EffectsModule.forRoot([AppStateEffects]),

    !environment.production ? StoreDevtoolsModule.instrument() : [],

    StoreRouterConnectingModule,


    StateMenuModule

  ],

  providers: [AppStateFacade],

  bootstrap: [AppComponent]

})

export class AppModule {}


effect 클래스를 보면 DataPersistence 헬퍼 클래스를 Nx에서 제공한다. 

  - async 처리에 대한 추상화이다. 

  - 4가지 주요 헬퍼 메소드 제공

    + optimisticUpdate: 요청값을 client에 먼저 반영하고 만일 backend 오류 발생시 이전 상태로 복원

    + pessimisticUpdate: 요청값을 backend에 반영하고 이후 client에 반영

    + fetch: 같은 Action에 대한 다중 요청은 가장 최신 것만 반영함. pessimisticUpdate이면서 같은 Action에 따른 요청은 최신만 반영하는 것.

    + navigation: routing될 때 effect 자동 호출

  - DataPersistence에 대한 상세 설명

  - Angular Application State관리 방법

import { Injectable } from '@angular/core';

import { Effect, Actions } from '@ngrx/effects';

import { DataPersistence } from '@nrwl/nx';


import { MenuPartialState } from './menu.reducer';

import {

  LoadMenu,

  MenuLoaded,

  MenuLoadError,

  MenuActionTypes

} from './menu.actions';



@Injectable()

export class MenuEffects {

  @Effect() loadMenu$ = this.dataPersistence.fetch(

    MenuActionTypes.LoadMenu, 

    {

      run: (action: LoadMenu, state: MenuPartialState) => {

        // Your custom REST 'load' logic goes here. For now just return an empty list...

        return new MenuLoaded([]);

      },


      onError: (action: LoadMenu, error) => {

        console.error('Error', error);

        return new MenuLoadError(error);

      }

  });


  constructor(

    private actions$: Actions,

    private dataPersistence: DataPersistence<MenuPartialState>

  ) {}

}



<참조>

- Nx Workspace 홈페이지

- Nx Github

- Angular Workspace의 Schematics 설정 목록

Nx workspace에서 component 생성하기 명령

- Angular Enterprise Architecture Pattern

- NgRx Schematics 설정

- Redux의 reselector를 통한 성능향상

- NgRx Facade 이해

- Angular Application State관리 방법

- Ionic + Angular + ngrx 사례

posted by Peter Note
2018. 12. 27. 15:27 Angular/Architecture

Angular CLI v6.* 이후 Multi Application을 위한 Workspace개념이 도입되었다. 공통 Module을 통해 하나의 폴더안에서 여러 애플리케이션을 만들 수 있는 방법에 대해 알아본다. 




Schematics


스케메틱스는 workflow 툴이다. 

  - 프로젝트에 파일을 생성하고

  - 기존 코드를 변경하고

  - 환경 옵션을 추가하거나 프레임워크를 추가할 수 있다. 


스케메틱스는 Angular CLI의 코드 스케폴딩에 사용하며 다음 목표를 지향하여 개발되었다. 

  - 사용 및 개발이 쉬워야 한다

  - 확장 및 재상용성이 좋아야 한다

  - CLI동작시 부작용을 제거할 수 있어야 한다.

  - 비동기성을 지원한다.


Tree

  - 이미 존재하는 파일 관계를 작는 데이터 구조체이다. 

  - 파일을 수정하거나 생성하고 찾아 갈때 사용한다.

  - 스케메틱의 Start point가 된다. 

  - 하나의 스케메틱 Tree를 다른 스케메틱 Tree로 전달할 수 있다. 

  - create, delete, rename, overwrite 내가지 함수를 제공한다.


나만의 스케메틱스 만들기 

  - Node v6.9 이상 설치

  - schematics 실행환경을 만들기 위해 shcematics-cli를 설치한다. 

$ npm install -g @angular-devkit/schematics-cli

// 빈 스케메틱스 프로젝트 생성

$ schematics blank --name=my-project

$ cd my-project


Collections

  - 이름을 갖는 schematics의 집합이다. 이것은 사용자에 의해 발행되고 설치될 수 있다. 

  - 예로 @schematics/angular collection이 있다. 이것은 component, module, application 등에 대한 schematics를 가지고 있다. 

  - 생성한 my-project는 하나의 schematics만을 가지고 있고, my-project/src/collection.json 에 정의되어 있다. 

  - schematics key안에 하나의 my-project schematic 이 설정되어 있다.

  - factory key는 자바스크립트 펑션 위치를 설정한다. 이것은 RuleFactory라 한다. 

// src/collection.json

{

  "$schema": "../node_modules/@angular-devkit/schematics/collection-schema.json",

  "schematics": {

    "my-project": {

      "description": "A blank schematic.",

      "factory": "./my-project/index#myProject"

    }

  }

}


// src/my-project/index.ts

import { Rule, SchematicContext, Tree } from '@angular-devkit/schematics';


export function myProject(_options: any): Rule {

  return (tree: Tree, _context: SchematicContext) => {

    return tree;

  };

}


Rule

  - Tree를 받아 Tree를 반환하는 함수이다. 

  - Rule이 스케메틱스의 핵심이다. 

  - Factory 함수는 입력 options 아규먼트를 받아 원하는 것을 처리 후 다시 Rule을 반환한다. 

  - 옵션은 CLI의 경우 command line 아규먼트로 전달되는 값이다. (보통 --name=<value> 같이 전달함)

 

사용자가 만든 스케메틱스를 수행하기 

  - dry-run은 스케메틱스 자신안에서 수행할 수 있게 한다. default는 false 이다.

  - 우리가 만든 스케메틱스는 애플리케이션안에서 사용하는 것이다. 따라서 자기 자신안에서 스케메틱스 검증을 해보려면 dry-run 옵션을 준다.

  - 만들어진 스케메틱스를 디버깅 할 수 있다. 

$ npm run build


// dry-run 수행시, 가급적 사용하지 말자, 별도의 temporary 폴더에서 dry-run없이 테스트 한다. 

$ schematics .:my-project --name=test --dry-run=true


// 디버깅

$ node --inspect-brk $(which schematics) .:my-project --name=test


다른 스케메틱스를 함께 사용하기 

  - chain을 통해 기존 @schamatics/angular의 component 생성하는 것을 이용한다. 

  - Angular component를 만든 다음 상단에 license 문구를 추가한다. 

import { Rule, SchematicContext, Tree, chain, externalSchematic } from '@angular-devkit/schematics';


const licenseText = `

/**

 * @license

 * Copyright Google Inc. All Rights Reserved.

 *

 * Use of this source code is governed by an MIT-style license that can be

 * found in the LICENSE file at https://angular.io/license

 */

`;


export function myProject(options: any): Rule {

  return chain([

    externalSchematic('@schematics/angular', 'component', options),

    (tree: Tree, _context: SchematicContext) => {

      tree.getDir(options.sourceDir)

          .visit(filePath => {

            if (!filePath.endsWith('.ts')) {

              return;

            }

            const content = tree.read(filePath);

            if (!content) {

              return;

            }


            // Prevent from writing license to files that already have one.

            if (content.indexOf(licenseText) == -1) {

              tree.overwrite(filePath, licenseText + content);

            }

          });

      return tree;

    },

  ]);

}


수행해 보자.

// my-project schematics 폴더안에서 의존관계있는 @schematics/angular 설치

$ npm install --save @schematics/angular

$ npm run build


// 신규 프로젝트 생성하고, my-project schematics 를 npm link 건다.

$ cd ../

$ ng new <otherProjectName>

$ cd <otherProjectName>

$ npm link <my-project schematics path>


// schematics:schematic 을 호출한다. angular module의 declarations에도 자동 추가된다. 

$ ng g my-project:my-project

? What name would you like to use for the component? hi

CREATE src/app/hi/hi.component.css (0 bytes)

CREATE src/app/hi/hi.component.html (21 bytes)

CREATE src/app/hi/hi.component.spec.ts (600 bytes)

CREATE src/app/hi/hi.component.ts (253 bytes)

UPDATE src/app/app.module.ts (537 bytes)




Multi Application을 위한 Nx Workspace


Nx Workspace는 nrwl에서 만든 multi application 개발을 위한 Angular CLI에 대한 확장팩이다. 다음 3가지의 향상시키기 위해 만들어졌다. 

  - 생산성: 초시 셋업시간을 절약한다.

  - 일관성: 기업용 애플리케이션을 위한 좀 더 향상된 코드 제너레이터를 제공하고, 일관된 물리적 공간과 컨벤션을 제공한다.

  - 안정성: 분석기능 강화




Workspace에서 작업하기

  - 단일 레파지토리에서 Multi Application과 Library에 대한 개발을 수행한다.

    + Unified versioning: 하나의 레파지토리 사용에 따른 

    + Promotes code sharing and reuse: lib모듈을 통한 공유

    + Easier dependency management: 하나의 node_modules만 사용, 하나의 build setup

    + Refactoring benefits: code editors 지원, 변경이 전체 애플리케이션에 반영

    + Consistent developers experience: 공유 코드 변경에 대한 전체 애플리케이션 유효성 체크 가능



Nx Workspace 만들기

create-nx-workspace 명령어를 통해 nx 기반 angular workspace를 생성한다. 마치 create-react-app과 같은 역할이다. 

  - npmScope: 그림처럼 NPM Scope로 library를 접근하는 @my-company와 같은 npm scope를 설정


예로 @angular가 npm scope이다. 


  - directory workspace의 폴더명 변경

$ npm i -g @nrwl/schematics  @angular/cli


// command: create-nx-workspace <workspace name> --directory=<workspace별칭폴더명> --npm-scope=<library접근 scope>

$ create-nx-workspace my-project-suite --npm-scope=apple




Multi Application & Library 생성하기


Nx Workspace에 application과 library를 생성한다. Angular CLI Workspace에서 만들어 지는 폴더 구조와 다음과 같은 차이가 있다. 

  - apps: apps폴더 밑으로 Application별 폴더가 존재한다. 

  - libs: application에서 공유하는 Angular Module별 폴더가 존재한다.


애플리케이션 프로젝트에 대한 정보는 angular.json에서 확인할 수 있다. 

{

  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",

  "version": 1,

  "newProjectRoot": "",

  "projects": {}, <-- 프로젝트 즉, 애플리케이션은 아직 등록되지 않았다. 

  "cli": {

    "warnings": {

      "typescriptMismatch": false,

      "versionMismatch": false

    },

    "defaultCollection": "@nrwl/schematics", <-- nrwl/schematics를 사용한다. 

    "packageManager": "npm"

  }

}


nx.json은 Nx Workspace특화된 환경값을 갖는다. 

{

  "npmScope": "apple",

  "implicitDependencies": {

    "angular.json": "*",

    "package.json": "*",

    "tsconfig.json": "*",

    "tslint.json": "*",

    "nx.json": "*"

  },

  "projects": {}

}


그외 tsconfig.json에 paths와 tslin.json의 nx-enforce-module-boundaries 설정, 그리고 package.json에 Nx를 위한 별도 script들이 존재한다. 


apps폴더 밑으로 프로젝트 추가하기

  - 명령: ng g app <application name>

  - ng g app --help 로 생성 옵션을 볼 수 있다. 예로 --routing 옵션을 주면 routing module이 자동 설정된다. 또는 생성시 yes 를 선택해되 된다. 

$ ng g app app-one


// 다음을 선택했다. 

? In which directory should the application be generated?

? Would you like to add Angular routing? Yes

? Which stylesheet format would you like to use? SCSS   [ http://sass-lang.com]

? Which Unit Test Runner would you like to use for the application? Jest   [ https://jestjs.io ]

? Which E2E Test Runner would you like to use for the application? Cypress[ https://www.cypress.io ]

? Which tags would you like to add to the application? (used for linting)


애플리케이션 app-one을 위해 다음과 같은 두개 폴더가 생성된다. 


만들어진 애플리케이션을 실행해 보자. 

  - ng serve <application name>

  - default port는 4200이다. 여러개의 애플리케이션을 동시 실행하고 싶다면 --port 옵션으로 포트를 서로 틀리게 설정한다. 또는 angular.json에 설정할 수 있다. 

$ ng serve app-one


libs폴더 밑으로 공유 라이브러리 추가하기

  - 라이브러리는 Angular Module이다.

  - ng g lib <library name> 

$ ng g lib adk

? In which directory should the library be generated?

? Which module should import the library?

? Would you like to add a routing configuration to the library? No

? Will this library be lazy loaded? No

? Would you like to generate an NgModule within the library? Yes

? Which tags would you like to add to the library? (used for linting)

? Which Unit Test Runner would you like to use for the library? Jest (https://jestjs.io/)


생성을 하게되면 libs/adk 폴더가 생성되고, angular.json에 projectType으로 library가 자동 등록된다. (nx.json에도 자동 등록됨)


lazy loading되는 library module 생성

  - --routing이 설정된 모듈

  - lazy loading되는 상위 모듈: 어차피 애플리케이션도 라이브러리도 모듈이다.

  - --lazy 옵션을 직접주거나 아래처럼 선택할 수 있다. 

$ ng g lib login --routing --parent-module=./apps/app-one/src/app/app.module.ts


? In which directory should the library be generated?

? Will this library be lazy loaded? Yes

? Would you like to generate an NgModule within the library? Yes

? Which tags would you like to add to the library? (used for linting)

? Which Unit Test Runner would you like to use for the library? Jest (https://jestjs.io/)


routing 설정을 하게되면 login.module.ts와 app-one의 app.module.ts 안의 설정은 다음과 같다. 

  - @apple 이라는 npm scope가 자동으로 붙는다. 

// libs/login/src/lib/login.module.ts

@NgModule({

  imports: [

    CommonModule,


    RouterModule.forChild([

      /* {path: '', pathMatch: 'full', component: InsertYourComponentHere} */

    ])

  ]

})

export class LoginModule {}


// apps/app-one/src/app/app.module.ts

@NgModule({

  declarations: [AppComponent],

  imports: [

    BrowserModule,

    NxModule.forRoot(),

    RouterModule.forRoot(

      [{ path: 'login', loadChildren: '@apple/login#LoginModule' }],

      { initialNavigation: 'enabled' }

    )

  ],

  providers: [],

  bootstrap: [AppComponent]

})

export class AppModule {}


루트의 tsconfig.json에는 library module에 대한 paths 정보가 자동 설정된다. 

    "lib": [

      "es2017",

      "dom"

    ],

    "baseUrl": ".",

    "paths": {

      "@apple/adk": [

        "libs/adk/src/index.ts"

      ],

      "@apple/login": [

        "libs/login/src/index.ts"

      ]

    }




Multi Application 빌드하기 


angular.json의 architect에는 build와 serve에 대한 환경설정이 있다.

      "architect": {

        "build": {

          "builder": "@angular-devkit/build-angular:browser",

          "options": {

            "outputPath": "dist/apps/app-one",

            "index": "apps/app-one/src/index.html",

            "main": "apps/app-one/src/main.ts",

            "polyfills": "apps/app-one/src/polyfills.ts",

            "tsConfig": "apps/app-one/tsconfig.app.json",

            "assets": [

              "apps/app-one/src/favicon.ico",

              "apps/app-one/src/assets"

            ],

            "styles": [

              "apps/app-one/src/styles.scss"

            ],

            "scripts": []

          },

          "configurations": {

            "production": {

              ....

             }

           }


빌드 명령

애플리케이션을 빌드한다

  - ng build <application name> --prod

  - nx workspace command 목록

$ ng build app-one --prod


라이브러리를 빌드하려면 라이브러리 생성할 때 --publishable 옵션을 주어서 생성한다. 그러면 angular.json파일의 "architect"에 "build"옵션이 추가된다. library build할 때는 ng-packagr를 이용하여 어디에서든 사용할 수 있는 APF v6가 적용된다. APF는 Angular Package Format의 약어이다. 

 $ ng g lib ui --publishable --routing --parent-module=./apps/app-one/src/app/app.module.ts


// angular.json 

    "ui": {

      "root": "libs/ui",

      "sourceRoot": "libs/ui/src",

      "projectType": "library",

      "prefix": "apple",

      "architect": {

        "build": {

          "builder": "@angular-devkit/build-ng-packagr:build",

          "options": {

            "tsConfig": "libs/ui/tsconfig.lib.json",

            "project": "libs/ui/ng-package.json"

          }

        },


Angular Pakage Format v6 지원 목록


ui라는 라이브러리 빌드하기 

$ ng build ui

Building Angular Package

Building entry point '@apple/ui'

Compiling TypeScript sources through ngc

Bundling to FESM2015

Bundling to FESM5

Bundling to UMD

Minifying UMD bundle

Copying declaration files

Writing package metadata

Removing scripts section in package.json as it's considered a potential security vulnerability.

Built @apple/ui

Built Angular Package!

 - from: /Users/dowonyun/mobicon/projects/bistel/prototyping/my-project-suite/libs/ui

 - to:   /Users/dowonyun/mobicon/projects/bistel/prototyping/my-project-suite/dist/libs/ui


// 다양한 번들 파일이 생성됨 



$schema와 schema.json 개념

Angular Workspace에 대한 schema를 강제하기 위하여 schema.json 파일을 angular.json의 $schema에 설정한다. 

  - Angular Workspace Schame에 대한 Json 스펙

  - Angular CLI의 Schematics 에 목록: 각 폴더 밑에 schema.json 파일이 존재한다. 

  - schematics 키의 값은 workflow를 수행할 때 적용할 옵션을 설정할 수 있다. 

     지정가능한 옵션 목록

"schematics": {

        "@schematics/angular:component": {

          "styleext": "scss",

          "changeDetection": "OnPush",

          "viewEncapsulation": "None",

          "export": true

        }

},




<참조>

- Schematics 소개

- 2018 FEConf, 고재도님의 Schematics 소개영상

- Angular CLI의 Workspace 과 Schematics 개념

- Angular CLI command 목록

- Nrwl Nx Workspace  홈페이지

- Nx Github 

- Nx Workspace 온라인 강좌 (Free)

- Angular Package Format(APF) 개념 강좌

- APF를 만들어주는 ng-packagr 소스 및 설명

- APF v6 스펙

- ng-packagr 소개

posted by Peter Note
2018. 12. 13. 16:39 Angular/Architecture

Angular 프로젝트를 위한 구조 설계 요건에 대해 알아본다. 


  - 프레임워크 선택 고려 사항

  - 개발 생산성과 유지 보수성을 높일 수 있는 방안

  - 참조 문서와 소스 

    + Angular Enterprise Architecture pattern 문서

    + 해당 문서의 예제 소스




프레임워크 선택 고려 사항


프레임워크는 잘 정돈된 놀이터와 같아 기구를 타고 놀면 된다. 하지만 라이브러리의 경우는 툴박스와 같아서 박스안에는 망치, 드라이버, 못같은 것만 있다. 그럼 놀 것을 어떻게 만들지는 도구를 사용하는 사용자의 몫이다. 현재 UI 프레임워크/라이브러리는 Angular, React, Vue 등이고 풀스택으로는 Meteor를 선택해서 사용하고 있다. Angular 프레임워크와 React UI 라이브러리 또는 Meteor 선택시 고려사항을 개인의견으로 간략히 정리한다. 


Angular Framework

  - 대규모 협업 팀에 유리: 대략 10명이상으로 HTML Publisher와 Javascript 개발자가 분리되어 있을 경우

  - JQuery가 low level의 javascript로 개발해 오던 개발자들이 접근하기에 수월하다고 판단함

  - Typescript, RxJS 반드시 알아야 한다.


React Library

  - HTML Publisher와 Javascript 개발을 같이하는 스타트업 또는 프론앤드 개발자에게 유리

  - 원하는 것들을 선택해 적용할 수 있다. 


Meteor

  - FullStack 으로서 javascript가지고 전부 개발하고 싶을 경우

  - 아이디어를 빠르게 구현하고 검증 받고 싶을 경우

  - UI는 Angular, React, Vue 등으로 선택해 사용할 수 있으나, React가 적합하다 판단



그러나 어떤 것을 선택하든 공통적으로 고려해야 하는 사항으로 애플리케이션 아키텍쳐이다. 이에 대한 좋은 영상이 있어 보기를 권한다. 




애플리케이션 아키텍쳐



위의 영상을 정리해 보면 다음과 같다. 

  - Layered Architecture 구성

  - 역할 분담

    + Module: 업무 최소 단위, 하나를 제거해도 다른 것에 영향을 주지 않는 단위, Module은 Sandbox만 알뿐이다. 

    + Sandbox: Module은 Sandbox를 통해 Application Core나 Base Library를 접근한다.

         - 일관성을 유지시킴

         - 시큐리티 가드 역할

         - 공통 Interface 역할

    + Application Core: Module을 관리(Control) 한다. 

         - Module의 Life Cycle을 담당한다.

         - Module 간 통신을 담당한다 (inter-module communication)

         - Module을 직접 가져다 쓰지 않고, Sandbox의 공통 API를 통해 명령을 내리고, 듣는다. 

         - General error handling

         - Extension을 통해 Application core기능을 확장한다.  

            

   + Extension 확장

       - Error handling

       - Ajax communication: 공통 Format (request/response) 통신, 서버 오류 관리

       - New module capabilities

       - General Utils

       - What you want

    + Base Library

       - 개발자들이 직접 base library를 건드리게 하지 말자. 나중에 바뀔 수 있다. 

       - Browser normalization

       - General purpose utilities: Paser/serializer, Object / DOM manipulation, Ajax Communication

       - low-level extension 제공: application extension처럼 base library를 확장한 것들을 제공한다. 

         


정리

  - Base Library만이 사용중인 브라우저를 알고 있다. 아키텍쳐의 다른 layer에서 알 필요가 없다.

  - Application Core만이 사용중인 Base Library를 알고 있다. 아키텍쳐의 다른 layer에서 알 필요가 없다. 

  - Module은 Sandbox의 존재외에는 아무것도 모른다. 아키텍쳐의 나머지에 대해선 아무것도 모른다.


장점

  - 하나의 프레임워크상에서 서로 다른 멀티 애플리케이션을 만들 수 있다. 즉, 기존의 컴포넌트를 재사용함으로서 시간을 줄일 수 있다. 

  - 느슨한 연결(loose coupling)으로 인해 모듈 단위 테스트가 가능해짐.

  - 확장 가능한 자바스크립트 아키텍쳐는 하나의 블록을 교체한다고 해도 두려워 할 필요가 없는 상태가 되어야 한다. 즉, 이를 달성할 수 있다.




유지 보수성 높이기


유지보수가 좋은 코드는 다음의 특성을 갖는다. 

  - 직관적이다. Intuitive

  - 코드 이해가 쉽다 Understable

  - 적용하기 쉽다 Adaptable

  - 확장하기 쉽다 Extendable

  - 디버깅하기 쉽다 Debuggable


이를 위해 해야할 것들. 
  - Code Style, Code Convention 지키기
  - Naming 잘 하기: 이름에 대한 길이에 대해 걱정하지 말자.
  - Javascript에서 css 핸들링 하지 말자 
  - event object를 바로 다른 function의 argument로 넘기지 말고, 필요한 정보만을 준다. 
  - 사용전 object undefined 체크
  - string 값들은 별도의 Config Data 객체에 담아서 사용한다.

    

  - 빌드 자동화 하자

    


posted by Peter Note
2017. 4. 23. 15:51 Angular/Concept

Angular CLI를 통해 프로젝트를 생성하고 Docker에 Nginx를 띄워서 간단히 연결해 보자. 




Angular CLI 기반 프로젝트 생성


NodeJS버전은 6최신을 사용한다. 

$ npm install -g @angular/cli 


설치가 되었다면 ng 명령을 통해 프로젝트를 생성한다. 

$ ng new angular-docker


프로젝트가 생성되었으면 프로젝트 폴더로 이동해서 소스를 빌드한다. 

$ cd angular-docker

$ ng build

Hash: cfba09939df99de45615

Time: 7424ms

chunk    {0} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 165 kB {4} [initial] [rendered]

chunk    {1} main.bundle.js, main.bundle.js.map (main) 3.61 kB {3} [initial] [rendered]

chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 9.77 kB {4} [initial] [rendered]

chunk    {3} vendor.bundle.js, vendor.bundle.js.map (vendor) 2.09 MB [initial] [rendered]

chunk    {4} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]





Docker CE 기반 Nginx 관리


Docker를 잘 모른다면 Docker CE를 설치해 사용한다. 

  - download docker CE (Community Edition)

 - Mac 버전을 설치하면 Docker 가 기동이 된다.

 

     


다음으로 Nginx image 를 docker명령을 통해 내려받는다. 만일 사용하지 않는 Docker image들이 있다면 다 삭제를 한고 작업을 해보자.

// Delete all docker containers

$ docker rm $(docker ps -a -q)


// Delete all docker images

$ docker rmi $(docker images -q)


// Install docker image

$ docker pull nginx

Using default tag: latest


// 설치 내역 확인

$ docker images 

REPOSITORY        TAG                 IMAGE ID            CREATED             SIZE

nginx                  latest              5766334bdaa0   2 weeks ago         183 MB


Angular 빌드 폴더로 이동해서 Nginx를 수행한다. 

$ cd dist

$ docker run -d -p 8080:80 -v $(pwd):/usr/share/nginx/html nginx:latest

48db2f0626c5a10429e95cbbbaf3cc58769cda45a9c1e7084b4f3a260e576838


// 이미지 실행 확인

$ docker ps -a

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                           NAMES

48db2f0626c5        nginx:latest        "nginx -g 'daemon ..."   2 minutes ago       Up 2 minutes        443/tcp, 0.0.0.0:8080->80/tcp   loving_lumiere


수행되고 있는 이미지를 멈추고 제거해 보자. stop, rm 다음은 Container ID의 처음 두자를 입력한다. 

// 멈춤 

$ docker stop 48

48


// 제거

$ docker rm 48

48


// 확인

$ docker ps -a

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES


Kinetic 애플리케이션을 사용해서 CLI 명령과 동일하게 GUI 기반으로 Container를 관리할 수 있다.




Docker Compose 사용하기


컴포즈는 환경을 기반으로 다양한 도커 이미지들을 동시에 기동하고 연결하는 역할을 수행한다. Nginx, NodeJS, MongoDB등을 서로 다른 Docker image기반으로 기동하고 연결하는 환경설정을 docker_compose.yml에 한다. angular-seed 예는 다음과 같다. 

version: '2'


services:


  angular-seed:

    build:

      context: .

      dockerfile: ./.docker/angular-seed.development.dockerfile

    command: npm start

    container_name: angular-seed-start

    image: angular-seed

    networks:

      - dev-network

    ports:

      - '5555:5555'


networks:

  dev-network:

    driver: bridge


빌드하고 수행하기 

$ docker-compose build

$ docker-comopse up


ng-conf 2017 의 docker 이야기




<참조>



posted by Peter Note
2017. 3. 29. 15:05 Angular/Concept

NodeJS에서 Typescript를 사용하기 위한 빠른 환경 설정 방법을 정리한다.



설치

먼저 테스트를 위한 폴더를 만들고 Node환경을 만든다. package.json을  파일 생성한다.

$ npm init -y


필요한 패키지를 설치한다.

$ npm i -g typescript@latest


$ npm i -g ts-node


$ npm i @types/node --save-dev




환경설정


Typescript 환경파일을 생성한다.

$ tsc --init


tsconfig.json파일 환경을 설정한다. typeRoots와 exclude를 추가한다. (tsocnfig.json의 상세내역 참조)

{

    "compilerOptions": {

        "module": "commonjs",

        "target": "es5",

        "noImplicitAny": false,

        "sourceMap": false

    },

    "typeRoots": ["node_modules/@types"],

    "exclude": [

        "node_modules"

    ]

}




테스트


테스트 파일을 생성한다.

$ touch index.ts

$ vi index.ts


const hi = 'hello peter';

console.log(hi);


테스트를 위해 소스 변경을 런타임시에 체크하고 적용하는 nodemone을 설치한다. 

$ npm i nodemon --save-dev


테스트 스크립트를 package.json의 scripts 항목에 추가한다.

$ vi package.json


{

...

  "scripts": {

    "start": "npm run build:live",

    "build:live": "nodemon --exec ./node_modules/.bin/ts-node  ./index.ts"

  },

...

}


테스트한다.

$ npm start


> typescript@1.0.0 start /Users/dowonyun/prototyping/typescript

> npm run build:live

> typescript@1.0.0 build:live /Users/dowonyun/prototyping/typescript

> nodemon --exec ./node_modules/.bin/ts-node ./index.ts


[nodemon] 1.11.0

[nodemon] to restart at any time, enter `rs`

[nodemon] watching: *.*

[nodemon] starting `./node_modules/.bin/ts-node ./index.ts`

hello peter

[nodemon] clean exit - waiting for changes before restart



또는 ts-node를 설치해서 수행해도 된다.

$ npm install --save ts-node 

$ ts-node ./index.ts



참조

https://basarat.gitbooks.io/typescript/docs/quick/nodejs.html

- https://nodemon.io/

- https://github.com/TypeStrong/ts-node


posted by Peter Note
2016. 12. 20. 20:54 Angular/Concept

오늘은 Progressive Web Apps 개발에 대한 세미나 참석 내용을 정리해 본다. 



AMP

Progressive는 구글이 생각하는 서비스에 대한 점진적인 개발 진행 방향을 이야기 한다. 즉, 기술아니라 사용자 경험을 더 좋게 하기 위한 개념이다. AMP (Accelerated Mobile Pages) 는 모바일 페이지를 빠르게 만드는게 목표이다. 네트워크가 빠르면 모바일 웹이 느리다는 것을 느낄 수 없지만 느리면 반응이 느려진다. 해당 기술은 데스크톱에도 동일하게 적용될 수 있다. AMP는 정적 페이지를 위한 것이다. 


- amp html


<html amp>를 넣는다. <style amp-boilerplate>를 넣어 페이지 로딩바가 보이도록 한다. 

<!doctype html>

<html amp>

 <head>

   <meta charset="utf-8">

   <link rel="canonical" href="hello-world.html">

   <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

   <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

   <style amp-custom>

    

   </style>

   <script async src="https://cdn.ampproject.org/v0.js"></script>

 </head>

 <body>Hello World!</body>

</html>


- <link rel="canonical" href="amp.html">  amp를 지원하지 않는 브라우저대응을 위한 대신할 html 지정 

- 속도를 위해 amp로 된 웹페이지를 하나 더 만들어 서비스 하는것이다. amp는 기존의 html, css를 변경해서 적용하는 것이다. 



Service Worker

Web Worker는 메인페이지와 병렬 스크립트를 실행하는 백그라운드 워커를 생성하는 API로서 메세지 전송기반의 스레드 수행과 유사하다. UI Rendering과 분리되어 수행할 수 있다. 따라서 Web Work에서는 


- DOM을 직접 건드릴 수 없다. 

- 자체적인 글로벌 스코프

- 일부 속성과 API만 허가: 보면서 디버깅할 수 있는 것이 없다


Service Worker는 오프라인일 경우에도 웹 어플리케이션의 기동을 가능토록 하는 훅(Hook)을 포함하여, 어플리케이션으로 하여금 지속적인 백그라운드 포로세싱의 장점을 취하도록 하는 방법. 브라우저에서 로컬 웹서버가 있는 것과 같다. 


- 지속적인 백그라운드 처리

- 브라우저에 무언가 설치하는 것이다


정적인 파일에 대한 요청이 있을 때 네트워크가 끊어졌을 때 로컬 브라우저에서 서비스를 할 수 있게 한다. 백그라운드에서 정적 파일을 가져와서 브라우저 요청을 로컬 Service Worker 에서 처리해 준다. Application Cache의 스펙 오류를 해결하기 위해 Service Worker가 나왔다. 


- 기본 https 에서만 작동한다. 해킹방지: 중간 공격자를 피하기 위함

- 대신 127.0.0.1, localhost 테스트는 가능하다 


예, 오프라인 웹앱, 구글의 공룡게임 - 브라우저에 함께 존재한다. 


배워야 할 것은 


- 리소스 저장을 위한 Cache Storage - promise객체를 반환 

- 이벤트 생명 연장의 꿈: .waitUntile()  이벤트가 종료되지 않도록 한다  

- 패치 onfetch() 브라우저에서 리소스 접근 요청될 때 호출되는 이벤트 -> FetchEvent 요청내용을 담고 있다. .responseWith() 통해 응답한다



NAMP-CARD 

https://ampbyexample.com 좀 더 심화된 예제 사이트 이다. sw.js를 작성한다. 


var CACHE_NAME = 'pwa-workshop.github.id-namp-card-cache-v1';

// 하기 해당하는 내용을 캐쉬에 저장한다 

var urlsToCache = [

'/namp-card',

    '/index.html',

    '/manifest.json',

    '/user.png'

];


self.addEventListener('install', function(event) {

event.waitUntil(

caches.open(CACHE_NAME).then(function(cache) {

console.log(`Opened cache for namp-card ${new Date()}`);

return cache.addAll(urlsToCache);

})

);

});


self.addEventListener('fetch', function(event) {

    event.waitUntile(

        // 캐쉬안에 브라우저 요청과 매칭되는 것이 있으면 리턴을 해준다. 

        // 없으면 fetch(event, request.url)로 원격 서버에 요청 

        caches

            .match(event.request.url)

            .then(function(res) {

                return res || fetch(event, request.url);

            })

    )

});


등록을 한다. amp-install-serviceworker 스크립트를 이용하면 하기 내용이 들어간다. 개발자가 직접 넣을 수 없다. 

navigator.serviceWorker.register('/sw.js', { scope: '/' })

          .then(function(registration) {

                console.log('Service Worker Registered');

          });


https://airhorner.com/ 예의 DevTool에서 Service Worker를 볼 수 있다. 




모바일 기기에 설치형 웹앱 만들기

설치형이란? 


- 네트워크 불안하거나 오프라인인 경우에도 동작

- 홈스크린에서 바로 실행

- 앱의 이름과 아이콘을 제공


동작 가능한 웹앱


- 서비스워커의 지원 필요

- 프리캐쉬(Pre-cache)된 애플리케이션 프레임워크(App-shell) 사용

- 서비스워커를 통해 Indexed DB 또는 히스토리컬 데이터 디스플레이 


반드시 웹 메니페이스(Manifest)를 작성해야 함


- 설치 방법을 기술: 브라우저에서 Add to Home Screen 하면 모바일 바탕화면에 아이콘이 나온다. -> 굳이 앱을 설치하지 않아도 접근 가능토록 한다

- Splash 윈도우 사용가능: 아이콘 지정, 텍스트 지정 

- Prompt (부추기기)를 통해 Add to Home Screen를 하도록 유도한다. 이를 통해 앱의 설치없이 전환율을 높인다. 

- 노드 모듈의 pwa-manifest를 설치해서 사용할 수도 있다. 



실제로 수행하는 순서 참조


-  https://github.com/pwa-workshop/roadshow/blob/master/turn-into-an-installable-webapp.md

- github.com의 개인 프로필로에서 https 를 사용토록 한다.  



<참조> 

https://github.com/pwa-workshop/namp-card

https://www.ampproject.org/ko

posted by Peter Note
2016. 11. 23. 14:23 Angular/Concept

오늘은 오후 일정을 비우고 PlayNode 컨퍼런스를 참석했다. 첫 시간은 늘 사용해 보아도 익숙해 지지 않는 RxJS시간이다. 



- Promise vs Observable 차이점

  + Observable에서 multi value처리 가능. stream이니깐 당연하다. 

  + lazy 기능으로 subscribe 했을 때 수행한다 

  + unsubscribe를 통해 cancelable할 수 있다. 

  + completion 콜백


- Operator

  + 200개 가량의 오퍼레이터 현재 v5.0.0-rc.4

  + create, fromEvent, mergeMap (flatMap)

    > mergeMap: 여러 observable을 하나의 observable로 만드는 오퍼레이터 

  + filtering 

    > takeUtil : 특정 Observable이 발생하면 observable생성을 멈춘다 p61

  + composition

    > combileLatest p63: 다른 observable의 마지막 값들을 합쳐서 obserbale을 만들어 준다 

    > zip : 각 observable에서 발생한 순번의 것들을 서로 묶어준다

  + error

    > retry: error 발생하면 2두번 더 실행한다 

    > retryWhen: 재시작 시점을 지정 가능하다  p72


- 비동기 코드 조합하기 p77

  + Drag & Drop

    > mousedown, mousemove, mouseup이벤트의 조합 p80: mousedown+ mousemove를 flatmap으로 조합하고 takeUtill에서 mouseup이 발생하면 대상 dom을 이동

  + Cache + DB

    > merge를 통해 가장 먼저온것을 take(1)으로 선택한다 

  + AWS Lambda p90

    > bindNodeCallback을 사용하면 node스타일 콜백을 observable로 변환가능하고 이를 다른 observable과 합친다

  + On / offline 브라우져에서 

    > retry 로 에러 발생시 재 시작토록 구현 p108

    > websocket에서 retryWhen으로 on / offline을 체크할 수 있다. 


- 장단점 p113



참조 

  - http://www.slideshare.net/kyungyeolkim39/compose-async-with-rxjs-69421413 













posted by Peter Note
2016. 10. 23. 22:59 Angular/Concept

Angular v2가 정식 릴리즈되었다. Angular v1 은 Two-way data-binding 이라는 독특한 특징으로 인해 많은 사용자 층을 확보했지만 장점 만큼이나 성능상의 단점도 존재했었다. 또한 처음엔 쉬운듯 하면서 좀 더 깊게 들어가볼려고 하면 학습곡선이 갑자기 껑충뛰기도 했다. 가장 많이 사용했던 Directive(지시자)가 대표적이다. 많은 개발자가 만들어 놓은 지시자를 쉽게 가져다 쓸 수는 있지만 직접 만들어 애플리케이션에 접목하려 할 때 첫 문턱을 만나게 된다. 그리고 jQuery사용에 익숙한 개발자에게 Angular v1 시점상의 차이로 Angular v1 방식의 개발패턴을 요구하기도 했다. 관성은 무섭다. 기존에 사용하던 방식을 버리고 Angular v1에 맞춰서 애플리케이션을 만들어 가기란 곤혹스럽다. Angular v2 또한 그런 인식의 전환을 요구할까? 그렇다 그리고 아니다. 






웹 애플리케이션 흐름

웹 애플리케이션 개발을 위해 우리가 사용하는 jQuery같은 라이브러리나 Angular, Backbone같은 프레임워크의 가장 1차적인 목적은 무엇일까? 나는 Data Projection이라 생각한다. 데이터를 화면에 출력하기 위해 DOM을 얼마나 쉽게 조작하고 상호 작용할 수 있느냐가 선택의 기준이라 생각한다. Data Projection을 일관되고 확장가능하고 배포가능하게 하는 방식으로 기술은 발전해 왔고, 현재는 화면에 대한 제어방식이 컴포넌트 기반 방식으로 발전해 오고 있다. 


Data Projection의 역사를 보면 초장기엔 Server Side Rendering 를 사용해 웹 애플리케이션을 개발했다. 예로 JSP, PHP, ASP 같이 서버 미들웨어서 데이터를 조회하고 HTML을 조작하여 결과 HTML을 브라우져에 전송하던 시대이다. 




1세대에는 AJAX가 나오고 다양한 라이브러리나 프레임워크가 나왔다. 이때는 데이터변경에 대한 DOM반영이 서버에서 클라이언트 개발자의 몫으로 넘어오게 되었다. 즉, 직접 DOM 을 얻어와서 특정 위치에 넣어 주어야 했고, DOM에서 발생하는 이벤트를 Listening해서 처리하고 DOM에 반영하는 모든 작업이 웹 개발자가 직접 코딩하던 단계였다. Java의 프레임워크 역사로 보면 Struts 로 비유할 수 있지 않을까 싶다. 




2세대로 넘어오게 되면 Model을 DOM 에 반영하는 방식은 자동화 된다. 여기에 대표적인 프레임워크가 Ember 와 Angular v1 이다. 이때 부터 Single Page Application (SPA) 개발이라는 용어가 나오게 된다. URI 변경에 대한 대응으로 Routing  개념이 나오고, Data Projection후 원하는 일부 DOM을 변경하는 역할이 프레임워크로 넘어갔고, 웹 개발자는 좀 더 애플리케이션 비즈니스 로직에 집중토록 만들었다. Java 프레임워크로 비유하자면 Struts와 Spring Framework 초기버전의 중간 지대 정도 쯤이라 생각한다.  이때부터 Frontend (프론트앤드)라는 직군이 웹 개발자와 분리되기 시작한 지점이라 생각한다. 이에 대한 자세한 설명은 태곤님이 작성한 "[번역] 프론트엔드 개발자는 왜 구하기 어렵나요?"를 참조하자. 2011년을 기점으로 2013년 웹 애플리케이션 프레임워크가 정착을 해가는 시기였고, 현재는 대부분의 스타트업이나 중견기업에서 2세대 웹 애플리케이션 프레임워크를 선택할 경우 프론트엔드 개발자와 백앤드 개발자를 구분하여 팀을 구성하고 있는 추세이다.





3세대는 2세대의 과도기를 거쳐 2세대의 장점을 흡수 하면서 성능상의 이슈를 해결하고, 점점 복잡해 지고있는 웹 애플리케이션을 보다 직관적이고 쉽게 개발할 수 있게 노력하고 있다. 대표적인 프레임워크로는 Facebook의 React와 Google의 Angular v2 (이하 Angular)이다. Angular는 Component기반 개발 방식으로 표준인 Web Components를 지원하며 Typescript를 기본 언어로 채택했다. Typescript는 Type 시스템을 제공하기 때문에 개발단계에서 버그의 가능성을 쉽게 찾을 수 있도록 도와준다. React와 Angular에 대한 장단점은 손창욱님의 "React보다 Angular v2에 더 주목해야 하는 이유"를 참조하자. Java의 Spring Framework이 성숙하면서 Annotation 같은 기능이 추가되듯, Angular v2 프레임워크는 Java의 Spring 프레임워크 최신버전과 비유할 수 있다. 



Angular v1에 대한 개발 및 컨설팅을 3년 가까이 하면서 올해 초 Angular v2를 공부하고 기존 v1 코드를 v2 코드로 전환하면서 코드 베이스는 50%가량 줄었고, 반응속도는 30%가량 개선되었다. 8명 프론트앤드 개발자와 컨버전을 진행하면서 이구동성으로 말하는 것은 "코드가 직관적으로 변했다. 코드량이 현저히 줄었다. Typescript의 타입체킹으로 인해 실수를 최소화 할 수 있었다" 이다. 



Angular v2 왜 배워야 하는가?

Angular를 왜 배워야 하는가? 답하자면 안배워도 된다. 단순 홈페이지나 업무 화면이라면 쉽고 더 빨리 만들 수 있는 워드프레스나 서비스를 이용하거나 DOM 핸들링 라이브러리나 플러그인을 사용해 개발하는 편이 낫다. 하지만 솔루션의 복잡한 요구사항을 지속적으로 반영해야 하고 DOM제어가 복잡해 질 가능성이 높다면 jQuery, React 같은 라이브러리 보다는 Angular 같은 프레임워크를 선택하는 것이 좋다. 그리고 최근에는 ES2015 표준이 확정되었고 최신 브라우져에 대부분 기능이 구현되고 있다. 2세대와 3세대 Data Projection의 가장 큰 개발 방식의 차이는 ES2015의 이해에서부터 시작한다.  즉, ES2015 문법을 잘 알고 사용하면 좀 더 쉽고 간단하게 코드 베이스를 유지하면서 오류를 최소화할 수 있다. 예로 -> 펑션은 this에 대한 오류를 방지하고, Set/Map등 Collection은 Java의 Collection과 유사한다. 



Angular v2 시작하면 초기에 배워야 하는 것들이 갑자기 늘어난다. 이것은 2세대와 3세대의 개발 패턴이 바뀌었음을 시사한다. ES2015 문법은 그대로 TypeScript에 녹아 있고, Type System과 Annotation 기능이 녹아 들어 더욱 편리한 개발을 가능토록 한다. 따라서 ES2015의 Syntax와 개념을 이해해야 한다. 그리고 Typescript를 다시 공부해야 한다. 또한 요즘 인기를 누리고 있는 Reactive Programming을 표방한 대표적인 라이브러리인 RxJS를 Angular가 근간으로 사용하고 있다. 따라서 RxJS 에 대한 개념과 사용법을 익혀야 한다. 그런후 Web Components 란 무엇인지 알아야 하고, Angular 프레임워크의 아키텍쳐를 구성하는 개념인 Change Detection 동작원리, Dependency Management, Modulization 을 알아야 하고, 다음으로 주변의 Tooling System으로 SystemJS (Webpack), Gulp 등을 알아야 한다. 


이렇게 열거해 보니 참으로 배울 것이 많다. 다시 말하지만 안 배워도 된다. 하지만 자신의 근육을 한단계 업그레이드 시키기 위해 고통스러운 인내의 시간은 필요하다. 배워야 하는 기준은 두가지 정도로 이야기 해본다. 


첫째, 서비스 버전업을 위해 요구사항이 계속 증가하고 있는가?

둘째, 더 적고 직관적인 코드 베이스를 유지하면서 성능을 높이고 싶은가?


 

프론트엔드 개발자 직군이 새롭게 자리잡게된  5년기간 동안 많은 부분이 기존의 백앤드 개발 패턴과 유사해 지고 있다. 모듈 의존성 관리, 빌드 시스템, 프레임워크의 발전은 Java개발자들이 초장기 프레임워크 없이 개발하다 Struts를 만났을 때 기쁨에서 Spring을 만나 자유를 얻었지만 여전히 배워야 할 것들은 더욱 증가했음을 알것이다. 그러나 어쩌겠는가 우리는 더 게을러 지고싶다는 욕구가 있고 프레임워크가 그것을 만족시켜줄것이라는 희망을 품고 있는 한 배움과 진보는 계속될 뿐이다. 



참조


posted by Peter Note
2016. 5. 1. 15:34 Angular/Concept

컴포넌트 기반 개발시에 어떤 설계방식으로 해야하는지 알아본다. 새롭게 알게된 GistRun 서비스를 사용해서 테스트해 볼 것이다. 예제의 내용은 최근 Rangle.io의 Angular2 Component 온라인 강좌를 참조한다.





GistRun 사용하기 


github기능중 코드 조각을 관리할 수 있는 서비스가 있다. 한번에 최대 10개까지 파일을 만들 수 있다.  여기를 클릭해 보면 Gist에 입력한 한 주제에 대한 파일을 보여주고 Gist의 내역을 테스트 해 볼 수 있다. 



plunker 또는 jsfiddle의 내용도 불러와서 나의 Gist에 저장을 할 수 있다. 각 서비스의 장점이 있지만 일단 GistRun은 UI가 깔끔하고 속도가 빠르다. 그리고 수정사항에 대한 버전을 관리할 수 있고, Github의 종속된 서비스이므로 소스를 관리한다는 입장에 일관성을 가질 수 있을 것으로 보인다. Gist만으로 모자랐던 것을 GistRun이 생명력을 불어 넣은 격이다. 





Angular2 Component 가이드


Angular2는 컴포넌트로 시작해서 컴포넌트로 끝난다. 컴포넌트기반으로 UI를 설계할 때 자주 나오는 방식이 프리젠테이션과 컨테이너의 분리이다. 


  - Container 컴포넌트

    + 데이터와 비즈니스 로직을 다룬다

    + 컴포넌트 트리(Tree)를 렌더링 한다

    + 재사용하기 어렵다 


  - Presentational 컴포넌트

    + 상태를 포함하지 않는다. 따라서 컴포넌트 속성에 대한 수순(pure) 펑션으로 구성한다

    + 표현만을 담당한다

    + 재사용이 가능하다 


Thinking in React의 내용은 Angular2의 컴포넌트 개발 방식과 거의 일치한다. Container 컴포넌트는 하위 컴포넌트의 이벤트에 대해 XHR 요청을 수행하는 Angular2 Service를 Inject해서 서버로 부터 데이터를 요청하고, Component Tree를 통해 하위로 데이터를 내려 보낼 수 있다. 



오렌지색 부분은 전체 애플리케이션을 감싸는 Container이고 초록색은 테이블의 Row를 표현한다. 프리젠테이션 부분은 상단의 Search Input, 하단의 Row들이 된다. Angular2에서 검색을 위한 Input과 Button, Title 애플리케이션을 다음과 같이 진행한다. 



Seach The Site 레이블을 표현하는 컴포넌트를 개발한다.  @은 Typescript의 Decorator를 이용해 Angular2에 구현된 것으로 Parent -> Child 방향으로 DOM Properties를 통해 값을 받고자 할 때 사용한다. 즉, RangleLabel 컴포넌트를 사용하는 Parent 컴포넌트가 name 속성에 [] 을 이용해 값을 설정한다.  

  - 컴포넌트를 사용할 때 [name]="<expression>"  [name] 부분을 target이라 하고 <expression> 부분을 source라고 한다. 

  - []을 사용할 때 source는 항상 template expression 즉, 식이어야 한다. (statement "문"은 이벤트에서 사용함) 

  - target에 []가 있으면 source는 항상 expression으로 수행된다.

import { Component, Input } from 'angular2/core';


@Component({

  selector: 'rangle-label',

  template: '<label class="rangle-label">{{ name }}</label>',

  styles: [ `

    .rangle-label {

      color: #422D3F;

      display: block;

      font-weight: bold;

      letter-spacing: .2em;

      text-transform: uppercase;

    }

  `]

})

export class RangleLabel {

  @Input() private name: string;

}


예) 부모 컨테이너에서 사용할 때: 부모 컨테이너 컴포넌트의 name 속성을 자식 컴포넌트인 rangle-label에 내려보낸다.  

     <rangle-label [name]="name"></rangle-label>


다음으로 Input 컴포넌트를 만든다. value 속성에 대해 ngModel처럼 양방향 바인딩을 주기 위해서는 컨벤션(Convention)처럼 Input은 value이고, Output은 valueChange이어야 한다. 

  - [()] 표식은 banana in the box 표현으로 양방향 데이터 바인딩이다. 

  - [] 은 Input으로 parent -> child로 속성값을 내려 보낼 수 있다. (top down)

  - () 은 Output으로 child -> parent로 값을 올려 보낼 수 있다. (bubble up)

import { Component, Input, Output, EventEmitter } from 'angular2/core';


@Component({

  selector: 'rangle-text-field',

  template: `

    <input class="rangle-text-field"

      [placeholder]="placeholder"

      #field (keyup)="handleKeyup(field.value)">

  `,

  styles: [ `

    .rangle-text-field {

      border-radius: 3px;

      border: 1px solid #ccc;

      box-sizing: border-box;

      display: inline-block;

      font-size: inherit;

      font-weight: inherit;

      height: 2.5rem;

      padding: .5rem;

    }

  `]

})

export class RangleTextField {

  @Input() private placeholder: string;

  @Input() private value: String;

  @Output() private valueChange = new EventEmitter<String>();


  handleKeyup(fieldValue: string): void {

    this.valueChange.emit(fieldValue);

  }

}


예) 부모 컨테이너에서 사용할 때 searchTerm은 부모 컨테이너 컴포넌트의 속성이다. value를 내려보내기도 하고, 이벤트를 받기도 한다. 

      <rangle-text-field 

        placeholder="Enter Keyword"

        [(value)]="searchTerm">

      </rangle-text-field>


버튼을 만들어 보자. 템플릿의 target=source 에서 target이 ()로 감싸지면 이벤트를 나타내고 source는 statement "문"을 쓴다. expression과 statement에 대한 이해는 Angular.io의 Template Syntax 설명을 참조한다.  여기서는 클릭이 되면 바로 부모의 handleSearch가 호출된다. 

import { Component, Input, Output, EventEmitter } from 'angular2/core'


@Component({

  selector: 'rangle-button',

  template: `

    <button

      [ngClass]="dynamicStyles()"

      class="rangle-button"

      (click)="onClick.emit()">

      {{ name }}

    </button>

  `,

  styles: [ `

    :host {

      display: flex;

      align-items: stretch;

    }

    .rangle-button {

      border: none;

      border-radius: 3px;

      color: white;

      font-weight: bold;

      letter-spacing: .2em;

      margin-left: 0.5rem;

      padding: 0.5rem;

      text-transform: uppercase;

    }

    .primary {

      background: #E5373A;

    }

    .normal {

      background: #422D3F;

    }

  `]

})

export class RangleButton {

  @Input() name: string;

  @Input() isPrimary: boolean;

  @Output() onClick = new EventEmitter();


  dynamicStyles() {

    return this.isPrimary ? 'primary' : 'normal';

  }

}


예) 부모 컨테이너 컴포넌트에서 사용할 때, handleSearch는 부모 컨테이너 컴포넌트의 메소드이다. 

      <rangle-button name="Search"

           [isPrimary]="true"

           (click)="handleSearch(searchTerm)">

      </rangle-button>


다음으로 Input 과 Button 컴포넌트를 재사용할 수 있는 컨테이너를 만들어 본다. Label만을 포함하고 있고 언제는 원하는 형태로 Input과 Button을 템플릿상에 포함 시킬 수 있다. 이를 위해 ng-content 태그를 사용한다. Angular v1의 transclude와 유사하다. 하지만 큰 차이점은 역시 Angular2의 컴포넌트 아키텍쳐는 Comopnent Tree이기 때문에 Change Detection(CD)는 항시 가장 위에서 아래로 점검되고 렌더링된다. Angular v1은 parent - child 관계가 있다하더라도 Parent가 먼저 렌더링 될지 Child가 먼저될지 보장을 못했다. (물론 Directive에 priority 옵션이 있지만 적용하기에 따라 순서가 정확한지 알 수 없었다.) 즉, Angular2에서 ng-content 태그를 사용해도 렌더링에 예측이 가능하다. 





import { Component, Input } from 'angular2/core';

import { RangleLabel } from './rangle-label';


@Component({

  selector: 'rangle-bar',

  directives: [ RangleLabel ],

  template: `

    <rangle-label [name]="name">

    </rangle-label>

    <div class="row">

      <ng-content></ng-content>

    </div>

  `,

  styles: [`

    :host {

      background: #F8F8F8;

      border: solid #ccc 1px;

      display: block;

      padding: 1rem;

      margin: 1rem;

    }

    .row {

      display: flex;

      margin-top: 0.5rem;

    }

  `]

})

export class RangleBar {

  @Input() name: string;

}


예) 부모 컨테이너 컴포넌트 사용 때 

    input과 button이 있는 경우 
    <rangle-bar name="Search the site">
        <rangle-text-field placeholder="Enter Keyword"
             [(value)]="searchTerm">
        </rangle-text-field>
        <rangle-button name="Search"
            [isPrimary]="true"
            (click)="handleSearch(searchTerm)">
        </rangle-button>
    </rangle-bar>

    또는 
   
   button만 있는 경우 
   <rangle-bar name="Other Stuff">
        <rangle-button name="Button 1"
            [isPrimary]="true">
        </rangle-button>
        <rangle-button name="Button 2"></rangle-button>
        <rangle-button name="Button 3"></rangle-button>
    </rangle-bar>


당연히 <ng-content>에는 input, button 컴포넌트외에 다양한 컴포넌트가 올 수 있다. 결과는 다음과 같다. 



실데이터를 요청하는 코드는 RangleBar 에서 XHR에 대한 요청을 하고 결과를 전달하는 과정을 거치면 될 된다. Redux를 사용한다면 Action Creator를 수행한다. 애플리케이션 소스를 보자. App 컴포넌트는 가장 최상위 애플리케이션으로 Container 컴포넌트와 Presentational 컴포넌트를 사용해 화면 레이아웃을 만들고 있다. 

import { ViewEncapsulation, Component } from 'angular2/core';

import { RangleBar }  from './rangle-bar';

import { RangleButton } from './rangle-button';

import { RangleTextField } from './rangle-text-field';


@Component({

  selector: 'app',

  directives: [ RangleBar, RangleTextField, RangleButton ],

  template: `

    <rangle-bar name="Search the site">

      <rangle-text-field placeholder="Enter Keyword"

        [(value)]="searchTerm">

      </rangle-text-field>

      <rangle-button name="Search"

        [isPrimary]="true"

        (click)="handleSearch(searchTerm)">

      </rangle-button>

    </rangle-bar>


    <rangle-bar name="Other Stuff">

      <rangle-button name="Button 1"

        [isPrimary]="true">

      </rangle-button>

      <rangle-button name="Button 2"></rangle-button>

      <rangle-button name="Button 3"></rangle-button>

    </rangle-bar>

    <p> inside viewCapsulation </p>

  `,

  styles: [ 'p { background: red; border: dashed yellow 2px; }' ],

  encapsulation: ViewEncapsulation.Native

})

export class App {

  private searchTerm: string;


  handleSearch(searchTerm: string): void {

    alert(`You searched for '${searchTerm}'`);

  }

}


GistRun의 소스와 Rangle.io 동영상을 참조하자.

  - Container & Presentational Component 개발 방식에 대한 소개 

  - Component LifeCycle에 대한 소개: ng-content를 특별히 View Content라 하고, 그외 템플릿에 직접 설정된 컴포넌트를 View Child라 한다. Life Cycle에서는 둘의 시점이 나뉘어져 있다. View Content가 먼저 호출된다.  

  - ElementRef 주입받아 컴포넌트의 DOM을 사용할 수 있다.





<참조>

  

  - Angular2 Component Basic (pptsrc)- Rangle.io

  - Thinking in React

  - Presentational and Container Component - Dan Abramov

  - Rangle.io's Angular2 GitBook 

  - Change Detection Reinvented - Victor Savkin's

posted by Peter Note
2016. 4. 16. 22:27 Angular/Concept

ExtJSAngular2의 기술적 차이점에 대한 질문을 받게되어 어떻게 대답을 하면 될까? 를 고민하다 정리를 해본다. ExtJS 는 일부 기능은 무료 오픈소스이지만 전체 기능을 사용하기 위해서는 유료이다. 현재 v6 까지 나와있다. 또한 최신버전은 Sencha라는 이름으로 통합되어 나오고, 현재 ExtJS v6 버전을 다운로드 받아 사용할 수도 있다. 따라서 ExtJS나 Sencha 에서 이야기하는 장점이라 말하는 부분을 토대로 Angular v2와 비교해 보기로 한다. 참조는 Top 8 Reasons Why Enterprises Prefer Sencha ExtJS over Angular 문서를 보고 ExtJS 쪽은 영문 요약을 간단히 했고, Angular 쪽은 영어로 작성해 본다.


This document is to write differences between ExtJS v6  framework and Angular v2 framework. I reference the ExtJS site (Top 8 Reasons Why Enterprises Prefer Sencha ExtJS over Angular) and I write my opinion about Angular.

*caution: AngularJS is Angular v1, Angular v2 or Angular is Angular v2. ExtJS is ExtJS v6.





Reason #1 Components, Components, Components


 - ExtJS

   + ExtJS contains components that are optimized for both desktop and mobile devices.

   + customize the theme. mobile apps can be themed to achieve an iOS, Android,  BlackBerry the look and feel.

   + Angular does not come with a component library.


 - Angular v2

  + Angular can easily make components that are usable anytime. If we want to use components i.e grids and charts, we can use the components that have already been made by many companies and open source developers.

  + Developer can build an application with components  and can also use the current web technology such as Web Components together.

  + Angular component architecture is a component-tree for improving performance to render web page views. This architecture is implemented in the ReactJS Framework from Facebook as well.

  + Angular can easily merge with the more popular CSS Framework such as Twitter Bootstrap, Material Design, Semantic UI and Foundation which can be customized to match with any company brand. One of these can be chosen for any brand style.

  + Angular is a platform for the web and mobile. Ionic v2 is a Hybrid mobile app framework. It is based on Angular v2 and has tools that can rapidly develop an app. So, the hybrid app can be developed using Angular in a friendly code style. The hybrid app gives customers a better UX(User eXperience) than mobile browsing.

  + Ionic v2 using Angular has lots of mobile components to support the look and feel for different mobile platforms such as iOS, Android and BlackBerry. We can also customize these styles.





Reason #2 ExtJS Has Ben Battle-Tested Since 2007


 - ExtJS

   + It is launched in 2007.

   + It has long-term success.

   + migration v5 to v6 smoothly


 - Angular v2

   + Angular v1 was launched on October 20, 2010 by Google.

   + Angular v1 also has had long-term success i.e NBC, Intel, ABC News and approximately 8,400 other sites out of 1 million tested in July 2015.

   + Angular v2 already has an upgrade tool to migrate v1 to v2.






Reason #3 A Robust Framework for Building Apps vs Building One's Own Framework


 - ExtJS

   + ExtJS has MVC(Model View Controller)/MVVM (Model View ViewModel) architecture.

   + ExtJS comes with an extensive component library.


 - Angular v2

   + Angular has MVC/MVVM as well.

   + Angular is easily customized for any application's architecture. It can be applied to the one-way data flow architecture like Flux from Facebook in order to easily manage any application's state.

   + Angular is an open source framework so, many developers and companies open their components like grids or charts that have been used within their applications. If there are  components with any issues, many contributors can solve the problems in the open system and components can easily be downloaded from consistency tools such as NPM (Node Package Manager) or Bower.

   + Angular v2 is a new platform for the modern web environment including Web Components, Reactive Programming and Immutable state to solve some issues which Angular v1 experienced. Applications can be developed to be more stable with better performance using these concepts.





Reason #4 Clearly-Defined Legacy Browser Compatibility By Default


 - ExtJS

   + support Internet Explorer (IE) 8


 - Angular v2

   + Angular can support IE 9 (link).

   + If IE 8 is to be supported, poly-fill can be used to support the lower version but MicroSoft has already stopped updating IE 8 securities. So, this version is not recommended because of the danger of hacking.





Reason #5 Integrated Tools Created With a Clear Vision and Purpose


 - ExtJS

   + Senchar has several tools including Senchar Cmd, IDE Plugins, and Senchar Inspector that developers can use to speed up their application development.


 - Angular v2

   + Angular uses the Gulp or Grunt tasker that can extend plugins which are required.

   + There are IDE Plugins (WebStorm, Atom, Sublime Text, MS Code) for Angular  and developers can check out an application's performance with Angular Inspector under the  chrome extension as well.

   + Angular uses the NPM (Node Package Manager) or Bower that all front-end developers use to manage the packages and components for any application.

   + Angular is oriented to use common tooling set in current front-end environments. So, the developer can use these tools in a friendlier way.





Reason #6 No Need to Learn TypeScript or other tools and component libraries with ExtJS6


 - ExtJS

   + ExtJS 6 is a JavaScript Framework.

   + Developer doesn't need to have experience with object-oriented programming (OOP)


 - Angular v2

   + Javascript before ECMAScript 5 doesn't support the OOP but ECMAScript 6 (ES2015) can support it and the developer can simply establish more complex applications with the OOP methodology.

   + TypeScript is a superset of ES2015 and has more features simply to code any sophisticated application such as Decorator. Typescript also includes a feature that transpiles code to ES5 or ES3 code, so it can be released into the production environment without worry.

   + TypeScript can support the Static Type Checking System during the development period. TypeScript can automatically suggest some problems in code so, the developer can recover the mistakes which occured in run-time.

   + If the developer has experience with Java or OOP, they can easily learn TypeScript. It is not a weakness, but rather a strength.





Reason #7 Excellent Design Tools


 - ExtJS

   + Sencha has an excellent set of design tools.

   + Sencha Architect is a perfect tool to create clickable prototypes.

   + ExtJS Stencils can be used to create wireframes and mockups that correctly reflect the look and feel of components


 - Angular v2

   + Angular doesn't have a design tool because it is optional. If it is needed, other professional design or mockup tools can be used .

   + Ionic v2 based on Angular v2 also has  a design tool such as Ionic Creator for mobile and has a testable native app in several mobile platforms (iOS, Android) such as Ionic Viewer.

   + The Angular team has been working closely together with the Ionic team.





Reason #8 Awesome Support and Training Options From the Creators of the Framework


 - ExtJS

   + Sencha has excellent support and training teams.

   + Sencha has a professional services team that can assist with a variety of enterprise development needs.


 - Angular v2

   + There are several professional Angular training companies such as Rangle.io and Egghead.io.

   + Global conferences are always held several times annually such as NG-Conf.

   + If developers want to learn Angular, they can easily get a huge range of materials like books, videos and online courses.

   + The Angular team at Google consists of 20 full-time developers and there are over 221 contributors for Angular v2.

   + It is not a level playing field when comparing ExtJS with Angular in my opinion.



ExtJS is a good framework and has a full set of tools for web development but it can restrict customization needs, because developers can just play around with ExtJS's environment and architecture. The current web trend - software and hardware - has been changing quickly so if some applications need to be adapted into the current environment, Angular v2 would be an excellent choice. Angular v2 can provide any company lots of opportunities to improve the UX and performance for applications but more time needs to be invested learning this framework. 


기회가 된다면 다음부터는 영어 블로그도 써볼 생각이다. 그리고 영어 Angular 관련 책을 출판해 보고 싶다. O'Reilly 또는 Packt Publishing 같은 곳과 연이 된다면... 그전에 열심히 영문 블로깅하면서 영작 실력을 키워야겠지만... 비오는 토요일 밤에...




Reference

  - Top 8 Reasons Why Enterprises Prefer Sencha Ext JS over Angular

posted by Peter Note
2016. 4. 8. 18:54 Angular/Concept

Angular2 또는 최신 라이브러리를 읽기 위해서는 ES2015 (ES6)에 대한 기본적인 이해가 필요하다. 모질라의 Depth in ES6 번역글과 S65 페북모임에서 얻은 지식을 한 페이지로 정리해 본다. 






let 과 const


기본 var는 함수에 대한 scope(스코프)만을 갖는다. for, {} 블록에 대한 스코프가 없다. var의 대체제가 let 이다. 

  - let은 블럭을 기준으로 스코프를 결정한다. block-scoped

  - 글로벌 let은 없다. 즉 window.xxx 접근이 안된다. 어디간의 블럭안의 스코프에 속한다. 

  - for (let x...) 루프구문에서 x 변수를 새로 바인딩 한다. 

  - let 변수를 선언 전에 참조하는 것은 에러이다. 

  - let, var 충돌시에는 ES2015 모듈패턴을 사용해서 let으로 전환한다. 


const는 최초 값을 할당한 후 재 할당 할 수 없다. 단, 객체의 속성은 가능하다. 변수 중에 불변의 값을 갖는 것은 모두 const로 할당한다. 재 할당이 안된다는 것 외에는 let과 완전히 동일하므로 애플리케이션 상태 관리의 복잡도를 단순화 시켜줄 수 있다. 




class


이제는 OOP(Object Oriented Programming)를 위한 접근이 훨씬 쉬워졌다. Java의 OOP에 익숙한 개발자라면 import, class, super, extends, implements(TypeScript 지원)등을 통해 이전 Prototypal Inheritance의 이해 없이도 쉽게 JavaScript를 이용한 OOP가 가능해 진것이다

class Parent {

   contructor(params) { ... }

   static XXX() { ... }

   YYY() { ... }

   get ZZZ() { ... }

   set ZZZ(value) { ... }

}




Arrow Function


event 또는 XHR 콜백 펑션을 등록할 때 간혹 내부에 this를 사용하면 Global scope를 참조하게 된다. 이때 var that = this; 한 후 that을 넘겨 사용하기도 하는데 이제는 더 이상 그럴 필요가 없다. 자신 Execution Context를 만들지 않고 (function 보다 가볍다) 화살표 함수를 감싸는 외부 스코프의 this 값을 바로 쓸 수 있는 방법이 => 화살표 함수이다. 

$('.button').click(function (event) {

  ...

});


변경

$('.button').click(event => {

  ...

});


한 줄일 경우는 {}을 사용하지 않고 자동 return 구문이 된다. 만일 여러 줄일 경우는 {} 으로 감싼다. 단, 한 줄로 비어있는 객체를 return하고 싶다면 어떻게 해야할까?

arrs.map( item => ({}) ); // 성공

arrs.map( item => {} ); // bug




iterable 과 for~of 구문


배열을 순회(loop)하기 위한 방법으로 ES5의 myArray.forEach(function (value) { ....});를 사용한다. 기존 for ~ in 루프는 확장 속성들도 순회하기 때문에 성능상 이점이 없다. 배열에 만일 myArray.name = 'dowon'을 넣으면 name도 순회하고 prototype chain도 순회한다. 또는 가끔 무작위 순서로 순회하기도 한다. 쇗!! 이에 대한 해결로 for ~ of가 나왔다. 

for (var value of myArray) {

  console.log(value);  // 값이다. for ~ in 처럼 속성의 key가 아니다

}


Array, Map, Set은 순회를 위한 iterator 메소드를 제공한다. 사용자가 원하는 객체에 iterator 객체를 제공할 수 있다. 

  - 어떤 객체든 myObject[Symbol.iterator]() 메소드를 추가하면 자바스크립트에서 해당 객체를 순회할 수 있다. 

  - Duck Typing의 예로 iterator가 있으므로 해당 객체도 순회가 가능하다는 방식이다. 

  - myObject['iterator'] = function () {...} 라고 했고 만일 iterator() 가 이미 있다면 문제가 될 것이다. 이를 위해 제 7원소 Symbol을 사용해 어떤 코드의 key와도 충돌하지 않게 만든다. 

  - [Symbol.iterator]() 메소드를 제공하는 겍체를 이터러블 객체 (iterable object)라고 한다. 

Iterable is a simple representation of a series of elements that can be iterated over. current state만 있고, Iterator제공하는 메소드 하나를 가진다. 

Iterator is the object with iteration state. hasNext(), next()를 통해 다음 엘러먼트로 이동한다. 


iterator는 next를 제공해야 하므로 Symbol을 이용할 경우 다음과 같이 한다. value를 계속 0 만 주무로 무한루프이다. 

var myIterator = {

  [Symbol.iterator]: function() {

    return this;

  },

  next: function() {

    return { done: false, value: 0 } 

  }

}



형식

for ( VAR of ITERALBE ) {

  STATEMENT

}

동등한 코드 

var $iterator = ITERABLE[Symbol.iterator]();

var $result = $iterator.next();

while (!$result.done) {

  VAR = $result.value;

  STATEMENT

  $result = $iterator.next();

}




Collection 


자바스크립트의 Object는 key-value 쌍의 컬렉션이다. 즉 속성을 추가하고 값을 할당할 수 있고 이런 속성의 집합을 객체라 한다. 일반 객체로 해결할 수 없는 자료구조에서 Map, Set을 도입한다. 

  - 속성 key를 객체로 사용하고 싶을 경우 (객체는 key는 문자열만 가능, 단 ES2015에는 Symbol이라는 새로운 타입이 존재한다)

  - 일반 객체는 iterable 하지 않기에 for~of 구문이나, ... 구문을 사용할 수 없다. 


Set은 중복을 제거할 때 사용한다. Value 를 추가하고 삭제하며 동일 Value는 포함 될 수 없기 때문이다. 

  - new Set, new Set(Iterable) : 새로운 set 만들기

  - size, has, add, delete, forEach, clear

  - 다양한 이터레이터를 리턴: keys, values, entries (Map과의 호환성을 제공)

  - set[Symbol.iterator]() 구문은 set안의 값들을 순회할 수 있는 새로운 이터레이터를 리턴한다. 

var uniqueWords = new Set(words);

for (var word of uniqueWords) {

  console.log(word);

}


Map은 key-value 쌍으로 이뤄진다. 순회시 분해(destructuring)을 사용할 수 있다. 

for (var [key, value] of addressMap) {

  console.log(key, ': ', value);


Set, Map의 대용이 없어지지않고 남아있으면 Garbage Collector가 메모리를 회수 할 수 없다. 이애 해결을 위해 WeakSet, WeakMap을 사용한다. 




Symbol


심볼은 ES2015의 7번째 타입이다. 프로그램에서 이름 충돌을 피하고자 객체 속성 키(symbol-keyed property)를 사용하고 싶을 경우 사용한다. 

  - Object.property 처럼 dot(.)로 접근할 수 없고 Object[] 형식으로 접근할 수 있다. 

  - if( MY_SYMBOL in element) 처럼 속성을 참조하거나, delete element[MY_SYMBOL] 처럼 속성을 제거할 수 있다. 

  - MY_SYMBOL은 실행 스코프안에서만 모든 행위가 가능해서 충돌을 걱정할 필요없이 캡슐화를 할 수 있다. 

var MY_SYMBOL = Symbol();

var myObj = {};

myObj[MY_SYMBOL] = "dowon";


사용방법

  - Symbol() 호출: 일반적인 사용 형태, Symbol('name') 과 같이 파라미터를 주는 것은 디버깅을 위한 용도이다. 

  - Symbol.for(string): 심볼을 공유하고 싶을 경우 사용

  - Symbol.iterator: 특정 객체에 대해 Duck Typing으로 iterator를 만들고 싶을 경우 사용 

  - core.js 폴리필을 첨부해야 사용이 가능하다


기본 6가지 타입

  - Undefined

  - Null

  - Boolean

  - Number

  - String

  - Object 




Generator, 2


자바스크립트의 co-routine 이다. 함수가 끝나기전에 자신의 스코프 밖으로 나올 수 없다. 그러나 제너레이터 함수(generator-function)를 만들면 가능해 진다.

  - 제너레이터 함수는 function* 키워드로 시작한다. 

  - 제너레이터 함수안에는 yield 구문이 존재한다. 함수의 return은 한번 실행되지만 yield는 여러번 수행 가능하다. yield는 제너레이터의 실행을 멈췄다가 다음에 다시 시작할 수 있게 만든다. 

function* mygen(name) {

  yield 'hi ' + name;

  yield 'Have a great day';

}


> var iter = myget('dowon');

 [object Generator]

> iter.next();

  'hi dowon'

> iter.next();

  'Have a great day'


제너레이터 함수를 호출하면 제너레이터 객체(generator object)를 전달 받는다. yield첫번째에  실행이 멈춘 상태의 객체이다. .next()를 호출하면 다음 yield까지만 수행한다. yield 구문이 실핼될 때, 제너레이터의 스택 프레임(stack frame: 로컬 변수, 인자, 임시 값, 제너레이터 코드의 실행 위치)은 스택에서 제거된다. 


제너레이터를 통해 이터레이터를 만들 수 있다. 

> Symbol을 통해 만들기: 실행

class RangeIterator {

  constructor(start, stop) {

    this.value = start;

    this.stop = stop;

  }


  [Symbol.iterator]() { return this; }


  next() {

    var value = this.value;

    if (value < this.stop) {

      this.value++;

      return {done: false, value: value};

    } else {

      return {done: true, value: undefined};

    }

  }

}


// 'start'에서 'stop'까지 더해나가는 새로운 이터레이터를 리턴합니다.

function range(start, stop) {

  return new RangeIterator(start, stop);

}


// 수행 

for ( let value of range(0, 5)) {

 console.log(value);

}


> Generator를 통해 만들기: 실행

 - Symbol과 동일한 역할을 하는 이유는 Generator는 .next() 코드와 [Symbol.iterator]() 코드를 내장하고 있기 때문이다. 그냥 루프 처리만 작성하면 된다. 

function* range(start, stop) {

  for (let i=start; i < stop; i++) {

    yield i;

  }

}


// 수행 

for ( let value of range(0, 5)) {

 console.log(value);

}


제너레이터는 객체를 이터러블하게 만들때, 엄청나게 큰 결과를 처리, 복잡한 루프 구문을 리팩토링, 이터러블을 다루는 도구등으로 사용한다. (이부분은 경험이 없어서 이해가 힘들다. 다음기회로..) 제너레이터의 동작은 동기적으로 싱글-쓰레드 환경에서 실행된다. yield에서 멈추고 .next()에서 수행되는 된다. 만일 for ~ of 구문의 경우 iterator 스팩에 따라 수행이 된다.  




Proxy


자바스크립트 스팩 레벨에서 특정 객체에 대한 hooking을 가능케 한다. 

  - 첫번째 인자는 후킹할 객체이다. 

  - 두번째 인자는 후킹을 위한 설정이다. 보통 스팩에서 정의한 14가지 내부 메소드(internal method)를 재정의한다. 

var obj = new Proxy(<후킹할 객체>, <핸들러>);


내부 메소드는 [[ ]] 로 감싼다. 내부 메소드는 가려져 있기때문에 개발자가 호출할 수 없다. 

  - 속성 값 가져오기: obj.[[Get]](key, receiver) 는 obj.prop 또는 obj[key] 사용시 호출된다. 여기서 receiver는 속성 조회를 처음 시작했던 대상 객체이다. 

  - 속성 값 할당: obj.[[Set]](key, value, receiver) 는 obj.prop = value 또는 obj[key] = value 사용시 호출된다.  

    예) obj.prop += 2 같은 할당문의 경우 [[Get]] 호출 후 [[Set]]을 호출한다. (++, -- 도 동일)

  - obj.[[HasProperty]](key): 속성이 존재하는지 테스트 

  - obj.[[GetPrototypeOf]](): obj의 프로토타입을 반환. obj.__proto__ 또는 Object.getPrototypeOf(obj) 사용시 호출된다. 

  - functionObj.[[Call]](thisValue, arguments): functionObj() 또는 x.method() 사용시 호출된다. 

  - constructorObj.[[Construct]](arguments, newTarget): 생성자를 실행. new Date(2017,1,1) 사용시 호출된다.  


핸들러 만들기

  - set시에 무조건 Error 발생시킴

  - get시에 Reflect를 통해 기본 동작을 수행하고 추가 작업을 수행할 수 있음

var target = {};

var handler = {

  set: function (target, key, value, receiver) {

    throw new Error('not settting value');

  }

  get: function (target, key, receiver) {

    // default action 

    var result = Reflect.get(target, key, receiver);

    // custom action 

  }

}

var proxy = new Proxy(target, handler); 


> proxy.name = 'hi';

  Error: not settting value


프락시를 이용하면 어떤 객체에 대한 접근을 관찰하거나 로그를 남길 때 유용하다. 




디스트럭쳐링(Destructuring)


배열 또는 객체의 속성값을 일괄처리로 변수에 할당 받을 수 있는 방법이다. 객체나 배열을 XHR을 통해 JSON형태의 포멧으로 받을 경우 해체를 통해 값을 간편하게 변수로 받아 사용할 수 있다. 이는 코드의 가독성과 간결성을 유지해 줄 수 있다. 해체시 Default Value를 할당 할 수 있다. 배열의 경우는 인덱스 순서에 따라 하나씩 변수에 값을 할당 받지 않고 한번에 변수에 값을 할당 받는다. 

var first = myArray[0];

var second = myArray[1];


이것은 하기와 동일하다


let [first, second] = myArray;


또는 다차원 배열의 해체도 가능하다 


let [foo, [[bar], baz]] = [1, [[2], 3]]; 


또는 선택해서 받을 수 있다. 


let [ , , third] = [1, 2, 3];


또는 Rest 패턴을 통해 배열의 요소를 다른 배열로 받을 수도 있다.


let [first, ...second] = [1, 2, 3, 4, 5];


또는 함수에서 배열 리턴값을 해체한다 


function myArrayFunc() {

  return [1, 2, 3, 4];

}

let [a, b, c, d] = myArrayFunc();


객체를 해체할 수 있다. 객체 해체시에는 반드시 let, const 또는 var를 써야한다. 객체의 경우 이름이 같으면 변수 alias를 사용하지 않아도 된다. 

let myObj = { name: 'dowon' };


// myObj.name을 받아 myName 이라는 변수에 할당한다.

let { name: myName } = myObj;


좀 더 복잡한 객체의 해체도 가능하다, second = 'kangnam'이라는 default value를 할당했다. 


let complicateObj = {

  arrProps: [

    'dowon',

    { address: 'seoul'}

  ]

}

let { arrProps: [first, { second = 'kangnam' }] } = complicateObj;


이터레이션 프로토콜과 함께 사용할 수 있다


for (let [key, value] of map) {

   console.log(key, value);

}


또는 함수에서 객체 리턴값을 해체한다


function myObjFunc() {

  return {

    name: 'dowon',

    address: 'seoul'

  }

}

let { name, address } = myObjFunc();


또는 continuation passing style 사용도 가능하다. k 라는 callback에 값 1, 2를 주면 foo = 1, bar = 2 각 해체되어 할당된다. 


function returnMultipleValue(k) {

  k(1, 2);

}

returnMultipleValue(( foo, bar ) => ..... ); 


또는 ES2015의 import 구문에서 사용한다


import { Component } from 'angular2/core'; 


함수의 파라미터가 객체일때 파라미터를 해체하는 구문을 사용할 수 있다. 기존에는 파라미터 객체를 받아서 함수 내부에서 다시 변수에 할당하는 방식이 있을 경우 파로 파라미터 객체 해체를 통해 코드 간결성을 유지할 수 있다.

function myFn({ a, b, c, d }




Rest Parameter 와 Default Parameter


함수 파라미터의 해체(Destructuring)외에 함수 문법의 표현을 간결하게 해주는 두가지가 Rest/Default Parameter 이다. 함수의 파라미터를 가져올 때 기존엔 parameters를 통해 접근을 했다면 ES2015에서는 Rest Parameter로 접근한다. Rest Parameter는 함수의 마지막에 정의한다. 

function myFunc(first, ...myParams) {

  for (let param of myParams) {

    console.log(param);

  }

}


myFunc('hi', 'dowon', 'great', 'day');


... 점(Dot) 3개이후 파라미터 명칭을 설정하면 나머지 파라미터가 배열 객체로 넘어온다. 


함수의 파라미터 값이 undefined인지 검증하는 코드를 함수안에 넣는데 undefined일 경우 기본 값을 할당할 수 있다. 

function myFunc( first = 'dowon', second = 'hi') {

  console.log(first, second);

}


myFunc('Yun');


arguments 객체를 코드를 읽기 어렵게 만들고 JavaScript VM의 성능 최적화하는 것도 어렵게 만든다고 하니 앞으로는 Rest Parameter를 사용하자.




템플릿 문자열 (Template String)


백틱(Backtick) ` ` 을 이용해 문자열을 만드는 방법이 새롭게 생겼다. Angular2에서 template 정의시 많이 사용한다. 이에 더불어 문자 맵핑 채워넣기 (string interpolation) 을 백틱안에서 ${ } 를 사용해 넣을 수 있다. 

  - cross-iste scripting에 대한 공격을 피하려면 기존 처럼 신뢰할 수 없는 데이터에 대한 처리를 직접해주어야 한다. 

  - 다국어 처리도 직접한다

  - 루프문이 없다. 

let name = 'dowon';

let myStr = `Hi ${name}. Have a great day!`;


태그된 템플릿 (Tagged Template)은 백틱앞에 붙이는 사용자 정의 함수라 할 수 있다. 즉, 이 함수를 통해 템플릿 문자열을 커스터 마이징 할 수 있다. 태그 함수의 인자에는 어떤 것이 와도 되고, 리턴 값도 마찬가지이다. 

function SaferHTML(templateData) {

  var s = templateData[0];

  for (var i = 1; i < arguments.length; i++) {

    var arg = String(arguments[i]);


    // 대입문의 특수 문자들을 이스케이프시켜 표현합니다.

    s += arg.replace(/&/g, "&amp;")

            .replace(/</g, "&lt;")

            .replace(/>/g, "&gt;");


    // 템플릿의 특수 문자들은 이스케이프시키지 않습니다.

    s += templateData[i];

  }

  return s;

}


SaferHTML`<p>${name} hi</p>` 처럼 말이다. 




참조


  - Depth in ES6 번역문서

  - iterator, iterable 차이



posted by Peter Note
2016. 2. 19. 12:10 Angular/Concept

모듈단위의 파일을 만들어 모듈간에 모듈을 로딩해서 사용하는 방법을 제시하는 것이 Module Loader의 역할이고, 만들어진 모듈을 어떻게 묶어 사용할지 제시하는 것이 Module Bundler의 역할이다. 이번 글에서는 Module Bundler에 대해 알아보자. 



            





파일 번들링의 일반적인 방식 


index.html 에 <script> 태그를 이용해 첫번째는 개발자가 직접 넣는 방법, 두번째는 Grunt 또는 Gulp의 프론트앤드 툴의 도움을 받아 자동으로 넣는 방법이 있다. 하지만 응답성능에 민감한 애플리케이션에는 초기 다량의 모듈 파일 전송이라는 네트워크 성능이슈를 야기한다. 따라서 운영시에는 좀 더 컴팩하게 파일을 묶을 필요가 있다. 

  - 파일을 합치고(Concatenate)

  - 압축(Minify)하는 과정을 거친다. 


통합하고 압축하는 역할에 대한 플러그인이 Grunt/Gulp에 모두 존재한다. 하지만 CommonJS 또는 AMD나 ES2015 네이티브 로더를 사용할 때는 브라우져에 진화적인 코드로 변환해야 한다. 이때 사용하는 것이 Browserify, Webpack, JSPM 와 같은 모듈 번들러이다. 




Browserify


NodeJS에는 다양한 패키지가 존재하고 NPM(Node Package Manager)를 통해 설치한다. 모든 패키지가 CommonJS에 맞춰 모듈 패턴으로 구현을 하고 있다. 만약 이를 브라우져에서 사용하고 싶을 경우에는 Browserify 의 도움을 받으면 된다.

  - CommonJS를 번들링할 때 사용한다. 

  - AST (Abstract syntaxt tree) 에 따라 require한 모듈에서 require하고 해당 모듈이 require하고 있는 모든 하위의 모듈의 의존 파일을 자동으로 묶어준다. 

  - browserify 명령에서 entry 파일만 지정하면 된다. 의존

// app.js

var math  = require('math');

...


// console

browserify app.js -o bundle.js 




Webpack


AMD 패턴의 모듈을 번들링 할 때는 RequreJS에서 제공하는 r.js를 사용할 수 있다. 하지만 애플리케이션에서 NodeJS의 모듈도 사용하고 AMD 패턴 모듈도 사용한다면 어떻게 될까?  

  - CommonJS, AMD, ES2015 방식에 대한 번들링이 가능하다 

  - Bunlde Chunk라는 단위 묶으로 나누어서 번들링이 가능하다 


* Naver D2 Webpack 상세설명 참조




RollupJS


웹팩과 유사한 차세대 모듈 번들러로는 RollupJS가 있다. 특히 모듈안에 있는 내용중 사용하지 않는 것은 제거하는 Tree-Shaking 기술이 존재한다. 

  - maths.js에 square와 cube 펑션을 export 한다

  - cube만 사용한다. 

// maths.js 

export function square(x) {

 return x*x;


export function cube(x) {

  return x*x*x;

}


// test.js 

import { cube } from './maths.js';

console.log( cube(5) ); 


Tree Saking을 한후 square를 제거한다. 나무를 흔들면 필요없는 것은 떨어지고 필요한 것만 남는 것과 같다. (예제)

(function () {

'use strict';


// This function gets included

function cube ( x ) {

// rewrite this as `square( x ) * x`

// and see what happens!

return x * x * x;

}


console.log( cube( 5 ) ); // 125

}());




 

JSPM 


SystemJS는 모듈을 로딩하는 일관된 API를(System.config, System.import) 제공하고 패키지를 받아오고 로딩하는 역할로 JSPM을 사용할 수 있다.

  - SystemJS를 위한 패키지 메니져이다. 

  - ES6 Module Loader로 불린다

  - npm, bower, GitHub으로 부터 로딩한다. 

  - 브라우져에서 NodeJS 패키지가 browserify와 똑같이 작동한다

  - 개발시에는 개별 파일로 관리하다가 프러덕션에서는 번들링을 한다. 

  - 사용자 가이드


Browserify ==> Webpack ===> JSPM 순서로 정리 해보자. 




Angular2에서의 JSPM/SystemJS
  - JSPM을 패키지 메니져로 사용
  - SystemJS를 모듈 로더로 사용
  - TypeScript를 ES2015 자바스크립트 슈퍼셋으로 사용
  - Angular 2 를 통해 웹, 모바일, 네이티브 개발 플랫폼으로 사용


Module Loader는 CommonJS, AMD, UMD, ES2015 스팩 방식이 있고, Module Bundler는 Browserify, Webapck에서 JSPM(+SystemJS) 방식으로 수렴되고 있다. Angular2를 하게되면 Module Loader로서의 SystemJS와 Module Bundler이면서 패키지 메니져 역할을 수행하는 JSPM을 알아둘 필요가 있다.  

  - Angular 2에서 Bundler에 따른 사용 모듈 목록



<참조>

  - 모듈 번들러 설명 

  - 모듈 번들러 비교 slideshare

  - Choose ES6 Modules

  - Grunt에서 파일들을 통합/압축하는 방법

  - Browserify 와 Webpack 비교 

  - ES2015 스팩  

  - ES2015의 import/export 이야기

  


posted by Peter Note
2016. 2. 18. 18:02 Angular/Concept

프론트앤드 자바스크립트 개발이 점점 복잡해 짐에 따라 모듈 패턴으로 코드를 작성하고 단일 책임 원칙(Single Responsibility Principle)을 지키는 것이 좋다. 모듈 코드를 작성한 후 모듈을 로딩하고 배포(번들링)하는 다양한 방법들이 존재한다. 먼저 Module Loader에 대해 살펴보고 다음 글에서 Module Bundler에 대해 정리해 본다. 







모듈 패턴


모듈패턴을 사용하는 이유

  - 유지보수성(Maintainability): 단일 책임 원칙에 따라 필요한 기능을 담고 있으면서 별도 폴더와 파일로 유지하면 변경이나 확장 발생시 찾고 수정하기 쉽다. 전제 조건은 외부에 노출하는 API를 일관되게 유지하는 것이 중요하다. 

  - 이름공간(Namespacing): 자바스크립트에서 전역변수를 통한 개발을 하지 않는다. 이를 위해 즉시실행함수표현(IIFE)를 사용하여 전역변수의 오염을 방지하는데, 모듈 패턴 또한 전역변수 오명을 방지한다. 

  - 재사용성(Resuability): 모듈의 성격을 잘 나누어 놓으면 다음 프로젝트에서 그대로 사용해 쓸 수 있다. 보통 SDK나 Base Framework을 만들어 놓으면 초기 구축 비용을 최소로 할 수 있다. 


JohnPapa Angular 스타일 가이드를 보면 특별히 모듈을 지원하는 라이브러리의 도움없이 자바스크립트 모듈 패턴 방식으로 앵귤러 v1 코드를 작성토록 가이드하고 있고, 앵귤러 팀에서도 공식적으로 추천하고 있다. 

(function () {

    'use strict';


    angular

        .module('a3.common.action')

        .factory('currentAction', currentAction);


    /* @ngInject */

    function currentAction(ActionType, stateManager) {

        return {

            setDashboard: setDashboard,

            setWorkspace: setWorkspace

        };


        function setDashboard(dashboardId) {

            var action = {

                ...

            };

            stateManager.dispatch(action);

        }


        function setWorkspace(workspaceId, taskerId) {

            var action = {

                ...

            };

            stateManager.dispatch(action);

        }

    }

})();


순수 자바스크립트로 모듈 단위로 만든 후 상호 운영은 어떻게 해야할까? 일단 index.html에 설정을 하고 사용하는 순서에 index.html에 script 태그를 통해 로딩을 하는 간단한 방식을 생각해 볼 수 있다. 하지만 필요한 시점에 자바스크립트에서 로딩을 해서 사용하는 방식을 명시적으로 하려면 별도 로더의 도움이 필요하다. 




CommonJS & AMD & UMD


CommonJS는 지정한 코드를 동기적으로 로딩하는 방식으로 서버 사이드의 Node.js에서 사용한다. 

  - Object 만을 대상으로 한다.

  - module.exports 구문으로 Object를 export 한다

  - require 구문으로 Object를 import 한다. 

// 파일명: module.js 

function module() {

  this.hi = function () { return 'hi'; }

}

module.exports = module;



// 사용하는 파일: test.js

var module = require('module');

var m = new module();

m.hi();


위에서 require를 차례로 호출하면 동기적으로 하나씩 로딩을 한다. 즉, 비동기적이지 않기 때문에 로딩이 전부 되어야 수행이 된다. 브라우져에서 동기적으로 모듈 파일을 로딩하게 되면 모든 파일이 로딩된 후 화면이 실행되므로 성능 이슈를 야기할 수 있다. 따라서 CommonJS는 Node.js에서 주로 사용하고 브라우져에서는 사용하지 않는다. 


AMD(Asynchronous Module Definition)은 비동적으로 모듈을 로딩한다. 

  - Object, function, constructor, string, JSON 등 다른 타입들도 로딩이 가능한다. 

  - define 구문을 사용한다.

 define(['jquery', 'angular'], function($, angular) { 

   ...

 });


jquery, angular 파일에 대해 비동기적으로 로딩한다. AMD대표적 구현체로는 RequireJS가 있다. 


UMD(Universal Module Definition)은 AMD와 CommonJS의 기능을 둘다 지원하는 것이다. 

  - AMD, CommonJS를 고려한다 

  - 구현체로 SystemJS를 들 수 있다. SystemJS는 Universal dynamic module loader로 AMD, CommonJS뿐만 아니라 브라우져의 global scripts와 NodeJS 패키지 로딩을 하고 Traceur 또는 Babel 과 같이 작동할 수도 있다. 특히, Angular 2에서 사용한다.

  - 아래와 같이 CommonJS와 AMD를 체크하여 사용할 수도 있다. 구현 방식에 대한 다양한 예를 참조한다. 

(function (d3, jQuery) {

    'use strict';

   var Sankey2 = { ... };

   ....


    // Support AMD

    if (typeof define === 'function' && define.amd) {

        define('Sankey2', ['d3'], Sankey2);

    } 

   // Support CommonJS

   else if ('undefined' !== typeof exports && 'undefined' !== typeof module) {

        module.exports = Sankey2;

    } 

   // Support window

   else {

        window.Sankey2 = Sankey2;

    }


})(window.d3, window.$);


브라우져에서 ES6 module loader가 아닌 SystemJS (Universal module loader)를 사용할 경우 System.import 호출로 AMD, CommonJS, ES6 모듈 형식을 로딩할 수 있게 API를 제공하고  패키지 메니져로 JSPM을 사용할 수도 있다. JSPM은 무저항 브라우져용 모듈 패키지 메니져 (frictionless browser package management)로써 ES6 module loader가 작동하지 않는 곳에서 사용하는 Polyfill 이면서 AMD, CommonJS, Globals 자바스크립트 모듈 형식을 로딩할 수 있다. 



Native JS


자바스크립트 ES2015 (ES6)에서 모듈 로더를 공식지원한다. ES2015는 모듈의 importing과 exporting을 제공한다. (참조) 간결관 syntax와 비동기 로딩과 cyclic dependencies에 대해 보다 잘 지원을 한다. 

  - import, export 를 사용한다. 

// app.js 

export let count = 1;


export function hi() {

  return 'hi-' + count++;

}


// test.js

import * as app from './app';


console.log(app.hi());

console.log(app.count);



모듈로더에 대해 정리를 해보자. 자바스크립트 개발시 모듈 패턴에 입각하여 개발할 때 다양한 방식을 사용할 수 있으나

  - NodeJS 기반 서버 사이드 개발은 CommonJS 이고

  - Browser 기반 클라이언트 사이드 개발은 AMD구현체 중 하나인 RequireJS 를 사용한다. 


ppt에서 r.js는 RequireJS에서 제공하는 모듈 번들러이다. 모듈 로더에 맞는 모듈을 개발한 후에 모듈 파일을 운영 배포하기 위해 번들링 즉, 묶는 과정을 거친다. 번들링 방법은 대해 다음 글에서 살펴보자. 




<참조> 

  - 모듈 로딩 다이어그램

  - 모듈 로딩: CommonJS & AMD & UMD

  - 모듈 번들링: Browserify & Webpack 

  - CommonJS와 AMD - D2 

  - UMD 구현 예 

  - SystemJS: Universal dynamic module loader

  - Rollup.js: 차세대 Javascript module bundler

  - ES6 Module Loader Polyfill: Top Level SystemJS

  - ES6 vs CommonJS 비교

  - JavaScript Module Pattern

posted by Peter Note
2016. 1. 15. 08:16 Angular/Concept

디자인 가이드는 초기 버전의 생각이므로 현재(2015.1.15) beta 버전의 구문 형식과 틀릴 수도 있다는 것을 숙지하고 어떤 사상을 가지고 있는지 알아보는 것에 집중하자. 물고기가 아니라 물고기 잡는 그물에 집중하자는 이야기이다. 




Expressions


Angular의 expression은 Angular1의 expression 과 유사하고 몇가지 더 추가되었다. 


  - Dirty Checking과 긴밀히 통합되어 expression의 prefix 또는 constant 부분에 대한 최적화를 수행한다. 

    좀 더 자세한 사항은 dirty checking 디자인 가이드를 참조한다. 

  - One time binding을 {{::foo}} 와 같이 최초 한번만 바인딩되고 이후 바뀌지 않도록 한다. Angular1에서 사용하던 방법




Directive API


Directive는 ES6 classes를 사용해 정의하고, Annotation을 사용해 meta data를 정의한다.



Class annotation


모든 Directive는 @DecoratorDirective, @TemplateDirective, @ComponentDirective 중 하나의 annotation을 갖는 ES6 class 이다. Annotations는 일반적인 properties를 갖는다. 


  - selector: directive가 적용될 element를 찾을 css selector이다. (string)

  - events: directive가 template안에서 on-.. attribute를 사용해 발생시키는 이벤트 목록이다. (list of string)

  - visibility: element의 subtree안의 directives들이 directive 인스턴스에 접근할 수 있도록 정의한다. ['local' | 'direct-children' | 'any-children']

  - microsyntax: 특별한 properties 구문 형식과 이 properties가 다른 properties와 어떻게 맵핑하는지 정의한다 (string)


아래 예를 보면 NgShowDirective 생성을 통해 element에 ng-show attribute를 사용할 수 있게 한다. 즉, annotation은 툴이 element안에 directive를 인스턴스화하는 과정없이 그리고 코드를 실행하지 않고도 directives를 찾게한다.

import {ng} from '...';


@ng.DecoratorDirective(selector: '[ng-show]')


class NgShowDirective {}



Constructor 에 Denpendency Injection 하기


모든 directives는 Dependency Injection을 통해 contructor의 parameters 값을 갖는다. 즉, DI를 통해 다른 오브젝트 인스턴스틀 갖질 수 있는 것이다. 아래 예를 보면 @Inject annotation을 사용해 DI하고 있다. 

import {ng} from '...';


@ng.DecoratorDirective(selector: '[ng-show]')


class NgShowDirective {

  @Inject(window.HTMLElement, ng.Http, ng.SomeOtherDirective)

  constructor(element, http, someOtherDirective) { ... }

}



Directive communication


http 갖은 것은 ui 오브젝트가 아니기 때문에 element의 subtree안의 모든 directives에 접근할 수 있도록 annotation에 visibility 을 사용할 수 있다. 예로 input element에서 user.value에 대해 NgInputDirective는 input 값의 변경을 Listening하고, NgModelDirective가 validation하며, NgFormDirective은 state를 유지하는 작업을 한다. 여기서 NgModelDirective는 <form> element에 있는 NgFormDirective에 접근할 필요가 있고, NgInputDirective는 같은 element에 있는 NgModelDirective에 접근할 필요가 있다. 이를 아래와 같이 visibility를 설정한다. 

<form>

  <input type="text" ng-model="user.value" required>

</form>


import {ng} from '...';


@ng.DecoratorDirective(

  selector: 'form',

  visibility: 'subtree'

)

class NgFormDirective {

  constructor() { … }

}


@ng.DecoratorDirective(

  selector: 'input[type=text]',

  visibility: 'local'

)

class NgModelDirective {

  @Inject(NgFormDirective)

  constructor(ngForm) { … }

}


@ng.DecoratorDirective(selector: 'input[type=text]',)

class NgInputDirective {

  @Inject(NgModelDirective)

  constructor(ngModel) { … }

}



Bindable properties


Directives의 모든 properties는 데이터 바인딩을 사용할 수 있고, 이를 위해 set(write)에 대해 @ng.PropertySet annotation을 통해 환경설정을 한다. minification 후에도 property 명을 보존하고 directive의 properties에 데이터 바인딩을 쉽게 만들기 위함이다. 


  - 구문: @ng.PropertySet({trigger: ['reference' | 'collection' | 'deferred'], domOnly: [false|true] })

  - trigger

     + reference: reference가 바뀌면 reference 안에서 전달 (default)

     + collection: collection의 entry가 바뀌면 collection 안에서 전달 

     + deferred: directive가 수행할 수 있는 컴파일된 expression을 전달

  - domOnly: DOM만 변경하고 watch하고 있는 다른 property는 제외함 (default: false)

  

예 

import {ng} from '...';


@ng.DecoratorDirective {

  selector: 'dialog'

}

class Dialog {

  constructor() {

    this._content = null;

  }

  get content(content) {

    return this._content;

  }

  @ng.PropertySet({domOnly: true})

  set content(content) {...}

}


<dialog content=”{{1+2}}”>



Properties를 위한 Microsyntax


directive가 여러 값을 다룰 필요가 있을 때 microsyntax로 설정을 한다. 예로 ng-repeat을 하면 track-by expression을 해야할 때. 구문은 다음과 같다. 


  - MICROSYNTAX=(VARIABLE|FIXED|OPTIONAL)+

  - VARIABLE=$\w+

  - FIXED=[^$\[\]]+

  - OPTIONAL=\[MICROSYNTAX\]


ng-repeat을 위한 microsyntax 예를 보면 <div>에 ng-repeat-item-name, ng-repeat-collection, ng-repeat-track-by를 사용한다. 

@TemplateDirective(

  selector: '[ng-repeat]'

  microsyntax: {

   'ng-repeat': '$item-name in $collection [track by $track-by]'

  })

class NgRepeat {

  @ng.PropertySet({trigger: 'reference'})

  set ngRepeatItemName() { … }


  @ng.PropertySet({trigger: 'collection'})

  set ngRepeatCollection() { … }


  @ng.PropertySet({trigger: 'deferred'})

  set ngRepeatTrackByFn;

}



<div ng-repeat="item in items track-by item.id">

<div ng-repeat-item-name="item" ng-repeat-collection="items" ng-repeat-track-by="item.id">



Lifecycle hooks 


모든 directives는 아래 특별한 함수를 구현할 수 있다. 이유는 templates이 initialization과 finalization을 알수 있도록 허용하기 위해 lifecycle hook을 둔다. 


  - attach: templates 안에 바인딩이 된 후 한번만 호출된다. 

  - detach: directive의 element가 destroy될 때 호출된다. 


Component directive는 특별히 아래 함수도 구현할 수 있다. 


  - templateLoaded: component의 template이 로딩되어 component element에 포함될 때 호출된다. 



Events


Directives는 HTMLElement.dispatchEvent를 사용해 사용자 정의 events를 발생시킬 수 있고, HTMLElement.addEventListener를 통해 이벤트를 Listening할 수 있다. 이벤트는 tree를 타고 bubble up 된다. 설정은 아래 예와 같이 class annotation 안에 하고, event가 발생하면 dirty checking 스케쥴이 돌고 template안에 on-... attributes 를 validation한다. 

 @ng.DecoratorDirective(

  selector: 'dialog',

  events: ['close']

)

class Dialog {

  @Inject(window.HTMLElement)

  constructor(element) { ... }

  close() {

    var evt = new Event('close');

    this.element.dispatchEvent(evt);

    if (!evt.defaultPrevented()) {

      // really close the dialog...

    }

  }

}




Directive 구현 예


Decorator: ng-show

import {ng} from '...';


@ng.DecoratorDirective(

  selector: '[ng-show]'  

)

class NgShow {

  @Inject(window.HTMLElement)

  constructor(element) {

    this.element = element;

  }


  set ngShow(value) {

    this.element.style.display = value ? 'block' : 'hidden';

  }

}


Template Directive: ng-if

template 태그의 content를 사용하는 간단한 template directive 이다. 

import {ng} from '...';


@ng.TemplateDirective(

  selector: '[ng-if]'  

)

class NgIf {

  @Inject(ng.ViewHole, ng.ViewFactory, Injector)

  constructor(viewHole, viewFactory, injector) {

    this.viewFactory = viewFactory;

    this.viewHole = viewHole;

    this.injector = injector;

    this.view = null; 

  }


  set ngIf(value) {

    if (this.view) {

      this.viewHole.remove(this.view);

    }

    if (value) {

      this.view = this.viewFactory(injector);

      this.viewHole.add(this.view);

    }

  }

}


Template Direcive: ng-include

import {ng} from '...';


@ng.TemplateDirective(

  selector: '[ng-include]'

)

class NgInclude {

  @Inject(ng.ViewHole, ng.Compiler, ng.Http, ng.Directives,

          Injector)

  constructor(viewHole, compiler, http, directives, injector) {

    this.viewHole = viewHole;

    this.compiler = compiler;

    this.directives = directives;

    this.injector = injector;

    this.view = null;

    this.$http = http;

  }


  set ngInclude(value) {

    var self = this;

    this.$http(value).always(removeView).then(addView);


    function removeView() {

      if (self.view) {

        self.viewHole.remove(self.view);

        self.view = null;

      }

    }

    function addView(templateString) {

      var viewFactory = 

            this.compiler(templateString, this.directives);

      this.view = viewFactory(injector);

      this.viewHole.add(this.view);

    }

  }

}


Templat directive: ng-repeat

template directive는 새로운 execution context를 제공할 수 있고, 아래 간단한 예에서 variable을 injector안에 있는 현재 execution context에서 검증한다. 

import {ng} from '...';


@ng.TemplateDirective(

  selector: '[ng-repeat]'

  microsyntax: {

   'ng-repeat': '$item-name in $collection [track by $track-by]'

  })

class NgRepeat {

  @Inject(ng.ViewHole, ng.ViewFactory, Injector injector)

  constructor(viewHole, viewFactory, injector) {

    this.viewHole = viewHole;

    this.viewFactory = viewFactory;

    this.injector = injector;

    this.views = [];

  }

  @ng.PropertySet({trigger: 'reference'})

  set ngRepeatItemName(value) { 

    this.itemName = value; 

    this.update(); 

  }

  @ng.PropertySet({trigger: 'collection'})

  set ngRepeatCollection(arrayChangeRecord:ArrayChangeRecord) { 

    this.arrayChangeRecord = arrayChangeRecord;

    this.update(); 

  }

  @ng.PropertySet({trigger: 'deferred'})

  set ngRepeatTrackByFn(value) { 

    this.trackByFn = value; 

    this.update();

  }

  update() {

    …

    // deleting a view    

    this.viewHole.remove(deletedView);

    …

    // creating a new view

    var childContext = {

         $index: index,

         $odd: !!index%2,

         $even: !index%2 

    };

    childContext[this.itemName] = this.collection[index];

    var view = this.viewFactory(injector, childContext);

    viewHole.append(view);

   }

   ...

  }

}


Component Directive: pane

title이 있는 pane 구현 예

import {ng} from '...';


@ng.ComponentDirective(

  select: 'pane',

  template: ng.inline('<div>{{title}}</div><content/>'),

  css: ng.url('pane.css'),

)

class sample.Pane {

  constructor() {}

  set title() { … }

}




다른 Web Component 프레임워크에 component를 publishing하거나 consuming하기 



Custom Elements로 X-Tags, Polymer를 사용하는 프레임워크 


Angular는 Custom element API가 유효한지 찾고 custom element로 컴포넌트를 자동 등록하고, component directive의 properties가 custom element의 인스턴스를 접근할 수 있게 한다. 


  - custom element로 Angular component를 export 할 경우 

    + custom element API가 유효하면 Javascript 애플리케이션에서 Angular component를 DOM element 접근방식으로 event의 listen과 properties를 접근가능케 만든다.

  - Angular 애플리케이션에서 custom element 사용할 경우 

    + Angular는 native DOM element를 사용하듯이 custom elements를 사용할 수 있고, event도 listen할 수 있다.



가이드-1 다시 보기



<참조> 


  - Angular Templating 디장인 가이드 

  - Creating, Triggering Events 모질라 문서 

posted by Peter Note
2016. 1. 14. 08:23 Angular/Concept

이번에는 Angular2 Templating에 대한 Design Guide를 살펴본다. Angular1에서 Angular2로 오면서 살아남은 명칭중 하나는 Directive(지시자)이다. 지시자는 Angular 프레임워크에서 컴포넌트의 지위를 얻을 수 있는 방법을 제공했으나, Scope에 대한 격리 옵션과 모델들의 @/&/= 옵션, ControllerAs 등 문법적으로 알고 가야할 사항이 많아서 처음 접근하는 개발자에게 상당한 Learning Curve가 존재한다.




친숙함과 간결함 사이에서 (Familiarity vs Simplicity)


친숙함은 달콤하다. 지금 잘 알고 있는 것을 가지고 현재를 편하게 즐길 수 있도록 해준다. 하지만 변화에 둔하고 러닝커브가 높을 경우 신규로 알아야 할 사람들에게 많은 시간을 투자하게 만든다. 친숙함이 정말 친숙한 것인지 한번 더 돌아보고 주위 사람들이 왜(Why) 어려워 하고 어떻게(How)하면 쉽고 빠르게 익히고 널리 사용할 수 있도록 무엇(What)으로 만들 수 있을지 기술 리더는 고민해 보아야 한다. 


간결함은 하는 역할이 명확하여 쉽게 이해한다. 배움의 시간을 단축시켜주고 즐거움을 줄 수 있다. 그러나 복잡함을 간결하게 표현하기 위해서는 함축적이다. 따라서 그 내면에 있는 내용을 이해하고 쓰면 더 많은 생각들을 읽을 수 있다. 따라서 간결함을 왜 어떻게 무엇으로 만들었는지 알아 보는 것이 중요하겠다. 그 간결함을 쉽게 설명할 수 있다면... Angular2 Templating은 간결함의 시작중 하나라 본다. 


* 주의) 글에서 Angular 또는 Angular2는 Angular version 2를 지칭하고, AngularJS 또는 Angular1는 Angular version 1를 가르킨다. 


 

Templating 개념 둘러보기


Angular는 DOM element와 행위에 대한 것을 연관(연결) 한다. 여기서 행위(Behavior)를 Directive라고 부른다. 행위에 대한 부분이기 때문에 Directive는 CSS Selector와 맵핑되는 DOM element를 위해 인스터스화된 자바스크립이다. DOM element는 애플리케이션과 상호작용하기 위해 properties와 events를 사용하는데, Directive도 DOM element의 properties와 events의 동일 인터페이스를 사용한다. 


Angular 애플리케이션이 사용자 인터페이스는 "Component Directive"를 사용해 구성한다. Component Directive는 애플리케이션의 Data와 Logic을 저장하고, 또한 사용자 인터페이스를 정의하는 html template도 가진다. 컴포넌트 안에서 element와 상호작용하는 컴포넌트는 Decorator Directive이다. 보통 ng-show="false"와 같이 element의 attribute로 동작하고 엘러먼트에 여러개가 놓일 수 있다. 


Angular는 양방향 데이터 바인딩을 사용한다. 데이터 바인딩은 template안에 특별한 html attribute를 이용해 설정한다. 이때 바인딩은 expression이라고 부르는 것을 이용해 정의한다. expression은 함수(Function)를 호출하거나 데이터에 접근하는 것으로 모든 expression은 execution context안에서 실행된다. 이런 작용은 Dependency Injection Container 안에서 아래와 같이 수행된다.





Directive Type


지시자의 종류 목록


Provides execution context for expressions

Provides a hole in the DOM to insert template instances

Isolates the DOM/expressions/css for reuse

Decorator Directive

no

no

no

Template Directive

can create child execution context, don't have to.

yes

no

Component Directive

isolated execution context, always.

no

yes


Directive에 대한 일반 제약조건은 Directive는 DOM 구조를 제거(remove)/변경(change) 해서는 안된다. Template Directive와 Component Directvie는 별도의 Execution Context를 가질 수 있다. Angular에서 template directive가 execution context를 갖는 것에 유념하자.



Decorator Directive


새로운 element를 만들고 해당 element에서 뭐든 할 수 있다. 그러나 만들지 않은 것은 다른 element는 attribute 변경만 가능하다.



Template Directive


원래 있던 element/template 영역의 특정 부분에 template 인스턴스를 넣을 수 있고, template directive는 자식(child) execution context를 생성한다. 예로 ng-repeat는 row 마다 execution context를 만들지만 ng-if는 부모(parent) execution context를 재사용한다. Template Directive 종류로는 ng-if, ng-repeat, ng-view, ng-switch, ng-include 가 있다. 일반적인 문법을 보자 

<template ng-repeat>

  <div> ... </div>

</template>


template element 자체는 제거되고 template의 일부가 되지 않는다. 즉, template directive는 <template> element만을 허용한다. 중첩으로 아래와 같이 사용할 수도 있다. 

<template ng-repeat>

  <template ng-if>

    <div>...</div>

  </template>

</template>

    

template directives를 사용하면 element에 아래와 같이 template로 변경된다. 

<ul>

  <li ng-repeat>

    <span ng-if> ... </span>

  </li>

</ul>

은 아래 내용과 완전 동일하다

<ul>

  <template ng-repeat>

    <li>

      <template ng-if>

        <span> ... </span>

      </template>

    </li>

  </template>

</ul>


위이 template 태그는 Angular1의 directive의 compile/link 과정과 동일하다. 즉, Angular2에서는 compile/link과정을 template directive로 대체하는 것이다. 


    // Angular1의 이런 구문이 사라지는 것이다. 

    return {  

           ....

            templateUrl: 'plugins/taskers/wafer-traffic/wafer-traffic.html',

            replace: true,

            link: link,

            controller: ctrl,  

            ....

        };

    function link() {}

    function ctrl() {}



Component Directive 


javascript 로직, html template 과 옵션으로 css style을 컴포넌트에 가지고 있다. 이를 위해서 template안의 expressions을 격리(isolate)한다. - execution context의 격리: component directive 인스턴스가 template안의 expresssions를 위한 새로운 execution context가 되는 것이다. 즉, template안의 expressions은 component directive 인스턴스의 함수(function) 또는 properties만 접근 가능하다는 것이다. 이것은 Angular1의 directive 정의시 scope: {...} 격리하는 방법과 controllerAs를 사용해서 this로 접근하는 것등을 개발자가 정의할 필요없이 Component directive로 통일한 것으로 보인다. 프로젝트를 진행하다보면 거의 대부분 scope: { model: '=' } 과 controllerAs를 default로 놓고 사용하기 때문에 프레임워크 단에서 simple화 한 것은 환영할만 하다. 


  // Angular1의 이런 구문이 사라지는 것이다. 

  return {

            restrict: 'EA',

            scope: {

              model: '='

            },

            controller: trafficCtrl,

            controllerAs: 'traffic',

            bindToController: true

        };


- DOM 과 CSS의 격리: Component directives는 다른 directive에서 컨텐츠 변경을 못하도록 Shadow DOM을 사용한다. 따라서 Shadow DOM안에서의 element events는 외부 element로 전파되지 않는다. (buble out of component directive) 

   + Properties와 events: Template은 component의 properties들과 데이터 바인딩 되고, 이벤트는 상위 컴포넌트로 전파할 수 있다. 

   + CSS properties: 템플릿은 Shadow DOM을 기본으로 사용하는 컴포넌트에 한해 스타일을 변경할 수 있다. 

   + Child fragment: 템플릿은 Shadow DOM의 <content> 태그를 사용하는 템플릿을 넣는 자식 elements를 제공한다. 자식 elements의 expression은 밖의 템플릿 execution context와 계속 연결된다. 


expression을 위한 Execution Context는 클래스 인스턴스이고 이를 통해 expression에 대한 type checks등 다양한 일을 수행할 수 있다. 



Directives를 인스턴스화 하는 순서 


자식 elements전에 부모 element의 directives가 먼저 인스턴스화 하고, 만약 template directive가 존재하면 이것을 인스턴스화 하고, 다음으로 element의 decorator directive를 인스턴스화 한다. 순서는 directive 생성자의 dependency injection 순서에 의해 결정된다. 그리고 나서 최종 component directive가 인스턴스화 한다. 즉, 다음과 같다. 


>> Parent Element 

     template directive --> decorator directives --> component directive

         >> Child Elements

                template directive --> decorator directives --> component directive




templates에 데이터 바인딩 설정 방법


elements 또는 directives의 events 와 바인딩 하기


형식: @on-[event name]="[expression]" 

        예) <button on-click="doSomething()">

의미: click 이벤트가 발생하면 doSomething을 호출한다. 

DOM events를 기반으로 하는 thrid party 이벤트 시스템을 바인딩 할 수 있고, Directives에 새로운 이벤트를 정의해도 listener를 달 필요가 없다.



elements 의 properties 와 바인딩 하기


형식: @bind-[property name]="expresion" 

         예) <input bind-value="user.name">

의미: expression인 user.name에 대한 값 변경을 감시하다가 element property값을 갱신 한다. 


만일 element의 property가 바뀌었는데 expression은 writable하지 않거나, expression의 값이 바뀌었는데 property가 writable하지 않으면 에러가 발생한다. 양방향 데이터 바인딩은 directive와 element property 사이에 일어나기 때문이다. element의 attribute로 하지 않고 property로 바인딩 하는 이유는 다음과 같다. 


  - 거의 대부분의 attribute는 대응하는 property를 가진다. 만일 대응하는 property가 없으면 attribute가 대신한다. 

  - element properties는 항시 현재 값을 가진다. 그러나 attributes는 때때로 초기값을 지정해 주어야 한다. 예) <input>의 value attribute.

  - native attributes는 브라우저가 알아서 자동으로 대응하는 property 값을 바꿔준다. 

    예) <img>의 src property는 src attribute 바뀌면 자동을 변경된다)



elements의 properties 넣기 


형식: @[property name="a {{ [expression] }} b"

        예) <input title="some Text {{someValue}}">

의미: <input bind-title=" 'a ' + someValue + ' b' ">  


{{}} 를 사용하면 항상 string으로 변환하고, 단방향 연결이 된다. Angular1 directive의 @ 과 같다. 



text 넣기


형식: {{ [expression] }}

        예) hello {{user}}

의미: hello <span bind-text-content=" ' ' + user "> 


text node 내역과 데이터 바인딩도 항시 string으로 변환되고, 단방향이다. 



Guide-2 이어보기



<참조>


  - Templating 디자인 가이드 

  - Template Syntax 개발자 가이드 



posted by Peter Note
prev 1 2 next