🌚 다크모드, 진짜로 눈에 좋을까? HCI 유저 스터디 - (2) 리액트에서 컴포넌트 만들기

대학교 2021년 1학기 인간컴퓨터상호작용(HCI) 학부 과목을 수강하며 진행한 프로젝트입니다.
유저 스터디에 사용한 사이트: https://hci-proj-1.web.app/
이번 글에서는 해당 사이트를 개발하며 있었던 일 - 리팩토링을 정리합니다.

보이세요? 제가 만들어낸 수많은 중복 코드가...

컴포넌트?

Component의 사전적 의미는 다음과 같습니다.

• 더 큰 전체 부분, 특히 기계나 차량의 부품 또는 요소 (Oxford Languages)
• 다른 부분과 결합하여 더 큰 것을 형성하는 부분 (Cambridge Dictionary)
• 어떤 것의 component는 그것이 만들어진 부품을 말한다. (Collins Cobuild Advanced Learner's English Dictionary)
  👉 즉, 전체적인 부분을 이루는 작은 부분을 의미합니다.

웹에서 말하는 컴포넌트도 같은 의미를 갖습니다. 하지만 단순히 전체를 이루는 요소라는 의미만 갖는 것은 아닙니다. 전체의 일부로써 할 수 있는, 그리고 해야하는 역할이 몇가지 있습니다. 이를 구글 검색바를 예제로 정리해보려 합니다.

역할 1 - 재사용성

위 3가지 검색바는 각각 구글 메인 화면, 구글 검색 결과 화면, 이미지 검색 화면에서 나타나는 검색바입니다. 서로 다른 페이지에서 똑같은 요소인 '검색바'를 보여주기 위해, 같은 형태의 검색바를 사용하고 있습니다. 이처럼 컴포넌트 하나를 만들어놓으면 여러군데에서 재사용할 수 있습니다.

만약 이 검색바를 컴포넌트로 만들어놓지 않고 매번 새롭게 만들어주면 어떤 일이 일어날까요? 검색바를 나타내기위한 코드를 여러번 작성해야하는 문제가 생깁니다. 별로 달갑지 않은 일이죠. 똑같은 결과를 위해 중복 작업을 해야합니다. 우리는 그러고 있을 시간이 없어요! 🙃 반면 검색바 코드를 한번만 작성하고 이를 컴포넌트화하여 관리한다면, 그냥 검색바가 필요한 곳에 이런식으로 코드 한줄만 추가하면 검색바가 생길거에요.🙂

...
  <div>
      <img src={MainLogo} />
      <SearchBarComponent /> ->컴포넌트가 된 검색바
...

역할2 - 유연성

스크린샷을 자세히 살펴보면 같은 검색바 컴포넌트인데도 조금씩 다른 부분이 있습니다.

왼쪽의 일반 검색에는 없던 아이콘 2개가 오른쪽 이미지 검색에 생겼습니다. 이처럼 서로 다른 페이지에서 쓰이는 컴포넌트의 특성상 세부적인 요소를 추가, 수정 또는 삭제해야 하는 일이 생기기도 합니다. 그래서 컴포넌트 하나를 만들 때는 그 안의 세부 요소를 바꿀 수 있도록 설계하는 것이 좋습니다.

역할3 - 일관성

컴포넌트의 재사용성 때문에 생기는 또다른 특성이 있습니다. 바로 일관성입니다. 개념 하나를 표현하기 위해 컴포넌트 하나만을 사용하기 때문에 기능이나 스타일이 달라질 일이 없습니다. 우리가 구글의 메인 페이지와 이미지 검색 페이지에서 똑같은 기능과 스타일을 가진 검색바를 보는 것처럼 말이죠. 컴포넌트화를 통해 사이트의 전체적인 일관성을 유지할 수 있습니다.

리액트에서 컴포넌트화하기

이제 웹사이트를 만들면서 컴포넌트를 활용한 예시를 보여드리려합니다.

아래는 유저 스터디에 사용했던 사이트의 일부입니다. 원래 목적은 다크모드와 라이트모드에서 글을 읽을 때 피로도 차이를 알아보는 것이었으나, 이 목적을 숨겨야 했습니다. 그래서 짧은 글에서 특정 단어가 몇 번 나오는지 세면서 자연스럽게 글 전체를 읽도록 유도했습니다.

이 페이지에서 공통으로 사용하는 요소는 다음과 같습니다.

• 무지개 모양 아이콘
• "** (이)라는 단어가 총 몇 번 나오나요?", "버튼을 눌러 ~ 조절하지 마세요." 문구
• 글자 밝기 조정 버튼
• 배경색이 있는 짧은 글
• 숫자를 입력하는 필드
• 다음으로 넘어가는 버튼

반면 매번 달라져야하는 요소도 있습니다.

• 찾아야하는 단어
• 사용자가 읽을 짧은 글의 내용
• 다크모드일 경우, 글자 색상의 초기값
• 배경색

처음에는 Ctrl + C, Ctrl + V의 유혹에 빠져 각 페이지별로 파일을 하나씩 만들었습니다. 그렇게 하다보니 엄청난 문제가 생기기 시작했습니다.

1. 가장 먼저, 코드가 매우 더러워졌습니다.
   • 중복 코드가 무더기로 생겼기 때문이죠.
2. 하나를 수정하기 위해 수정 작업이 N번 필요했습니다.
   • 예를 들어, "밝게" 버튼 하나의 사이즈를 고치려면 똑같은 작업을 페이지 갯수만큼 해줘야 했습니다.
3. 새 페이지를 추가하기 위해 또다시 중복 코드를 만들어야 했습니다.
4. 기존 페이지를 삭제하기 위해 여러 군데에서 코드를 고쳐야 했습니다.

🧹 이대로는 안 되겠다 싶어 페이지 자체를 컴포넌트로 만들어버리기로 했습니다. 공통적으로 사용하는 요소를 먼저 만들고, 페이지별로 달라져야하는 요소는 props로 받게 했습니다.

그리고 찾아야 하는 단어와 짧은 글은 따로 constant로 빼서 관리하기로 했습니다.

코드의 일부만 봐도 얼마나 중복 코드가 많이 사라졌는지 알 수 있겠죠? 리팩토링을 마친 뒤 아래와 같은 장점이 생겼습니다.

1. ✨깔끔한 코드✨
2. 하나를 수정하기 위해 수정 작업을 1번만 하면 됩니다.
3. 페이지별 수정 사항이 생길 때 constant 파일만 고치면 바로 적용됩니다.
4. 새 페이지를 추가하기 편리해졌습니다.

• 프로젝트 git repo 보러가기: https://github.com/broccolism/HCI-how-they-read
• 리팩토링 전체 코드 보러가기: https://github.com/broccolism/HCI-how-they-read/commit/2828af90864b2a731abce420e4c7d9b68c39420e