웹 서비스에는 수 많은 정보 입력이 있고, 유저들은 서비스를 사용하기 위해 일러주는 타이핑 양식을 바탕으로 빈칸을 채운다. 회원가입할 때 마주하는 빈칸들을 봤을 때 입력하기 귀찮았던 경험이 분명 있을 거다.
form에는 유저와 상호작용하는 input, select/option, button 등의 요소와, 적절한 스타일의 변화는 유저가 form 작성을 성공적으로 마칠 수 있도록 이끄는 가이드이다.
프론트엔드 개발자로서 유저의 form 이용에 대한 고민으로 불편함을 최소화하는 것이 필요하다고 생각하여 어떤 것을 고민해야하는지 알아보았다.
클라이언트 양식 유효성 검사
필요성
MDN에 따르면 양식 유효성 검사를 하는 이유는 초기 검사와 우수한 사용자 경험을 위해서라고 한다. 아래 그림을 통해 더 자세히 알아보자.
client-side 유효성 검사 안 하는 경우
- 모든 경우, 서버에 양식 유효성 검사를 요청한다.
- 서버에서는 양식 유효성 검사 결과에 따라 다른 응답을 한다.
- 성공인 경우: 로직 실행 후 클라이언트에 성공 응답 처리
- 실패인 경우: 로직 실행 후 클라이언트에 성공 실패 처리
client-side 유효성 검사 하는 경우
- 클라이언트 양식 유효성 검사를 만족한 경우, 서버에 양식 유효성 검사를 요청한다.
후자의 경우는 위에서 말한 초기검사를 하는 케이스이다. 클라이언트에서 유효성 검사를 통과하지 않는 한 서버에 요청하지 않기 때문에 불필요한 네트워크 통신을 줄일 수 있는 이점이 있다.
클라이언트의 동작은 JavaScript 엔진의 연산이기 때문에 네트워크 통신보다 빠르다. 클라이언트에서 체크할 수 있는 오류 사유에 한해서 유저는 우수한 사용자 경험을 얻을 수 있다.
네트워트 통신 발생 -> 비용 + 서버 부하 -> 늦은 피드백 -> 나쁜 사용자 경험
유형
기본 제공 양식 유효성 검사
- HTML5 기능
- 장점: 성능이 우수하다
- 단점: 세부적인 사항을 다룰 수 없다
JavaScript 양식 유효성 검사
- 장점: 완전한 사용자 정의 가능
- 단점: 직접 작성해야하거나 라이브러리를 사용해야함
어떤 유형을 사용하여 form 유효성 검사를 하는 것이 좋을까? 개인적으로는 '둘 다 사용'하는 것이 좋다고 생각한다. 유효성 검사의 조건은 기본 제공 기능을 사용하되, 오류가 발생했을 때의 분기 로직은 JavaScript로 처리하는 것이다. 이렇게 혼합하여 사용하면, 성능과 커스터마이징을 동시에 누릴 수 있기때문에 가장 이상적이라고 생각한다.
기능
pattern
글자 제한
Form Styling
novalidate
Validation API
사용자 정의 오류메시지
지금까지 클라이언트단에서 양식 유효성 검사가 왜 필요한지, 프론트엔드 개발자로서 우리는 어떤 것을 신경써야하는지 알아보았다.
다음 글에서는 위에서 알아본 기능들을 사용하여, 불편한 유저 양식을 개선시키는 구현을 다루려고 한다.
참고
https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation
즐겁게 읽었습니다. 유용한 정보 감사합니다.