개인 사정으로 인해 1년이라는 시간이 훌쩍 지나가 버렸다.
다시 개발자의 길을 걷기로 다짐하고 나서 바로 프로젝트를 만들기로 다짐했었는데 막상 다시 돌아오고 나니 뭔가 붕뜬 느낌이었다.
앞길이 막막한 느낌? 어떻게 코드를 짰더라.. npm으로 어떻게 켰더라.. 이 생각에 2일간 절망에 빠졌었는데 다행히도 차근차근 하다보니
금방 기억이 나고 몸이 기억해서 3일째부터는 조금씩 나아지기 시작했고, 일주일이 지났을 때부터는 예전처럼 코드를 짤 수 있게 되었다.
그동안 정말 만들고 싶었던게 있었는데 바로 메이플 관련 사이트였다.
메이플은 한동안 푹 빠져서 했을 정도로 애정이 많은 게임이었기도 하고, OPEN API가 공유 되면서 유저들의 정보와 스킬, 스탯 뿐만이 아니라 큐브와 스타포스 히스토리등 이용할 수 있는게 굉장히 많았다. 비매너 유저를 찾을 수 있게 되기도 해서 한동안 비매너 유저의 박제글이 생겼을 정도였으니.. 아무튼 통합적으로 다루는 사이트는 없나하고 보니 그런 사이트는 없어서 유저 정보, 큐브, 스타포스 히스토리를 다루는 사이트를 만들기로 결심했다.
1. 디렉토리 구조
디렉토리 구조는 전에 사용하던 것과 거의 비슷하게 사용하기로 했다.
다만 이번에는 조금씩 명칭을 달리해서 api 작업은 services쪽에서 하기로 했다.
또한 components에서 저번에는 features, layout으로 api 위주 작업과 레이아웃 작업 위주 작업을 구분했었는데, 이번에는 더 직관적으로 볼 수 있게 바꿨다. 아마도 많은 UI 관련 컴포넌트들이 생긴다면 common으로 배치하지 않을까 싶다.
그리고 저번에는 Pages에서 api관련 작업도 했었지만 이번에는 그러지 않고 pages 디렉토리는 라우터 작업만 했다.
라우터 작업만 함으로써 params를 내리는 용도로 작업하는게 더 직관적으로 작업할 수 있었다.
해당 페이지의 api, layout은 components에서 구현하고 pages에 넣어줬다.
2. 컴포넌트 구조
지난 수풀 프로젝트를 진행 했을 때는 하나의 컴포넌트에서 거의 모든 작업을 진행 했었다. 이 점은 하나의 컴포넌트에서 작업하기 때문에 다른 컴포넌트를 드나들 필요 없다는 점과 다른 컴포넌트를 굳이 만들지 않아도 돼서 작명을 하지 않아도 되고, 보기에도 편한 느낌이 들어 굳이 많은 컴포넌트를 생성하지 않았었다.
하지만 TypeScript를 도입하고 나서부터 생각이 바뀌었었다. 한 번만 만들고 말 사이트라면 컴포넌트를 굳이 나눌 필요는 없겠지만, 유지보수를 꾸준히 하게 된다면, 그리고 만약 작업자가 바뀌게 된다면, 방대한 코드로 이루어진 컴포넌트를 마주할 것이다.
이런 코드를 유지 보수를 한다는 것은 끔찍할 것이라 생각하게 되었고, 따라서 컴포넌트를 최대한 UI 별로 혹은 기능별로 나누게 되었다.
내가 직접 몸소 겪으니 디렉토리 및 컴포넌트 구조의 중요성을 알게 되었다.
디렉토리나 컴포넌트 구조라는게 검색한다 하더라도 사람들마다 다 달라서 정답이라는 것을 알 순 없지만, 완전 정형화 되어 있는 자료를 볼 수 있으면 좋을 것 같다.
위와 같이 view에 따라 컴포넌트를 나누어 주었다. 누군가의 입장에서는 더 나눠야 할수도, 덜 나눠야 할수도 있지만, 내 입장에서는 더 나누게 된다면 많은 props를 발생시킬 것 같고, 전역 상태가 필요하게 될수도 있다고 생각되어 더 나누진 않았다.
api 작업을 하는 컴포넌트를 중점으로 하위 컴포넌트를 한 개로 두어 작업을 진행했다.
Char 컴포넌트에서 api 작업을 하면
하위 컴포넌트에 뿌려 주는 방식이다.
전역 상태 관리를 최소화 하고 싶었다. 전역 상태 관리라는 것이 언제 어디서나 사용가능하다는 장점이 있지만, 이게 정확히 어디에 쓰이는건지, 무슨 역할을 하는건지 다시 되돌아가서 확인을 해야되기 때문에 유지보수에 차질이 생길 것 같다는 생각이 들었다.
따라서 전역 상태 관리는 최대한 피하고 낮은 props driling으로 해결을 하고자 상위 컴포넌트에서 api 작업을 하고, 바로 하위 컴포넌트에 뿌려주는 방식을 채택했다.
'토이프로젝트 > MapleInfo' 카테고리의 다른 글
| [MapleInfo] 다크모드 (0) | 2024.04.30 |
|---|
