2번째 PR에 대한 Review
오늘 우리 팀원이 나의 PR에 대한 리뷰를 해주었다. 아직 프로젝트 초반이라 자잘자잘한 작업량이 많아 커밋된 양이 적진 않은데 하나하나 확인해주고 코멘트를 달아줘서 굉장히 고맙다 👍
typescript 타이핑에 대한 내용이 있었는데, 객체 비구조화를 통해서 해당 값을 사용할 때 조금 더 타이트하게 타이핑을 해줄 것. 그리고 interface를 통해서 type을 선언할 때 id와 같은 값은 ?을 통해 type의 required를 풀어 줄 것.
마지막으로는 여러 화면을 구성할 때 페이지 단위가 아니라, 컴포넌트를 단위로 구성해볼 것. 내가 구현하는 부분중에 한 사람의 정보에 대해 4개로 탭으로 나누어져 그 안으로 들어가는 구조가 있었다.
내가 처음 구현한 방법은 localhost:3000/employees/1/personal 과 같은 방식으로 구현했었다. 이렇게 구현한 이유는 각 next.js에서는 화면의 단위를 html 파일 단위로 구성하는게 큰 의심없이 자연스럽게 생각되기도 했고, 단순한 컴포넌트 전환만으로는 UX 측면에서 불편함이 있지 않을까 생각했기 때문이다. 그리고 아직 자연스러운 흐름으로 떠오르지 않지만 SSR 구현 측면에서도 페이지가 분리되어 있는게 더 편하지 않을까? 라는 생각을 했었다.
일단 우리 팀원의 제안으로 페이지로 구분하지 않고, 컴포넌트로 구분하여 재구현 해놓았다. 한 페이지에서 tab 매뉴에 따라 쿼리스트링을 이용해서 url을 구분하니 history가 쌓이면서 뒤로가기를 눌렀을 때도 자연스럽게 UI/UX의 흐름이 이어졌다. SSR 구현에만 제약이 없다면 이런 방식으로 구현하는게 아무래도 1개의 페이지안에서 모든게 이루어지다보니 자잘한 코드의 중복이 감소하긴 한다.
SSR에 대한 구상은 아직 잘되지 않아서, 이 부분은 조금 더 생각을 해봐야겠다.
useSWR를 Hook으로 추상화하기
SWR을 사용하다보니, data fetching 이 있을 때 마다 hook이 점점 증가한다. 가족정보를 불러오는 useFamilies, 임직원 정보를 불러오는 useEmployees 등등.. 기본적인 코드의 구조가 같다보니 fetcher를 비롯한 여러코드의 중복이 일어나는데, 이것을 방지하고 추상화시킨 것이 useRequest 예제이다.
fetcher와 axios 까지 다 합쳐서 추상화 시켜놓았기 때문에 코드의 반복이 굉장히 적게 발생한다. 근데 한가지 풀지 못한 부분이 있다. mutate가 생각한대로 잘 맞지 않는 느낌이다. SWR을 사용하면서 Optimistic UI를 지향하고자 했고, 이에 따라 각 useSWR 에서 적절하게 mutate를 통해 그것을 구현하고자 했는데 useRequest를 통해 구현하려고하니 조금 난잡하기도하고 정리가 안되는 느낌이다.
아직 그 예제에 대해 능숙하지 못해서 설명도 잘 안된다. 그래서 이 부분을 조금 더 연구해보기로 했다.
