Form

머릿말 

  Angular의 Form은 두 가지 종류가 있다. 한가지는 Template-driven 방식, 다른 한가지는 Reactive 방식이다. 이번 글에서는 Template-driven 방식과 Reactive 방식의 특징과 차이점을 살펴보고, Template-driven 방식 보다 Reactive 방식이 왜 더 좋은지 살펴볼 것이다.

  Template-driven 방식의 공식 문서는 Template-driven Forms에서 확인 할 수 있고, Reactive 방식에 대한 공식 문서는 Reactive Forms에서 확인 할 수 있다. 해당 글에서는 각각의 코드 사용법은 거의 언급하지 않을 것이므로, Angular Form에 대한 사용법을 알기 위해 이 글을 찾아 왔다면, 공식 문서로 찾아갈 것을 권장한다. Angular의 공식문서는 번역이 안되있어서 그렇지 아주 잘 되어 있다.

  해당 글에서 언급하는 단어 중 템플릿은 *.html 파일이고 컴포넌트 클래스는 *.ts 파일이다.

Template-driven 방식

  Template-driven 방식은 입력 폼에 ngModel을 이용해 템플릿에서 폼 관리를 하는 방식이다. 

  Template-driven 방식은 컴포넌트 클래스에 적은 코드를 쓰고도 사용 할 수 있다는 것이 장점이다. 또한 양방향 데이터 바인딩은 angular의 공식 튜토리얼인 Tour of Heroes에서도 사용하고, 여러 공식 예제에서도 심심치 않게 볼 수 있기 때문에 처음 angular를 접하는 사람들은 양방향 데이터 바인딩이 only way 혹은 best way라고 생각한다. ( 필자도 처음 angular를 시작했을 때는 베타 버전이었고 참고 할 만한 레퍼런스나, 예제가 공식 문서 밖에 없었기 때문에 당연히 양방향 데이터 바인딩이 쉽고 쓰기 좋았고, 폼을 구성하는 유일한 방법인 줄 알았다. ) 

  지금은 공식문서에 그런 언급이 사라졌지만, 예전 공식문서에는 양방향 데이터 바인딩은 성능 이슈에 문제가 될 수 있으니 정말 필요한 곳에만 사용하라고 언급을 했다. (글을 쓰기 위해 CHANGELOG.md를 살펴봤지만 별다른 업데이트 내역은 찾아볼 수 없었다.)

  성능 문제가 아니더라도 angular는 템플릿과 컴포넌트 클래스의 역할 분리를 권장한다. 간단한 대입문도 왠만하면 컴포넌트 클래스에서 함수를 만들어서 할 수 있도록 하는 걸 보면 역할 분리를 엄격하게 했으면 하는 철학을 가진 것 같다. 하지만 Template-driven 방식은 이름에서도 알 수 있듯 템플릿에서 Form에 대한 기능을 주도하고 있다. 이렇게 되면, 컴포넌트 클래스는 폼에 대한 권한이 템플릿에 있으므로 사용자의 입력을 비동기적으로 처리 하게 되고, 개발자는 컴포넌트 클래스에서 변수를 사용함에 있어 초기화 문제가 발생하여, 하지 않아도 되는 예외 처리를 해야 할 수도 있다.

  이러한 문제점들을 Reactive 방식에서는 대부분 해결 할 수 있다.

Reactive 방식

 Reactive 방식은 ReactiveForm에 속하는 FormBuilder, FormControl, FormGroup, FormArray를 이용하여, 컴포넌트 클래스에서 주도적으로 폼에 대한 구조를 명세하고, 폼에 속하는 변수와 그에 대한 초기화를 담당하므로서 앞서 Template-driven 방식에서 있었던 문제들을 대부분 해결 할 수 있다.

  공식 문서에서 Reactive 방식에 대한 코드를 봤다면 알겠지만, 컴포넌트 클래스에서 FormBuilder를 이용하여 FormGroup과 FormControl, FormArray로 폼에 대한 구조화를 미리 명세해 놓고, 템플릿에서 입력 폼을 만들고 FormBuilder에 등록된 FormGroup과 FormControl을 차례대로 놓아주면 FormBuilder를 통해 Validation, Status 체크를 컴포넌트 클래스 내에서 동기적으로 수행할 수 있게 된다. 이 뜻은, 앞서 말했듯 컴포넌트 클래스에서 폼에 대한 주도권을 가지고 있는 것이고, 이에 따라, 컴포넌트 클래스에서 폼에 따른 알고리즘을 개발자의 입맛에 맞게 설정 할 수 있다는 것이다.

  또한, Reactive 방식을 사용하게 되면 Validation을 컴포넌트 클래스에서 정해 줄 수있어, 폼에 대한 기능을 모두 한 곳에서 관리 할 수 있게 된다. 이는 향후 유지보수에서도 상당한 도움이 된다.

  하지만, Template-driven 방식에 비해 신경을 써야할 부분이 두군데가 되기 때문에 스트레스가 있을 수도 있다. 그럼에도 앞서 Template-driven 방식에서의 단점이 그 스트레스보다 크기 때문에 Reactive 방식을 채용하는 것이 프로젝트를 장기적으로 봤을 때 더 효율성이 높다고 볼 수 있다.

맺음말

  Reactive 방식이 Template-driven 방식에 비해 개발, 유지보수의 입장에서 더 효율적이라는 것을 보았다. 추가적으로  필자의 경험상 Template-driven 방식을 사용했을 때 연관된 변수들을 관리하고 템플릿에서 넘어오는 값들에 대한 예측을 하면서 예외처리를 한 것보다 Reactive 방식을 사용 했을 때 직관적으로 보이는 초기값, Validation들이 있기 때문에 넘어오는 값을 예측하지 않아도 됐기 때문에 오히려 개발 스트레스가 적어졌었다. 또, 유지보수를 할 때에도 폼이 추가되지 않는 이상 컴포넌트 클래스를 벗어나 수정해야 할 사항이 없기 때문에 유지보수도 훨씬 수월했다.

  Tour of Heroes 같은 곳에서 Template-driven 방식을 쓰고 있지만, 그것은 한 코드에서 모든 것을 보여주는 게 훨씬 이해하기 쉽기 때문에 그렇게 구현하지 않았을까 생각하고 있다.

  하지만, 성능상의 문제를 가지고 있는 양방향 데이터 바인딩과 역할 분리가 제대로 되지 않았다는 문제점을 가진 Template-driven 이기 때문에 필자의 생각으로는 그 방법을 쓰는 것을 지양해야 한다고 생각한다.