jQuery vs Angular 코드 비교

들어가기 전에

이 포스팅은 지난 2015 나는 프로그래머다 컨퍼런스 중 React 라이브 코딩에서 보고 알게 된 jQuery versus React.js thinking 글에서 영감을 얻어 (원저자의 허락을 받고) Angular 버전으로  쓴 글 입니다.

This post is the result affected by original post “jQuery versus React.js thinking” that I found on React.js live coding session in “I am programmer” conference. I wrote this post with the permission of original blog post’s author.

이 글에서는 아주 간단한 예제를 jQuery와 Angular로 각각 구현하여 어떤 차이점이 있는지 확인해 보려고 합니다. jQuery와 Angular의 직접적인 비교라기 보다 최근의 프론트엔드 프레임워크가 어떤 방식으로 어플리케이션을 구성하는지 확인하기 위한 목적의 글입니다.

예제 설명

예제는 jQuery versus React.js thinking과 동일하며 아래와 같은 기능으로 이루어져 있습니다.

  • 아이템의 목록이 있으며 아이템은 detail 정보를 기본적으로 드러내지 않음
  • 사용자가 아이템 클릭 시에 해당 아이템의 detail 정보가 펼쳐짐
  • 이 때 클릭 안 한 아이템들은 grey로 색 변경
  • 클릭한 아이템을 재클릭 시, detail 정보는 다시 감추고 원래 상태로 돌아감
  • 클릭해서 펼쳤던 아이템 외에 다른 아이템 클릭 시 펼쳤던 아이템은 닫히고 클릭한 아이템을 펼침

jQuery 방식

jQuery 방식의 소스는 원 글의 소스와 동일합니다.

라이브 예제
JS Bin on jsbin.com

jQuery 방식의 구현은 먼저html 파일에 아이템 정보가 정적으로 표현되어 있습니다. JavaScript 코드를 보면 DOM의 정보와 속성을 변경하기 위해서는 “li”, “:hidden”과 같은 셀렉터를 사용해서 접근합니다.

간단한 예제이지만 jQuery방식의 구현의 문제점을 요약하면 역할이 혼재되어 있다는 것입니다. 구체적으로 다음과 같

  1. html 파일 안에 뷰의 정보와 데이터가 공존한다.
  2. JavaScript 코드에 DOM의 조회 및 상태 갱신이 로직이 함께 있다.

결론적으로 기능이 복잡해 질수록 jQuery 방식의 개발 방법론에는 다소 간의 어려움이 있습니다. 그렇다면 Angular를 사용하면 어떻게 구현하는지 확인해 봅시다.

Angular 방식

Angular는 컴포넌트 기반으로 애플리케이션을 구성합니다.  컴포넌트는 화면을 구성할 뷰를  관리할 논리적인 개념입니다. Angular는 뷰와 직접적인 관계를 가진 로직을 컴포넌트에 담습니다. 주로는 데이터를 사용자에게 보여주기 위한 로직이나 뷰에서 발생한 이벤트를 처리하는 로직입니다.

간단한 예제이기 때문에 하나의 파일 안에서 모든 기능을 구현해 넣을 수 있습니다. 하지만 Angular  스타일 다운 특징을 보여주고자 일부 요소를  역할에 맞게 나누었습니다. 예제는 JavaScript에 타입 등의 syntax가 추가된 Typescript로 구현되어 있습니다. 먼저 동작하는 예제를 확인해 봅시다.

라이브 예제

컴포넌트 단위 구성

앞서 잠깐 언급한 것과 같이 Angular는 하나의 뷰를 여러 컴포넌트로 구성합니다. 본 예제에서는 AppComponent, ProductsComponent로 뷰를 구성합니다.  index.html 코드를 보면 다음 코드를 발견할 수 있습니다.

src/app/app.component.ts

app-root라는 태그는 이 예제에서 필자가 선언한 컴포넌트의 태그명입니다. 이 태그의 비밀은 AppComponent의 코드를 보면 알 수 있습니다. AppComponent 코드인 src/app/app.component.ts 파일의 내용은 다음과 같습니다.

코드의 4번줄에 app-root가 보이네요. AppComponent는 5-8번줄에 template에 선언된 뷰 템플릿을 갖는 간단한 컴포넌트 입니다. 본 예제의 루트 컨테이너와 같은 역할을 한다고 생각해도 됩니다.

src/app/products/products.component.ts

그럼, 템플릿의 7번줄에 선언된 app-products도 마찬가지로 다른 컴포넌트의 태그입니다. 하나 남은 ProductComponent가 바로 app-products의 주인입니다. 그럼 역시 코드를 확인해 봅시다.

ProductsComponent는 AppComponent보다 좀 더 긴 코드 입니다.  먼저 5번줄 부터 봅시다. 앞서 AppComponent의 뷰에 선언된 app-products를 확인할 수 있습니다.  이어서 각각 template, styles라는 키에 ProductsComponent의 뷰가 갖는 템플릿 정보와 스타일 정보가 있습니다.

클래스에 선언된 속성은 모두 뷰에서 사용할 상태정보를 담당합니다. jQuery 방식과 달리 데이터를 클래스의 속성으로 선언함으로 명시적으로 뷰와 데이터를 분리한 것을 볼 수 있습니다.

뷰에 노출될 아이템은 28번줄의 products 속성입니다. 이 데이터는 ProductService라는 클래스에 있습니다. Angular는 실제 비즈니스 로직은 Service 클래스에 담도록 안내하고 있습니다. Service를 Component에서 가져다 쓸 때에는 간단한 선언을 통해서 자동으로 Service객체를 주입받습니다. 32번줄의 생성자의 인자가 Component에서 사용할 의존성을 선언하는 방법입니다.

product.service

서비스 클래스는 아이템 데이터를 반환하는 getProducts 메서드 하나 만을 갖고 있습니다. ES6에 추가된 const 키워드를 사용하여 상수로 mock 데이터를 선언하여 메서드에서 반환합니다. 실제 상황에서는 getProducts 메서드 안에서 ajax 호출을 하도록 구현합니다.

2번 라인에서 import한 Product와 12번 라인에 메서드의 반환타입으로 Product[]로 되어 있는 것은 아이템 데이터의 타입을 명시한 Product 클래스 정보입니다. Typescript는 반드시 타입을 필요로 하기에 다음과 같이 모델 클래스를 선언하여 사용합니다.(자세한 내용은 연재 중인 Angular.io 글 목록을 참고해 주세요.)

 

이 글에서 Angular의 모든 것을 일일이 설명하지 않았습니다. jQuery 방식과 비교할 때 Angular는 어떤 형태로 구현하는지를 초점을 두고 가볍게 살펴 보았습니다. Angular 방식의 구현이  jQuery방식과 다른 점은 역할과 관심사의 분리입니다. 명시적으로 파일 혹은 Angular가 제공하는 개념 단위로 관심사를 분리할 수 있습니다.

  • template: 뷰 역할
  • component: 뷰와 모델, 상태 관리
  • service: 비즈니스 로직

분리된 코드는 Angular 프레임워크가 필요에 따라 적절하게 실행할 수 있도록 책임집니다. jQuery 방식에 비해 파일 개수도 늘어나고, 코드의 양도 늘어나지만 Angular 방식은 코드의 양이 늘어나고 복잡해 질수록 기능 개선 및 유지보수에 훨씬 더 쉬운 방면 jQuery 방식은 상대적으로 코드의 복잡도가 증가하게 됩니다.

Angular는 독립적인 컴포넌트 방식으로 뷰를 개발하기 때문에 재사용에도 용이하며, DOM으로부터 벗어나서 컴포넌트 단위로 독립적인 테스트까지 가능합니다.

결론

웹 어플리케이션의 복잡도가 증가하면서 지속적인 개선 및 유지보수를 고려할 때, 일정 규모 이상의 웹 어플리케이션 개발 시 프레임워크 사용은 더 이상 선택사항이 아니라고 생각합니다.

블로그의 내용을 바탕으로 앵귤러 첫걸음 이라는 책이 출판되었습니다. 블로그에서 담기 힘든 자세한 내용을 책으로 엮었습니다. 조금 더 다양한 예제와 설명은 책에서 제공합니다. 블로그의 글도 시간을 내어 최신버전에 맞게 내용을 짬짬히 업데이트 할 예정입니다.

Angular 글 목록보기

참고: jquery-versus-react-thinking