React, 의존성
모든 개발이 그렇듯이, 프론트엔드에서도 개발을 하고 있으면 조금 더 최적화된 코드를 갈망한다.
본인 또한 VanliaJS에서 React로 넘어가며 컴포넌트 단위 개발 작업 때 이 같은 고민이 항상 따라 다녔다.
🤔 대체 어떻게 해야 재사용성을 높이고 클린코드를 만드는거지...
하지만 정해진 방법이 없는 React 특성 상 이는 매번 나에게 많은 고민만 안겨 주었다.
오늘은 나와 같은 고민을 계속하는 분들을 위한 게시글을 작성해보려 한다.
해당 포스트는 Youtube 'FEConf Korea' 채널의 '[A3] 컴포넌트, 다시 생각하기_발표자 원지혁님'의 영상을 보고, 정리한 내용입니다. https://youtu.be/HYgKBvLr49c
의존성이란
케이크의 의존성
발표자 원지혁님은 의존성에 대한 예시로 케이크를 이야기한다.
케이크를 만들기 위해서는밀가루,설탕,계란이 필요하다.케이크가밀가루,설탕,계란에 의존한다.- 결론:
케이크의 의존성은밀가루,설탕,계란이다.
React의 의존성
앞서 말한 케이크에 대한 예제를 React의 컴포넌트에 적용할 수 있다.
컴포넌트의 의존성은 기능적(Type), 특징적(Feature)을 기준으로 분류 할 수 있다.
기능적 분류
| 이름 | 설명 |
|---|---|
| props | props를 통해 데이터를 사용 |
| hooks | 기본제공 혹은 커스텀 hook을 사용해 데이터를 사용 |
| import | 외부 모듈, 파일 등을 불러와 사용 |
특징적 분류
| 이름 | 설명 |
|---|---|
| 스타일 | 컴포넌트의 css 스타일 |
| 특정 컨트롤 로직 | UI 조작 동작, 사이드이펙트 실행 등 |
| 전역 상태 | 유저의 액션을 통해 초래된 상태 |
| 리모트 데이터 스키마 | API 서버에서 내려주는 데이터의 모양 |
🤔 리모트 데이터 스키마?
다른 이름들과 달리 해당 분류는 익숙하지 않은 단어이다.
아래 Facebook Relay 문서에 작성된 일부 문구를 보며 이해를 해보도록 하자.
대다수의 제품은 '하나의 특정 동작'을 원합니다.
'로딩 인디케이터🔄를 표시하면서' (중략) '필요한 모든 데이터'를 가져온 다음,
데이터를 사용할 수 있게 되면 '전체 뷰를 렌더링' 합니다. - by. facebook relay document
(무슨 말인지 더 모르겠어요 😂)
언뜻 보기에는 이해하기 어려워 보이는 글이나, 강조한 부분을 차근차근 읽어보면 어렵지 않다.
예시로 가져온 네이버 메인 페이지를 보며 한번 이해해보도록 하자.
사진을 살펴보면 임의로 나눈 6개의 데이터 영역이 보인다.
(뉴스 타이틀, 뉴스 리스트, 게시글, 날씨, 증권, 쇼핑)
아마도 각 데이터 영역은 각각의 API를 통해 호출 될 것이고, 이 속도는 제각기 다를 것이다.
만약 네이버에 접속했는데 이 다른 속도를 그대로 표시하게 하면 어떻게 될까?
(🙄 악 내눈!!!)
극단적이긴 하지만... 이 같이 드르륵 하는 모션이 보여질 것이다.
이는 당연히 좋은 유저 경험이 아니기에, 각 영역이 아닌 동시에 렌더링 되는 것을 추구한다.
또한 유저 경험 뿐 만 아니라, 렌더링 최적화의 방면에 있어서도 지양해야 하는 방식이다.
다시 케이크로 돌아가서
그럼 만약 케이크에 딸기를 얹고 싶다면 (추가하고 싶다면) 어떻게 해야할까?
그냥 케이크 빵에 딸기를 올리는 것이 아닌, 생크림 위에 올려야 할 것이다.
이 말인 즉슨, 케이크에 딸기를 추가하려면 생크림이 필요하다는 의미이다.
(↑ 생크림이 없다면 딸기는 케이크에서 굴러 갈 것이다. 이는 고객(클라이언트)가 원하는 것이 아니다.)
의존성에 빗대어 보자면, 딸기 케이크는 생크림에 추가적으로 의존한다.
다시 정리하면, 딸기 케이크의 숨은 의존성 : 생크림 이라고 볼 수 있다.
React 컴포넌트 라면?
그렇다면 컴포넌트에 새로운 정보를 추가하려면 어떻게 해야 할까?
앞의 딸기 케이크의 예시를 컴포넌트에 적용해 표현해보자.
케이크에딸기를 추가하고 싶다면,생크림이 필요하다.↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
컴포넌트에정보를 추가하려면,OOOO (다른수정)도 필요하다.
딸기케이크의 숨은 의존성 :생크림↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
정보를 표현하는컴포넌트의 숨은 의존성 :OOOO (다른수정)
즉, 컴포넌트에 새로운 정보를 표현하기 위해서는, 단순히 정보 뿐 만 아니라 또 다른 수정이 의존성으로 따라오게 된다는 것이다. 이번에도 간단한 예시와 함께 해보자.
아래와 같은 구조의 아티클을 표시해주는 코드가 있다고 가정해보고,
<Article /> 컴포넌트에 새로운 정보(Props)를 추가한다고 생각해보자.
<PageArticleList> // 아티클 리스트 페이지
<ArticleList> // 아티클 리스트
<Article /> // 아티클 컴포넌트
</ArticleList>
</PageArticleList>
| 작업 순서 | 대상 | 설명 |
|---|---|---|
| 1번째 | 리모트 데이터 | <Article /> 컴포넌트의 Props 수정 |
| 2번째 | 컴포넌트 | <Article />의 렌더링 부분 수정 |
| 3번째 | 숨은 의존성 | <ArticleList />의 Props 수정 |
| 4번째 | 숨은 의존성 | <PageArticleList />의 useEffect Hook 수정 |
(🤨 오잉, <Article /> 컴포넌트 만 수정하면 되는게 아니네??)
맞다. 보다시피 <Article /> 컴포넌트에 새로운 정보(props)를 추가하기 위해서는, 상위 컴포넌트들의 수정이 불가피하다.
결론적으로 이것은 리모트 데이터 스키마의 숨은 의존성이다.
지금까지의 의존성 정리
(↑지금까지 설명된 React 컴포넌트의 의존성)
컴포넌트의 의존성은 크게 두 가지 분류로 나눌 수 있음. (기능적(Type), 특징적(Feature))- 기능적 분류는
props,hooks,import등 - 특징적 분류는
스타일,로직,전역 상태,리모트 데이터 스키마 - 이 때
리모트 데이터 스키마는루트 컴포넌트와현재 컴포넌트사이의 수많은컴포넌트들에 숨은 의존성을 가짐
정리해 놓고 보니 많이 복잡한 내용은 아니다.
다음 게시글에는 이러한 의존성들을 어떻게 관리해야 할 지 알아볼 것이다.
+ 읽어주셔서 감사합니다.
+ 오타, 내용 지적, 피드백을 환영합니다. 많이 해주실 수록 제 성장의 밑거름이 됩니다.