IT/모바일
자바스크립트를 이용한 이벤트 기반 애플리케이션 : MV* 접근법을 위해 jQuery 너머 보기
제공 : 한빛 네트워크
저자 : Patrick Mulder
역자 : 조석규
원문 : Event-driven application design with JavaScript
계산기, 편집기, 아니면 결과창 검색기 같은 데이터를 가지고 상호작용하는 대시보드를 만들려고 할 때, JavaScript와 클라이언트 측 MVC가 중요해지고 있다. 왜 이벤트 기반 애플리케이션 디자인과 상태와 행동이 분리된 인터페이스가 필요해질까? 몇 가지 예를 들어 설명하겠다.
브라우저가 할 일 목록을 위한 편집기처럼 행동하는 간단한 예제를 본 적이 있을 것이다. 이런 애플리케이션에는 텍스트와 상태(완료, 진행중)로 구성된 할 일을 편집한다. 이 작은 편집기는 키보드에서 오는 이벤트들을 감시하고, 페이지 내용 일부를 부분적으로 업데이트하는 것을 배우는 데 매우 유용하다. 이 두 가지가 웹 브라우저에서 돌아가는 애플리케이션을 만드는 중심 원리이다.
할 일 목록보다 더 나아가고자 한다면, 필요한 게 더 많아진다. 예를 들어, 커서 위치를 추적하기 위해서나 글상자 내부의 단어를 세기 위해 변수 여러 개를 이용할 수도 있다. 여러 편집 모드나 텍스트 형식 지정자들, 아니면 편집 후 백앤드와의 상태 동기화 같은 게 필요할 수 있다.
만일 좀 더 진보된 편집기를 만드는 게 아니라, 리더나 문서 탐색기 같은 걸 만들 때라도 MVC 패턴을 알아야 하는가? 클라이언트 측 MVC는 종종 이 경우에도 마찬가지로 중요하다. 예를 들어, 검색 결과를 보여주는 웹 애플리케이션에서 종종 미세 상호작용이 필요한 경우가 있다.
검색 결과 묶음을 보여줄 때, 사용자는 그것들을 "보관함"에 넣거나 "즐겨찾기"로 표시하고 싶을 수 있다. 이것은 작은 정보를 서버에 저장하고 행동의 결과에 따라 로컬 DOM을 업데이트 한다. 또, 사용자가 결과의 상세 사항을 요구하는 경우에 검색 상태를 브라우저에 저장하거나 검색 결과물을 장바구니에 담고 싶을 수도 있다.
jQuery 대안
그러니, 브라우저 이벤트와 상태를 추적한다고 가정하자, 어떻게 애플리케이션을 만들기 시작하겠는가? 한가지 좋은 대안은 jQuery로시작하는 것이다. jQuery를 말하는 데는 여러 이유가 있다.
jQuery 그 너머
애플리케이션이 일정한 규모가 되거나, 한 페이지 애플리케이션을 처음부터 잘 만 들고 싶다면, 다음 두 가지 방법을 쓰는 게 좋을 것이다.
옵저버 패턴과 애플리케이션 상태 표현은 모두 프론트 앤드 MV* 라이브러리와 프레임워크로 구현된다. 하지만 Backbone.js 같은 라이브러리는 제한 없이 사용자의 요구에 따라 애플리케이션을 수정할 자유를 제공해 준다는 의미에서 특별하다.
Backbone.js에서, Backbone 컴포넌트를 필요에 따라 사용할 수 있다. 예를 들어, 사용자 이벤트를 추적하기 위해 Backbone.Views를 사용할 수 있다. 아니면 Backbone.Models과 Backbone.Collections를 jQuery 콜백으로 직접 호출해서 업데이트 한다. 또는 원격지 데이터를 받아와서 모델들과 그 집합을 DOM에서 갱신 할 수 있다.
컴포넌트간의 결합도를 최소화 하는 것은 확장성 말고도 많은 추가적인 장점이 있다. 행동이나 상태를 추가하기 위해 한 군데만 신경쓰면 되고, 비지니스 로직을 여러 인터페이스에 걸쳐 사용할 수 있고, 사용자 이벤트 같은 의존성을 쉽게 흉내낼 수 있기 때문에 인터페이스가 더 테스트 하기 쉽게 된다.
JavaScript로 사용자 인터페이스를 만들게 되면, 서버와 브라우저 양방에 걸친 JavaScript 환경 재사용에 대해 생각하게 될 것이다. Airbnb의 Rendr.js 프로젝트, Facebook/Instagram의 React.js 같은 것에서 선구적인 작업이 진행되었다. Rendr는 자바스크립트를 HandlebarsJS 템플릿 안에 포함한 데 반해, React.js 는 변환 규칙에 따라 HTML을 만든다. 마지막으로, 뷰를 다루는 양쪽 접근법 모두가 Backbone.Models를 통해 멋지게 결합되고, Collections로 애플리케이션 상태를 변경할 수 있다.
안타깝게도 이 모든 이점을 그냥 얻을 수는 없다. 프론트앤드 MV*를 쓰기 전에, 개발, 테스트, 배포를 도와줄 Javascript 빌드 도구를 공부해야 할 것이다. 프론트 앤드 호스팅 유지를 하는 또한 극히 간단한 것부터 서버 사이드 프레임워크와 아주 긴밀히 통합된 것까지 다양한 프론트앤드 자원들을 배포하고 운영하는 데 대한 방법에 대해서도. 이 방법은 현재는 두 가지 의견에 의해 영향 받고 있는데, 하나는 JavaScript 모듈 로더이고, 하나는 JavaScript의 비동기성이다.
웹 업계는 자바스크립트에 덮여 있고, 프론트엔드 MV* 에서 온 개념은 백앤드와 API를 개발하는 자바스크립트 역할에 대한 이해의 기초가될 수 있다. 키/값 자료구조와 집합에 대한 추상화 개념은 Michael Fogus가 그의 책 함수형 자바스크립트에서 설명했듯, 함수형 프로그래밍을 시작할 수 있는 기반이 된다. Backbone.Collections의 일부 개념은 ArangodDB.Foxx나 Everplay의 Serverbone.js 같은 NoSQL 데이터 저장 라이브러리에 널리 퍼져 있다. Promise에 대한 개념은 최소한의 노력으로 병렬 컴퓨팅을 시작할 수 있게 해 준다.
저자 : Patrick Mulder
역자 : 조석규
원문 : Event-driven application design with JavaScript
계산기, 편집기, 아니면 결과창 검색기 같은 데이터를 가지고 상호작용하는 대시보드를 만들려고 할 때, JavaScript와 클라이언트 측 MVC가 중요해지고 있다. 왜 이벤트 기반 애플리케이션 디자인과 상태와 행동이 분리된 인터페이스가 필요해질까? 몇 가지 예를 들어 설명하겠다.
브라우저가 할 일 목록을 위한 편집기처럼 행동하는 간단한 예제를 본 적이 있을 것이다. 이런 애플리케이션에는 텍스트와 상태(완료, 진행중)로 구성된 할 일을 편집한다. 이 작은 편집기는 키보드에서 오는 이벤트들을 감시하고, 페이지 내용 일부를 부분적으로 업데이트하는 것을 배우는 데 매우 유용하다. 이 두 가지가 웹 브라우저에서 돌아가는 애플리케이션을 만드는 중심 원리이다.
할 일 목록보다 더 나아가고자 한다면, 필요한 게 더 많아진다. 예를 들어, 커서 위치를 추적하기 위해서나 글상자 내부의 단어를 세기 위해 변수 여러 개를 이용할 수도 있다. 여러 편집 모드나 텍스트 형식 지정자들, 아니면 편집 후 백앤드와의 상태 동기화 같은 게 필요할 수 있다.
만일 좀 더 진보된 편집기를 만드는 게 아니라, 리더나 문서 탐색기 같은 걸 만들 때라도 MVC 패턴을 알아야 하는가? 클라이언트 측 MVC는 종종 이 경우에도 마찬가지로 중요하다. 예를 들어, 검색 결과를 보여주는 웹 애플리케이션에서 종종 미세 상호작용이 필요한 경우가 있다.
검색 결과 묶음을 보여줄 때, 사용자는 그것들을 "보관함"에 넣거나 "즐겨찾기"로 표시하고 싶을 수 있다. 이것은 작은 정보를 서버에 저장하고 행동의 결과에 따라 로컬 DOM을 업데이트 한다. 또, 사용자가 결과의 상세 사항을 요구하는 경우에 검색 상태를 브라우저에 저장하거나 검색 결과물을 장바구니에 담고 싶을 수도 있다.
jQuery 대안
그러니, 브라우저 이벤트와 상태를 추적한다고 가정하자, 어떻게 애플리케이션을 만들기 시작하겠는가? 한가지 좋은 대안은 jQuery로시작하는 것이다. jQuery를 말하는 데는 여러 이유가 있다.
- jQuery는 클릭이나 입력 같은 이벤트나 변경점을 쉽게 살펴볼 수 있게 해 준다.
- jQuery는 페이지의 HTML을 쉽게 바꿀 수 있게 해 주는 여러 전략을 제공한다.
- jQuery는 IE같은 오래된, 하지만 널리 사용되는 브라우저에서 바로 Ajax를 사용할 수 있게 해 준다.
- jQuery는 풍부한 생태계를 가지고 있어서 많은 플러그인과 예제가 있다.
jQuery 그 너머
애플리케이션이 일정한 규모가 되거나, 한 페이지 애플리케이션을 처음부터 잘 만 들고 싶다면, 다음 두 가지 방법을 쓰는 게 좋을 것이다.
- 옵저버 패턴. jQuery의 on 메소드를 이용해서 DOM 말단의 이벤트들 받아 볼 수 있다. 모든 종류의 로직을 이벤트에 묶는 게 아니라 상태 변화와 유저 인터페이스를 분리하기 위해서 통보자(notifier)를 쓸 수 있다. 많은 MV* 프레임워크가 옵저버 패턴의 형태를 취하고 있다.
- 전용 오프젝트를 가지고 애플리케이션의 상태를 표현할 수 있다. 이는 이벤트의 숫자가 금방 폭발적으로 증가하므로 중요하다. 상태 변경에서 촉발되는 비슷한 많은 이벤트 대신에, 상태를 변수에 사상하고, 그것을 자기 프로그램의 다른 부분에서 업데이트 할 수 있다. 애플리케이션 상태를 MV* 프레임워크에 어떻게 표현하는가에 대해서는 많은 이견이 있다. 순수한 형태로는, JavaScript 객체표현(JSON)이 임의의 키에 값을 저장하고 브라우저 상태를 추적하는 우아한 방법을 제공한다.
옵저버 패턴과 애플리케이션 상태 표현은 모두 프론트 앤드 MV* 라이브러리와 프레임워크로 구현된다. 하지만 Backbone.js 같은 라이브러리는 제한 없이 사용자의 요구에 따라 애플리케이션을 수정할 자유를 제공해 준다는 의미에서 특별하다.
Backbone.js에서, Backbone 컴포넌트를 필요에 따라 사용할 수 있다. 예를 들어, 사용자 이벤트를 추적하기 위해 Backbone.Views를 사용할 수 있다. 아니면 Backbone.Models과 Backbone.Collections를 jQuery 콜백으로 직접 호출해서 업데이트 한다. 또는 원격지 데이터를 받아와서 모델들과 그 집합을 DOM에서 갱신 할 수 있다.
컴포넌트간의 결합도를 최소화 하는 것은 확장성 말고도 많은 추가적인 장점이 있다. 행동이나 상태를 추가하기 위해 한 군데만 신경쓰면 되고, 비지니스 로직을 여러 인터페이스에 걸쳐 사용할 수 있고, 사용자 이벤트 같은 의존성을 쉽게 흉내낼 수 있기 때문에 인터페이스가 더 테스트 하기 쉽게 된다.
JavaScript로 사용자 인터페이스를 만들게 되면, 서버와 브라우저 양방에 걸친 JavaScript 환경 재사용에 대해 생각하게 될 것이다. Airbnb의 Rendr.js 프로젝트, Facebook/Instagram의 React.js 같은 것에서 선구적인 작업이 진행되었다. Rendr는 자바스크립트를 HandlebarsJS 템플릿 안에 포함한 데 반해, React.js 는 변환 규칙에 따라 HTML을 만든다. 마지막으로, 뷰를 다루는 양쪽 접근법 모두가 Backbone.Models를 통해 멋지게 결합되고, Collections로 애플리케이션 상태를 변경할 수 있다.
안타깝게도 이 모든 이점을 그냥 얻을 수는 없다. 프론트앤드 MV*를 쓰기 전에, 개발, 테스트, 배포를 도와줄 Javascript 빌드 도구를 공부해야 할 것이다. 프론트 앤드 호스팅 유지를 하는 또한 극히 간단한 것부터 서버 사이드 프레임워크와 아주 긴밀히 통합된 것까지 다양한 프론트앤드 자원들을 배포하고 운영하는 데 대한 방법에 대해서도. 이 방법은 현재는 두 가지 의견에 의해 영향 받고 있는데, 하나는 JavaScript 모듈 로더이고, 하나는 JavaScript의 비동기성이다.
웹 업계는 자바스크립트에 덮여 있고, 프론트엔드 MV* 에서 온 개념은 백앤드와 API를 개발하는 자바스크립트 역할에 대한 이해의 기초가될 수 있다. 키/값 자료구조와 집합에 대한 추상화 개념은 Michael Fogus가 그의 책 함수형 자바스크립트에서 설명했듯, 함수형 프로그래밍을 시작할 수 있는 기반이 된다. Backbone.Collections의 일부 개념은 ArangodDB.Foxx나 Everplay의 Serverbone.js 같은 NoSQL 데이터 저장 라이브러리에 널리 퍼져 있다. Promise에 대한 개념은 최소한의 노력으로 병렬 컴퓨팅을 시작할 수 있게 해 준다.
TAG :
최신 콘텐츠