그동안 개인적으로 사이드 프로젝트를 할 때도, 회사에서 일을 할 때도, 클라이언트에서 Form 관련 로직을 구현할 때는 습관적으로
react-hook-form 패키지를 사용했다. 그러나 개인적으로는 이 패키지의 사용성이 불편하다는 인상을 언제나 지울 수 없었다.“Form은 N개의 상태를 편하게 일괄 관리할 수만 있으면 되는 거 아닌가?”라는 생각이 머릿속을 스쳐지나가면서, 이러한 순수한 멘탈 모델만을 가진 패키지를 직접 개발하기로 했다.
1. react-hook-form 패키지의 사용성
그동안
react-hook-form 패키지를 사용하며 불편하다고 느낀 점은 다음과 같았다.1-1. Form 상태 값 읽기
- 상태 값을 읽는 방법이 파편화되어 있고, 각 방법에 대한 일정 수준의 이해도가 필요하다.
useForm(...).getValues(...): 상태 값 전체를 읽되, 값의 변경을 구독하지는 않는다.
useController(...).field.value: 상태 값의 일부를 읽고, 그 값의 변경을 구독한다.
1-2. Form 상태 값 변경하기
- 상태 값을 변경하는 방법이 파편화되어 있고, 각 방법에 대한 일정 수준의 이해도가 필요하다.
useForm(...).setValue(...): 상태 값의 일부를 변경한다.
useForm(...).reset(...): 상태 값 전체를 변경한다. 파라미터가 없으면 디폴트 값으로 변경한다.
useController(...).field.onChange: 상태 값의 일부를 변경한다.
1-3. Form 상태 값 검증하기
- 상태 값을 검증하는 로직이 Colocation 되지 않고 각 부분에 흩어진다.
- 이 때문에 검증 로직을 한눈에 파악하기 어렵고, 필드 간의 검증 의존성도 파악하기 어렵다.
1-4. 패키지의 장점을 살리지 못하고 있음
react-hook-form은 Uncontrolled 방식에 기반한 리렌더링 최소화가 강점인데, 이 방식을 따르며 얻는 것에 비해 개발 생산성에서의 손실이 더 크다고 생각했다.
- 필드 간의 검증 의존성이 있는 경우 그 의존성을 명시적으로 꼼꼼히 챙겨주지 않으면 버그를 만들기 쉽고, Form에서의 리렌더링 최소화가 이러한 리스크를 감수할 만큼의 이득이라고 보이지 않았다.
1-5. 단순 상태 관리 이상의 기능을 내재함으로써 일정 수준의 러닝 커브가 발생
control객체,useController()함수 등의 사용 방법을 익히려면 어쨌든 추가 학습이 필요하다. 상식적인 지역 상태 관리 방식에 대한 멘탈 모델로만으로는 사용할 수 없다. 특히 파편화된 인터페이스들이 그렇다.
- 이는
react-hook-form패키지가 단순 상태 관리 이상의 기능(핸들러 제공, 포커스 등)을 제공함에 따라 탄생하게 된 부수적인 인터페이스라고 보인다.
2. react-bulk-form 패키지의 개발
추가적인 학습 없이 상식적인 멘탈 모델만으로도 Form 관련 로직을 쉽게 구현할 수 있도록 패키지를 개발했다. (구체적인 멘탈 모델과 인터페이스는 README의 내용을 참고하자.)
