검증된 UI 패턴을 이용해 리액트 어플리케이션 만들기

https://martinfowler.com/articles/modularizing-react-apps.html#ApartFromTheUserInterface

위 글을 읽고 번역 및 학습한 내용이다.

 

이 글의 제목에서 ‘리액트 어플리케이션’이란 표현을 사용했지만, 사실 리액트 어플리케이션이라는 것은 없다. 자바스크립트 혹은 타입스크립트로 작성하고 리액트를 뷰를 그리기 위해 사용한 프론트엔드 어플리케이션이 있을 뿐이다.

 

종종, 사람들은 리액트 컴포넌트나 훅스에 다양한 것들을 욱여넣어 어플리케이션이 돌아가도록 한다. 이렇게 덜 정리된 구조들은 작은 어플리케이션이나 비즈니스 로직이 많지 않을 때에는 괜찮을 수 있다. 그러나, 요즘같이 더 많은 비즈니스 로직들이 프론트엔드로 넘어온 시점에서는, 모든것을 컴포넌트에 담는 이런 구조는 많은 문제를 일으킨다.

리액트는 뷰를 만들기 위한 단순한 라이브러리이다.

리액트의 핵심은 유저 인터페이스를 만들기 위한 라이브러리라는 사실을 종종 까먹는 것 같다.

이러한 맥락에서, 리액트는 웹 개발의 특정한 면에 집중하는 라이브러리라는 점이 두드러진다. 즉, UI 컴포넌트를 위한 라이브러리이며 어플리케이션의 전반적인 구조나 디자인 측면에 있어서 UI 컴포넌트를 쉽게 그릴 수 있게 해 주기 때문에 리액트는 사실은 엄청난 자유를 제공하고 있는 것이다.

 

이렇게 말하면 굉장히 단순하고 쉽게 들린다. 그러나 나는 많은 사람들이 데이터 페칭과 로직들을 그 데이터가 사용되는 곳에 바로 관련 코드를 작성한 경우를 많이 보았다. 예를 들어, 리액트 컴포넌트 안에서 데이터를 페칭할 때, 아래와 같이 렌더링 직전에 useEffect를 사용해 데이터를 페칭해오는 경우를 많이 보았다.

useEffect(() => {
    fetch("https://address.service/api")
        .then((res) => res.json())
        .then((data) => {
            const addresses = data.map((item)=>({
            street: item.streetName, 
            address: item.streetAddress,
            postcode: item.postCode,
            }))
        })
}, [])

// the actual rendering...

 

이런 식으로 작성하는 것이 프론트엔드 생태계에서 아직 전반적으로 통용되는 스탠다드가 없어서 그런걸 수도 있고, 그냥 안 좋은 프로그래밍 습관일 수도 있다. 그러나 프론트엔드 어플리케이션들도 다른 일반적인 소프트웨어 어플리케이션과 같은 방향으로 생각해야 한다. 프론트엔드 생태계에서, 코드의 구조를 정리하기 위해 '관심사의 분리' 개념을 사용해야 하며, 다른 유용한 디자인 패턴들도 적용되어야 한다.

Welcome to the real world React application

대부분의 개발자들이 UI를 하나의 독립된 함수로 만들어 data를 DOM에 묶는 방식으로 간단하게 만들수 있다는 방식에 감탄했었다. 어떤 정도까지는 이 말이 맞다.

 

그러나 많은 개발자들이 백엔드에서 네트워크 호출을 하여 데이터를 부르거나, 페이지 네비게이션을 해야할 때 곤란함을 겪게 되는데, 사이드 이펙트가 컴포넌트를 덜 순수하게 만들기 때문이다. 그리고 이런 상태값들에 대해서 생각을 하는 순간, 많은 것들이 복잡해지고 UI의 어두운 면이 등장하게 된다.

Apart from the user interface

리액트는 유저 인터페이스를 만들기 위한 라이브러리이만큼, 순수한 계산이나 비즈니스 로직을 어디에 두느냐에 큰 관심이 없다. 그러나 그 뷰단을 넘어서, 프론트엔드 어플리케이션은 다른 영역들도 많이 있다. 어플리케이션이 동작하도록 하려면, 라우터, 로컬스토리지, 다른 레벨의 캐싱들, 네트워크 요청, 써드파티통합, 써드파티로그인, 보안, 로밍 퍼포먼스 튜닝 등 신경써야 할 게 많이 있다.

 

이렇듯, 많은 것들을 처리해야하기 때문에 모든 것을 리액트 컴포넌트나 훅스 안에 끼워 넣는 것은 좋은 생각이 아니다. 여러가지 컨셉을 한 곳에 두는 것은 대부분 더 많은 혼란을 가져다주기 때문이다.

 

만약 우리가 구조화된 폴더나 파일로 관심사를 분리할 수 있다면, 어플리케이션을 이해하기 위한 정신적 부하를 훨씬 더 많이 줄일 수 있을 것이다. 그리고 한 번에 한 가지에만 집중할 수 있게 될 것이다. 다행히도 잘 작동하기로 증명된 프로그래밍 패턴들이 존재한다.

리액트 어플리케이션의 진화

작거나 단순한 프로젝트에서는 리액트 컴포넌트안에 모든 로직이 들어있는 형태를 보았을 것이다. 전체적으로 컴포넌트들도 몇 개 없었을 것이다. 페이지를 동적으로 만들기 위한 몇몇의 변수나 스테이트를 제외하고는 전반적으로 HTML 처럼 보였을 것이다. 데이터 페칭 로직이 컴포넌트의 useEffect안에 들어있는 것을 많이 보았을 것이다.

 

그러나 어플리케이션이 커질수록 더 많은 것들이 코드에 더해지기 시작한다. 이를 잘 정리하지 않으면 점점 코드는 유지보수가 불가능한 상태로 변해버리고, 작은 기능 하나를 만드는 데에도 시간이 많이 들고 읽기에도 어려운 코드를 작성하게 된다는 뜻이다.

 

그래서 지속가능한 어플리케이션을 만들 수 있는 몇 가지 단계들을 리스트화 하여 말하고자 한다. 전반적으로 노력이 더 필요하나, 어플리케이션 내에 구조를 가지고 있는 것이 매우 도움이 될 것이다. 어떻게 하면 구조를 가진 프론트엔드 어플리케이션을 만들 수 있는지 필요한 단계들을 간단하게 한번 살펴보도록 하자.

Single Component Application

<Component>
    Network requests
    State management
    Domain loginc
    Render
</Component>

 

이런 형태로 한 컴포넌트로 된 어플리케이션을 만든다면, 곧 한 컴포넌트 안에서 읽어야 하는 것이 엄청 많아지는 것을 알 수 있을 것이다.

Multiple Component Application

<Component>
    Network requests
    State management
    Domain logic
</Component>

<Component>
    State
    Render
</Component>

<Component>
    Render
</Component>

 

이런 방식으로 한번에 한 컴포넌트로 분리할 수는 있겠으나, UI 와 관련없는 코드들을 컴포넌트 안에 넣어 놓는게 뭔가 맞지 않다고 느낄 것이다. 또한, 어떤 컴포넌트들은 너무 많은 내부 변수를 갖게 된다.

State management with hooks

그래서 이런 UI 와 관련없는 로직들을 별도의 공간에 놓는게 좋겠다는 생각이 들 것이다. 다행히도 리액트에서 사용자는 직접 훅을 만들 수 있다.

<Component>             useHook
    State    ----->       Network request
    Render                Domain logic
</Component>
      |       \
      |        \
<Component>.    <Component>
     Render        Render
</Component>    </Component>     

 

자 이제 모든걸 다 때려넣은 싱글컴포넌트에서 많은 것들을 추출해 냈다. 그리고 몇몇 개의 렌더링을 위한 순수한 컴포넌트들과 스테이트를 가지고 있는 재사용가능한 훅들을 만들어냈다. 그러나 훅스에 대한 문제점은, 사이드 이펙트와 상태관리와는 별개로, 어떤 로직들은 상태와 상관없는 순수한 계산처럼 보인다는 것이다.

Business models emerged

따라서 이러한 상태와 관련없는 로직들을 따로 정리하면 좋겠다는 생각이 들게 된다. 예를 들어, 이런 로직들을 떼어놓으면 로직이 다양한 뷰와 결합할 수 있게 될 것이다.

 

따라서 presentational/container component 패턴과 같은 다른 곳에 사용된 디자인 패턴들을 가져다가 사용할 수 있게 된다.

참고.
https://patterns-dev-kr.github.io/design-patterns/container-presentational-pattern/

요약하자면, presentational 컴포넌트는 데이터를 prop으로 받아 렌더링만 담당하는 컴포넌트이고, container 컴포넌트는 사용할 데이터를 가져오는 로직을 가지고 있는 컴포넌트를 의미한다. 그러나 훅스의 등장으로 이제 container 컴포넌트는 굳이 사용할 필요가 없어지고, presentational 컴포넌트에서 훅스를 이용하여 데이터를 가져와서 바로 렌더링 할 수 있게 되었다.

Layered frontend application

어플리케이션이 점점 더 복잡해지면 어떤 패턴이 필요해질 것이다. 그리고 다양한 레이어로 분리하여 한번에 한가지만 집중할 수 있도록 만들고 시어질 것이다. 이 때 사용할 수 있는 것이 Presentation Domain Data Layering이다.

https://martinfowler.com/bliki/PresentationDomainDataLayering.html

presentation(UI), domain logic(business logic layer that contains validations and calculations) , data access(sorts out how to manage persistent data in a database or remote services)

 

이제 어떻게 하면 이러한 구조를 프론트엔드 어플리케이션에 적용할 수 있는지 알아보도록 하자.

Introduction of Payment feature

온라인 쇼핑몰을 예제로 들텐데, 고객이 주문서에 물품을 추가하고, 결제방식중 하나를 선택해 결제하는 경우를 예로 들어보려고 한다.

이 결제 방식 옵션들은 서버사이드에서 받아 고객의 나라에 따라 다르게 보여주려고 한다. 자 이를 하기 위해 다음과 같은 코드를 작성했다고 해보자.

import { useEffect, useState } from 'react';  

export const Payment = ({amount}: {amount: number}) => {  
  const [paymentMethods, setPaymentMethods] = useState<LocalPaymentMethod[]>([])  

  useEffect(() => {  
    const fetchPaymentMethods = async() => {  
      const url = "https://online-ordering.com/api/payment-methods";  

      const response = await fetch(url);  
      const methods: RemotePaymentMethod[] = await response.json();  

      if(methods.length> 0){  
        const extended: LocalPaymentMethod[] = methods.map(method => ({  
          provider: method.name,  
          label : `Pay with ${method.name}`  
        }));  
        extended.push({provider: "cash", label : "Pay in cash"});  
      }else{  
        setPaymentMethods([])  
      }  
    };  

    fetchPaymentMethods();  
  }, [])  

  return(  
    <div>      <h3>Payment</h3>  
      <div>        {paymentMethods.map(method => (  
          <label key={method.provider}>  
            <input  
              type="radio"  
              name="payment"  
              value={method.provider}  
              defaultChecked={method.provider === 'cash'} />  
            <span>{method.label}</span>  
          </label>  
        ))}  
      </div>  
      <button>{amount}</button>  
    </div>  
  )}

 

자, 이런 방식으로 된 전형적인 컴포넌트를 아마 많이 봤을 것이다. 나쁘지는 않지만, 위에서 언급했듯이 이 안에 너무 많은 관심사가 들어있어서 읽기가 조금 어렵다.

the problem with the initial implementation

첫 번째로 다룰 문제는, 컴포넌트가 정말 바쁘다는 것이다.

 

만약 이 컴포넌트를 변경하려면 네트워크 요청을 어떻게 시작해야하는지, 어떻게 하면 데이털를 컴포넌트가 이해할 수 있는 형태로 가공할 수 있는지, 그리고 렌더링은 어떤 방식으로 일어나는지를 모두 다 이해해야 한다.

 

첫 번째로 할 수 있는 것은 view와 non-view를 분리하는 것이다. 그 이유는 전반적으로 뷰 로직은 non-뷰 로직보다 훨씬 더 자주 변경되기 때문이다.

The split of view and non-view code

리액트에서는 훅스를 사용하여 state를 관리하게 하고, 컴포넌트 자체를 조금 더 stateless하게 만들 수 있다. 함수를 추출하여 훅스를 만들어보면 다음과 같다.

import { useEffect, useState } from 'react';  

const usePaymentMethods = () => {  
  const [paymentMethods, setPaymentMethods] = useState<LocalPaymentMethod[]>([])  

  useEffect(() => {  
    const fetchPaymentMethods = async() => {  
      const url = "https://online-ordering.com/api/payment-methods";  

      const response = await fetch(url);  
      const methods: RemotePaymentMethod[] = await response.json();  

      if(methods.length> 0){  
        const extended: LocalPaymentMethod[] = methods.map(method => ({  
          provider: method.name,  
          label : `Pay with ${method.name}`  
        }));  
        extended.push({provider: "cash", label : "Pay in cash"});  
      }else{  
        setPaymentMethods([])  
      }  
    };  

    fetchPaymentMethods();  
  }, [])  

  return paymentMethods;  
}  

export default usePaymentMethods;

import usePaymentMethods from './usePaymentMethods';  

export const Payment = ({amount}: {amount: number}) => {  
  const {paymentMethods} = usePaymentMethods();  

  return(  
    <div>      <h3>Payment</h3>  
      <div>        {paymentMethods.map(method => (  
          <label key={method.provider}>  
            <input  
              type="radio"  
              name="payment"  
              value={method.provider}  
              defaultChecked={method.provider === 'cash'} />  
            <span>{method.label}</span>  
          </label>  
        ))}  
      </div>  
      <button>{amount}</button>  
    </div>  
  )}

 

자 이렇게 view와 non-view로 나누어보았다. 그런데 paymentMethods가 데이터 배열을 순회하며 하는 일을 살펴보면, 관심사의 분리가 또 필요하다는 것을 알게될 것이다.

Split the view by extracting sub component

그리고 만약 우리가 순수함수컴포넌트를 만들 수 있다면, 우리가 더 쉽게 코드를 이해할 수 있고 재사용하기가 쉬워질 것이다. 결국, 컴포넌트가 작으면 작을수록 재사용가능성이 더 높아진다.

 

자, 그럼 다시한번 더 함수를 추출해보도록 하자.

const PaymentMethods = ({  
                          paymentMethods,  
                        }: LocalPaymentMethod[]) => (  
  <>  
    {paymentMethods.map(method => (  
      <label key={method.provider}>  
        <input  
          type="radio"  
          name="payment"  
          value={method.provider}  
          defaultChecked={method.provider === 'cash'} />  
        <span>{method.label}</span>  
      </label>  
    ))}  
  </>  
)

export const Payment = ({amount}: {amount: number}) => {  
  const {paymentMethods} = usePaymentMethods();  

  return(  
    <div>      
        <h3>Payment</h3>  
        <PaymentMethods paymentMethods={paymentMethods} />  
        <button>{amount}</button>  
    </div>  
  )};

 

PaymentMethods함수 컴포넌트는 이제 어떤한 상태도 가지고 있지 않은 순수한 컴포넌트가 되었다.

Data modeling to encapsulate logic

이렇게 뷰와 뷰가 아닌 것으로 나누어 보았다. 그러나 자세히 보면 더 개선의 여지가 있는 것을 알 수 있다. 예를 들어 PaymentMethods 컴포넌트를 보면 default로 체크되어 있어야할지 여부에 대한 로직이 있는 것을 알 수 있다. 이는 데이터 누수가 발생할 수 있는 가능성을 지니고 있는 것이다.

 

또한 데이터를 받아 변환하는 과정에서도 누수가 발생할 가능성을 가지고 있다.

이런 상황에 우리는 data와 이에 따른 행동변화를 한 곳에 집중해 둔 class PaymentMethod를 만들어 사용할 수 있다.

class PaymentMethod{  
  private remotePaymentMethod:remotePaymentMethod;  

  constructor(remotePaymentMethod:remotePaymentMethod) {  
    this.remotePaymentMethod = remotePaymentMethod;  
  }  

  get provider(){  
    return this.remotePaymentMethod.name;  
  }  

  get label(){  
    if(this.provider === 'cash'){  
    return `Pay in ${this.provider}`  
  }  
  return `Pay with ${this.provider}`  
  }  

  get isDefaultMethod(){  
    return this.provider === 'cash';  
  }  
}

이 클래스를 활용하여 default cash payment method를 만들 수 있다.
const payInCash = new PaymentMethod({name:"cash"})

 

또한, 데이터를 가져와서 가공하는 과정에서 이 클래스로 만든 PaymentMethod 객체를 사용하거나 이를 convertPaymentMethods라는 함수로 만들 수도 있다.

기존의 usePaymentMethods는 다음과 같이 변경될 수 있겠다.

const payInCash = new PaymentMethod({name:'cash'})  

const convertPaymentMethods = (methods) => {  
  if(methods.length === 0 ){  
    return [];  
  }  

  const extended = methods.map(  
    method => new PaymentMethod(method)  
  );  
  extended.push(payInCash);  

  return extended;  
}

/////

import { useEffect, useState } from 'react';  

const usePaymentMethods = () => {  
  const [paymentMethods, setPaymentMethods] = useState<LocalPaymentMethod[]>([])  

  useEffect(() => {  
    const fetchPaymentMethods = async() => {  
      const url = "https://online-ordering.com/api/payment-methods";  

      const response = await fetch(url);  
      const methods: RemotePaymentMethod[] = await response.json();  
      setPaymentMethods(convertPaymentMethods(methods));  
    };  

    fetchPaymentMethods();  
  }, [])  

  return paymentMethods;  
}  

export default usePaymentMethods;

 

그리고 또한 PaymentMethods를 렌더링 하는 과정에서 method.provider === 'cash 를 사용하는 대신 getter를 직접 부를 수도 있겠다.

...
const PaymentMethods = ({ ...}) => (
  <>  
    {paymentMethods.map(method => (  
      <label key={method.provider}>  
        <input  
          type="radio"  
          name="payment"  
          value={method.provider}  
          defaultChecked={method.isDefaultMethod} />  // 이렇게!
        <span>{method.label}</span>  
      </label>  
    ))}  
  </>  
)
...

 

자 이제 우리는 Payment 컴포넌트를 다음과 같이 작은 단위로 쪼갰다.

새로운 구조의 장점

• 클래스를 사용하여 UI와 관련이 있는 인포메이션을 제외한 것들을 담았다. 따라서 로직 변경이 되었을 때에 이 로직이 뷰 안에 있는 것보다 훨씬 쉽게 변경할 수 있다.
• 새로운 PaymentMethods 컴포넌트는 순수 함수로서 도메인에서 받은 데이터에만 의존하고 있기 떄문에 테스트하기도 쉽고, 재사용하기도 쉽다.
• 코드들이 각각 명확한 자기 기능을 하고 있다. 새로운 요구사항이 오더라도 적당한 위치에 가서 코드를 다 읽지 않더라도 쉽게 변경할 수 있다.

자 그러면, 새로운 변경사항이 생겼을 때 어떻게 쉽게 대응할 수 있는지 한번 살펴보자.

New Requirement: donate to charity

이제 여기에 다음과 같은 기능을 추가해야 한다고 해보자.

사용자의 총금액에 비례하여 일정 금액을 기부하도록 하는 부분이 생기며, 버튼에는 '최종금액(총금액 - 기부금액)'이 표시되도록 해야한다고 해보자.

 

현재 폴더구조는 다음과 같이 되어있다.

  src
  ├── App.tsx
  ├── components
  │   ├── Payment.tsx
  │   └── PaymentMethods.tsx
  ├── hooks
  │   └── usePaymentMethods.ts
  ├── models
  │   └── PaymentMethod.ts
  └── types.ts

Internal state: agree to donation

Payment에 대해 변경을 하기 위해서, 즉 유저의 체크박스 체크여부를 관리하기 위해 우리는 새로운 내부 state를 하나 만들어야 한다.

export const Payment = ({amount}: {amount: number}) => {  
  const [agreeToDonate, setAgreeToDonate] = useState<boolean>(false);  

  const {total, tip} = useMemo(() => (  
    {      total : agreeToDonate? Math.floor(amount+1) : amount,  
      tip : parseFloat((Math.floor(amount+1)-amount).toPrecision(10))  
    }  
  ), [amount, agreeToDonate])  

  const {paymentMethods} = usePaymentMethods();  

  return(  
    <div>      
        <h3>Payment</h3>  
        <PaymentMethods paymentMethods={paymentMethods} />  
        <div>        
            <label>  
              <input type='checkbox' onChange={handleChange} checked=                           {agreeToDonate}/>  
              <p>            
              {agreeToDonate? "Thanks for your donation" : `I would like to                     donate ${tip} to charity.`}          
              </p>  
            </label>  
        </div>  
        <button>{total}</button>  
    </div>  
  )};

 

이렇게 변화를 반영함으로써 우리는 또다시 컴포넌트를 더럽히고 많은 것들을 하게 되었다. 자 그러면 또 이걸 어떻게 뷰와 non-뷰 코드로 바꿀 수 있는지 살펴볼 타이밍이 된 것이다.

Extract a hook to the rescue

그러면 다시 한번 다음과 같이 hooks로 state관련 로직을 분리할 수 있다.

export const useRoundUp = (amount:number) => {  
  const [agreeToDonate, setAgreeToDonate] = useState<boolean>(false);  


  const {total, tip} = useMemo(() => (  
    {      total : agreeToDonate? Math.floor(amount+1) : amount,  
      tip : parseFloat((Math.floor(amount+1)-amount).toPrecision(10))  
    }  
  ), [amount, agreeToDonate])  

  const updateAgreeToDonate = () => {  
    setAgreeToDonate(prev => !prev)  
  }  

  return{  
    total, tip, agreeToDonate, updateAgreeToDonate,  
  }  
}

 

그리고 Payment는 다음과 같이 다시 깔끔해질 것이다.

export const Payment = ({amount}: {amount: number}) => {  
  const {paymentMethods} = usePaymentMethods();  
  const {total, tip, agreeToDonate, updateAgreeToDonate} = useRoundUp(amount);  

  const formatCheckboxLabel = (agreeToDonate:boolean, tip:number) => {  
    return agreeToDonate? "Thanks for your donation" : `I would like to donate ${tip} to charity.`  }  

  return(  
    <div>      
        <h3>Payment</h3>  
        <PaymentMethods paymentMethods={paymentMethods} />  
        <div>        
         <label>  
          <input type='checkbox' onChange={handleChange} checked={agreeToDonate}/>  
          <p>{formatCheckboxLabel(agreeToDonate, tip)}</p>  
        </label>  
      </div>  
      <button>{total}</button>  
    </div>  
  )};

 

그리고 나서 다시 한번 체크박스 UI도 분리할 수 있다.

export const DonationCheckbox = ({onChange, checked, content}) => {  
  return(  
    <div>      <label>  
        <input type='checkbox' onChange={onChange} checked={checked}/>  
        <p>{content}</p>  
      </label>  
    </div>  
  )}

 

그리고 Payment는 다시 한번 다음과 같이 깔끔해진다.

export const Payment = ({amount}: {amount: number}) => {  
  const {paymentMethods} = usePaymentMethods();  
  const {total, tip, agreeToDonate, updateAgreeToDonate} = useRoundUp(amount);  

  const formatCheckboxLabel = (agreeToDonate:boolean, tip:number) => {  
    return agreeToDonate? "Thanks for your donation" : `I would like to donate ${tip} to charity.`  }  

  return(  
    <div>      <h3>Payment</h3>  
      <PaymentMethods paymentMethods={paymentMethods} />  
      <DonationCheckbox onChange={updateAgreeToDonate} checked={agreeToDonate} content={formatCheckboxLabel(agreeToDonate, tip)}/>  
      <button>{total}</button>  
    </div>  
  )};

 

그러면 이 시점에서 우리의 코드 구조는 다음과 같아진다. 각각의 컴포넌트가 하나의 역할을 잘 해주고 있는 형태이다.

More changes about round-up logic

만약 국가가 추가되면 기부금액을 계산하는 로직도 전부 다 달라져야 할 것이다. 예를 들어 일본 시장에서 0.1엔은 너무 작다. 어떻게 하면 고치기 쉬울까?

 

countryCode만 추가로 Payment 컴포넌트에 내려주면 된다.

<Payment amount={3312} countryCode="JP"

그리고 기부금액을 계산하는 모든 로직이 useRoundUp에 있기 때문에, countryCode를 해당 훅에 넘겨줄 수 있겠다.

export const Payment = ({amount, countryCode}: {amount: number}) => {  
  const {paymentMethods} = usePaymentMethods();  
  const {total, tip, agreeToDonate, updateAgreeToDonate} = useRoundUp(amount, countryCode);  

const formatCheckboxLabel = (agreeToDonate:boolean, tip:number) => {  
  const currencySign = countryCode === "JP" ? "Y" : "$"  

  return agreeToDonate? "Thanks for your donation" : `I would like to donate ${currencySign}${tip} to charity.`}

...

export const useRoundUp = (amount:number, countryCode:string) => {  
  const [agreeToDonate, setAgreeToDonate] = useState<boolean>(false);  


  const {total, tip} = useMemo(() => (  
    {      total : agreeToDonate? countryCode === "JP" ? Math.floor(amount / 100 + 1) * 100 : Math.floor(amount+1) : amount,  
      tip : parseFloat((Math.floor(amount+1)-amount).toPrecision(10))  
    }  
  ), [amount, agreeToDonate, countryCode])  

  ...
}

The shotgun surgery problem

이런 식으로 버그를 수정하거나 하나의 기능을 추가할 때 여러 개의 모듈을 변경시켜줘야 하는 문제를 "shotgun surgery"라고 부른다.

예를 들어, 만약 이 상태에서 덴마크를 추가해야 한다면 아래와 같은 코드를 여기저기 붙여야 할 것이다.

const currencySignMap = {
  JP: "¥",
  DK: "Kr.",
  AU: "$",
};

const getCurrencySign = (countryCode: CountryCode) =>
  currencySignMap[countryCode];

 

그럼 이 문제를 어떻게 해결해야 할까 Extract Class와 Replace Conditional with Polymorphism (조건문을 다형성으로 바꾸기)를 통해 해결할 수 있을 것이다.

export interface PaymentStrategy{  
  getRoundUpAmount(amount:number) : number;  
  getTip(amount:number): number;  
}  

export class PaymentStrategyAU implements PaymentStrategy{  
  get currencySign(): string{  
    return '$';  
  }  

  getRoundUpAmount(amount: number): number {  
    return Math.floor(amount+1);  
  }  

  getTip(amount: number): number {  
    return parseFloat((this.getRoundUpAmount(amount) - amount).toPrecision(10))  
  }  
}

이렇게 만든 클래스를 가지고 나라마다 서브클래스를 만들 수도 있겠지만 자바스크립트에서는 함수가 일급시민이니까, 그냥 round-up 알고리즘을 넘겨 사용할 수 도 있겠다. 이렇게 하면 서브클래스 개수도 줄어들 것이다.

export class CountryPayment{  
  private readonly _currencySign : string;  
  private readonly algorithm: RoundUpStrategy;  

  public constructor(currencySign:string, roundUpAlgorithm:RoundUpStrategy) {  
    this._currencySign=currencySign;  
    this.algorithm = roundUpAlgorithm;  
  }  

  get currencySign(): string{  
    return this._currencySign;  
  }  

  getRoundUpAmount(amount:number): number{  
    return this.algorithm(amount);  
  }  

  getTip(amount:number):number{  
    return calculateTipFor(this.getRoundUpAmount.bind(this))(amount)  
  }  
}

 

그리고 나면 이제 useRoundUp 훅을 다음과 같이 strategy를 이용해서 변경할 수 있다.

export const useRoundUp = (amount:number, strategy: PaymentStrategy) => {  
  const [agreeToDonate, setAgreeToDonate] = useState<boolean>(false);  


  const {total, tip} = useMemo(() => (  
    {      
      total : agreeToDonate? strategy.getRoundUpAmount(amount) : amount,  
      tip : strategy.getTip(amount),  
    }  
  ), [amount, agreeToDonate, strategy])  

  const updateAgreeToDonate = () => {  
    setAgreeToDonate(prev => !prev)  
  }  

  return{  
    total, tip, agreeToDonate, updateAgreeToDonate,  
  }  
}

 

그리고 만든 클래스를 이용하여 Payment에서부터 countryCode 대신 이 클래스를 활용하여 strategy를 내려주도록 한다.

그럼 이제 countryCode에 따라서 바꾸지 않아도 손쉽게 나라별 정보를 추가할 수 있게 되었다.

export const Payment = ({amount, strategy = new PaymentStrategyAU("$", roundUpToNearestInteger)}: {amount: number, strategy?: PaymentStrategy}) => {  
  const {paymentMethods} = usePaymentMethods();  
  const {total, tip, agreeToDonate, updateAgreeToDonate} = useRoundUp(amount, strategy);  


  const formatCheckboxLabel = (agreeToDonate:boolean, tip:number, strategy: CountryPayment) => {  
    return agreeToDonate? "Thanks for your donation" : `I would like to donate ${strategy.currencySign}${tip} to charity.`  }  

  return(  
    <div>      
      <h3>Payment</h3>  
      <PaymentMethods paymentMethods={paymentMethods} />  
      <DonationCheckbox onChange={updateAgreeToDonate} checked={agreeToDonate} content={formatCheckboxLabel(agreeToDonate, tip, strategy)}/>  
      <button>{total}</button>  
    </div>  
  )};

Push the design a bit further: extract a network client

'관심사의 분리'라는 마인드셋을 가지고 있다면, 이제 다음으로는 usePaymentMethods훅을 정리하고 싶어질 것이다. 지금 상태로는 큰 문제는 없지만, 에러 핸들링과 재시도 등 네트워크 결과 처리 코드 등을 추가하게 되면 코드가 엄청 길어질 수 있다.

 

따라서 네트워크 페칭하는 함수는 별도로 빼서 여러 군데에서 재활용 할 수 있게 하고, 그 결과 처리도 각각 다르게 하도록 할 수 있다. 결론적으로 해당 컴포넌트는 아래와 같이 변경될 것이다.

const fetchPaymentMethods = async() => {  
  const url = "https://online-ordering.com/api/payment-methods";  

  const response = await fetch(url);  
  const methods: RemotePaymentMethod[] = await response.json();  

};  


const usePaymentMethods = () => {  
  const [paymentMethods, setPaymentMethods] = useState<LocalPaymentMethod[]>([]) 

  useEffect(() => {  
    fetchPaymentMethods().then(methods =>              setPaymentMethods(convertPaymentMethods(methods));  
  }, [])  

  return paymentMethods;  
}  

export default usePaymentMethods;