리액트 프로젝트 설계

프로젝트 리팩터링 과정에서 어떻게 리액트 / 컴포넌트 를 설계해야할까? 라는 고민이 생겼다.

 

사실 리액트를 하는 프론트 개발자라고 하기엔 너무 늦게 고민이 생긴게 아닌가..

평소 너무 생각 없이 작업을 해왔던게 아닌가 조금 부끄러웠다.

 

가장 먼저

 

리액트 공식홈페이지에서 리액트는 선언형 이라고 소개하고 있다.

선언형 프로그래밍이란?

 

위키피디아에서의 선언형 프로그래밍에 대해 이렇게 설명하고 있다.

 

프로그램이 어떤 방법으로 해야 하는지를 나타내기보다 무엇과 같은지를 설명하는 경우에 '선언형' 이라고 한다.

 

예를들어, 웹 페이지는 선언형인데 윕페이지는 제목, 글꼴, 본문, 그림과 같이 '무엇'이 나타나야하는지를 묘사하는 것이지

'어떤방법'으로 컴퓨터 화면에 페이지를 나타내야하는지를 묘사하는 것이 아니기 때문 .....

 

무엇과 어떤방법에서 나뉘는데 이것을 다른 의미로 보면 선언형(무엇)과 명령형||절차형(어떻게) 로 나눌 수 있다.

선언형 프로그래밍은 당신이 무엇을 할 것인가?
명령형(절차형)은 당신이 어떤일을 어떻게 할 것인가?

결론은 리액트는 어떻게 화면을 보여줄지가 아니라 무엇을 보여줄지를 프로그래밍하는 라이브러리이다.

 

파일 구조

 

다시 리액트 공식홈페이지 에서 리액트의 파일 구조를 설계하는 추천 방법에 대해 이야기하고 있는게 있다,

 

1. 기능이나 라우터에 의한 분류

특징은 파일을 기능이나 라우터로 분류를 해놓았고 하나의 파일안에 js css test 등 모든 파일을 넣어놨다.

 

예시)

예시와 같이 페이지별로 구분해서 해당 페이지에만 사용하는 컴포넌트들을 구성해놓는 경우도 있다.

 

특징,

해당 페이지에서 사용하는 독립적인 컴포넌트는 빠르게 찾을 수 있다는 장점이 있다.

 

2. 파일 유형에 의한 분류

이 경우에는 컴포넌트들은 컴포넌트 끼리 분류 해놓은 폴더구조이다.

이 구조는 더 잘게 잘게 잘게 나눠질수 없을 만큼 나눠버리는 아토믹 디자인을 적용할수 있다.

 

파일구조가 곧 리액트 설계 일까,

파일구조는 생산성을 높이기 위해 단순히 프로젝트의 파일을 효율적으로 나누기 위한 방법론일 뿐이라고 생각한다.

방법론에는 대해서는 프로젝트 규모, 작업자 스타일 등등 여러 케이스가 있고 케이스 바이 케이스이기 떄문에 정답은 없을 것이다.

 

 

리액트 컴포넌트 설계

 

리액트 컴포넌트에 대한 설계를 찾아보면 특징별로 정리를 해놓은 글인데 한번 읽어보면 좋을 것 같다.

https://javascript.plainenglish.io/5-advanced-react-patterns-a6b7624267a6

5 Advanced React Patterns

 

컴포넌트를 설계할때 고려 해야할 사항

• 재사용성과 범용적인 컴포넌트
• 관심사에 따라 단일 책임을 가지는 컴포넌트
• 외부에 제어를 위임 시키기

컴포넌트가 재사용성이 높을 수록 중복코드를 줄여주고 요구사항에 대해 유연하게 대처가 가능하기 때문에 개발 속도도 올라가고 결론 적으로는 높은 생산성을 기대할수 있다.

 

사실 재사용성이 높다라는 건 하나의 컴포넌트를 정의 해두고 여기저기서 마음대로 가져다 쓸 수 있어야한다라는 건데

요구사항이 많아질수록 그 요구사항을 충족시키기 위해 props를 덕지 바른다던가 코드만 넣다보면 그 재사용성의 본질을 잃어버리기 쉽다

 

이런 문제를 합성 컴포넌트로 해결 할 수 있다.

 

카카오 기술블로그 에서도 재사용성 가능한 컴포넌트와 합성 컴포넌트에 대한 주제를 다뤘다.

너무 좋은글이라서 한번 읽어보면 좋을 것 같다. 

 

리액트 공식홈페이지에서 어떤 것이 컴포넌트가 되어야 할지 어떻게 알 수 있을까요? 라는 부분에서 우리가 새로운 함수나 객체를 만들 때 처럼 만들면 된다고하면서 단일책임을 언급한다.

 

단일책임원칙에 따라 "하나의 컴포넌트가 하나의 책임만 담당해야하는 것이 좋다." 

단일책임원칙(SRP)에 따르면 모듈을 여러가지로 분할하면 각종 변화에 유연하게 대처할 수 있고 행동 및 책임이 격리 되어있어 연쇅적인 사이드 이펙트가 발생할 여지가 줄어든다. 이는 모두 유지보수 비용의 감소로 이어진다.

보통 컴포넌트 하나에 모든 로직을 작성하다보면 코드가 500줄 600줄 ~~ 1000줄도 넘을 수 있다.

이런경우엔 사이드 이팩트를 걱정안할수도 없고 가독성이 안좋기 때문에 유지보수할때도 꽤나 애를 먹어야한다.

 

단일책임으로 컴포넌트를 나누게되면 당연히 가독성 유지보수도 향상되지만 테스트하기도 좋다.

 

---

 

리액트 컴포넌트에 대해서는 좋은 자료들이 많다.

확실한건 컴포넌트를 나눌때 베스트는 컴포넌트의 단일책임을 부여하는것이다

그리고 재사용성이 가능하고 재사용이 가능하려면 요구사항을 만족시키기 위해 추상적인 컴포넌트를 만들어야한다.