brunch

You can make anything
by writing

C.S.Lewis

Form(폼) 요소에 대한 검증 및 오류 처리 개선

파트너스는 모든 페이지에 폼이 있고, 우린 모든 페이지를 수정해야 합니다

안녕하세요.

플랫폼 개발팀 프론트엔드 개발자 다나(dana) 입니다.


이번 달에는 저희 자사 서비스의 파트너스 사이트에서 Form(폼) 요소에 대한 검증 및 오류 처리를 어떻게 개선했는지에 대해 블로그에 작성하려고 합니다.



기존방식과 리팩토링 필요성


파트너스 사이트는 주로 폼 태그를 활용하여 서버로 데이터를 전송하는 작업이 주로 이루어집니다.

아래는 폼 요소를 포함하고 있는 리팩토링 대상에 해당하는 페이지 목록입니다.

회원가입 페이지

상담신청 페이지

입점신청 페이지

명의변경 페이지

서비스정보 페이지

통신판매업신고증 페이지

직원관리 페이지

메뉴관리 페이지

스타일관리 페이지

예약관리 페이지

이벤트관리 페이지

결제정산 페이지

광고관리 페이지

권한관리 페이지

계정관리 페이지


파트너스 사이트 내에 거의 모든 페이지가 리팩토링의 대상입니다. 작업 범위가 크다는 걸 알 수 있습니다.


또한, 각 페이지마다 독립적인 코드를 사용하고 있어서 코드를 재사용하지 않는 형태였습니다.

만약 새로운 페이지를 개발해야 한다면 html 코드 한땀한땀 처음부터 개발해야 하는 구조였습니다.


이런 문제점을 해결하고자, 저희 팀은 폼 요소를 공통화해서 사용할 수 있도록 컴포넌트를 제작하게 되었습니다. 만약 새로운 페이지를 개발하는 요청이 들어온다면 공통 컴포넌트를 활용하여 원하는 폼 요소를 조합하고, UI의 일관성을 유지하면서도 더 신속하게 페이지를 개발할 수 있도록 하고자 합니다.


리팩토링 방향성


폼 요소를 관리하는 대표적인 라이브러리를 두 가지 꼽으라면 react-hook-form과 formik이라고 할 수 있습니다. 파트너스 사이트는 formik 라이브러리를 사용하여 폼 요소를 관리하고 있습니다.


react-hook-form은 비제어 컴포넌트를 활용하고, 폼 상태를 직접 제어하는 대신 필요한 입력 필드에 ref를 이용하여 성능상 이점을 갖고 있지만, 이를 도입하려면 클래스형 컴포넌트에서 함수형 컴포넌트로의 전환 및 다양한 리팩토링 작업이 필요합니다.


현재 파트너스는 클래스형 컴포넌트에서 함수형 컴포넌트로의 전환, 타입스크립트 도입, React Query의 도입, 그리고 마크업 코드 내재화 같은 다양한 리팩토링을 진행 중입니다. 

많은 페이지가 개선되고 있지만 제한된 작업시간 내에 다른 리팩토링 작업과 함께 개선하기엔 현실적으로 어려울 것이라 판단하였습니다.


결국 formik 라이브러리를 계속 사용하되, 변경 및 유지보수가 용이하도록 작업을 진행하게 되었습니다.



코드 개선사항


아래는 회원가입 페이지 코드입니다.

회원가입 페이지에는 이름, 휴대폰 번호, 이메일 세 가지 항목을 입력받도록 되어 있습니다.


기존 코드를 보시면 하나의 입력값을 생성하기 위해, 

해당하는 input 엘리먼트 한땀한땀 작성해야 하기 때문에 반복적인 코드가 사용되고 있습니다. 

이로 인해 코드의 양이 상당히 많아졌고, 코드의 가독성 또한 매우 떨어진 상태였습니다.

변경 전과 변경 후, 각각의 색깔로 구분된 상자는 동일한 기능을 수행하는 부분입니다. 
기존 코드(변경 전)

각 입력 항목을 생성하는 데 사용되는 공통 로직을 모듈화하여 코드 양이 상당히 줄었습니다.

개발자의 입장에서 한눈에 해당 컴포넌트가 어떤 역할을 하는지 구분하기 쉬워졌습니다.


단순히 코드의 가독성만 개선된 것이 아니라 코드의 일관성도 유지할 수 있고, 추후에 추가적인 리팩토링 작업이 생긴다면, 공통된 코드를 수정하면 관련된 모든 부분에 반영할 수 있으므로 유지 보수가 용이해집니다.

ㄴ`Definition`이라는 합성 컴포넌트를 생성하고 원하는 조합으로 화면을 만들 수 있게 되었습니다.

ㄴ 에러 핸들링 관련 로직도 포함하여 에러 발생 시 일관된 처리를 진행할 수 있게 되었습니다.

리팩토링 코드(변경 후)


결과화면


기존 방식:

폼 요소에 에러가 발생하면, 하나의 에러 메시지만이 Alert 창으로 표시되었습니다.

사용자가 정보를 입력하고 확인 버튼을 누르면 발생한 에러 메시지를 읽어 필요한 수정을 진행한 후, 다시 버튼을 눌러 에러를 확인하는 번거로운 반복이 필요했습니다.


개선된 방식:

이제 모든 에러를 한번에 확인할 수 있습니다.

각각의 필드에 빨간색 테두리와 에러 메시지가 표시되어 사용자가 어떤 입력 필드에서 어떤 문제가 발생했는지 명확히 알 수 있습니다.


이렇게 변경함으로써 사용자 경험을 향상시키고, 발생한 오류를 더 쉽게 식별할 수 있게 되었습니다.

이제 저희 파트너스 사용자들은 시각적으로 명확한 표시를 통해 기능을 더 쉽게 이해하고,

폼 요소에서 발생한 에러를 더 쉽게 해결하게 되실겁니다!


리팩토링 회고


파트너스는 지금 과도기 단계에 있다고 생각합니다.

프론트팀에서는 오래된 레거시 코드를 제거하기 위해 여러 작업을 진행하고 있습니다.


새로운 기능을 개발하는 것보다 코드 리팩토링을 통해 많은 것을 배울 수 있었습니다.

이 과정에서 예전에는 당연하게 여겼던 것들이 정말 맞는건지 다시 한번 생각하게 되고, 시행착오를 통해 깨달은 부분도 많았습니다.


formik의 prop-driven 방식으로 하위 컴포넌트로 formik 관련 props를 모두 전달하는 경우가 생긴다거나, 제어 컴포넌트 기반이라 불필요한 리렌더링이 발생할 수 있다는 점, 복잡한 에러 핸들링은 어려울 수 있다는 점 개선해야 할 과제들도 있습니다.


현재 이 단계가 지난 뒤에는 formik 라이브러리를 대체할 리팩토링이 필요할 수도 있겠다는 생각이 들었습니다. 이미 폼 요소 관련해서 공통 컴포넌트를 추출해놨으니 다음번에 좀 더 수월하지 않을까 생각합니다.

좀 더 유연하고 지속적으로 발전 가능한 코드로 거듭나면 좋겠네요~!


그럼 이만 11월 포스팅을 끝내봅니다 !!! 퇴근 !!!


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari