brunch

브런치북 웹을 그리는 작가 09화

라이킷 5 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by zwoo Jun 12. 2020

웹에게 말을 걸때 지켜야 할 규칙

FORM

웹에게 말을 걸어본 적이 있나요?

그렇다.

당신도, 나도, 웹에게 말을 걸어본 적이 있다.

온라인으로만 만날 수 있는 우리 웹 사용자들은 서로를 만나기 위해 폼(form)을 사용한다. 기본적으로 웹사이트에서의 소통이란 몇개의 input 과 textarea와 전송버튼으로 구성된 폼을 통해 글을 작성하고 게시하고 조회하는 행위이다.

지금 내가 썼다 지웠다 하며 자유롭게 작성한 폼은 우측의 상단의 발행버튼을 통해 조회할 수 있는 형태로 변경된다. 내가 건네는 말이 여러분에게 가 닿는 것이다. 무척 신기하지 않은가? 나는 웹을 공부한 후 처음 폼을 접했을 때와 지금 폼에 대한 생각이 아주 많이 달라졌다. 폼은 몇가지 정보를 기입할 수 있는 빈칸들이 주루룩 적혀있는 한장의 종이보다 더 큰 무언가이고, 아주 다양한 모양으로 꾸며질 수 있지만 내용을 적고 서버에 전송한다는 본질은 절대 변하지 않는다.

웹과의 유일한 소통창구, 폼

웹 언어로 사이트를 만들어볼수록 폼의 중요성을 깨닫는다.

고작 input 몇개로 이루어진, 스타일을 주기 전까지는 매우 후줄근해보이는 이 아이가 사실은 거의 유일하게 사용자와 소통할 수 있는 창구가 되어주는 것이다. 디자인을 예쁘게 입혀놓아서 그렇지, 사실은 바로 그 투박하고 네모난 녀석들과 다를 바가 없다. 모든 웹에는 저마다 아름답게 디자인된 폼들이 있고, 모든 폼에는 정해진 규칙이 있다.

하나,

빈값을 보내지 않는다.

둘,

최소 혹은 최대분량과 형식(문자 / 숫자 ...등등)을 지킨다.

셋,

규칙을 지키지 않을 시에는 에러문구가 출력되고 제출할 수 없거나 다음 스텝으로 넘어갈 수 없다.

사용자 프로필을 폼으로 입력받아 서버에 저장하는 상황을 생각해보자. 만약 장난꾸러기 J씨가 모든 input 에 정보를 기입하지 않고 빈값으로 둔 채 가입버튼을 눌러버리면 어떻게 될까? 서버의 몇번째 줄에는 빈 배열이 덩그러니 놓일 것이다. 이 데이터는 이름으로도, 닉네임으로도, 이메일주소로도 조회할 수 없지만 어딘가에는 존재하는 유령데이터가 될 것이다. 또 만약 정해진 분량이나 형식을 지키지 않았을 때는 어떨까? J씨의 이메일주소가 문자열이 아닌 숫자 '0000' 으로만 적혀있다면 J씨는 이메일 알림을 받겠다고 설정했더라도 메일을 받을 수가 없게 된다. 이런 각각의 상황에 대한 에러메시지는 사용자가 일부러 짓궂게 구는 경우보다는 실수로 잘못 입력하는 경우를 염두에 두고 만든다. 사용자가 비밀번호를 '0000' 등으로 너무 쉽고 짧게 만든 경우, '비밀번호는 최소 6자리 이상, 영문과 숫자 조합이어야 합니다.' 와 같은 에러메시지를 인풋 하단 혹은 팝업 알림으로 띄우고, 제대로 입력하여 에러메시지를 없애고 난 다음에야 가입버튼이 활성화되는 이유는 바로 사용자를 도와주기 위한 배려이다.

이 세가지는 아주 기분적인 폼의 규칙일 뿐이다. 회사 방침에 따라 여러가지 세부적인 규칙들이 더해질 수 있다. 회원가입시 동일한 아이디가 이미 있는지 검증하거나, 실제 이메일 주소로 인증링크를 보내어 해당 링크를 통해 들어온 유저인지 검증할 수도 있다.

하지만 폼작성 규칙을 걱정하고 고민하는 일은 사용자 쪽이 아니라 개발자 쪽이니 사용자가 부담을 가질 필요는 없다. 작성하기 편안하면서도 아름다운 폼, 쓰고싶고 읽고싶은 폼, 폼에서 에러가 발생하더라도 부드럽게 다음 행동을 유도해주거나 아니면 아예 폼에서 에러검증을 하지 않고 다른 방식으로 필터링을 하는 사용자 친화적인 서비스들이 날이 갈수록 많아지고 있기 때문이다. 때문에 사용하는 입장에서는 복잡하게 생각할 것 없이 그저 적으라는 곳에 글씨를 쓰고, 사진을 업로드하고, 버튼을 눌러 글을 게시하면 폼검증은 화면 저 너머의 서버에서 알아서 처리된다.

RC-FIELD-FORM

넥스트로 폼을 작업하면서 어려웠던 것은 바로 이 폼검증이었다.

회원가입 폼부터 1대1 문의 폼, 세금신고서 양식 폼, 블로그 포스트 폼까지 아주 다양한 폼이 있었고 번번이 검증규칙을 만들기가 버거웠다(서로 미묘하게 달라서 같은 컴포넌트를 재사용하기가 어려웠다). 그러다가 만난 라이브러리가 rc-field-form 이었다. 이 라이브러리는 내부적으로 검증 라이브러리를 참조하여 Form 이라는 컴포넌트의 각 Field 에 자동으로 에러메시지를 할당해준다.

<Field

name={'email'}

initialValue={data.email}

value={data.email}

errors={data.emailError}

validateTrigger={['onSubmit', 'onBlur']}

rules={[{ required: true, message: 'email is required' }]}

<input type="email"/>

이와 같은 형태로 작성하면 작성된 룰에 맞게 정해진 트리거 포인트마다 에러메시지가 필드에 할당되는 방식이다.

그러나 이 폼을 사용하는 데 있어서 난관이 없지는 않았다. 가장 많이 헤맨 부분은 에러를 받아오고 핸들링하는 부분이었다. 앞서 말한 내부적인 검증 라이브러리는 async-validator 라는 라이브러리인데, 해당 라이브러리를 통해 에러메시지가 콘솔에 출력되기는 했지만, 그 에러메시지를 내가 원하는 특정 변수에 담는 방법은 알 수 없었다. 변수로 받아야 화면에 출력할 수가 있기 때문에 이는 매우 중요한 문제였다.

여러 방면으로 검색해본 끝에, Form 의 onFieldsChange 를 이용해 필드가 변경될 때마다 폼이 userData 를 감지하도록 시켰다.

<Form
  form={form}
  onFinish={doSubmit}
  onFieldsChange={() => {
    setData({
      ...data,
      email: '',
      password: '',
      emailError: '',
      passwordError: ''
    });
  }}
>
      <Field
        name={'email'}
        initialValue={data.email}
        value={data.email}
        errors={data.emailError}
        validateTrigger={['onSubmit', 'onBlur']}
        rules={[{ required: true, message: 'email is required' }]}
      >
          <input
            type="email"
            placeholder="Email"
            value={data.email}
            onChange={(event) => {
                setData({ ...data, email: event.target.value, emailError: form.getFieldError('email') });
              }}
            onBlur={() => {validate('email');}}/>
          <p>{data.emailError}</p>
      </Field>
      <button>Log in</button>
</Form>