아무래도 리액트에서는 기능별로 컴포넌트를 나누면서 props 중첩이나 상태관리가 안되었던 문제라 할 수 있을 것 같다.
는 이전 프로젝트를 진행하며 게시판 쪽을 제작했었는데, 게시글 작성, 수정, 삭제를 할 때나 또는 신고를 하게 되면 서버에는 반영이 되었는데 클라이언트에서는 되지 않고, 새로고침을 해야지만 반영이 되는 문제가 있었다.
다시 말하자면 게시글 데이터에 변동이 있을 때 해당 변동 사항을 반영하지 못하는 문제다.
이 부분은 SWR을 사용했다. 몰론 SWR이 전통적인 상태관리 라이브러리는 아니지만 상태관리가 가능하며 가볍다는 장점, 데이터 패칭에 특화 되어있다는 부분 때문에 사용했다.
SWR을 이용해 데이터 패칭을 시키도록 구현하고, mutate 함수를 사용해 데이터 패칭 이후에 재렌더링이 일어날 수 있도록 로직을 작성함으로서 상태관리 문제를 해결했다.
하여 사용하게 되니, 게시글 input창에 텍스트를 입력하면 props가 중첩되는 컴포넌트들에 불필요한 렌더링이 발생했었다.
데이터 패칭 로직들을 커스텀 훅으로 따로 분리해 관리하고 해당 로직들이 필요한 컴포넌트에 바로 import 시켜줌으로써, props 중첩 문제를 해결함은 물론, 컴포넌트들의 가독성을 높이고 유지보수성을 개선할 수 있었다.
협업을 할 때에 있어 어려웠던 부분들은 개발 환경 차이부터,대소문자 구분 문제, 리액트 디자인 패턴에 대한 이해도 부족이 컸었던 것 같다.
는 맥하고 윈도우의 차이였는데, 퍼블리싱을 하고 맥과 윈도우에서 비교해보니 맥에서는 문제가 없었으나, 윈도우에서만 요소가 오른쪽으로 치우쳐져 있거나 자식요소가 부모요소 밖으로 튀어나오는 등의 문제가 발생했는데, 결국 윈도우 노트북까지 옆에 켜두고 비교해가며 수정하는 방식으로 해결했었다,,, (이게 정답은 아닐 수 있지만 윈도우와 맥에서 동일하게 출력된다면 해결된 것 아닐까,,,?)
가 있는데, 팀원이 파일명 대소문자만 바꿔서 깃허브에 커밋하고 Dev 브랜치에 머지까지 해버리자, Dev 브랜치를 땡겨받은 팀원들이 대소문자 구분 때문에 경로 에러가 무진장 발생하는 사태가 발생했다.
결국 Dev 브랜치에 경로 오류가 나는 폴더, 파일 이름을 바꿔서 커밋하고 다른 팀원들이 바뀐 브랜치를 땡겨 받도록 하여 해결했다.
인데,,, 리액트 디자인 패턴에 대한 이해도가 다들 부족했기 때문에, 기능을 담당하는 로직을 컴포넌트 분리 없이, 출력을 담당하는 컴포넌트에다가 한번에 적어버려, 가독성 저하 및 컴포넌트의 재사용이 불가능한 문제가 있었다.
나도 초반에 출력 컴포넌트에 기능 로직을 마구 휘갈겨 작성했었다가, 뒤늦게 문제를 인지하고 기능 로직과 출력로직을 분리하는 과정을 거쳐 해결했다.
하지만 팀원들 코드는 300~400줄이 넘어가는 코드를 고칠 엄두가 안나서,,, 조만간 하나씩 개선해봐야겠다ㅎㅎ