JS vs TS
사실 이 프로젝트가 처음으로 해보는 리액트 프로젝트라 많이 부족한 점이 많았다.
타입스크립트를 적용하고 싶었으나 아직 배우지 않아 적용하지 못하였다.
패턴 및 최적화
ContextAPI와 useReducer를 사용하여 자연스럽게 FLUX 패턴이 적용되었다.
커스텀 훅과 useCallback, useMemo, debouncing 등을 이용하여 좀 더 최적화 할 수 있었을텐데 시간이 부족하여 하지 못하였다.
style
css는 styled 컴포넌트를 처음으로 써보았는데 파일이 분리되지 않는 장점이 있었으나
파일내 코드가 길어지는 단점이 있었다. styled component의 스타일에 맞게 모든 html jsx 태그들을 styled component로 변경하였다. 이렇게하면 jsx 부분이 모두 html 태그명이 아닌 컴포넌트 명이라 뭔가 더 제대로된 CBD 느낌이 난다. 물론 이 것이 정확한 컨벤션인지, 베스트 프랙티스인지는 모르겠지만...
API
axios와 fetch중 고민하였는데 axios를 한 번도 사용해보지 않아 일단 fetch로 구현하고 나중에 변경해보려고 했는데 그럴 필요를 딱히 못 느꼈다. 아마 프로젝트가 Todo 사이즈라 중복이 많지 않아 그런가 보다.
hook
많이들 보면 중복 사용되는 로직 및 api 호출 등은 커스텀 hook으로 빼서 사용한다. 마찬가지로 hook을 사용해 본 적이 없어 일단 함수 export 방식으로 작성하였고 나중에 변경하기로 했는데 굳이 필요성을 못 느꼈다. 이 또한 아마 프로젝트가 Todo 사이즈라 중복이 많지 않아 그런가 보다.
commit convention
커밋 컨벤션은 예전에 사용했던 angular 커밋 컨벤션을 내 임의대로 변형하여 사용하였다. 커밋은 최대한 명세서 요구사항을 기준으로 하였다.
상태관리
물론 리액트를 처음 써보았지만 개인적으로는 props-drilling이 2단계 이상 발생하면 전부 전역으로 보내버리는게 유지보수나 생산성 측면에서 좋다고 생각한다. Vanilla JS를 하다 와서 그런가 굳이 좋은 전역 상태관리 기능들을 사용하지 않는게 이상하다고 생각하기 때문이다. 그리하여 ContextAPI를 사용했다. 외부 상태관리 라이브러리는 사용 불가 했기 때문이다.
문제는 작성할 땐 기능 구현에 급급해 신경쓰지 못했는데 Auth, Todo 이 두 부분 중 Todo에만 ContextAPI를 적용해놓고 Provider를 App단위에다 감싸 버린 것이다. Provider로 감싸진 자식들은 전부 전역 상태가 변경 될 때 리렌더링 하므로 Todo 페이지에만 감쌌어야 한다. 물론 변명을 하자면 추후에 확장성~ 어쩌고 하면서 할 수 있겠지만 이 부분은 확실히 실수 한 것이다. 처음 써보는 ContextAPI 여서 그런가 보다.
결론
아직까지 각 부분들에서 무엇이 best practice며 컨벤션인지 잘 모르겠다. 게다가 아직 바닐라 JS처럼 코드를 작성하는 느낌이 있어 모던 리액트 스타일로 작성하는 버릇을 들여야 겠다.
