*비 개발자를 대상으로 하는 설명으로 현상을 좀 더 쉽게 설명하는 데 중점을 뒀습니다.
삼분의일은 angular를 이용해서 SPA(Single Page Application)방식으로 웹페이지를 준비하고 있습니다. 함께 일하고 있는 동료들에게 angular에서 발생하는 레고 같은 component들의 조합방식을 설명하고, 우리 브랜드를 대표하는 웹페이지의 뒤에서는 과연 어떤 일이 일어나고 있는지 공유하기 위해 이 글을 작성합니다.
고객이 웹페이지에 들어와 리뷰를 남기기 위해 리뷰 버튼을 클릭하면 일어나는 일 들을 비 개발자인 동료들이 좀 더 쉽게 공감할 수 있도록 풀어서 작성하려 노력했습니다.
[리뷰, 그 긴 여정의 시작]
먼저 이런 웹페이지가 있다고 생각해 봅시다.
여기서 사용자는 상단의 reviews버튼을 클릭하며 여러 고객이 쓴 여러 리뷰들이 나오는 리스트를 상상할 것입니다. 이렇듯 여러 리뷰들을 보여주기 위한 여정의 시작이 바로 상단의 reviews버튼을 클릭하는 행동입니다.
[리뷰는 다 같은 리뷰가 아니야]
곰곰히 생각 해 보면 리뷰라는 큰 덩어리에 관련된 일들은 하나가 아니라는 것을 알 수 있습니다. 사용자가 메인에서 reviews 버튼을 클릭해서 나타난 창을 보면서 리뷰 라는 큰 덩어리를 쪼개보도록 하겠습니다.
reviews버튼을 클릭하면 review라는 새로운 화면을 보여주게 되겠죠. 보여준다는 것은 실존한다는 말이니, review라는 새로운 component가 생성되고 화면에 뿌려진 것이라는 것을 알 수 있습니다.
그치만 이 review component의 하는일을 잘 살펴보면 또 여러개의 조각으로 나누어 볼 수 있습니다.
여러 리뷰들을 보여주는 review-list component, 그리고 새로운 리뷰를 쓸 수 있도록 하는 write 버튼이 될 수 있겠죠.
그런데, 자세히 보면 review-list component의 내용은 각각 한개의 리뷰들의 반복으로 이루어져 있음을 알 수 있습니다. 각각의 리뷰를 review-item component라 칭하면, 결국 review-list component는 반복된 review-item component 들과 write 버튼으로 이루어져 있네요.
(review-item component는 한 개를 만들어 둔 후에 우리가 갖고 있는 리뷰의 갯수만큼 반복해서 생성할 수 있습니다. 1000개의 리뷰가 있다면 review-item component를 1000개 만드는 것이 아닌 한 개를 만들어서 1000번 반복해서 보여주기만 하는 것이죠.)
그럼 이쯤에서 한번 정리를 해 볼까요? 지금까지 나온 리뷰와 관련된 화면은
-review component
-review-list component
-review-item component
로 정리할 수 있습니다.
여기까지가 사용자가 메인 페이지에서 reviews 라는 버튼을 클릭했을 때 다른 사람들이 쓴 여러 리뷰를 보여주는 화면을 만들기 위해 있어야 하는 component 들입니다. 그럼 단순히 다른사람의 리뷰를 보여주는 화면 이외에 사용자가 새로운 리뷰를 작성할 때는 어떨까요?
[에헴 ~ 새로운 리뷰를 작성하고 싶다면, 새로운 페이지를 내놓거라]
reviews 버튼을 클릭하고 review-list component가 보여주는 페이지에서 여러 리뷰들을 보던 사용자는 갑작스레 리뷰를 작성하고 싶어집니다. 그럼 상단에 있는 write 버튼을 클릭하게 되겠죠. write 버튼을 클릭하는 그 순간, 새로운 리뷰를 작성하기 위해 필요한 정보들을 입력받을 수 있는 review-new component 가 새롭게 렌더링 됩니다.
여기서 잠깐, review-new component 또한 review와 관련된 화면이기 때문에기존의 커다란 화면 전체를 감싸고 있는 review component안에서 나타나게 됩니다. 쉽게 말하면 커다란 review component 안에 review-list component가 보여지고 있던 상황에서 write버튼을 클릭하는 순간 review-list component가 있던 자리를 review-new component가 대신하는 것이죠. 그럼 이제 새롭게 등장한 review-new component를 뜯어볼까요.
아무래도 새로운 리뷰를 받는 화면이다 보니, 입력 폼들의 향연이 펼쳐집니다.
이름, 나이, 이메일 , 사는 곳 등등 사용자가 새로운 리뷰를 작성하는 데 필요한 기초 정보들과 리뷰의 내용을 입력받는 부분을 그려주고 있습니다. 여기서는 별다르게 반복되는 것들이 없어 보이는 것은 기분 탓일까요.. 그렇기 때문에 review-new component에서는 다른 기능을 가진 component들을 더 이상 추가하지 않기로 합니다. 그럼, 다시 정리를 해 보도록 하겠습니다.
지금까지 나온 리뷰와 관련된 모든 화면은
-review component
-review-list component
-review-item component
-review-new component
로 총 4개가 됐습니다.
[화면에 들어가 있는 데이터는 원래 그 곳에 있던 것일까?]
위에까지 리뷰와 관련된 화면들을 정의해 봤습니다. 이 화면 들에서 보여줘야 하는 데이터들은 어떻게 받아 오는 것 일까요? 또한, 사용자가 정성스레 작성한 리뷰를 저장하는 부분도 있어야 하지 않을까.. 하는 생각을 갖게 됩니다.
우리 지금까지 말한 화면들에서 데이터를 얻기 위해 서버에 접근하는 경우를 생각해보면 간단하게 생각해도 최소 2번의 접근이 필요합니다.
맨 처음 여러 사용자들의 리뷰를 보여주는 review-list component에서 엄청나게 많은 리뷰 데이터들을 받아오는 Fetch 부분 , 그리고 사용자가 리뷰를 작성하고 submit버튼을 눌렀을 때 사용자가 작성한 데이터를 DB에 저장하기 위한 Add부분입니다. (더 많은 접근이 필요하지만, 복잡함을 최소화 하기 위해 두가지 경우만 생각하겠습니다.)
벌써 리뷰와 관련된 component만 5개인데, 우리가 제공하고자 하는 웹페이지의 모든 화면과 기능을 만들면 더욱 많은 component들이 생기게 될 것입니다. 그렇게 많은 component들이 생겼을 때 리뷰데이터 뿐만 아니라 여러 데이터들이 문제없이 효율적으로 잘 돌아가게 하기 위해 우리는 store라는 저장소를 하나 생성한 후 앞서 말했던 리뷰 데이터 Fetch부분과 Add부분을 store를 통해 동작하게 합니다. (삼분의 일에서는 ngrx를 사용합니다.)
앞으로는 데이터와 관련한 동작들은 모두 store라는 저장소를 통해서 행해지며 리뷰 데이터에 관한 동작 또한 store라는 저장소를 거쳐 움직이게 될 것입니다.
하지만 이 store를 사용하기 위해서는 꼭 따라야 하는 프로세스가 있습니다. 이 프로세스에 필요한 action, reducer, effect 3가지 파일을 추가로 생성해 리뷰데이터에 접근하겠습니다.
그럼 이쯤에서 리뷰에 관한 화면과 기능을 정리해 보면,
-review component
-review-list component
-review-item component
-review-new component
-review-actions
-review-effects
-review-reducers
우와.. 리뷰에 관해 신경써야 할 것이 어느새 7개가 되었습니다.
그리고 review-actions, review-effects, review-reducers 이 3개의 파일은 리뷰에 관한 것이라면,
새로운 리뷰를 저장하거나, 기존에 있는 리뷰를 불러오는 행동 이외에도 필요한 행동이 있을 때마다 해당 행동들을 추가하여 관장하게 됩니다.
때문에 fetch와 add 이외에도 좀 더 많은 함수들이 추가될 수 있겠죠.
[번외, 리뷰에 필요한 그 밖의 이야기들..]
지금까지 말한 일련의 행동 이외에도
리뷰를 작성하려고 write버튼을 눌렀을 때 회원가입이 되어 있는지 아닌지,
회원가입이 되어 있다면 우리 제품을 주문한 기록이 있는지
그리고 그 주문건에 대하여 리뷰를 이미 작성한 적이 있는지에 대한 등의 validation 작업들과 그에 따라 서버에서는 일어나는 수많은 행동들..
지면관계상 미처 다 설명하지 못한 여러 행동들이 웹페이지 뒤에서 열심히 뚜쉬뚜쉬 일어나고 맞물리며 한 가지 기능을 온전히 제공하게 됩니다.
사용자가 웹페이지에 접속한 순간 부터 웹페이지는 마치 심장처럼 멈춤 없이 요청을 하고 응답을 받으며 누구보다 열심히 돌아가게 됩니다.
부족하지만 이 글을 통해 component를 쪼개고 조합하는 과정이 마치 레고를 조립하는 것처럼 조금이라도 더 쉽게 와닿았기를 바랍니다.