🥅 제작 목표
- 동적으로 그려지는 후기 폼 만들기.
- 모든 항목을 직접 입력하는 게 아닌 json 또는 object 파일을 받아 동적으로 그려질 수 있도록 함.
- 질문 별로 컴포넌트 만들기.
🌳 폼 제출 방식 정하기
고민 포인트 1
input이 컴포넌트로 나뉨에 따라 폼 제출 방식을 정해야 했다. 사실 한 컴포넌트 안에 모든 input이 있으면 쉽겠지만
가독성! 그거 하나만 팬다..라는 느낌?이 있었다.고민 포인트 2
라이브러리에 대한 의존을 만들어도 될까? 실제 서비스에 도입되는 코드를 짜본 게 처음이라 감히 라이브러리를 사용해도 될지 의문이 들었다. 물론 회사는 써도 된다 했지만 나 스스로 의문을 계속 갖고 있었다.고민 포인트 3
react hook form을 썼을 때 2가지 장점을 느꼈다.
- 여러 개의 input이 있을 때 required 임에도 채우지 않고 제출을 하면 데이터를 입력해야 하는 input으로 슈루룩 이동한다. 별도의 애니메이션을 주지 않아도 멋져서 좋았다.
- 에러 메시지를 띄우는 코드 양이 적다. react hook form을 쓰지 않으면 form이 올바른지, 올바르지 않은지 체크해서 에러 메시지를 보여줄지 말지를 결정하는 코드를 input 마다 일일이 써줘야 한다.
하지만 이번에 내가 만들 form은 input이 많아봐야 3개고, 에러 메시지를 띄우는 게 아닌 제출 버튼을 비활성화 시키기 때문에 react hook form의 장점을 활용하지 못한다 생각했다.
결론
장점을 제대로 활용 못하고 의존성만 생기는 라이브러리를 쓰지 말고 내 상황에 맞는 hook을 만들자! (미리 말하자면 잘못 생각했다!)
🔨 useInput 제작
useInput 역할
- 폼 컴포넌트가 동적으로 생성될 때, 상태를 가질 수 있도록 함.
- (아직 코드로 만들어지진 않았지만) 상태를 set하기 전 validation을 통해 패턴에 맞는 형식만 set할 수 있도록 함.
결과물
.gif?table=block&id=7b3479ed-c737-430b-92b0-abcce5c3372a&cache=v2)
Pub-Sub 패턴 활용
주된 개념은 서로를 모른다라는 건데 이 표를 보면 이해가 쉬울 것이다.
- Observer 패턴의 경우 Subject에 Observer를 등록하고 Subject가 직접 Observer에 직접 알려주어야 한다.
- Pub-Sub 패턴의 경우 Publisher가 Subscriber의 위치나 존재를 알 필요없이 중간지점에 메시지를 던져 놓기만 하면 된다.
- 반대로 Subscriber 역시 Publisher의 위치나 존재를 알 필요없이 Broker에 할당된 작업만 모니터링하다 할당 받아 작업하면 되기 때문에 Publisher와 Subscriber가 서로 알 필요가 없다.
주저리 써놨지만 결국 form과 form에 들어갈 input 컴포넌트들은 useInput을 통해 데이터를 전달할 뿐 서로를 몰랐으면 좋겠다고 생각했다. 독립적인 존재니까! 내 케이스가 펍섭 패턴에 정확히 대응되는지는 모르겠지만 이런 느낌으로 가져가고 싶었다.
한계
처음엔
그래도 완성했다! 폼 제출되네하면서 뿌듯했지만 그건 무지로부터 온 뿌듯함이었다. 받은 피드백을 정리하면 다음과 같다.- checkbox, radio button, textbox의 개별 validation이 들어가면 복잡해질 것 같다.
- 너무 크리티컬한 문제점이었다. 하지만 사실 나도 이 부분은 알고 있었다. 코드를 보면
changeCheckboxState가 별도로 setValue를 함을 알 수 있다. 이는 checkbox가 복수 선택이기 때문이다. 그래서 강제로 배열로 만들고 setValue를 해줬다. 결국 맞지 않는 걸 억지로 맞춘 것이다.
- hook은 다른 곳에도 쓰일 수 있게 확장성을 고려해야 하는데 useInput은 순수하지 않기 때문에 reivew form에서만 쓸 수 있다.
- 이것도 너무 맞는 말이다;_; review form에서만 쓰려고 만든 hook은 맞지만 과연 hook이라고 할 수 있을까도 의문이다.
- input 컴포넌트의 값이 controlled하게 처리된다. uncontrolled component로 개선할 때 처리가 까다로울 것 같다.
- 지금은 useInput의 영향으로 한번 input의 업데이트에 의한 렌더링이 발생하고, 각 컴포넌트의 useEffect로부터 props.onChangeInputState의 영향을 받아 리렌더링이 또 전체적으로 되는 구조다. 리렌더링이 필요 이상으로 발생하는 것 같다.
❓ controlled, uncontrolled
💡 몰랐기도 하고 중요하게 생각해야 할 포인트라 생각해서 별도의 목록으로 뺐다.
엘리먼트의 ’상태’를 누가 관리하느냐에 따라
Contorlled와 Uncontrolled Component로 나뉜다.controlled (제어 컴포넌트)
- 엘리먼트를 가지고 있는 컴포넌트가 관리함.
- 우리는
React state를 “신뢰 가능한 단일 출처 (single source of truth)“로 만들어 두 요소를 결합할 수 있음.
- 그러면 폼을 렌더링하는 React 컴포넌트는 폼에 발생하는 사용자 입력값을 제어함. 이러한 방식으로 React에 의해 값이 제어되는 입력 폼 엘리먼트를
제어 컴포넌트 (controlled component)라고 함.
uncontrolled (비제어 컴포넌트)
- 엘리먼트의 상태를 관리하지 않고 엘리먼트의 참조만 컴포넌트가 소유함.
- 모든 state 업데이트에 대한 이벤트 핸들러를 작성하는 대신
비제어 컴포넌트를 만들려면ref를 사용하여 DOM에서 폼 값을 가져올 수 있음.
⇒ 결국 리렌더링까지 고려하지 않았는데 필드가 늘어날수록 불필요한 렌더링이 점점 늘어나는 구조라고 생각했다.
👻 내가 몰랐던 react hook form
처음으로(?) react-hook-form 공식 홈페이지를 들어가봤다. 첫 화면에 react hook form의 장점을 너무 명료하게 볼 수 있었다. 만약 이걸 먼저봤다면 내 의견이 달라질 수도 있었을 텐데 공식 홈페이지 한 번 안들어가보고 react-hook-form을 판단했던게 부끄러웠다.
내가 몰랐던 장점을 나열하면 다음과 같다.
- 리렌더링을 하지 않음.
- 다음과 같이 controlled form은 리렌더링이 이루어지는 데 react hook form은 그러지 않는다는 걸 알 수 있다.
- formik에 비해 더 가볍고 빠름.
- formik도 고려군 중 하나였는데 react hook form이 formik에 대항하여 나왔기도 하고 실제로 더 좋다고 판단했다. [차이점 참고]
- controlled와 uncontrolled를 선택할 수 있음.
⇒ 결국 렌더링을 안하면서 데이터를 핸들링할 수 있다는 게 큰 장점이었다. 이 근본은 모른채 애니메이션이 어떻고 에러 처리가 어떻고 평가했다.. 🥲
최종
- useInput은 지우고 각 input 컴포넌트가 동적으로 불릴 때 react hook form의
register를 사용하여 폼 state를 만들었다.
- 그 결과 코드를 읽기 쉬워졌고, 코드양도 줄어들었다.
- 실제 테스트 했을 때 렌더링 유무를 확인했더니 최소 render만 실행된 후 더이상 렌더링이 되지 않았다. 만약 상태가 바뀔 때 UI 렌더링이 있다면 controlled가 좋지만, 없다면 uncontrolled가 좋기 때문에 내 코드는 uncontrolled하다고 할 수 있다!!
- check 유무는 css로 처리했다.
.gif?table=block&id=9d3f50f9-328e-41a8-8f7a-5d8c1773aa1c&cache=v2)
⇒ 아직 api 통신을 하지 않은 상태이긴 하지만 form을 제출하는 방식에 대해 이렇게 많이 고민할 수도 있다는 걸 느꼈다.
이게 최선인가?에 대한 답은.. 잘 모르겠지만 계속 고민해볼 예정이다.참고 자료: