[리팩토링][북스테어즈] 9개월 묵은 코드 뜯어내기 (1) 데이터 구조 변경

서론

나의 첫 협업 프로젝트인 북스테어즈는 지난 9개월 가까이 개발 진척이 잘 안되었다.

 

4 Depth 까지의 꼬리 질문/답변 기능이 주범이다.

절대적인 리소스 투입도 적었고, 클라이언트 팀에서의 버그를 잡지 못해 지난 달에는 API 구조 변경까지 논의되었다.

애정하는 프로젝트로 사용자들을 만나고 싶다는 동일한 목표로 우리 팀은 지속해서 코드를 살펴보았고, 최근 들어 버그를 Fix 할 수 있었다.

이 Fix 작업으로 인해 코드를 리팩토링하며 서비스를 다시 만들어나가는 계기를 마련했다.

 

그 과정을 다시 복기하고 정리하고자 한다.

 

---

작업에 불을 붙인 에러 해결

 

북스테어즈의 꼬리 질문/답변 기능

 

신뢰 가능한 단일 출처를 지키지 못한 제어 컴포넌트와 비제어 컴포넌트의 결합

위 영상과 같은 꼬리 질문/답변을 React에서 권장하는 제어 컴포넌트만을 이용해 구현한다면, 어마무시한 리렌더링이 일어나 성능 저하를 일으킬 것이다.

리렌더링을 효과적으로 최적화 하기 위해

submit 버튼의 활성화를 위한 최상단의 📎 제어 컴포넌트와,

그 children 인 📎 비제어 (재귀) 컴포넌트가 함께 구성된다.

 

비제어 컴포넌트의 기능적 한계

 

이 때 비제어 컴포넌트는 필요할 때 필드에서 값을 pull 하여 이용하고,

제어 컴포넌트는 권장된 방식으로 state를 이용해 값 변경을 push 하여 데이터(상태)와 UI(입력)가 항상 동기화 된다.

 

두 로직을 혼용하기 위해서는 신뢰 가능한 단일 출처를 철저하게 지켜가며 설계를 해야 했으나, 우리 팀의 옛 코드는 당연하게도 복잡한 로직의 스파게티 코드를 만들었다.

꼬리 질문/답변을 Delete & Create 하는 시점에서

“state(객체)"의 로직과 “필드의 값(useForm의 path value)” 을 pull 업데이트 하는 로직이 동기화되지 않았고, 리팩토링이 필수적으로 필요하였다.

 

이 에러 찾기가 참 힘들었고, 결국 9개월 동안 작업이 흐지부지 되었는데 📎 최근에야 임시방편으로라도 Fix 를 할 수 있었다.

 

벽을 하나 넘으니, TODO :: 상태 관리가 자리를 지키고 있더라.

 

---

도와줘, Recoil

(Recoil의 자세한 사항은 📎 공식 문서를 확인하면 좋다)

1. 전역 상태 관리

• 헤더 부분의 저장하기(save) 버튼
• 꼬리 질문/답변 state
• 맨 아래 위치한 제출하기(submit) 버튼

전형적으로 상태관리가 필요한 설계였다

당시 기본기에 충실하고자 한 우리는 state로 상태를 관리하고자 하였었고, props drilling이 밧줄만큼 튼튼하게 이뤄졌다

이를 뜯어내고 전역적으로 관리하고자 하였다.

 

이 때, 서버 사이드 데이터와의 동기화는 필요하지 않았고

캐싱, 실시간 풀링 등 다양한 옵션들의 활용보다는 패칭한 데이터의 전역적인 상태 관리가 필요했기에,

사용이 간결하고 친숙한 Recoil 로써 관리하게 되었다

 

[ 상태관리, 이제 Recoil 하세요.]( https://youtu.be/0-UaleJZOw8 )

 

Recoil은 직교(orthogonal)하지만 본질적인 방향 그래프를 정의하고 React 트리에 붙인다.

상태 변화는 이 그래프의 뿌리(atoms)로부터 순수함수(selectors)를 거쳐 컴포넌트로 흐르는 Data Flow Graph 를 가진다

이 때 Atoms는 컴포넌트가 구독할 수 있는 상태의 단위이고

Selectors는 atoms 상태값을 동기 또는 비동기 방식을 통해 변환한다.

 

이러한 Recoil 의 Atom 상태 하나로, 📎 단단한 props drilling을 걷어낼 수 있었다.

 

2. 효율적인 서버 통신

하나의 atom 상태를 가지고 컴포넌트마다의 커스텀 훅을 호출하려니, 중복적인 서버 통신이 일어난다.

Recoil 을 이용하여 캐싱을 할 방법은 없을지 알아보자.

 

> https://snupi.tistory.com/214

[리팩토링][북스테어즈] 9개월 묵은 코드 뜯어내기 (2) Recoil