먼저, UI를 바탕으로 컴포넌트를 분할해본다. 이 때, 기본 원칙은 하나의 컴포넌트는 하나의 역할을 한다는 것이다(단일 책임원칙). 뿐만 아니라 컴포넌트를 구성할 때에는 '재사용성' 측면을 고려해야한다. 예를 들어, Modal을 하나 만들어놓고, pwdModal 등 다양한 Modal에서 재사용할 수 있도록 한다. 컴포넌트를 분할한 다음에는 그 컴포넌트 들을 계층(상하구조)별로 나누어 본다. 그 다음에, 정적인 버전의 리액트 앱을 만들어 본다. 즉, state를 구성하지 않고, props로 더미 데이터를 내려주며 만들어본다. 이 때, 상향식 개발 순서는(아래서 위로) 주로 어렵고, 복잡한 앱에, 하향식 개발 순서(위에서 아래)는 대부분 간단한 앱에서 사용한다. 그 다음으로, 이제는 state를 결정한다. 이 때, state의 조건을 기억해야한다. state는 먼저, 바꿀 값이여야 한다. 즉, 계속 정적인 값은 state로 쓸 필요가 없다. 다음으로, props로 내려받는 값이 아니여야 한다. 마지막으로, 굳이 중복되어서는 안된다. 즉, 다른 state로 얻을 수 있는 값을 또다시 state로 만들어서는 안된다. 마지막으로, state를 어느 컴포넌트에 위치시킬지 정한다. 공동 소유 컨테이너 컨포넌트(대부분의 컴포넌트를 포함하는)보다 상위 컴포넌트에 state를 위치시키는 것이 좋다. 이에 더하여, state 끌어올리기(역방향 설계, 본래 state를 props로 내려주는 것이 정방향 설계라면)도 설계해준다.
figma를 통해 팀원과 함께 UI를 설계하고, 그 설계한 부분을 제플린에 export하면, 디자이너와 개발자가 협업할 수 있다. 현실에서는 디자이너가 figma를 통해 설계해놓고, 제플린에 공유하면, 개발자가 그것을 보고 css 정보 등도 얻는 형태일 것이다.
너무나도 지친다. 역시 SR기간이 제일 어렵다.. 하지만 이 기간에 이렇게 힘들어야 나중에 계획대로 순탄하게(?) 진행될 수 있기에 좀만더 노력하자. 나는 솔직히 웹 디자인 쪽에는 소질이 없는 것 같다. 하지만, 뭐 개발자니까 상관없다!. 파이팅하자