복잡한 폼 의존성 설계

필드 모델링

각 필드가 value만 필요한지 touched, dirty, error까지 필요한지 정한다.

모든 필드에 같은 무게의 상태가 필요하지는 않다

비밀번호 확인, 국가별 주소, 결제수단별 입력처럼 서로 영향을 주는 필드를 표시한다.

교차 검증은 필드 단독 검증과 다르다

단순 폼은 useState, 이벤트가 많고 전이가 복잡하면 reducer로 모은다.

이벤트 이름이 명확하면 reducer가 읽기 쉽다

client invalid, pending, server rejected, success를 한 상태기계처럼 다룬다.

중복 제출과 서버 오류를 놓치지 않는다

검증, reset, submit 로직이 반복되면 custom hook이나 form library로 분리한다.

라이브러리는 상태 모델을 대신 정해준다

useState

작고 독립적인 필드 필드가 적고 서로 영향이 거의 없으면 충분하다.

상태가 흩어져도 이해 가능해야 한다

reducer

전이가 많은 폼 change, blur, reset, submit, serverError가 명확한 action으로 정리된다.

상태기계처럼 읽힌다

custom hook

반복 로직 추출 여러 폼에서 같은 검증과 제출 흐름을 공유할 때 쓴다.

UI와 업무 규칙을 섞지 않는다

library

대형 폼 필드 등록, schema validation, 성능 최적화가 필요하면 도구를 검토한다.

팀의 디버깅 가능성도 본다

reset 범위 값, 오류, touched, server error 중 무엇이 reset되는지 확인한다.

교차 검증 한 필드 변경이 관련 필드 오류를 다시 계산하는지 본다.

제출 실패 서버 오류 후 사용자가 수정하면 오류가 어떻게 사라지는지 확인한다.