리팩토링 | 컴포넌트 형태로 추상화하기

프로그래머스 블로그에 있는 해설 글을 참고해 리팩토링한 내용

상태에 따라 바뀌어야 하는 영역이 크게 두 가지다. Nodes와 Breadcrumb!

리팩토링 전

App 컴포넌트 내에서 renderNodesSection 와 renderBreadcrumbSection 함수를 작성했다. 각 함수 내에서, 상태를 기반으로 마크업을 렌더링한다. 상태가 변경되면 해당 함수들을 호출해 업데이트된 상태로 화면을 렌더링한다.

구현 조건 및 프로그래머스 블로그에서 제시한 바람직한 방향은 다음과 같았다.

• 컴포넌트 형태로 추상화
• DOM 접근을 최소화
• 명령형 프로그래밍보다는 선언적 프로그래밍

컴포넌트 형태로 추상화하기

'컴포넌트 형태로 추상화 하라'는 게 어떤 의미인지 잘 와닿지 않았다. 검색해 본 결과 추상화란 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 의미한다. 컴포넌트란 재사용이 가능한 각각의 독립된 모듈을 의미한다.

 

그렇다면 컴포넌트 형태의 추상화란 전체 App에서 특정 기능을 재사용이 가능한 독립된 모듈로 간추려내는 것이겠다.

 

내가 이해한 모듈은 다음과 같은 느낌이다.

모듈을 사용하는 입장에서는 모듈의 내부 작동 원리를 알 필요가 없다. 그저 어떻게 사용하는지와, 해당 모듈이 어떤 기능을 수행하는지(모듈이 만들어 내는 결과물)만 알면 된다. → 이를 만족하게끔 특정 기능을 분리해 내는 게 모듈화 아닐까?

 

명령형 프로그래밍 v.s. 선언적 프로그래밍

이 개념 또한 잘 이해가 되지 않아 찾아봤다.

"나는 지금 e마트 바로 옆에 있습니다. 그럼 여기서부터 집까지 어떻게 가야 할까요?"

명령형 방식 (HOW) : 주차장 북쪽 출구를 나와 왼쪽으로 가세요. 12번가 출구에 도착할 때까지 15번 북쪽 도로를 타세요. 이케아를 끼고 우회전하세요. 직진하여 첫 번째 신호등에서 우회전 하세요. 다음 신호등을 지나 좌회전을 하세요. 우리 집은 298입니다.

선언형 방식 (WHAT): 내 주소는 98 West Immutable Alley, Eden, Utah 84310입니다.

선언적 방식: 무엇을 수행하는지에만 관심이 있다. 그 무엇이 정확히 어떻게 이뤄지는 지에는 관심이 없다. 마치 블랙박스처럼, 난 input을 줄테니 너는 내가 원하는 output을 내놓기만 하면 돼.

 

따라서 컴포넌트 단위로 분리하는 패턴은 선언적 방식이라고 할 수 있다. 가령 한 UI 컴포넌트가 있다면, 우리는 그 컴포넌트에 state를 넘겨주고 (그 안에 과정이 어떻게 되든) 해당 컴포넌트가 그 state를 가지고 우리가 원하는 UI를 렌더링하기를 기대할 것이다.

 

그 외에도 선언적 방식은 다음과 같은 특징을 갖는다.

• 선언적 방식은 코드가 달성하고자 하는 게 무엇인지만을 나열하기 때문에, 코드의 재사용성이 높다.
  (상세한 구현 방식이 달라지지 않으므로)
• 선언적 방식은 상태를 직접 수정하지 않는다.
• 가독성이 좋다 = 코드 한 줄 한 줄을 읽지 않아도 해당 코드가 어떤 기능을 하는 코드인지 파악할 수 있다.

---

map 함수가 대표적인 선언적 방식에 해당한다고 볼 수 있다.

• 명령형 방식

function double (arr) {
  let results = []
  for (let i = 0; i < arr.length; i++){
    results.push(arr[i] * 2) // 상태를 직접 수정한다.
  }
  return results
}

• 선언형 방식

function double (arr) {
  return arr.map((item) => item * 2) // 상태를 직접 수정하지 않는다. 
}

물론, 선언형 방식이 제대로 동작하기 위해서는 명령형으로 "어떻게"가 구현된 것들이 추상화되어 있어야 한다. map 함수는 명령형 구현을 추상화한 대표적인 함수라고 할 수 있다. 컴포넌트 단위의 추상화 또한 비슷한 의미인 것으로 파악된다. 컴포넌트 내부에 "어떻게"를 구현하고, 전체 App에서는 해당 컴포넌트를 사용해 명령형 프로그래밍을 한다.

 

리팩토링 후

상태에 따라 Nodes UI를 렌더링한다. → 해당 기능을 Nodes 라는 컴포넌트로 추상화했다. setState 함수를 통해 컴포넌트에게 명령을 내릴 수 있다. 내가 명령한 상태를 기반으로 UI가 렌더링되는 세부 과정을 나는 알 수 없다. 

 

• DOM 접근의 최소화: DOM 접근이 일어나는 경우를 두 가지로 한정했다.
  • 컴포넌트가 인스턴스화 될 때
  • render 함수가 실행될 때
• render 함수가 호출되는 상황 또한 두 가지로 한정했다. 컴포넌트가 인스턴스화 될 때와 상태가 변경되었을 때! 이전 코드에서는 DOM접근과 렌더링이 언제 언제 발생하는 지 알 수 없었다.(renderNodesSection 함수가 어디 어디에서 호출되었는지 일일이 확인해야 했다.) 상태의 변경이든, UI의 변경이든  모든 변경은 최소한의 횟수로 예상 가능하게 발생하는 게 좋다. 그런 의미에서 render 함수가 호출되는 상황을 한정하는 것은 중요하다.

다음 글에서는 컴포넌트 간 의존성에 대해 다뤄보자.