#AngularJs2 | Explore Tumblr posts and blogs

pignose-barn · 8 years ago

Text

자바스크립트 모듈 제공을 위한 AMD, CommonJS 그리고 RequireJS 소개

자바스크립트는 편리한 언어이다.

필자는 자바스크립트의 유연함과 고차함수, 익명함수 사용의 편리함과 직관적은

정말이지 엄청난 매력을 가지고 있다고 생각한다.

이번 포스팅에는 자바스크립트가 모듈을 제공하기 위해서

AMD, CommonJS를 알아보고 RequireJS에 대해서도 소개하고자 한다.

서론

필자는 오픈소스를 자주 사용한다.

그리고 오픈소스 기여도 자주 하는편이라고 생각된다.

오픈소스 참여를 할 때, 깃허브를 많이 사용하는데

여러분도 이 고양문어(옥토캣)을 많이 보셨을 거라 생각한다.

필자가 기여하는 프로젝트 중에

달력 컴포넌트를 만들어주는 자바스크립트 프로젝트가 있다.

이 곳에서 해당 프로젝트를 확인 할 수 있다.

이 코딱지 만한 프로젝트도 점점 사용자들이 이용해주면서

기능을 확장하고 있는데

최근에 AMD, CommonJS 지원 작업을 한 적이 있는데

작업을 진행하면서 발생한 크고작은 이슈에서 얻은 경험을 공유하고자 한다.

시작하기 앞서 이 글을 읽어보면 좋을 것 같다. (4년도 더 된 글이다..)

배경

자바스크립트는 파이썬, 루비, 다른 스크립트 언어 계열과 차이점이 존재한다.

바로 모듈 사용의 표준이 존재하지 않다는 것이다. (ECMA5 기준)

https://gist.github.com/KennethanCeyer/6d6ba68b76354398f770b1e0adc0b8e2

파이썬 모듈 사용

https://gist.github.com/KennethanCeyer/7d02f92ba85c16533668bfe6cdd6e4a5

루비 모듈 사용

Node.js를 사용하고 있는 개발자들은 module.exports를 통해 모듈을 정의하고

require() 함수를 통해 정의한 모듈을 불러와 사용하고 있다.

이곳을 통해 Node.js에서 모듈을 어떤식으로 사용하는 지 알 수 있다.

이러한 방식을 CommonJS로 불린다.

https://gist.github.com/KennethanCeyer/d4848af11711a3ab3f65653449b32c43

Node.js 모듈 형태를 보면 다른언어에 비해 모듈제공이 조금 차이가 있다.

module.exports와 exports 두개를 사용하는데

이런 제공방식은 혼동을 초래하기도 한다.

필자는 그래도 Node.js의 모듈 형식에 대해서 크게 불만을 가지고 있지 않다.

문제는 프론트엔드에서는 이런 모듈 제공방식�� 없었다는 것이다!!

https://gist.github.com/KennethanCeyer/609879cb173368093316eb7de667f54b

그나마 비슷하게 모듈 제공방식을 따라해봤다.

프론트엔드에서 사용하는 자바스크립트는 DOM 오브젝트를 사용하고 있다.

전역 오브젝트인 window를 사용하면 다른 자바스크립트 파일에 리소스를 전달 할 수 있다.

하지만 이것도 사용하는 HTML에서 불러오는 모듈 파일을 먼저 로드해야

문제가 없이 작동된다.

즉 대상 모듈이 존재 할 수도, 존재하지 않을 수도 있는 상태가 벌어진다. (으아아악!)

하지만 프론트엔드에서 사용하는 프로젝트도 규모 커지면 커질수록

모듈의 필요성은 커져갔고

그렇게 AMD 방식과 CommonJS 방식 두개의 모듈 정의 규칙이 생기게 되었다.

사실 두개 말고도 ES2016, ES6, System.register 등등의 모듈제공 방식도 있지만

여러분의 정신건강을 위해 비밀로한다... (이미 비밀이 아니잖아!!)

AMD

AMD는 Asynchronous Module Definition (비동기 모듈 정의) 규칙이다.

https://github.com/amdjs/amdjs-api/wiki/AMD에서 자세한 내용을 확인 할 수 있다.

https://gist.github.com/KennethanCeyer/3c78f7c18c3519355509e2174103d633

AMD의 규칙을 이용해서 정의해봤다.

브라우저에서 모듈을 정의하고 불러오는 기능을 사용하기 위해서는

AMD의 규칙을 따르는 도구를 사용해야 하는데,

위의 코드에서는 RequireJS를 사용했다.

(RequireJS에 대한 설명은 http://requirejs.org/에서 확인 할 수 있다.)

위 사진에서 math.js는 main.js의 require 함수에 의해 동적으로 로딩되었다.

AMD 관련한 글 중에

AMD is Not the Answer(AMD는 해답이 아니다.)라는 글이 있다.

여기서는 AMD의 정의구조와 HTTP 동적 로딩을 비판하고 있는데 관심있는 분들은

한번 읽어보시길 바란다.

필자는 이렇게 생각한다.

AMD와 CommonJS 둘 모두 프론트엔드 브라우저에서 동적 로딩을 할 경우

페이지가 열리기 전까지 수많은 JS를 사용자가 페이지를 열어볼 때 불러오므로

부하가 발생하게 된다. (캐시를 해도 느린건 마찬가지)

여러분이 생각하는 1~20개의 자바스크립트 파일 로딩이 아니다.

몇 백개의 자바스크립트를 매 사용자가 페이지를 전환할 때마다 불러 온다고 생각해보자...

AMD, CommonJS 모두 비동기 통신을 통해 파일을 동적으로 불러오는 경우

성능의 이슈가 있기 때문에

보통 프로덕션 서버로 배포 할 때 번들링(Bundling) 작업을 진행하게 된다.

번들링은 이후 섹션에서 자세히 설명하도록 하겠다.

아까전에 얘기했던 오픈소스 프로젝트 PIGNOSE Calendar는

AMD 스타일로 모듈을 정의한다.

소스코드를 통해 확인이 가능하다.

그렇다고 RequireJS를 사용하지 않는 프로젝트에서

해당 프로젝트 소스를 불러와도 (이를테면 <script> 태그를 통해 로딩 시)

소스는 문제없이 작동해야한다.

AMD는 define 함수와 require 함수를 통해 모듈 정의와 로딩을 진행하는데

이 두가지 함수 모두 브라우저에서 인식 할 수 있는 함수가 아니다.

따라서 아까 우리는 require.js 스크립트를 추가적으로 불러와

브라우저에서도 모듈 정의와 로딩이 동작하도록 했다.

하지만 라이브러리에서 require.js 파일을 의존하여

같이 빌트-인 하기에는 require.js 소스코드 용량이 크다.. (18KB)

RequireJS 측에서는 이렇게 AMD를 사용하지만 라이브러리 형태로 제공해야하는

프로젝트를 위하여 RequireJS의 미니마이즈 버전인 Almond(아몬드)를 제공한다.

아몬드의 설명에 따르면 gzip과 클로저 컴파일러를 이용할 때 약 1킬로바이트의 용량이 된다고 한다.

필자는 RequireJS를 번들링 하기 위해 Grunt Task(그런트 테스크)를 사용하는데

그런트 RequireJS 테스트 설명을 보면

almond 빌트 인이 명시되어있다.

여러가지 유명 자바스크립트 라이브러리를 살펴봐도

대부분 아몬드를 빌트인 하여 제공하고 있다.

CommonJS

아까 설명한 것과 같이 Node.js 진영에서는 CommonJS를 기본으로 사용하고 있다.

그 외에도 tsconfig에서 commonjs로 모듈을 정의해도 CommonJS로 정의가 된다.

CommonJS 제공이 중요한 이유가

당연하게도 Node.js에서 모듈을 불러오는 기본 스타일이 CommonJS이기 때문에

프론트엔드 라이브러리일지라도 Node.js 코드를 통해 유닛 테스팅을 하는 경우

혹은 moment, underscore처럼 Node.js에서도 사용 가능해야하는 라이브러리 일 경우

CommonJS 모듈 형태도 제공해야 한다. (맙소사, 저 울어도 되요?)

번들링

번들링을 쉽게 설명하자면

여태까지 여러분이 모듈들을 싸질러놓은 똥을 하나의 단일 파일로 취합하는 과정이다.

앞서 말씀드린 모듈 타입(AMD, CommonJS, ES2015, ES6 etc)을

분석하고 거기서 불러오는 파일을 파악하여

하나로 모아주는 번들러(Bundler)가 필요한데.

많이 사용하는 번들러 종류는 아래와 같다.

Webpack

Rollup.js

Jspm

Browserify

Grunt와 Gulp와 같은 빌드테스크 도구에서도 플러그인을 연결하여

번들링을 진행 할 수 있다.

PIGNOSE Calendar는 앞서 말했듯 Grunt를 사용하여

RequireJS를 번들링하고 Almond를 묶어서

번들러의 선택은 여러분의 자유지만

여러분의 정신건강 상 웹팩(Webpack) 번들러를 사용하시기를 권장드린다.

필자는 AngularJS 2 AOT 를 사용할 때 그곳에 명시된 롤업JS(Rollup.js)를 사용했으나

무수한 경고(Warning)이 표시되었고

AngularJS2에서는 무슨일에선지 그것을 무시하는 코드를 넣어 공식페이지에 공개했다.

그 때문에 필자는 웹팩(Webpack) 버전 2로 교체하고 잘 쓰고 있다.

참고로 Webpack 1에서는 AngularJS AOT를 번들링 할 때 Uglify에서 에러가 발생한다.

아무도 해결방법을 공유안해서 필자가 직접 했다고 한다.

혹시 같은 문제를 겪는 분은 이 링크를 살펴보시길 바란다.

AngularJS 2 AOT를 적용하시고자 하신다면 Webpack 2를 사용하시는 게 정신건강에 좋다.

배포

좀 전에 얘기드린바와같이

우리의 아름다운 자바스크립트 프론트엔드 환경에서는

제공하는 라이브러리를 어떤식으로 호출 할지 모른다.

require([``], function(module) {})로 사용 할 수도 있고. (AMD)

var module = require(``)로 사용 할 수도 있다. (CommonJS)

심지어 import { module } from ``; 형태로 사용 할 수도 있다. (ES6)

우리는 이런 모듈 방식을 모두 제공하는 팩토리 형태를 만들어야 한다.

심지어 이 팩토리 표현에 대해서는 마땅한 표준도 없다.

(세상에 마상에)

표준은 아니지만 UMD라는 친구가 있는데

Universal Module Definition의 약자이다.

여기서 제공하는 템플릿이 그래도 많이 사용되고 있는 듯 보인다.

힘내세요 프론트엔드 라이브러리/프레임워크 개발자 여러분..

피토하셔도 이해합니다..

이 글을 읽어보자

글의 제목은

It's Not Hard: Making Your Library Support AMD and CommonJS

(여러분의 라이브러리가 AMD와 CommonJS를 지원하는 것은 결코 어렵지 않습니다.)

인데 이 글의 분량이 어느정도인지 파악이 되는가?

여러분은 고작 다른언어에서는 기본적으로 제공하는 모듈 지원을 위해

이 정도의 글을 더 읽어야한다.

(모듈 지원도아니다, 지원하고 있는 모듈 외에 모듈 정의 호환 지원이다.)

본론으로 돌아와서,

앞서 말했던 PIGNOSE Calendar 플러그인은 AMD 모듈을 사용하고 있지만

CommonJS, Plaintype(<script>를 통해서 불러오는 경우)를 지원해야 했다.

이를 위해 하나의 Factory를 정의하게 되는데

기초 원리는 간단하다.

우선 아래 코드를 먼저 살펴보자.

https://gist.github.com/KennethanCeyer/19402abf4901a833052319ece54119d4

자바스크립트를 조금 공부하신분은 IIFE에 대해서 들어보셨을 것이다.

IIFE는 Immediate Invoked Function Expression의 약자로 즉시 함수 호출 표현식이다.

이걸 왜 사용하는지는 이곳에서 자세히 살펴보실 수 있다.

이것을 사용하는 주요 이유는 전역 함수와 지역 함수 구분을 위한 클로저 정의를 위해 사용한다.

아까 보여드린 Factory에서도 IIFE 형태의 호출 표현식을 사용하는데

root, factory 매개변수를 IIFE 형태로 전달한다.

root는 this가 전달되며 factory는 모듈로 제공될 함수가 전달된다.

IIFE에서는 각 모듈을 사용하는지 검사 한후 factory를 호출하게 된다.

PIGNOSE Calendar는 module.export (CommonJS) 형태에서

Mocha를 통한 Unit Test를 제공해야 하기 때문에

각종 의존라이브러리를 추가하여 부르게 된다.

그리고 Node.js 환경에서는 window, document가 존재하지 않기 때문에

window와 document를 jsdom을 통해 Mocking 하고있다.

결론

결론적으로 아직 자바스크립트의 모듈링 표준은 걸음마 단계이다.

아직 ECMA 6가 모든 브라우저에서 채택되지 않았기 때문에 (채택상태 보기)

과도기적인 면모를 보인다.

ECMA 6가 AMD와 CommonJS 스타일을 사용하지 않기 때문에

나중에는 AMD와 CommonJS 모두가 버려지는 아름다운 현상이 일어나진 않을지..

이곳에서 RequireJS를 지원하는 Grunt 설정을 볼 수 있다.

PIGNOSE Calendar는 모듈 호환을 제공하고 브라우저에서도 정상 동작한다.

이곳에서 확인해보자

여러분도 자바스크립트 모듈을 사용하고

빈틈 없는 멋진 개발자가 되보자.

(모듈 모르는 뇌 삽니다.)

#개발 #commonjs #requirejs #amd #es2015 #es6 #import #exports #module #almond #factory #webpack #rollupjs #angularjs #angularjs2 #ahead of time #aot #bundler #frontend

2 notes · View notes

mytectrablog-blog · 8 years ago

Text

6 Reasons to learn AngularJS

Angular 2 was released in late 2016 and brought Angular into the modern web with its desktop and mobile applications. If you build Web applications, chances are you’ve heard of Angular, the popular JavaScript framework for building full-featured, client-side, browser-based applications. The recent release of Angular 2 (September 2016) brought Angular into the modern Web and expanded its reach into mobile and desktop applications.

So what’s all of the Angular 2 excitement about? How is it different from every other JavaScript framework out there? Is it worth learning? What’s there to love?

Here are six reasons to love Angular 2.

1. Enhanced developer productivity with Angular 2

The Web has changed significantly during these past five years. With ECMAScript (ES) 2015, we have modules, classes and arrow functions. Angular 2 leverages these features to make its coding patterns more consistent and easier to learn.

Add to that Typescript, a language that is a superset of JavaScript and provides static typing and interfaces. By leveraging TypeScript for Angular development, we get great tooling such as type checking, safer refactorings and inline code documentation.

These features enhance our development and editing experience and help us reason about, debug and better understand our code.

2. Consistent coding patterns

One of the best things a framework can do for developer productivity is have a consistent set of coding patterns, and Angular does just that. Let’s talk about three of them: classes, built-in dependency injection and the MVVM (model-view-view/model) pattern.

Angular 2 uses ES classes and a set of annotations, called decorators, to build all of the key Angular constructs. Want to build an Angular component? Create a class and add the appropriate decorator. Want to build a custom pipe filter? Create a class and add the appropriate decorator. Building an Angular module? Create a class and add the appropriate decorator. Building a service? Well, for a service we … build a class and add the appropriate decorator. You get the idea here. Angular 2 provides a very consistent coding pattern for building up the pieces of the application.

Another coding pattern Angular 2 leverages is the power of dependency injection (DI). To use any of the built in Angular services, such as HTTP or Router, we simply inject the service into any class that needs the service. Angular implements constructor-based dependency injection, so to inject a service we simply pass that service as an argument to the class constructor. That’s it. And when we build our own custom services, we inject them using the same technique.

Angular also takes advantage of common architectural patterns. When building client-side applications there are often three pieces to the puzzle: the user interface, the code that supports and controls that user interface and the model containing the data for that interface. Angular 2 clearly separates these three pieces using the model-view-view/model, or MVVM, pattern.

The view is defined in a template that contains the HTML for a specific component. The template can layout a page, any part of a page, or define a reusable set of user interface elements.

The model is defined as properties of the component class. For example, we define a hero property that models a superhero. We use an interface to define the details of that hero property, identifying the specific data elements associated with that hero such as hero name, alter ego and special powers.

The view/model is the class that manages both the view and the model. This is the code that calls services to retrieve data, reacts to user interactions on the view such as hiding or showing elements and calls services to save user entries.

By taking advantage of these common patterns, Angular 2 makes development easier and more productive.

3. Extensive binding with Angular 2

Many client-side Web applications work with data. The application retrieves data from a back-end server and displays that data in a view using a template. And if the user can change that data, the user’s entries must be read from the view and saved back to the back-end server. The code required for this process can be tedious and error prone.

Angular 2’s data binding makes this process easy. Simply bind HTML elements in the template to the model properties in the class and the data will automatically appear in the view. And if the user can change the values, Angular 2 supports two-way data binding. So any change the user makes to the data in the view automatically updates the model properties in the class.

In addition to data binding, Angular 2 supports property binding. This allows us to control the document object model (DOM) by binding HTML properties to component class properties. For example, we bind the HTML hidden property of an image element to a component class property such as hideImage. When the component class property is set to true, the image element is automatically hidden. When the component class property is set to false, the image element automatically appears.

And lastly, Angular 2 supports event binding. This means we can react to any event from the view, including HTML events such as click, third party component events or our own custom events. We simply bind the event to a method in the component class. When the event occurs, the method is executed.

These extensive binding features make it easy to display data, obtain user entries, control the DOM and react to events.

4. Full-featured routing

One view does not an application make. Most client-side Web applications provide many views to support all of their functionality. There may be a view for a welcome page, a hero list page, a hero detail page and a hero edit page. Then sets of views for villains or jobs. We need to display the correct view at the correct time. That is the purpose of routing.

Angular 2 provides full-featured routing. With Angular we define a route to each page of the application. Then we activate the appropriate route based on the user’s actions. We can pass data to routes, so we can tell the hero detail page to display the details for the hero with an id of 42.

We can guard routes so that a user cannot access a route without a login or only if they are an administrator. We can prevent leaving an edit page until the user confirms they want to save or cancel their changes. We can pre-load data before displaying a page.

Angular 2 supports child routes for navigating within a specific route. For example, we navigate to a detail page and from that page navigate to child routes for a technical specifications page or more information page. This is also useful when displaying tabs of information within a page.

We can even lazy load specific routes so the code for the route is not downloaded to the browser and loaded unless the user accesses the features associated with that route. So if we have admin features for example, those features are not loaded until the user requests to access the admin features.

Together, these many features make Angular 2 routing very flexible and powerful.

5. Minimized size and maximized performance

Size and performance are somewhat related when working with a Web-based application. A smaller component improves startup performance both on download time and compile time in the browser. One of the key goals for Angular 2 is to minimize size and maximize performance.

Minimizing the size of the download is achieved in several ways. First, we can make the size of each component as small as possible. Second, the components are organized into Angular modules in such a way that logical groupings can be downloaded together. And third, lazy loading of routes only downloads the Angular modules required to display the user-selected route. As the user moves to other routes, the needed content is downloaded, and routes the user never use are never downloaded unnecessarily.

Then there is the Ahead of Time (AoT) compiler. With AoT, the compiler runs once at build time. The browser then downloads the pre-compiled version of the application and renders the application immediately, without the need to compile it first in the browser. Plus there is no need to download the Angular compiler, dramatically reducing the application download size.

Angular 2 executes faster, has less work to do and has a low memory footprint.

6. Documentation and community

The documentation for Angular 2, at angular.io, is extensive and varied. It includes a quickstart guide for getting you up to speed quickly with Angular 2. It includes a user guide and an API reference. It provides documentation on more advanced features, and a cookbook with recipes for common tasks such as form validation and dependency injection.

But the best part for learning Angular 2 is the tutorial. It provides a step-by-step code-along experience introducing all of the basic features of Angular 2. Or, if you would prefer a live online classes or classroom training join myTectra : Angular 2

Read more in the post below, which was originally published here on CIO.com.

#angularjs #angularjs2

0 notes