첫번째 예시로 이진 탐색을 통해 특정 값의 존재여부를 리턴하는 binarySearch 함수를 만든다고 생각해보자. 이진 탐색은 선결 조건으로 정렬이 이루어진 목록 을 요구한다.

function binarySearch<T>(sortedArray: T[], findItem: T): boolean {
  // 구현 생략
}

‘정렬이 이루어진’ 이라는 선결조건을 명시적으로 나타내고자 매개변수명을 sortedArray 로 힌트를 두었으나 실수로 인해 정렬되지 않은 리스트를 인자로 넘길 경우가 존재한다.

두번째 예시로 간단한 환율 계산 앱을 만든다고 가정해보자. 이 앱이 수행하는것은 사용자에게 계산하고자하는 원 단위를 입력받아 현재 기준 환율에 맞게 달러로 변환하여 화면에 보여주는 것이다. 현재 기준 원을 달러로 반환해주는 currencyCalculator.wonToDollar 메서드가 존재하고, renderDollar 라는 달러를 인자로 받아 화면에 렌더링하는 함수가 있다고 가정해보자.

class CurrencyCalculator {
  //...
  wonToDollar(won: number): number {
    return this.getExchangeRate() * won
  }
}

function renderDollar(dollar: number): void {
  //...
}

const currencyCalculator = new CurrencyCalculator()

const dollar = currencyCalculator.wonToDollar(1_000)
renderDollar(dollar)

마찬가지로 renderDollar 의 dollar 매개변수를 두었으나, number 타입으로는 할당되는 값이 won 인지, 계산이 완료된 dollar 인지 제약을 둘 수 없다. 마찬가지로 개발자의 실수로 인해 실행 문맥이 변경되면 잘못된 결과가 계산될 여지가 있는 것이다.

상표(brand) 기법 을 통한 명목적(nominal) 타이핑

타입스크립트는 구조적 타이핑을 차용하지만 특성 사례에 이러한 제약을 두고싶은 경우 상표 기법으로 명목적 타이핑을 흉내낼 수 있다.

type Brand<T, K> = T & { __brand: K }

Brand 타입에 제너릭 매개변수 T, K 를 통해 구조적 타입에 __brand 를 부여함으로 명목적 타입으로 사용할 수 있다.

여기에서 교차 타입으로 선언된 __brand 는 말그대로 명목적 타이핑을 위한 이름이다. 런타임에서는 실제로 존재하지않으며 타입 시스템에서만 쓰이기에 런타임 오버헤드를 발생시키지 않는다.

binarySearch 매개변수에 제약 두기

이 타입을 사용하여 binarySearch 의 매개변수에 제약을 부여해보자.

type SortedArray<T> = Brand<T[], 'sorted'> // T[] & { __brand: 'sorted' } 

function binarySearch<T>(sortedArray: SortedArray<T>, findItem: T): boolean {
  // 구현 생략
}

제약이 부여된 sortedArray 에 배열 리터럴로 배열을 넘기면 타입 에러가 발생하는 것을 확인할 수 있다.

binarySearch([3, 1, 2], 3);
/** 
 * 🚨 TS2345: 
 * Argument of type 'number[]' is not assignable to parameter of type 'SortedArray<number>'. 
 * Property '__brand' is missing in type 'number[]' but required in type '{ __brand: "sorted"; }' 
 */

이제 binarySearch 에 sortedArray 인자를 넘기기 위해서는 정렬된 배열임을 증명해야 한다.
정렬함수를 거쳐 SortedArray 를 만들어내보자.

type SortedArray<T> = Brand<T[], 'sorted'> // T[] & { __brand: 'sorted' } 

function sortArray<T>(array: T[]): SortedArray<T> {
  return [...array].sort() as SortedArray<T>
}

const sortedNumbers = sortArray([3, 1, 2]) // number[] & { __brand: 'sorted' } 
console.log(sortedNumbers) // [1, 2, 3] 

sortArray 함수를 통해 SortedArray 상표가 부여된 sortedNumbers 는 비소로 안전하게 binarySearch 의 인자로 할당될 수 있다.

renderDollar 매개변수에 제약 두기

마찬가지로 Brand 를 통해 원시 타입 number 에 상표를 부여해보자.

type Brand<T, K> = T & { __brand: K }
type Dollar = Brand<number, 'dollar'> // number & { __brand: 'dollar' } 

wonToDollar 메서드가 Dollar 타입을 리턴하도록 변경하고, renderDollar 함수가 Dollar 타입을 매개변수로 받도록 변경한다.

function renderDollar(dollar: Dollar): void {
  //...
}

class CurrencyCalculator {
  //...
  wonToDollar(won: number): Dollar {
    return this.getExchangeRate() * won as Dollar
  }
}

const currencyCalculator = new CurrencyCalculator()

const dollar = currencyCalculator.wonToDollar(1_000)
renderDollar(dollar)

이를 통해 currencyCalculator.wonToDollar 메서드의 리턴값만 인자로 할당 할 수 있도록 제약을 둘 수 있다.

한계점 & 정리

상표 기법은 산술 연산을 거치면 상표가 없어지기에 수많은 산술 연산을 거치는 과정에 사용하기엔 무리가 있을 수 있다.

type Brand<T, K> = T & { __brand: K }
type Dollar = Brand<number, 'dollar'> // number & { __brand: 'dollar' } 

const dollar: Dollar = currencyCalculator.wonToDollar(1_000)
const millionDollar = dollar * 1_000_000 // number

renderDollar(millionDollar)
/**
 * 🚨 TS2345:
 * Argument of type 'number' is not assignable to parameter of type 'Dollar'.
 * Type 'number' is not assignable to type '{ __brand: "dollar"; }'.
 */

이와 같은 한계를 인지하고 상표 기법을 사용해야 한다.

이팩티브 타입스크립트는 상표 기법을 다음과 같이 요약한다.

• 타입스크립트는 구조적 타이핑(덕 타이핑)을 사용하기 때문에, 값을 세밀하게 구분하지 못하는 경우가 있다. 값을 구분하기 위해 공식 명칭이 필요하다면 상표를 붙이는것을 고려해야 한다.
• 상표 기법은 타입 시스템에서 동작하지만 런타임에 상표를 검사하는 것과 동일한 효과를 얻을 수 있다.

reference

• [댄 밴더캄] 이팩티브 타입스크립트 : 37. 공식 명칭에는 상표를 붙이기
• [toss.tech] TypeScript 타입 시스템 뜯어보기: 타입 호환성
• [Michal Zalecki] Nominal typing techniques in TypeScript

탬플릿 문자열은 i18next 등으로 다국어를 지원할때에 흔히 사용하는 방식이다. 명사/대명사 등을 동적으로 변수를 통해 적용할때에 json 형식으로 문자열을 선언해두고, 사용부에서 매개변수에 값을 넘기는 식으로 동적으로 변경되어야하는 문장의 현지화를 지원하고는 한다.

• {fieldName}(을)를 입력하세요.
• {a}(와)과 {b}(을)를 선택해주세요.
• {userName}(이)가 메시지를 보냈습니다.

i18next 형식으로 나타내보자면 아래와 같다.

const translation = {
  wild_pokemon_appeared: "야생의 {pokemon}(이)가 튀어나왔다!"
}

t('wild_pokemon_appeared', {pokemon: '리자몽'}) // 야생의 리자몽(이)가 튀어나왔다! 

을/를, 이/가 중 무엇을 붙힐지 계산하는 방법은 검색을 통해 쉽게 찾을 수 있는데, String.prototype.charCodeAt 을 통해 변수로 들어올 명사의 마지막 글자의 유니코드를 확인하는 방법을 사용할 수 있다. (참고)

/**
 * 마지막 글자가 받침을 가지는지 확인
 */
function checkBatchimEnding(word: string): boolean {
  const lastLetter = word[word.length - 1];
  const uni = lastLetter.charCodeAt(0);

  // 한글 범위 밖일 경우 false
  if (uni < 44032 || uni > 55203) return false;

  // 받침이 있을 경우 true
  return (uni - 44032) % 28 !== 0;
}

checkBatchimEnding('리자몽') // true
checkBatchimEnding('피카츄') // false

다음으로 checkBatchimEnding 을 이용하여 i18next 로 변수에 따라 조사를 달아주는 포멧팅 함수를 정의해보자. i18next 의 i18next.services.formatter.add 을 이용하여 정의할 수 있다. (참고)

i18next.services.formatter.add('이가', value => {
  return value + (checkBatchimEnding(value) ? '이' : '가');
});

i18next.services.formatter.add('을를', value => {
  return value + (checkBatchimEnding(value) ? '을' : '를');
});

함수명이 이가, 을를 인 받침이 있느냐 없느냐에 따라 조사를 붙혀주는 포멧 함수를 만들었다. 이 함수는 i18n 다국어 탬플릿내에 다음과 같이 사용할 수 있다. 함수명을 이례적으로 한글로 명명한 이유는 다국어 탬플릿만 보아도 자연스럽게 의미가 설명 될 수 있게하기 위함이다.

const translation = {
  wild_pokemon_appeared: "야생의 {pokemon, 이가} 튀어나왔다!",
  caught_a_pokemon: "신난다! {pokemon, 을를} 잡았다!"
}

t('wild_pokemon_appeared', {pokemon: '리자몽'}) // 야생의 리자몽이 튀어나왔다!
t('caught_a_pokemon', {pokemon: '피카츄'}) // 신난다! 피카츄를 잡았다!

i18next 는 위와 같은 formatting 이외에도 많은 유틸리티 기능을 제공한다. 이와 같이 값에 따라 동적으로 문자열을 변경해야할때에 찾아보면 썩 도움이 될만한 기능들이 많은것같다.

예시로 작성한 실행 가능한 코드를 github 에 올려두었다.

https://github.com/kjkandrea/i18next-josa/blob/main/src/main.ts

전자상거래에서의 상품을 타입으로 나타낸다면 대략 다음과 같을 것이다.

interface Product {
  id: string,
  name: string,
  featured_image: {
    url: string,
    alt: string
  },
  price: Money,
}

위와 같은 상품 데이터를 토대로 사용자에게 장바구니 리스트, 장바구니 상품의 구매가능 여부등을 제공하는 장바구니 클라이언트를 개발한다고 생각해보자.

개발을 하다보니 구매불가한 상품에 대한 처리가 필요해졌다. Product 인터페이스에 해당 프로퍼티를 추가한다.

interface Product {
  id: string,
  name: string,
  featured_image: {
    url: string,
    alt: string
  },
  price: Money,
  status: 'ONSALE' | 'UNAVAILABLE',
  /** saleStatus UNAVAILABLE 일때의 구매 불가 사유 */ 
  unavailableReason?: string
}

status 를 추가하고 선택 속성(optional property) 을 통해 unavailableReason 를 추가했다.
이에 따라 썸네일에 ‘구매 불가’ 텍스트를 씌우고, 구매불가 사유를 표기해야한다. JSX 탬플릿을 다음과 같이 업데이트한다.

<CartProduct>
  <CartProduct.FeaturedImage 
    image={product.featured_image}
    unavailable={product.status === 'UNAVAILABLE'} 
  />
  // 📌 problem.
  {
    product.unavailableReason !== undefined
    && <CartProduct.GuideText text={product.unavailableReason} color="warn" />
  }
  <CartProduct.Title text={product.title} />
  <CartProduct.Price price={product.price} />
</CartProduct>

어색한 부분이 보인다. Product.unavailableReason 은 product.status === 'UNAVAILABLE' 일 경우에만 존재하는 값이지만, Product 인터페이스는 status 와 unavailableReason 의 연관성을 나타내지 못한다.

때문에 주석상의 📌부분에서는 product.status === 'UNAVAILABLE' 과 별도로 unavailableReason 의 존재 유무를 검사하고 있다.

현재 상태로 특정 status 에 대한 프로퍼티가 더 추가되거나 한다면 Product 의 이러한 구분은 더욱 모호해질 것이다.\

불가능한 상태는 불가능하게

이러한 데이터의 경우 태그된 유니온 을 통해 속성과 속성간의 관계를 다음과 같이 명시적으로 나타내줄 수 있다.

interface BaseProduct {
  id: string,
  name: string,
  featured_image: {
    url: string,
    alt: string
  },
  price: Money
}

interface OnSaleProduct extends BaseProduct {
  status: 'ONSALE'
}

interface UnavailableProduct extends BaseProduct {
  status: 'UNAVAILABLE',
  unavailableReason: string
}

type Product = OnSaleProduct | UnavailableProduct 

이제 status 필드는 해당 Product 의 유형을 설명하는 태그 역할을 한다.
이를 통해 status 와 unavailableReason 의 관계가 명확해졌기에 JSX 도 다음과 같이 status 중심으로 작성될 수 있다.

<CartProduct>
  {() => {
    switch (product.status) {
      case 'ONSALE':
        return (
          <CartProduct.FeaturedImage image={product.featured_image} />
        );
      case 'UNAVAILABLE':
        return (
          <>
            <CartProduct.FeaturedImage image={product.featured_image} unavailable={true} />
            <CartProduct.GuideText text={product.unavailableReason} color="warn" />
          </>
        )
    }
  }}
  <CartProduct.Title text={product.title} />
  <CartProduct.Price price={product.price} />
</CartProduct>

정리

위와 같이 태그된 유니온을 통해 선언된 타입은 가능한 상태와 불가능한 상태를 나타내는 일종의 문서 역할을 한다.
이처럼 태그만을 추가하는 간단한 방법을 통해 데이터를 보다 명시적으로 모델링하고 안전하게 다룰 수 있다.

작성된 양식이 서버에 도달한 후 거부되면 사용자에게 지시하기 이전에 잘못된 입력에 대한 정보를 보다 이른 시점에 제공하고자 유효성 검증(validate) 로직을 브라우저에서 컨트롤하곤 한다.

이러한 제출 양식이 어떠한 일을 하는지 한번 나열해보자.

1. 입력 가능한 필드를 제공한다.
2. 입력이 완료되면 서버에 전송한다.
3. (서버 처리 결과 알림) 서버에서 400 번대 에러가 응답되었다면, 사용자에게 피드백을 제공한다.
4. (브라우저 측 검증) 필수 입력 필드를 입력하지 않았다면/입력 양식이 정합하지 않다면, 사용자에게 피드백을 제공한다.
5. 사용자가 입력 필드를 작성하다가 제출하지 않은 채 이탈하려 한다면, 작성중이던 양식이 사라질 수 있다는 걸 확인시킨다.
6. 입력 양식을 이용하여 검색을 한다면 search params 와 사용자가 입력한 양식을 동기화한다.

5, 6 은 상황에 따라 구현이 필요한 불필요한 경우도 있지만, 1, 2, 3, 4 은 제출 양식을 구현할때에 대부분의 경우 필수적이다.

제출 양식을 통한 사용자 인증 을 구현해보자.

1, 2, 3, 4 의 기능을 무작정 구현하여 복잡성을 체감해볼까?

import { signInMutation } from 'store/auth'

function SignIn() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [clientErrorMessage, setClientErrorMessage] = useState('');

  const {
    mutate,
    // 3. (서버 처리 결과 알림) 서버에서 400 번대 에러가 응답되었다면, 사용자에게 피드백을 제공한다. 
    error: {message: serverErrorMessage},
  } = signInMutation();
  
  // 4. (브라우저 측 검증) 필수 입력 필드를 입력하지 않았다면/입력 양식이 정합하지 않다면, 사용자에게 피드백을 제공한다.
  const validate = (): boolean => {
    if (!email.trim()) {
      setClientErrorMessage('이메일을 입력하세요.');
      return false;
    }

    if (!password.trim()) {
      setClientErrorMessage('비밀번호를 입력하세요.');
      return false;
    }
      
    return true;
  }

  // 2. 입력이 완료되면 서버에 전송한다. 
  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
      
    const invalid = !validate();
    if(invalid) return;

    mutate({
      email,
      password,
    });
  };

  // 1. 입력 가능한 필드를 제공한다.
  return (
    <form onSubmit={e => handleSubmit(e)}>
      <input
        type="text"
        name="email"
        value={email}
        onChange={e => setEmail(e.target.value)}
      />
      <input
        type="password"
        name="password"
        value={password}
        onChange={e => setPassword(e.target.value)}
      />
      {clientErrorMessage}
      {serverErrorMessage}
      <input type="submit" value="로그인" />
    </form>
  );
}

여러 관심사가 하나의 컴포넌트로 응집되어 있는 모습이다. 재사용성 관점에서 생각해보자. 이메일, 패스워드 필드가 이 양식에서만 등장할까? 이메일은 회원가입, 이메일을 통해 비밀번호 찾기 양식 등에서 등장할 수 있고 마찬가지로 비밀번호 필드도 여러 양식에서 등장할 수 있다.

각 필드들이 EmailField, PasswordField 컴포넌트로 정의된다면 어떨까? *Field 컴포넌트가 맡게 될 관심사는 다음과 같다.

• 1. 입력 가능한 필드를 제공한다.
• 4. (브라우저 측 검증) 필수 입력 필드를 입력하지 않았다면/입력 양식이 정합하지 않다면, 사용자에게 피드백을 제공한다.

구현 중점으로 조금 더 명확하게 정의해보자면 다음과 같다.

• 제출 이벤트가 일어날 때에 부모로 부터 메시지를 받을 수 있다.
• 입력 가능한 Input 을 제공한다.
• 입력된 값을 부모에게 전달할 수 있다.
• 유효성 검증 규칙을 내부에서 지니고 있다.

리액트의 설계원칙대로 부모에서 자식으로 메시지 전달하기

*Field 를 사용하는 부모 컴포넌트에서 *Field 에게 제출되는 시점에 유효성 검증을 요청해야한다.

리액트 컴포넌트가 아닌 객체라고 가정하면 부모 객체에서 자식 객체로 메시지를 보내는것은 비교적 간단하다. 제출이 일어나는 시점에 this.emailField.validate() 자식 객체에서 지닌 메서드를 다음과 같이 호출하면 될것이다.

리액트는 이러한 부모가 자식을 제어하는 구조를 권장하지않고, 예상 가능한 데이터의 흐름과 구조의 단순화를 위해 단방향 데이터 흐름을 통해 컴포넌트를 설계하기를 권장한다.

그렇다면 조금 다르게 사고해보자. 제출이 일어나는 특정 시점에 메서드등 자식이 내부에서 지니고 있는 기능을 호출하는 것이 아닌, 특정 시점에 호출될 메시지를 자식에서 사전에 정의하여 부모에게 전달해둔다면 어떨까?

위 정보를 토대로 FieldRegister 를 구성해보자.

// 자식 컴포넌트에서 *Field 컴포넌트를 정의하려면 fieldRegister 를 거쳐야한다. 
export type FieldRegister = (
  // field 명, 유효성 검증 규칙을 fieldRegister 를 통해 전달해야한다.
  fieldName: string,
  validate: (value: string) => boolean
) => {
  name: string
};

const fieldRegister: FieldRegister = (fieldName, validate) => {
  // ...
  return {
    name: fieldName
  }
}

// ...
<EmailField fieldRegister={fieldRegister} />

FieldRegister 를 통해 이메일 필드를 생성하는 EmailField 컴포넌트도 러프하게 정의해볼까?

예제에서는 적당한 복잡성을 유지하기위해 입력값이 있는지만을 검증하겠지만, 앞으로 정의될 validate 의 검증 규칙이 정규표현식이 들어가고 길이 제한이 있는 등 매우 디테일하다고 상상해보자.

function EmailField({ fieldRegister }: { fieldRegister: FieldRegister }) {
  // 유효성 검증 실패시 보여줄 안내 문구 state
  const [guideMessage, setGuideMessage] = useState('');

  return (
    <div class="field">
      <input
        type="email"
        // 📌 FieldRegister 의 규칙에 따라 fieldName, validate 를 정의한다.
        {...fieldRegister('email', (value: string) => {
          if (!value.trim()) {
            setGuideMessage('이메일을 입력하세요.');
            return false;
          }

          return true;
        })}
      />
      {guideMessage}
    </>
  );
}

주석의 📌 부분은 리액트의 디자인 패턴인 Props Getter Pattern 패턴을 따른다. register 의 리턴값이 <input> 에 바인딩 됨으로 fieldRegister 의 리턴값을 통해 부모에서 인풋을 제어할 수 있다. 가령 onChange 를 리턴한다면 실시간으로 값을 부모에서 조회할 수 있는 구조를 갖출 수 있을것이다.

제출이 일어나는 시점에 유효성 검증 실행

부모에서 validate 를 자식에게 전달받을 수 있음으로, 부모에서 원하는 시점에 유효성 검증을 실행할 수 있다.

제출(submit) 과 fieldRegister 규칙을 커스텀 훅을 통해 캡슐화할 수 있도록 만들어보자. 커스텀 훅의 이름은 useForm 이다.

interface FormField {
  validate: (value: string) => boolean;
  value: string;
}

function useForm<FormValues>() {
  const formFieldsRef = useRef<{
    // 딕셔너리 구조로 각 필드의 validate, value 를 관리한다.
    [key: string]: FormField;
  }>({});

  const register: FieldRegister = (fieldName, validate) => {
    const field = {
      validate,
      value: '',
    };
    // formFieldsRef 에 register 를 통해 생성된 필드를 등록한다.
    formFieldsRef.current = {
      ...formFieldsRef.current,
      [fieldName]: field,
    };

    return {
      name: fieldName,
      onChange: e => {
        field.value = e.target.value;
      },
    };
  };
 
  // 훅에서 제출 이벤트 핸들러를 제공한다.
  const handleSubmit = (
    e: React.FormEvent<HTMLFormElement>,
    // 양식 검증이 완료되었다면 next 콜백을 호출한다.
    next: (result: FormValues) => void
  ) => {
    e.preventDefault();

    // formFieldsRef 에 등록된 모든 양식이 validate: true 라면 검증된(true) 값이다.  
    const valid = Object.values(formFieldsRef.current).every(
      ({validate, value}) => validate(value)
    );

    if (!valid) return;

    const formValues = Object.entries(formFieldsRef.current).map(
      ([fieldName, {value}]) => [fieldName, value]
    );

    // 검증이 성공하였을 경우 next 를 호출한다.
    next(Object.fromEntries(formValues));
  };

  return {
    register,
    handleSubmit,
  };
}

자 이제 준비된 useForm 커스텀 훅을 부모 컴포넌트에서 사용해보자.
react-hook-form 라이브러리를 사용해보았다면 react-hook-form 의 useForm 과 유사한 구조를 지님을 알아차렸을 수도 있겠다.

function SignIn() {
  const {handleSubmit, register} = useForm<{
    email: string;
    password: string;
  }>();

  const {
    mutate,
    error: {message: serverErrorMessage},
  } = signInMutation();

  return (
    <form onSubmit={e => handleSubmit(e, mutate)} noValidate>
      <EmailField register={register} />
      <PasswordField register={register} />
      {serverErrorMessage}
      <input type="submit" value="로그인" />
    </form>
  );
}

무엇이 나아졌는가? 가장 눈에 띄는 부분은 부모 컴포넌트 SignIn 과 자식 컴포넌트 *Field 가 각자의 관심사를 나눠가졌다는 것이다.

부모 컴포넌트 SignIn

• 입력이 완료되면 서버에 전송한다.
• (서버 처리 결과 알림) 서버에서 400 번대 에러가 응답되었다면, 사용자에게 피드백을 제공한다.

자식 컴포넌트 EmailField, PasswordField

• 입력 가능한 필드를 제공한다.
• (브라우저 측 검증) 필수 입력 필드를 입력하지 않았다면/입력 양식이 정합하지 않다면, 사용자에게 피드백을 제공한다.

커스텀 훅 useForm

• 부모, 자식이 메시지를 주고받는 방식을 제공한다.
• Field 의 생성 규칙을 정의한다.

또한 자식 컴포넌트는 재사용이 가능하다. 이 글에서는 입력요소(<input>) 만을 다루었지만 입력요소 조합된 형태의 fieldSet 이나, 체크 박스, 선택 입력 등을 Field 계층과 동일한 접근법을 통해 정의할 수 있음을 예상할 수 있다.

Field 의 관심사가 명확해졌고, 그에 따라 정의된 EmailField, PasswordField 컴포넌트는 회원가입, 이메일을 통해 비밀번호 찾기, 비밀번호 변경 등에 범용적으로 사용될 수 있다.

react-hook-form 소개

react-hook-form 은 위의 예제와 유사한 방식으로 동작하는 리액트 폼 라이브러리이다.

사실 ‘React 제출 양식에서 입력 필드의 재사용성 찾기’ 의 방안을 찾아보던 중 react-hook-form 을 먼저 접하게 되었고, 위 코드는 해당 라이브러리에서 useForm, register 의 설계를 이해하기 위해 직접 구현해본 것이다.

유효성 검증 시점을 선택할 수 있다거나, 구체적인 validate 규칙을 pattern 객체를 통해 제공하는 등 uncontrolled 하게 form 을 관리하기 위한 많은 부가기능과 여러 룰을 제공한다.

팀 내의 특정한 규칙이 없다면 입력 양식 관리는 개인 스타일에 따라 중구난방이 되기 마련인데, react-hook-form 은 팀 단위로 일하는 클라이언트 개발 조직에서 규칙성있게 제출 양식을 관리하는 합리적인 대안으로 보인다.

react-hook-form 으로 구현된 로그인 양식은 다음과 같다. 아래 예시에서는 register 를 prop 으로 전달하는 방식대신 useFormContext 훅을 사용하여 부모와 메시지를 주고받도록 하였다.

import {SubmitHandler, useForm, FormProvider} from 'react-hook-form';

export default function SignInPage() {
  const methods = useForm<SignInFormValues>({
    mode: 'onSubmit',
  });

  const {
    mutate,
    error: {message: serverErrorMessage},
  } = signInMutation();

  return (
    <FormProvider {...methods}>
      <Form onSubmit={methods.handleSubmit(mutate)} noValidate>
        <EmailField />
        <PasswordField />
        <button type="submit">로그인</button>
      </Form>
    </FormProvider>
  )
}

import {useFormContext} from 'react-hook-form';

function EmailField() {
  const {
    register,
    formState: {errors},
  } = useFormContext<EmailValues>();

  return (
    <Form.Input
      id="email"
      type="email"
      label="email"
      {...register('email', {
        required: '이메일을 입력하세요.',
      })}
      helperText={errors.email?.message}
    />
  );
}

마치며

예전에 경험했던 프로젝트에서 입력 양식을 규칙 없이 관리하여 수십개의 동일한 브랜드 검색 기능을 지니는 폼을 일괄 수정해야할 때 터무니없는 오랜 시간이 걸려 팀의 사기가 저하되는 경험을 한적이 있다.

이렇게라도 정리해두니 동일한 시행착오를 밞지 않을것같아 한시름 놓인다.

특정 라이브러리의 최소 기능 버전을 러프하게 구현해보는 것은 해당 라이브러리를 이해하기에 많은 도움이 되는것같다.

reference

• react-hook-form
• Qoddi : Create a Reusable Text Input With React Hook Form
• 심재철 : [React Design Pattern] Props Getter Pattern

최근 팀 내 프로젝트에서 이런 패턴으로 컴포넌트를 단계별로 구현하는 경험을 하였는데, 어려웠던 점은 최소단위인 atom 컴포넌트를 구현하는 방법이었다. 최소단위의 컴포넌트는 HTML 엘리먼트와 닮아있다. 가령 버튼 atom 컴포넌트를 만든다고 가정해보자.

이 버튼은 특정 자바스크립트 이벤트를 트리거 하기 위한 버튼일 수도 있고, 양식을 제출하기 위한 버튼일 수도 있다. 특정 페이지로 이동시키는 링크를 제공하는 버튼일수도 있다.
최소단위를 이루는 컴포넌트는 위와 같이 넒은 범위의 쓰임새에 대한 많은 가정을 해야하며 그 때문에 구현하기 까다로워 보인다.

특정 문제를 해결하는 도메인에 집중하는 서비스 개발과는 달리 라이브러리를 만들듯이 범용성을 갖추어야 한다. React UI 라이브러리인 머티리얼 UI의 Button 컴포넌트의 API 를 살펴보자. clickable 한 요소가 수용할 수 있는 넒은 범위의 수많은 옵션(Prop)을 제공한다.

‘어떻게 보여질 것인가’ 를 정의하는 옵션이외에 대략 다음과 같은 옵션을 확인할 수 있다.

• component(as) : 어떤 ElementNode 로 렌더링할 것인가
• disabled : 클릭 이벤트를 비활성화
• href : 링크 기능으로 쓰일때에 이동 주소

문서내에 언급되진 않았지만 이 외 onClick, type 등 다양한 기본 옵션들이 존재한다. 이제 여러 사용케이스를 포괄하는 다형성을 지닌 버튼을 만들어보자.

Button 을 만들어보자.

‘어떻게 보여질 것인가’ 를 제외한 몇가지 옵션이 구현된 버튼을 만들어보자. 어떻게 보여질것인가를 다루지 않기때문에 완성된 형태는 <button> ReactElement 와 동일할 것이다.

import React from 'react';

interface ButtonProps {
  children: React.ReactNode;
  onClick?: React.MouseEventHandler<HTMLButtonElement>;
}

export default function Button({onClick, children}: ButtonProps) {
  return (
  <button type="button" onClick={onClick}>
  {children}
  </button>
  );
}   

현재 상태로는 클릭 이벤트를 바인딩 할 수 있지만 type, disabled 등 <button> 이 지니는 기본 어트리뷰트를 제어할 수 없다.

ComponentPropsWithoutRef(참고) 를 이용하여 조금 더 범용적으로 타입을 정의해보자.

interface ButtonProps extends React.ComponentPropsWithoutRef<'button'> {
  children: React.ReactNode;
}

export default function Button({children, ...rest}: ButtonProps) {
  return <button {...rest}>{children}</button>;
}

이제 Button atom 요소를 다양한 사용 케이스를 포괄하여 사용할 수 있게 되었다.

다형적 컴포넌트

머티리얼 UI 에서 제공하는 버튼 컴포넌트를 살펴보면 <button> 처럼 사용할 수도 있지만 href, target 등 어트리뷰트를 넘길 수 있는 <a> 로 사용할 수도 있다.

href 가 있느냐 없느냐를 기준으로 어떤 엘리먼트로 렌더링할지 분기해보자.

type ButtonElementProps = JSX.IntrinsicElements['button'];
type AnchorElementProps = JSX.IntrinsicElements['a'];
type ButtonProps = ButtonElementProps | AnchorElementProps;

function isPropsForAnchorElement(
  props: ButtonProps
): props is AnchorElementProps {
  return 'href' in props;
}

export default function Button(props: ButtonProps) {
  if (isPropsForAnchorElement(props)) {
  return <a {...props} />;
  } else {
  return <button {...props} />;
  }
}

이제 Button 컴포넌트는 아래와 같은 두가지 사용 사례를 받아들 일 수 있게 되었다.

<Button type="button" onClick={() => alert('clicked!')}>
  클릭이벤트
</Button>
<Button href="https://google.com" target="_blank">
  google 로 이동
</Button>

조금 더 욕심을 부려 ReactRouter 를 사용할때에 <NavLink /> 등 다른 컴포넌트를 Button 컴포넌트를 통해 렌더링 할 수 있을까? NavLink 는 자주 쓰이기에 합리적인 가정으로 보인다.

as 를 통해 어떠한 Element 로 렌더링할지 선택할 수 있는 옵션을 추가해보자.

// 1. <button> & <a> 사용 시의 Props 타입
type ButtonElementProps = JSX.IntrinsicElements['button'];
type AnchorElementProps = JSX.IntrinsicElements['a'];

// 2. as 를 통해 ElementType 를 지정할 경우의 Props 타입
type PolymorphicElementProps<T extends React.ElementType> = {
  as: T;
} & React.ComponentPropsWithoutRef<T>;

type ButtonProps<T extends React.ElementType> =
  | ButtonElementProps
  | AnchorElementProps
  | PolymorphicElementProps<T>;

// 3. 렌더링 분기를 위한 is 함수
function isPropsForPolymorphicElement<T extends React.ElementType>(
  props: ButtonProps<React.ElementType>
): props is PolymorphicElementProps<T> {
  return 'as' in props;
}

function isPropsForAnchorElement(
  props: ButtonProps<React.ElementType>
): props is AnchorElementProps {
  return 'href' in props;
}

export default function Button<T extends React.ElementType>(
  props: ButtonProps<T>
) {
  if (isPropsForPolymorphicElement<T>(props)) {
  const {as, ...rest} = props;
  const Element: React.ElementType = as;
  return <Element {...rest} />;
  } else if (isPropsForAnchorElement(props)) {
  return <a {...props} />;
  } else {
  return <button {...props} />;
  }
}

<Button as={NavLink} to="/getting-started">
  시작하려면 이 버튼을 누르세요.
</Button>
<Button type="button" onClick={() => alert('clicked!')}>
  클릭이벤트
</Button>
<Button href="https://google.com" target="_blank" disabled>
  google 로 이동
</Button>
<Button as="div" role="button">
  나도 버튼 역할을 한다.
</Button>

이제 Button 컴포넌트를 다형적으로 사용할 수 있게 되었다.

다만 Button 컴포넌트에 3가지 사용 유형을 정의하게 되면서 교차 타입을 사용하게되며 주석이 필요할 정도로 내부 구현이 상당히 복잡해졌다.

href 를 넘기면 자동으로 <a> 로 추론되는 편의 기능을 트레이드오프를 한다면 조금 더 내부 구현을 간단명료하게 변경할 수 있다. <button> 외에 다른 Element 로 렌더링하고 싶다면 무조건 as 를 필수 값으로 넘기도록 하는것이다.

const defaultElement = 'button';

type ButtonProps<T extends React.ElementType> = {
  as?: T;
} & React.ComponentPropsWithoutRef<T>;

export default function Button<
  T extends React.ElementType = typeof defaultElement
>({as, ...rest}: ButtonProps<T>) {
  const Element = as ?? defaultElement;

  return <Element {...rest} />;
}

href 사용 시 <a> 로 추론 되는 기능이 사라져 공짜는 아니지만, 장황한 선언을 제거하니 이제 어느정도 읽을만한 녀석이 되었다. 나는 이 버전이 마음에 든다.

부모에서 ref 전달할 수 있도록 하기

앱에 진입 시 ‘시작하려면 이 버튼을 누르세요.’ 에 자동으로 포커스를 주고자 한다거나, 다른 여러 이유에 의해서 Button 에 ref 가 필요할 수 있다.

forwardRef 를 통해 ref 를 전달 받을 수 있도록 하자.

const defaultElement = 'button';

type ButtonProps<T extends React.ElementType> = {
  as?: T;
} & React.ComponentPropsWithoutRef<T>;

const Button = React.forwardRef(
  <T extends React.ElementType = typeof defaultElement>(
    {as, ...rest}: ButtonProps<T>,
    ref: React.Ref<any>
  ) => {
    const Element = as ?? defaultElement;

    return <Element ref={ref} {...rest} />;
  }
);

export default Button;

마치며

라이브러리 성격의 컴포넌트는 서비스 어플리케이션을 구현할때와 조금 다른 사고가 필요하다고 느꼈다. 특정한 문제를 해결하는 개발을 할때에는 불필요한 인터페이스를 최대한 줄이고 당장 필요하지 않다면 구현하지 않는(YAGNI) 원칙을 따르고자 노력했는데 많은 사용 사례를 가정하는 컴포넌트를 구현하다보니 영 익숙치 않았다.

React 자체에서 제공하는 타입에 대한 이해도가 어느정도 필요하다고 느꼈다. 머릿속의 의도대로 타입을 작성하는것이 쉽지 않아 여러 레퍼런스들을 검색해가며 Button 하나 만드는데에 상당부분 시간을 할애했다.

참고 자료

• evan-moon : 타입스크립트와 함께 컴포넌트를 단계 별로 추상화해보자
• Create a Polymorphic Component with Typescript and React
• typescript-cheatsheets/react : Useful Patterns by Use Case

테스트 주도 개발?

재작년 이맘때 쯔음 작은 어드민 대시보드 성격의 프로덕트를 개발한 적이 있는데 일정 내에 충분히 감당할 수 있겠다고 여겨지는 적당한 규모의 프로젝트 였다. 때문에 나는 그간 들어왔던 TDD 를 개발 중 시도해보았다. Jest 와 React Testing Library 를 이용하여 만들고자하는 함수와 컴포넌트 기능 하나하나마다 테스트를 작성하였다.

첫번째로 mocking 개념을 이해하는게 여간 어려운게 아니었다. 테스트를 작성할때에 벡엔드 API 의 응답을 모방하고 외부 라이브러리 훅들을 모방해야 했는데 이 부분을 작성하는데에 시간이 많이 소요되었다.

둘째로 구체적으로 어떠한 테스트를 작성해야하는지가 잘 연상되지 않았다.
데이터가 주입하면 리스트가 렌더링 되는 컴포넌트가 있는데 한 화면에 몇개의 테스트를 보여주는지까지만 테스트해야되는지, 리스트 아이템들의 콘텐츠들을 mock 데이터와 하나하나 비교하는 식으로 테스트를 작성해야하는지, hover 동작에 따라 아이템이 강조되는 동작이 있을 경우 이러한 테스트는 어떻게 작성해야하는지, 작성하는게 맞는지 등 테스트를 작성하며 여러 모호한 고민이 꼬리에 꼬리를 물었다.

결국 떠오르는 테스트를 모두 작성했고, 2주 동안 이렇게 개발을 하며 커맨드를 입력하면 내가 작성한 테스트의 갯수와 green 이 뜨며 테스트가 통과하는걸 동료들에게 보여주며 뿌듯해 했다. 거기까지 였다. 이후 프로젝트가 진행되며 스팩이 크고 작게 변경됨에 따라 많은 테스트 케이스들이 유효하지 않게 되었다.
테스트를 수정해가며 변경에 대응했으면 좋았겠지만 이때 생산성 측면에서 발목을 크게 잡히는 느낌이였다. 결국 이 시점에서 테스트를 수정하지 않고 코드를 수정하여 기민하게 대응하는 것을 택했고, 어느정도 시간이 지난 이후 이따금 상한 테스트 코드들을 실행해보면 수십개의 테스트를 실패하는 모습을 보게되었다.

결론적으로 당시 내가 느낀 어려움은 다음과 같았다.

1. 3 만큼의 시간이 있다면 테스트 작성을 하는데 2, 제품을 구현하는데에 1의 시간이 걸렸다. 숙련도 부족으로 테스트에 대한 자신감이 저하되었다.
2. 내가 작성한 테스트 케이스들이 제품에 도움이 되는 테스트 케이스라는것을 확신할 수 없었다.
3. 결과적으로 자신감보다는 테스트를 실행하는데에 또 어느 테스트가 망가졌을지 공포감을 느끼게 되었고 테스트를 개발 프로세스에서 배재했다.

당시를 회고해보면 나는 테스트 자체가 가져다주는 실용주의적 측면보다는, TDD 라는 트랜디한 키워드 자체에 매료되었던것 같다.

당시를 떠올려보면 적절한 타협안을 찾았더라면 좋았겠다 싶다. 테스트 커버리지의 욕심, TDD 의 프로세스에 매몰되기보다는 ‘자동화 테스트를 통해 결과물에 대한 자신감을 얻자’ 는 측면에 집중하며 시도해볼만하다 싶은 부분에는 TDD 를 적용해보고, 숙련도가 부족하다면 구현을 먼저하고 단위 테스트를 작성해보는 식으로 욕심을 덜어냈더라면 결과가 달라졌을 것이다.

e2e 테스트와 Cypress

현재는 cypress 라는 도구로 e2e 테스트 를 작성하는 방법을 동료들과 스터디하고 있는데 나는 이 도구가 썩 마음에 든다. “특정 이벤트가 발생되면 사용자 브라우저에 콘텐츠가 노출되는지” 등을 모킹에 대한 걱정없이 스무스하게 작성할 수 있었고 이러한 테스트를 검증하는 과정을 브라우저를 통해 실시간으로 확인할 수 있단 점이 시각적으로 나에게 매우 큰 즐거움을 준다.

무엇보다 즐거운 점은 QA 엔지니어들과 공감대를 형성할 수 있고 QA 엔지니어들과 함께 테스트를 작성할 수도 있겠다는 점이다. Cypress : Testing Types 란 아티클을 보면 다음과 같이 e2e테스트와 단위테스트의 장점을 비교해둔 테이블을 확인할 수 있다.

앱의 기능에 대한 검증이라는 테스트의 본질을 이점으로 가져가기 쉽다.

또하나의 재밌는 점으로 Cypress 는 jQuery 를 이용하여 DOM 에 엑세스 한다는 점이다. jQuery 는 검증하고자 하는 DOM 에 접근할때에 정말 편하게 접근할 수 있고 선택과 검증을 메소드 체이닝을 통해 표현 할 수 있다.

$.fn 으로 필요한 메소드를 커스텀하여 정의하듯이 Custom Commands 를 통해 필요한 메서드를 정의하여 재사용할 수 있다. 다분히 익숙하게 느껴지는 방식이다.

아래는 내가 cypress를 연습하며 작성한 다마고찌 앱의 청소 관련된 기능을 테스트하는 코드인데 테스트가 이러한 장점 덕에 쉽게 읽히게 작성할 수 있단 점이 너무 마음에 든다.

Cypress.Commands.add('cleanPoop', () => 
  cy
    .contains('Clean Poop')
    .click()
    .root()
)

it('Clean Poop 버튼을 누르면 Poop 이 지워진다.', () => {
  cy
    .cleanPoop()
    .hasPooped(false)
});

it('생성된 Poop 을 치울 때 마다 Clean Count 가 증가한다.', () => {
  cy
    .cleanPoop()
    .contains('Clean Count : 1');
});

결론

현재 나는 클라이언트 측의 로직상 중요한 계산을 하는 함수나, 리팩토링을 할때에 before & after 를 보장하기위해 간간히 단위테스트를 작성한다. 여전히 물흐르듯 단위 테스트를 작성하지는 못한다.

e2e 테스트도 즐겁게 학습을 하는 단계이지 무언가 가시적인 성과는 아직 거두지 못하였다.

조급함에 항상 주의하며 자동화 테스트를 나의 개발 프로세스에서 서서히 스며들게 해보고 싶다. 작은 시도들을 통해 경험치를 천천히 쌓아가며 그를 통해 자신감을 얻자.

내가 이야기하고 싶어하는 도구란 무엇일까? 도구를 무조건적으로 사용하는것을 옳은가?
우선 도구의 기준을 정의해보고 어떻게 도구를 다루어야할 지 살펴보자.

도구는 저수준의 문제를 감춘다.

내가 생각하는 도구에 부합하는 가장 근본적인 개념 중 하나는 고차함수 이다. 자바스크립트의 Array.prototype.map 을 보자.

[1,2,3,4,5].map(num => num * 5) // [5, 10, 15, 20, 25]

이 아름다운 빌트인 메서드는 다음과 같은 주제를 추상화 한다.
복잡한 개념을 추상화 하고 프로그래머는 ‘어떻게’ 할 것인가를 정의한다.

1. 반복을 어떻게 할 것인가? : 배열의 항목 만큼 반복할 것이다.
2. 반복하며 무엇을 할 것인가? : 배열의 각 항목에 하고자 하는바 를 대입하여 새로운 값을 리턴한다.

이처럼 Array.prototype.map 의 함의하고 있는 주제는 ‘매핑’ 이다.
프로그래머는 매핑이 어떻게 이루어지는지에 대해는 관심을 가지지 않는다. 단지 하고자 하는바 를 함수라는 형태로 도구에 전달하고 도구는 그에 맡게 내가 원하는 바를 수행하여 나에게 돌려준다.
다음으로 좀 더 고수준의 도구를 살펴보자.

도구는 여러 프로그래머에 의해 정의된다.

도구는 다른 프로그래머에 의해 정의되고, 사용된다.
A 는 특정 문제를 해결하는 함수나 객체생성자를 만든다. 그리고 같은 팀원인 A, B, C 는 이 도구를 사용하여 같은 주제를 다루는 문제를 쉽게 해결한다.
가령 상품의 소비자가와 판매가에 대한 할인률을 계산하여야 하는 주제가 있다면 다음과 같은 도구를 정의하여 해결한다.

export function getDiscountRateBy (fullPrice: number, salesPrice: number) {
  return ((fullPrice - salesPrice) / fullPrice) * 100
}

getDiscountRateBy(2500, 1750) // 30. 30% 할인이 적용된 금액이다.

이러한 getDiscountRateBy를 A, B, C 개발자가 소스코드 전반에 사용한다면, 다음과 같은 현상이 나타난다.

1. getDiscountRateBy 는 소스코드 전반에 결합도를 지니게 된다.
2. getDiscountRateBy 의 공식이 재정의 될 경우 소스코드 전반에 영향을 미친다.
3. 따라서 getDiscountRateBy 는 우리의 소프트웨어와 강하게 결합된다.

도구를 정의하고 사용하는것은 문제해결에 큰 도움을 준다.
도구를 신뢰하고자 할 경우 테스트코드 등을 작성하여 신뢰도를 높힐 수 있다.
만일 해당 도구의 내부 수식이 잘못되었을 경우에는 해당 도구를 수정하여 실수를 코드 전반을 수정하는 것이 아니라 내부 구현을 수정함으로 해결할 수 있다.

그렇다면 이러한 도구가 가지는 트레이드오프는 없는가?
트레이드오프는 존재한다. 해당 도구와 우리의 소프트웨어가 결합되는 것이다.

그럼에도 이러한 ‘공공재’ 도구를 정의하는것은 권장된다.
개개별 리소스를 절약할 수 있으며, 검증된 도구는 소프트웨어 전반의 신뢰도를 향상시킨다. 소프트웨어의 중복을 줄임으로 관리를 용이하게 한다.

다만 도구가 한가지 문제를 해결하는것이 아니라, 여러가지 문제를 해결하고자 하는 도구일 경우 상황이 복잡해진다.

타인이 쥐어준 맥가이버 나이프

맥가이버 나이프는 멀티 툴 이다.
하나의 개체로 존재함에도 여러가지 문제를 해결하는데에 도움을 준다.
이러한 도구를 제조하는 관점에서는 이 도구가 유용하게 쓰이고자, 또는 시장에 잘 팔리고자 보다 유용한 기능을 많이 담고자 한다.

사용자의 관점에서는 나에게 당장 필요없는 기능이 몇가지 있더라도, 다른 많은 기능이 필요하다면 기꺼이 이 도구를 구매할 것이다.

소프트웨어의 세계에서는 이러한 맥가이버 나이프가 많다.
라이브러리와 프레임워크가 그 것 이다.

날짜와 시간의 맥가이버 나이프. momentJS

momentJS 는 날짜와 시간이라는 개념을 다루는데 특화된 라이브러리 이다. 이 도구는 대략 다음과 같은 기능을 제공한다.

이 도구의 유용함을 들여다보자. 직접 시험하고 싶다면 https://momentjs.com 에 접속 후 콘솔창에 moment 를 입력하면 실행가능한 전역 객체를 제공하는 것이 보일 것이다.

moment.locale('ko'); // 사용자의 로케일을 지정한다.

moment().format('YYYY-MM-DD'); // 2022-07-31. 현재 날짜를 리턴한다.
moment().format('LTS'); // 1:09:34 PM. 현재의 시간을 리턴한다.

const tomorrow = moment().add(1, 'days'); // 내일의 시간을 담는다.
tomorrow.format('YYYY-MM-DD'); // 2022-08-01. 내일의 날짜를 리턴한다.

moment().subtract(100, 'year').format('YYYY-MM-DD') // 100 년 전 날짜를 리턴한다.

moment 는 이처럼 날짜와 시간을 다루는데에 있어 유용하다.
세부사항에 대한 이해 없이도 메서드만 이해하면 사용할 수 있도록 적절히 추상화 되어있기 때문에 이 도구를 사용하면 할 일은 내가 필요한 시간대를 입력한 후, 그에 맞는 포멧을 입력하는 것 뿐이다.

이 유용한 도구를 우리의 소프트웨어에 초대하려면 해당 도구를 다운로드 받아 프로젝트에 import 한 다음 필요한 소스 코드 전반에 사용할 수 있다.

하지만 이러한 결정을 하기전에 조금 더 생각해볼 필요가 있다.

맥가이버 나이프는 부식된다.

소프트웨어에서의 도구는 현실의 도구와 닮아있다.

오픈소스의 기반 아래 시간이 지날수록 더 가볍고, 더 유용한 기능을 갖춘 도구가 생산된다.
잘 사용하던 도구가 유지보수 종료선언을 하기도 하거나 취약점이 발견되거나, 망가져서 소프트웨어 생태계 전반에 영향을 미치기도 한다.

이러한 상황이 발생하면 우리는 해당 도구를 다른 유용한 도구로 교체하거나, 기존에 도구가 해주던 역할을 우리가 직접 구현하던지 해야할 것이다.

나의 경우 momentJS 를 한동안 즐겨 사용하였고, 이 도구는 현재 deprecated 되었다. 구조가 오래되었고, 때문에 번들링 과정에서 트리 쉐이킹을 지원하기 어려우며, 불변성 관련된 문제가 있단것이 그 이유였다.

현재는 dayJS 라는 다른 대안이 사용되곤 한다. 그럼에도 내가 관리하는 일부 소프트웨어들은 아직 momentJS 의존성을 지니고 있다.

그 이유는 momentJS 가 이미 내가 구성한 프로젝트 전반에 강하게 결합되어 있고, 강하게 결합되어 있기 때문에 moment 와 결별하는데에 지나치게 많은 리소스가 들어가게 되는것 이 그 이유이다.

그렇다면 어떻게 다루어야 했을까?

대부분, 맥가이버 나이프의 모든 기능을 사용하지 않는다.

라이브러리, 프레임워크로 분류되는 도구들은 대부분 유용한 기능을 많이 담고자 하며, 그를 통해 유용하게 사용되고 주제에 부합하는 한 넒은 범위에 대한 해결 능력을 사전에 갖추어 놓고자 한다.

때문에 실제로 사용하지 않는 기능이 많음에도, 유용한 기능이 많기 때문에 이러한 도구들은 손쉽게 프로젝트에 초대되곤 한다.

이러한 도구가 초대되었을 때 프로젝트 전반에 도구의 어떠한 기능이 사용되고, 어떠한 기능은 사용되지 않는지 알 수 있는가?

가령 momentJS 를 사용할때에 우리의 프로젝트에서 format 기능만 사용하는지, subtract 기능은 사용하지 않는 지 알 수 있는 방법은 없는가?

도구가 부식되고, 교체가 필요해졌을 경우 이러한 범위를 신속하게 파악하고 교체할 수 있는가?

도구를 경계하라. 경계를 만들어라.

신중하게 도구를 사용한다면 상황이 닥쳤을 때 신속하게 이별하고 재정의 할 수 있다.

나의 소프트웨어 계층으로 도구를 입국 시킬때에는 신중하게 비자를 발급하자.
momentJS 를 datetime 이란 비자로 랩핑하여 우리의 소프트웨어로 신중히 입국시켜보자.

경계를 처리하는 wrapper 를 만들어라.

momentJS 를 그대로 사용하지 않는다. 함수나 객체생성자를 이용하여 momentJS 를 숨기고 소프트웨어에서 직접적으로 접근하여 사용하지 못하게 하자.

Datetime 을 다루는 객체생성자를 만듬을 통해 특정 소스코드만 moment 의존성을 지니도록 래핑하여보자.

현재 사용이 예상되는 moment.add, moment.subtract, moment.format 기능의 일부를 동일하게 메서드 체이닝이 가능하도록 제공하는것을 목적으로 한다.

// wrapper/datetime.ts
import moment from 'moment';

type DateFormat = 'YYYY-MM-DD' | 'LTS'
type DateUnit = 'day' | 'month' | 'year'

class Datetime {
	private _date: Date;

	constructor(date = new Date()) {
		this._date = date;
	}

	static datetime(date = new Date()) {
		return new Datetime(date);
	}

	public format(dateFormat: DateFormat) {
		return moment(this._date).format(dateFormat);
	}

	public add(amount: number, unit: DateUnit) {
		return Datetime.datetime(moment(this._date).add(amount, unit).toDate());
	}

	public subtract(amount: number, unit: DateUnit) {
		return Datetime.datetime(moment(this._date).subtract(amount, unit).toDate());
	}
}

export const datetime = Datetime.datetime;

완성된 래핑 계층은 위와 같다.

import {datetime} from "./wrappers/datetime";

datetime().format('YYYY-MM-DD') // 2022-07-31
datetime().add(1, 'year').format('YYYY-MM-DD') // 2023-07-31
datetime().subtract(1, 'year').format('YYYY-MM-DD') // 2021-07-31

사용례는 위와 같다.

moment 는 moment() 를 통해 메인함수를 호출하였을때 moment.Moment 라는 여러 메서드가 정의된 인스턴스 리턴하는데 반해, datetime() 은 Datetime 클래스에 정의된 좁은 범위의 인스턴스를 리턴한다.

따라서 소프트웨어 단에서 datetime 을 사용하는 한 다음과 같은 이점을 지닌다.

• 통제 가능 : 라이브러리 내에서 어떠한 기능을 사용할지 경계를 둠으로 사용되는 유형을 제한할 수 있다.
• 경계의 분리 : 소프트웨어는 moment 에 직접적으로 의존하지 않는다. moment 에 직접적으로 의존하는것은 래핑 계층 뿐이다.

이러한 간단한 기교를 통해 맥가이버 나이프에서 내가 필요한 기능만 안정적으로 사용할 수 있다.
기성복을 맞춤형 정장으로 수선하는 것이다.

우아하게 의존성을 교체하라

시간이 흘러 moment 는 부식되었다. 우리는 트리쉐이킹이 가능한 경량화 라이브러리 dayjs 로 내부 부품을 교체하기를 원한다.

이 때 우리가 할 일은 datetime 래핑 계층 내부의 moment 의존성을 dayjs 의존성으로 대체하면 된다.

코드에 변경되는 부분은 moment 라는 선언을 dayjs 로 변경하는 것 뿐이다.

import dayjs from "dayjs";

type DateFormat = 'YYYY-MM-DD' | 'LTS'
type DateUnit = 'day' | 'month' | 'year'

class Datetime {
	private _date: Date;

	constructor(date = new Date()) {
		this._date = date
	}

	static datetime(date = new Date()) {
		return new Datetime(date)
	}

	public format(dateFormat: DateFormat) {
		return dayjs(this._date).format(dateFormat)
	}

	public add(amount: number, unit: DateUnit) {
		return Datetime.datetime(dayjs(this._date).add(amount, unit).toDate())
	}

	public subtract(amount: number, unit: DateUnit) {
		return Datetime.datetime(dayjs(this._date).subtract(amount, unit).toDate())
	}
}

export const datetime = Datetime.datetime;

시간이 흘러 dayjs 가 교체될 날이 온다면 동일한 방법을 적용할 수 있을것이다.

외부 라이브러리에 더 이상 의존하기 싫어진다면 제한된 인터페이스에 맞추어 직접 메서드를 구현할 수도 있을것이다.

github 레포지토리에 관련 소스코드를 남겨 두었다.

정리

경계를 처리하는 간단한 계층을 도입함으로 도구와 소프트웨어의 거리감을 유지할 수 있다.

이러한 간단한 wrapper 를 도입하여 소프트웨어를 외부 도구로 부터 보호할 수 있는 라이브러리는 많다.

다만 jQuery 나 React 와 같은 UI 라이브러리 의 경우라면 어떨까?
이와 같은 경계를 만드는것은 도전해 볼만한 주제이나 쉽지 않을것이다.

다만 이러한 라이브러리와 소프트웨어의 코어 비즈니스 로직을 분리함으로 우리의 핵심 구현을 지킬 수 있을것이다.

시간이 된다면 이러한 비즈니스 로직을 라이브러리와 분리하는 주제에 대해 포스팅 해보았으면 좋겠다.

이 아티클은 로버트 C. 마틴 의 클린 코드 의 8장. 경계 를 상당부분 참고하였다.

전반적으로 나 자신에 대한 아쉬움을 많이 느낀 한 해 였는데 무엇이 부족했고, 2022년은 무엇을 개선 할 수 있을지 되돌아보자.

‘함께’ 를 항상 생각하자

“이해가 되지 않습니다. 저 역시 그렇게 하려고 깃의 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는 데 실패했습니다. 사람들이 너무 수동적이고 보수적이에요”

“그 조직원들이 선생님을 좋아하나요?”
– 함께 자라기 : 애자일로 가는 길

독단에 치우치는 사람이 되지말자

개발을 하다보면 독단적인 사고에 매몰될 때가 유난히 많은것같다.

개발자는 저마다 중요하다 여기는 것의 차이가 있고, 동일한 기능을 구현하더라도 그에따라 각기 다른 코드가 생산된다.

기능 수정 및 유지보수 비용이 높아질 수 있기에 일관된 자연스레 스타일을 추구하게 된다. 프로젝트 초기 단계에서 사용할 도구들과 컨벤션에 대해 의논하고, 각 중요 피쳐에 코드리뷰를 하며 서로의 스타일을 맞추어 나간다.

이 과정에서 자연스레 서로의 의견을 공유하게 되고, 여러 의견 중 우리의 방향을 도출해나가야하는 상황이 생겨난다.

이러한 과정은 진리를 추구하는 숭고한 여정이 아닌, 미래의 우리의 시간과 정신을 보살피기 위함이다.

내가 새로 도입하고 싶은 도구나 패턴이 있다면 그것의 필요성을 증명하고 가르치려하기보단,
공감대를 먼저 형성하고 그에 대해 모두가 충분히 생각해볼 수 있는 시간을 마련하자.

잔에 깨끗한 물을 담으려고, 복잡한 파이프라인을 만들어 놓고 여과기를 층층이 설치하면 결국 잔에 한방울의 물도 담기지않고, 그 누구도 물을 담으려 하지 않을 수 있다.

잘못된 피드백은 피드백을 안하니만 못하게 된다.

내가 실수한것이 있는지, 무엇이 잘못되었고 무엇을 개선할 수 있는 지 가장 빨리 인지할 수 있는것은 나의 결과물을 다른 시각으로 바라봐 줄 수 있는 타인에게 피드백을 받는 것이다.

나는 동료들에게 많은 피드백을 제공하려 노력한다. 개선할 점이 보이면 개선을 종용하고, 결과물에 버그가 예상되는 부분이 있으면 사전에 알려주고자 한다.

다만 이러한 의견을 전달할때에 작년을 돌이켜보니 부족한 부분이 많았던 것 같다. 다음과 같은 피드백은 그 안에 담긴 내용의 가치여부를 떠나서 공격적으로 보일 수 있다.

• 특정 주제에 대해 별다른 설명없이 내가 옳다고 생각하는 기술 문서나 아티클을 공유하는 행동
• 정답을 제공하지 않는 상호간에 소모적인 의사소통. 이렇게 하면 ‘A’와 같은 문제점이 예상되니 ‘A’가 발생하지 않도록 더욱 고려해주셔야 할것같아요.
• 특정 문제에 대해 상대방을 무작정 가르치려는 행동

이러한 섣부른 피드백은 문제를 이슈업 할 수는 있겠으나 공격적으로 받아들여 질 수 있고, 서로의 신뢰관계에 독성으로 작용한다.

내가 많은 피드백을 제공한다고, 나도 많은 피드백을 받을 수 있을것이라고 생각하는건 유아적인 생각일 수 있다. 잘못에 대해 가르치려 들지말고, 문제에 대해 생각할 수 있는 계기를 제공하자.

그리하면 자연스레 긴장이 줄어들고, 나도 많은 피드백을 제공받을 수 있을것이다.

인지하는것과 아는것의 차이. 책을 통해 개념을 숙달하자.

2년 전 나에게 가장 필요한것은 구현능력 이었다.

일터에 가니 나에게 생소한 도구들이 있었고, 당장은 쓰지않더라도 이건 모름직이 알아야 한다고 생각되는 도구들이 많았다.

그에 나는 우선 익숙해질 수 있는 도움을 주는 클론코딩 등 강의를 보며 정신없이 따라하며, 무엇이라도 우선 만드는 능력을 얻는것에 집중했다.

조급한 나의 눈에 들어오는 텍스트는 기술 Documentation 이나, 특정 개념에 대해 축약하여 설명하여 주는 기술 아티클 뿐이였다.

그때의 버릇인지 나는 책에서 한동안 멀어져 있었다.

나는 내가 아는것에 대해 설명하는것에 어려움을 느낀다. 최근엔 신규입사자들에게 언어에 대해 교육하는 업무를 맡아볼 기회가 생겼는데, 개념에 대해 설명하는것에 큰 어려움을 겪었다.

몸으로는 체득하고 있었으나 그것을 타인에게 설명하려니 도무지 입 밖으로 나오지않아 예제 코드와 동작을 보여줌으로서 모면하고자 하였다. 부끄러운 일이다.

책을 읽으며 개념과 용어에 대해 익숙해지고, 알게된 지식을 다른사람에게 설명해주는 연습을 하자.

책은 강의와 달리, 내가 모르는 부분을 표시해두고 이해가 안가는 부분이 있다면 그 부분을 세번이고 네번이고 읽을 수 있다. 지금까지 구현 방법을 키우는 공부를 했다면, 이제 그 방법이 왜 생겨났고 어떻게 동작하는 가에 대한 동작원리를 잘 설명할 수 있는 사람이 되고싶다.

##나 자신이 개선할 것이 많다는것에 즐거워하자

개선할 부분이 많다는것을 나 자신이 더 많이 성장할 수 있는 기회라고 생각하자.

내년에 2022년을 돌아봤을때는 조금은 더 자신에게 떳떳한 사람이 되도록 노력하자.

우리는 유저에게 입력값을 받아 입력된 값을 저장하거나 수정하고자 할때 Form 을 사용한다.

React, Vue 등으로 Form 을 다루고자 할때에는 해당값을 바인딩해서 제어하고 싶어하는 경향이 있다. 프레임워크의 방식대로 사고하다보면 자연스레 해당 값을 상태로서 제어하고 싶어하기 때문 이다.

가령 nickname 을 입력받는 Form 을 React 로 Controlled 하게 작성해보자.

Controlled Form

const ReactForm = () => {
  const [nickname, setNickname] = React.useState() // 1. nickname 의 상태

  return (
    <form>
      <label>
        nickname:
        <input 
          type="text" 
          name="nickname"
          value={nickname}
          onChange= {e => setNickname(e.target.value)} // 2. change 마다 username 동기화
          />
      </label>
      <button type="submit">Join the room</button>
      
      {/* 3. username 상태가 동기화 되어 업데이트 된다. */}
      <p>nickname is : {nickname}</p>
    </form>
  )
}

ReactDOM.render(<ReactForm />, document.querySelector("#app"))

1. 1번에서 nickname 의 상태를 생성하였고
2. 2번에서 입력값과 상태의 동기화를 위하여 이벤트를 생성하였다.
3. 3번은 불필요하나, 상태가 실시간으로 동기화된다는것을 보여주고자 추가하였다.

nickname 상태에 입력값이 항상 동기화 되므로 우리는 아래와 같이 submit 이벤트를 처리하여, 유저가 submit 을 발생시켰을 때에 nickname 을 원하는 바 대로 처리할 수 있다. 가령 다음과 같이 말이다.

const ReactForm = () => {
  const [nickname, setNickname] = React.useState()
  
  const handleSubmit = event => {
  	event.preventDefault()
  	alert(nickname) // 입력받은 nickname 으로 하고싶은 일을 한다.
  }

  return (
    // ...
  )
}

handleSubmit 을 통해 입력받은 nickname 값을 원하는 시점에 처리할 수 있다.

이제 반문해보자.

onChange 를 왜 사용하였는가?
nickname 과 input.nickname.value 의 value 를 동기화 하기 위해서이다.

input.nickname.value가 변경되는 시점에 nickname 이 왜 매번 동기화 되어야하는가?
submit 이벤트가 발생하는 시점에 nickname 이 준비되어 있어야 하기 때문이다.

위와 같은 이유 때문에 양방향 바인딩이 필요하다.

위와 같은 양방향 바인딩은 React 의 세계에서는 자주쓰이나, 다음과 같은 비용을 지불해야 할 수 있다.

가령 입력을 받아야하는 필드가 추가되었고, 그에 따라 nickname 과 유사한 phoneNo, age 등 여러 상태들이 생겨났다고 가정해보자. Form 하위에 TextField 등 서브컴포넌트가 생겨났다고 가정해보자.

ReactForm 는 특정 상태가 업데이트 될때에 해당 상태를 양방향 바인딩하기 위해서 리렌더를 시도할것이다. 리렌더가 필요하다면 React 는 diffing check 를 해가며 변경되어야 하는 요소만 DOM 에 업데이트 시킬 것이다.

성능을 챙기고 싶다면 개발자는 이를 도와주기 위해서 useMemo 등을 이용하여 각 TextField 가 해당 TextField 에 해당하는 상태가 업데이트 될때만 리렌더링 하도록 하는 코드를 작성할 것이다.

위와 같은 작업은 필요한가? Submit 과 같이 사용자가 값을 제출하였을때만 각 필드들의 값이 필요할때에는 필요 없을 수 있다.

우리가 애써 React 의 상태로 관리하려 한 값은 이미 DOM 의 input.nickname.value 에 실시간으로 바인딩되어있다.

그렇다면 이제는 uncontrolled 하게 관리해보자.

UnControlled Form

React 에서 소개하는 비제어 컴포넌트 는 요약해보면 상태를 만들지도 않고 관리하지도 않는것이다. 단지 해당 데이터가 필요할때에 해당 값을 읽어오면 된다.

값이 바인딩된 nickname Form 을 아무런 상태도 없는 순진무구한 상태로 되돌려보자.

const ReactForm = () => {
return (
  <form>
    <label>
      nickname:
      <input
        type="text"
        name="nickname"
      />
    </label>
    <button type="submit">Join the room</button>
  </form>
)}

그리고 useCallback 을 이용하여 submit 이벤트 핸들러를 작성한다.

const ReactForm = () => {
  
const handleSubmit = React.useCallback(event => {
  event.preventDefault()
  alert('submit')
}, [])

return (
  <form onSubmit={handleSubmit}>
  // ...
  <form>
)}

그리고 handleSubmit 에서 input 에 접근하여 value 를 가져오면 된다.

현재 공식문서에는 useRef 를 사용하여 input.nickname.value 를 가져오나, 나는 훌륭한 Web API 인 FormData 를 이용하여 value 를 가져올 것이다.

const getFormData = formEl => {
  const formData = new FormData(formEl);
  
  const result = {};
  for (const [key, value] of formData.entries()) 
    Object.assign(result, { [key]: value });
  
  return result;
};

const ReactForm = () => {
  
const handleSubmit = React.useCallback(event => {
  const { nickname } = getFormData(event.currentTarget)
  event.preventDefault()
  alert(nickname)
}, [])

return (
  <form onSubmit={handleSubmit}>
  // ...
  <form>
)}

이제 nickname 을 입력 후 submit 을 동작하여보면 alert 에 입력한 nickname 값이 담겨서 출력되는것을 볼 수 있다.

정리

UnControlled Form 은 상태를 양방향 바인딩 하는 방식에 비해서 성능상의 이점과, 작성의 편의를 제공하나 입력 즉시 validation 을 실행하여 잘못된 입력값이 있음을 알려주고자하는 기능을 구현하고자 할때에는 적절 치 않을 수 있다.

하지만 무작정 모든 값을 프레임워크의 상태 값으로 관리하는것보다는 더 나은 선택 일 수 있다는것을 기억하자.

• 상태를 양방향 바인딩할때는, 양방향 바인딩이 꼭 필요한 행위인지 반문하여 보자.
• 양방향 바인딩이 필요없다면 양방향 바인딩을 하지 않으면 된다.
• UnControlled 하게 input 에 기본 값을 바인딩하고자 할때에는 defaultValue 를 사용하자.
• 복잡한 Form 을 UnControlled 하게 관리하고자 한다면 react-hook-form 모듈을 활용하는것도 좋은 대안이 될 수 있다.

서버와 클라이언트와 통신은 모두 비동기 요청으로 이루어진다. 서버가 언제 응답을 줄지 알 수 없기 때문이다.

때문에 개발을 할때에서는 서버로 부터 응답이 온 후에(비동기) 다음 로직이 실행될 수 있도록 콜백, 프로미스 등 여러가지 처리를 한다. 가령 다음 코드처럼 말이다.

async getData() {
  const data = await api.fetchData() // await. 응답이 올때까지 기다려.
  console.log(data); // 응답이 오면 data를 표시해줘.
}

이러한 비동기 요청의 응답을 기다린 이후, 다음 코드를 실행하는 패턴이 나에게는 당연하다고 여겨지는 패턴이다. 이러한 http call 을 처리해주는 jQuery.ajax 에 대해 간단히 살펴보자.

jQuery.ajax

jQuery.ajax : zerocho

jQuery.ajax.async = false

레거시 프로젝트에서 api 요청을 할때에는 jQuery.ajax 를 사용하곤 한다.

이 프로젝트는 fetch, axios 등을 사용하지않고 jQuery.ajax 를 통해 api 요청을 웹핑한다.
사용부에서 이해가 안가는 부분을 발견하였는데 다음과 같다.

getData() {
  const data = api.fetchData() // 어..? 비동기 처리를 안하네..?
  console.log(data); // 아니 비동기 처리를 안했는데 어떻게 이 시점에 response 를 받을 수 있지??
}

이는 여태까지 써왔던 패턴과 사뭇 다른데, 이러한 패턴이 가능한 이유를 풀어보면 다음과 같았다.
async 란 $.ajax 옵션을 사용하는것이다.

plainSyncCall() {
  const res =  $.ajax({
    method: 'GET',
    url: 'http://localhost:3004/posts/1',
    async: false // 이 녀석이 범인이다.
  })
  console.log(res.responseJSON)
}

이게 어떻게 가능한데?

Synchronous and asynchronous requests : MDN

XMLHttpRequest 는 요청을 동기로 처리할지 비동기로 처리할지 정할 수 있는 패터미터가 있었다. 세번째 인자가 그것인데 아래와 같이 xhr 을 동기식으로 요청할 수 있다.

var request = new XMLHttpRequest();
request.open('GET', '/bar/foo.txt', false); // 세번째 인자 async: false

서버의 응답이 올때까지 javascript 의 다음 행을 실행하지 않는것이다. MDN 에서는 이를 이렇게 표현하고 있다.

Synchronous requests block the execution of code which causes “freezing” on the screen and an unresponsive user experience

동기 요청은 코드 실행을 차단하여 화면이 “얼어 붙어” 버리고 응답하지없는 듯한 사용자 경험을 만듭니다.

이는 안티 패턴인가?

모든 ajax 요청을 동기적으로 처리한다면 개발자는 더이상 비동기 요청을 처리하는 케이스에 대해서 생각하지 않아도 될지 모른다.

이 방식으로 개발하게 된다면 마치 내가 구현하는 서비스에 비동기적 요청이 일체 없는듯한 착각을 불러일으킬것이다.

허나 이러한 xhr 요청을 하거나, jQuery.ajax.async = false 를 사용하면 브라우저 콘솔에서 다음과 같은 경고문을 볼 수 있다.

[Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check https://xhr.spec.whatwg.org/.

[Deprecation] 메인 스레드의 동기 XMLHttpRequest 는 최종 사용자의 경험에 해로운 영향을 미치기 때문에 더 이상 사용되지 않습니다. 자세한 도움말은 https://xhr.spec.whatwg.org/를 확인하세요.

그럼 왜 동기적 요청 패턴을 사용하면 안되는가??

‘사용하면 브라우저 콘솔에 Deprecation warning 이 뜨니깐요..’ 라는 대답은 근본에 비켜나간 대답인것같고 내가 느끼기엔 조금 멍청해보인다.

그래서 나는 이것에 대해 타당한 근거를 제시하는 여러 아티클을 찾아보았으나, 안타깝게도 ‘이러이러해서 안티패턴이구나!’ 라고 느껴지는 아티클을 찾지못하였다.

대부분 다음 코드 실행을 의도치않게 중지시킬 수 있기때문에 사용하면 안된다는 내가 느끼기에는 조금 모호해보이는 대답이 부지기수였다.

나의 생각

다시 처음으로 돌아가서 맨 처음 살펴보았던 async await 패턴을 보자.

async getData() {
  const data = await api.fetchData() // await. 응답이 올때까지 기다려.
  console.log(data); // 응답이 오면 data를 표시해줘.
}

이 코드의 목적성은 jQuery.ajax.async = false 나 Synchronous XMLHttpRequest 와 근본적으로 동일하다. 응답이 온 이후에 응답값을 표시하기를 바라기 때문이다.

다만 위 동기적 api 콜들과 한가지 다른점은 다음과 같다.

1. 개발자가 이 코드가 비동기 요청이라는것을 명확하게 인지하고 동기적으로 처리하고있디.
2. 다른 개발자가 이 코드를 보더라도 비동기요청을 동기적으로 처리한다는 것을 명확하게 알 수 있다.

만일 jQuery.ajax api 웹핑을 할때 async = false 를 기본값으로 두고 이 이름을 api 가 아닌 전혀 비동기임이 연상되지않는 네이밍으로 지었다고 생각해보자.

가령 웹핑시 이름을 data 라고 지었다면 다음과 같은 코드가 될것이다.

// 사용자의 프로필을 서버요청을 통해 받아와 렌더링 하는 코드 

displayProfile() {
  const id = data.getId() // 'id: foo'
  const profile = data.getProfile({ id })
  this.renderProfile(profile)
}

data.getId, data.getProfile 이 비동기 요청임에도 코드상에 전혀 들어나지 않는다.

의도에 맞게 실행될 것이지만, 데이터를 서버에서 받아오는지, 스토리지에서 가져오는지, 인스턴스에서 가져오는지가 코드상에 전혀 들어나지않는다.

이는 추후 특정 응답에 문제가 있거나, 코드를 해석하고자 할때 큰 혼란을 불러일으킬 것이다.

어느 부분이 비동기이고, 어느 부분에 브라우저가 await 를 하고있는지를 혼탁하게 만든다.

이러한 이유때문에 목적성은 같더라도 callback, promise, async, await 등으로 비동기 처리를 하는 것이라고 생각한다.

이러한 일반적인 비동기 요청 핸들링은 동기적 코드와 비동기적 코드를 구분지어주며 브라우저가 기다릴 부분과 기다리지 않아도 될 부분을 명확히 분간하여 개발자에게 인지시켜준다.

때문에 Synchronous XMLHttpRequest 가 안티패턴으로 정의되었고, 이러한 패턴이 지양되어야한다는 의견이 지배적인것이 아닌지 생각해본다.

추가로 알아보고 싶은 주제

jQuery.ajax 에서 병렬 요청이 가능한가요?

https://sharepoint.stackexchange.com/questions/263675/how-to-use-promise-all-and-foreach-to-make-ajax-call-per-array-item