티스토리 뷰

그 많고 많은 Javascript Library는 어쩌라고...


ng로 View를 구성하면서, 예전에 써오던 Javascript Library(이하 JS LIB)를 사용하려고 했었다. 문제는 Angular는, Spring 처럼 틀에 정해진 injection을 제공하기 때문에 마음대로 JS LIB를 사용한다면 의존성 개무시 상황에 이를 수 있게 된다. 다시 말하자면 엘레강스하거나 깔끔해지지 못한다는 것이다.


마손리를 처음에 적용할 때도 jquery 기반의 마손리를 선택 했었고, 그게 큰 짐으로 다가왔었다. 그래서 같이하는 팀원과 이에 대해 심도 깊은 대화를 하였고, 그 때 하는 말이,


"대부분 유명한 JS LIB들은 Angular로 앞에 붙여서 검색하면 Angular 기반 모듈로 만들어진 것들을 얻을 수 있을 텐데요?"


 WHAT? 


그 말을 듣자 마자, 마손리가 ng 기반으로 있는지 검색해봤다. 해보니, 있네. 있어.


ng를 하면서 가장 힘들었던게, 바로 이 부분이었는데 역시 선구자님들께서 나같은 어린양을 위해 벌써부터 준비해 놨구나를 확인한 결과, 참 기분이 오묘했다. 물론 bower를 이용하여 간편 다운로드 기능들은 대부분 지원해주는 건 당연지사.


참고로, 왠만하면 ng 기반의 라이브러리들은 bower를 통하여 다운받도록 하자. 나를 이것도 사람이 만들기 때문에 완벽한 경우는 없어서, 그냥 다운 받아서 해봤더니 에러나고 뭐가 없다고 그러고... 이상하게 라이브러리를 만들어서 배포하는 사람들은 bower로 다운받는 것에 더 신경을 쓰는 경향이 있었고, 이렇게 다운받아서 문제없이 사용할 수 있는 경험이 많았다. (대표적인것이 angular-masonry)


물론 bower가 완벽히 의존성등을 처리해 주는 것이 아니지만, 아무것도 모르는 상황에서 첫 시도로 bower를 사용해서 다운받는 것 나쁘지 않고, 차후 배포 시에도 bower config 파일을 잘 정리해서 배포하면 관련 라이브러리를 같이 올리지 않아도 각 배포 단에서 손쉽게 다운받아 설치할 수 있기 때문에 쓸만하다.



다이얼로그 하나 출력하는데...


jq에서는 레이어 팝업 형태인 다이얼로그를 출력하기 위해서 출력할 페이지 내 <div> 태그로 감싸는 다이얼로그를 구성하고, 여기에 동적이든 정적이든 커스텀 레이아웃을 만들고 jq의 기능으로 다이얼로그를 부르면 됬었다. 하지만, material에서 지원하는 다이얼로그는 좀 UI구조가 들어간다 하면 각각의 template.html과 controller.js를 만들어야 하고, 서로 다른 controller이기 때문에 $scope 영역이 달라지면서 모델간의 연동을 해줘야하는 일이 벌어진다.


다시 말하자면 딸랑 이거 하나 만드는데 불필요한 코드들이 너무나 많이 들어 간다는 것이다. 강력한 가이드를 제공해줘서 차후 ng를 아는 개발자끼리는 유지 보수에 편리성을 주겠지만, 막상 사용하기 위해 들어가는 러닝커브의 어려움()이 이런것들의 강력한 역할을 하고 있다. 물론 이 틀이라는 것이 익숙해 지면 편하겠지만... (Ctrl+c, Ctrl+v와 작은 코딩 변경만 하면 되니까.)



페이지 하나가 복잡하면 어렵기는 매한가지...


가장 중요하면서도 많은 정보가 출력하는 상세 페이지에서 사용자들이 보는 것 만이 아닌 그 자리에서 추가/수정/삭제를 한다고 보자. 일단 이러한 구조는 필연적으로 html에 많은 코드들을 강요하게 된다. 일반적인 관리 프로그램들은 한 화면에 하나의 기능만 하는 경우가 많기 때문에 복잡도가 높지 않지만, 여러 기능을 하나의 페이지에 구성하면 기하급수적으로 늘어난다.


특히, jq 기반의 웹 앱은 이러한 경우 개발자 개개인이 자신만의 가이드를 제공하면서 화면을 구성하면 유지보수가 그나마 낳겠지만, 그렇지 않다는게 큰 문제다. 대부분의 개발자는 자신에게 부여된 데드라인을 맞춰 개발하기 위해 수단과 방법을 가리지 않기 때문이다. 조그마한 주석이래도 달아주면 감사할 정도로 이기적으로 변하고 개발에 임하게 된다. 데드라인의 가까울 수록 이러한 이기적인 성향은 더 강해지며, 데드라인이 저 멀리에 있다면 아직은 이기적으로 변하지 않는다.


그런 상황에서 ng의 디렉티브는 매력적이다. 디렉티브는 자주 쓰는 로직을 함수화 시켜서 계속 사용하는 것 처럼 view와 controller를 하나의 컴포넌트화 시켜 차후 개발 시, 간단하게 불러와 사용할 수 있게 해준다. 그게 html의 태그 형식이 될 수 있고, 태그 내 어트리뷰트가 될 수 도 있다. 그건 만든 사람이 선언하기 나름이고, 이것만 쓸 줄 알고 이해한다면 ng에 대해 중급 이상은 하지 않을까 생각된다.


ng도 디렉티브를 사용하지 않고 복잡도가 높은 페이지를 구성하게 된다면 jq랑 별차이가 없다는게 내 생각이다.



SPA에 특화된 ng


Single Page Application에서 ng가 강하다. 한페이지 내에 동적으로 코드를 바꿔서 출력하는 형식의 SPA는 필요로 하는 .js를 다 호출해서 가지고 있기 때문에 기능을 사용함에 있어서 추가나 중복적으로 .js를 서버에서 다운로드 받을 필요가 없어지는 강점을 가지고 있다. 하지만, 한번에 연관된 (쓰든 쓰지 않든) 모든 .js를 다 가져오기 때문에 첫 로딩에 부하가 있을 수 있다. 물론 많은 선구자들 덕분에 lazy하게 로드할 수 있는 방안은 검색하면 충분히 나오지만, ng에서 사용하는 controller는 내가 알기로 모두 가져와야 하는 것으로 알 고 있다. 


아직 나에게도 숙제이고 이 글을 보는 분들도 한번 즈음 생각해 봄 직 하다.


jq와 다르게 SPA 구성하기 위해서 제공되는 ng만의 틀은 깔끔하게 분산하여 개발할 수 있게 해주고, 이는 한 페이지를 여러 개발자가 같이 개발할 수 있게 할 수 있는 환경을 제공해 주는 것도 좋은 점이다.

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/03   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
글 보관함