React 에서 코드를 재사용 하는 방법
올바른 방식으로 React 코드를 공유하는 데 도움이 되는 기술
원문: https://medium.com/better-programming/how-to-reuse-code-in-react-40637747125f
안녕하세요! 저는 EPAM System에서 리드 소프트웨어 엔지니어로 있습니다. 오늘 저는 React 프로젝트에서 코드를 재사용 하는 것에 대한 제 생각과 경험을 적어보려 합니다.
저는 React로 이뤄진 크고 멋진 프런트엔드 프로젝트를 진행하고 있습니다. 코드 재사용 문제를 매일 마주하고 있으며, 이것에 대해 폭넓고 성공적으로 사용하고 있는 기술들이 있습니다. 이 기술들이 제가 이 주제에 대해서 여러분과 이야기하는 이유입니다.
아마도 여러분은 이미 이 글에 있는 것 중에 일부분 혹은 모든 기술과 원리를 알고 있을 수도 있습니다. 어쨌든, 저는 이 글이 여러분의 코드 품질을 증가시키는데 많은 도움이 되기를 바랍니다.
시작합니다!
DRY와 AHA의 대립 이야기
여러분은 이미 "똑같은 일을 두번하지 말 것"(Don't Repeat Yourself:DRY) 라는 디자인 패턴에 대해서 알고 있을 것입니다. 이것은 절대적으로 명확하고 합리적으로 들립니다. 코드의 중복을 피하라. 그 경계는 어디에 있을까요? 우리는 직면하는 모든 코드 중복을 피해야 할까요? 공유하고 재사용할 수 있도록 만들어야 하는 최소 코드 크기는 어떻게 될까요?
아시다시피 어려운 질문입니다. 그리고 DRY 원칙은 여러분의 코드를 전혀 유지할 수 없게 만들 수 있기 때문에 주의해야 합니다. 여기서 문제는 무엇일까요?
"성급한 추상화를 피할 것"AHA(Avoid Hasty Abstractions:AHA) 디자인 원칙에 대해 들어본 적이 있으시나요? 이 약어는 성급한 추상화 방지를 의미합니다. 이 원리에 대해서 Kent C. Dodds이 작성한 아주 좋은 글이 있습니다. 해당 글에 대해 요약하자면, 추상화를 많이 사용하는 것에 대한 경고를 하고 있습니다. 그러나 추상화란 무엇일까요? 추상화된 코드는 코드 중복을 방지하기 위해 통합된 인터페이스 아래 숨겨진 공유 및 재사용 가능한 코드 조각입니다.
하지만, 진실은 무엇일까요? 한쪽에서는 코드의 중복을 피하라고 하고, 다른 쪽에서는 추상화(예: 공유 코드)를 피하라고 합니다. 이 질문에 답하려면 더 깊게 파고들어야 합니다.
DRY와 AHA의 조화로운 이야기
이 섹션에서는, DRY와 AHA의 균형에 대해서 알아볼 것 입니다. 그것이 재사용 가능성과 지원 가능성에 대한 토론의 주요 내용이기 때문입니다. 코드 공유에 대해 청신호부터 시작해봅시다.
Step 1: 새로운 기능. 자. 프로젝트를 위한 "멋진 기능1"을 개발하는 중이라고 상상해보겠습니다. 이 멋진 기능은 파일 업로드를 할 수 있어야 합니다. 파일 업로드 기능은 "FileDropArea"라는 React 컴포넌트와 "FileUploader"라는 헬퍼 클래스로 구성됩니다. 구현의 세부 사항은 자세히 보지 않고, 개념적인 것들에 집중해봅시다.
app
├── features
. ├── awesome-feature
. ├── index.js
├── container.js
├── component.js
├── file-frop-area
. ├── index.js
├── container.js
├── component.js
├── file-uploader.js
.이 단계에서 코드를 공유 가능하도록 만드는 것은 좋은 생각이 아니라는 것은 명백합니다. 그럼 다음 단계로 넘어갑니다.
Step 2: 새로운 기능 하나 더. 이제 시간이 지나 파일 드롭 "멋진 기능2"를 개발하게 되었습니다. 멋진 기능2 또한 멋진 기능1 처럼 파일 드롭 영역을 가져야 합니다. 여러분들이 했던 작업입니다! 대부분의 유사한 상황에서, 일반적인 사람들은 "FileDropArea" 컴포넌트를 공유하도록 만들 것입니다. 제 의견은, 그것은 완전히 잘못된 것입니다! 이것은 성급한 추상화의 좋은 예입니다. 가능한 모든 사용 사례를 알지 못하고 코드를 공유하려고 하는 것입니다.
그렇다면, 이 경우에 어떻게 해야 할까요? 일단은 "멋진 기능2"에 "FileDropArea" 컴포넌트를 복사해 사용하겠습니다. 이 복사된 컴포넌트는 초기의 예제와 일부 차이가 있을 수 있으며, 이 단계에서는 아무것도 공유할 필요가 없습니다.
Step 3: 그리고 새로운 기능 하나 더. 그리고 "멋진 기능3"도 마찬가지로 파일 드롭 영역이 포함 되어 있습니다. 간략히 말씀 드리면, 이 때가 "FileDropArea"를 공유 코드로 만들 적절한 순간입니다. 이 공유 React 컴포넌트에 대한 통합 API를 개발하고 이 컴포넌트를 포함하는 모든 기능에서 재사용합니다.
어떻게 정리할까요? 이것은 제 제안입니다.
app
├── features
. ├── shared
│ ├── file-frop-area
│ . ├── index.js
│ ├── container.js
│ ├── component.js
│ ├── file-uploader.js
│ .
├── awesome-feature-1
├── awesome-feature-2
├── awesome-feature-3
.잘못된 추상화
그리고 이제 여러분은 어떻게 성급한 추상화를 인식하고 피할 수 있는지를 질문 할 수도 있습니다. 자세한 내용은 Kent C. Dodds의 기사를 참고하시면 됩니다. 그리고 지금 떠오르는 몇가지 포인트 들이 있습니다.
추상화를 위한 추상화는 피하세요. 길지 않고 유용한 예가 있습니다. 사용자가 어떤 타입인지 확인하는 기능이 있다고 가정해봅시다.
const getIsUserOfType = curry((type, user) => user.type === type);
const user = { id: '1', type: 'WRITER' };이것은 올바른 사용의 예제입니다.
getIsUserOfType('ADMIN', user); // false
getIsUserOfType('WRITER', user); // true그리고 이것은 추상화에 대한 추상화를 나타내는 잘못된 예 입니다.
const getIsUserOfAdminType = getIsUserOfType('ADMIN');
const getIsUserOfWriterType = getIsUserOfType('WRITER');
getIsUserOfAdminType(user); // false
getIsUserOfAdminType(user); // true확실히 추상화를 위한 추상화가 필요한 경우가 있습니다. 하지만 대부분의 경우 getIsUserOfType과 같은 로우 레벨의 함수에서는 이러한 추상화가 없어야 합니다.
중복된 코드를 제어하세요. 올바른 방법으로 코드를 복제하는 방법을 알아야 합니다. 대부분의 경우 여러분의 프로젝트에서 코드 복제에 대한 명확한 정책을 세우는 것이 좋습니다.
두 가지 종류의 중복된 코드가 있습니다:
- 기능/앱에 유연성을 제공하는 중복코드.
- 보편화되고 공유되기를 기다리는 중복코드.
어떻게 코드를 공유할까요?
이 글에서 React 코드 공유에 대한 많은 내용을 언급하지는 않고 싶습니다. 이 주제에 대한 많은 문서들이 많기 때문입니다. 주목해야 할 몇 가지 도구들이 있습니다.
HOC. 이것은 React 훅이 도입 되기 전에 가장 널리 사용된 표준 기술입니다. HOC를 사용하는 여전히 많은 라이브러리들이 있습니다. 여러분들도 이와 같은 사용자 지정 HOC를 만들 수 있습니다. 하지만 훅스를 사용하는 것을 고려해 보세요.
React hooks. 재사용 코드를 위해 아주 유용한 것입니다. 저는 요즘엔 이것을 폭넓게 사용하고 있습니다.
Shared components. 가장 쉬운 옵션입니다. 우리는 이것을 "Step 3: 그리고 새로운 기능 하나더" 섹션에서 볼 수 있습니다. 이것은 Storybook 및 Bit과 매우 잘 어울립니다.
이게 다입니다!
저는 병원에서 이틀 동안 이 문서를 작성했습니다. 이 문서는 마치 여러분들이 필요에 깊게 파고들고 적응할 때 사용할 수 있는 논문의 모음 처럼 보입니다. 이 문서가 여러분에게 도움이 되었기를 바랍니다.
