CommonButton, CommonInput 이런 식으로 모양새가 비슷한 버튼이나 input을 공통 컴포넌트로 빼서 props를 받아 사용하는 방식을 개인적으로 애용했다.
분명 이름은 "공통"인데 위치에 따라 width, height 등이 달라지는 경우에 props가 하나둘씩 추가되는 문제가 항상 거슬렸다.
이 문제의 두가지 원인은 아래와 같다.
섣부르게 공통같아 보이니 빼자! 라는 생각을 버리자.
비슷한 것들이 계속 반복돼도 일단 다 만들어둔 후에 여러 옵션들을 생각하고 공통으로 빼서 수정하는게 맞다!
결국 처음에 만들어두면 공통 컴포넌트가 공통이 아니게 되는 이상한 컴포넌트가 만들어진다.
기획서 작업이 완료되고 디자인을 기다리는 동안 프론트엔드, 백엔드가 서로 api 정의서 관련 회의를 한 후 프론트엔드는 시간이 붕뜨게 된다.
그 시간에 그저 손놓고 기다릴 수는 없으니, ui를 제외한 데이터 부분은 미리 작업을 해야 한다.
여태껏 목업 데이터를 단순히 객체, 배열로 선언하여 끌고 왔었는데 이렇게 작업할 경우 결국 api가 나오기 전까지 프론트엔드는 할 수 있는 업무가 한정적이다.
typescript를 쓴다는 가정 하에 (이제 typescript는 거의 필수이니), interface로 각 api의 type을 선언 후 api로 데이터를 불러오듯이 함수를 정의하고 활용해보자!
사실 OOP처럼 테스트 코드도 작성해보고 활용해봐야 한다는 막연한 생각만 갖고 외면하고 있었다.
현재 작업하고 있는 블로그 만들기 프로젝트 초반에
이 두 가지는 내꺼로 체화시키고자 하는 목표가 생겼다!
Keep, Problem, Try의 약자로 회고 내용을 세 가지 관점으로 분류하여 회고를 진행한다.
KPT에 맞춰 회고하는 습관을 들여보자!
블로그 프로젝트에서 새로운 목업 데이터 작성법 활용, 테스트 코드 작성 및 활용을 열심히 해볼 것이다!
패턴을 실제로 적용해서 만들어보는건 사실 아직까지 너무 이르지 않을까란 생각이 들었다. 적용 전에 이론부터 알아야할 것 같은...
제일 먼저 class형 함수와 팩토리 패턴에 대해 공부를 해보자!
와 짧으면 짧고 길면 긴 시간 안에 많은걸 배우며 내 자신을 돌아봤다. (역시나 예상대로 우당탕탕이였던..>_o)
내 성격에 분명 한 번에 다 소화시키려고 하면 체할게 분명하니 당장 적용시킬 수 있는 것부터 하나씩 차근차근 나아가보자!