리덕스 메인테이너가 추천하는 리액트 폴더 구조 - feature first

원문 : Practical Redux 과정의 리덕스 메인테이너가 쓴 글

https://www.educative.io/courses/practical-redux/gxkVE8NEvXj

Thoughts on Folder Structure - Practical Redux

Redux 애플리케이션을 위한 좋은 폴더 구조가 무엇인지에 대해 많은 논의가 있었습니다.

일반적인 접근 방식은 일반적으로 두 가지 범주로 나뉩니다.

• 파일 타입 우선
  • /reducers, /components 등과 같은 폴더
• 기능 우선
  • "파드(pods)", "도메인(domain) 기반" 또는 "feature 폴더"
  • 각 기능에 관련한 모든 파일 유형이 있는 폴더 구조

 

원래 Redux 예제는 "파일 타입 우선" 접근 방식을 사용하였으나,

최근의 많은 기사와 토론에서 "기능 우선" 접근 방식을 보여주고 있습니다.

 

어느 쪽이든 장단점이 있습니다.

"파일 타입 우선"을 사용하면 모든 리듀서를 한 곳에 모으는 것과 같은 작업을 정말 쉽게 수행할 수 있지만,

주어진 기능에 대한 코드가 흩어져 있을 수 있습니다.

기능 우선은 위의 반대입니다.

 

 

내 현재 접근 방식은 대부분 "기능 우선" 스타일 접근 방식입니다.

Max Stoiber가 자신의 기사 How to Scale React Applications에서 설명한 접근 방식과 몇 가지 유사점이 있습니다만,

주요 차이점은 다음과 같습니다.

• 모든 폴더에 "actions.js" 및 "reducer.js"라는 이름의 파일을 두는 것보다 파일에 고유한 전체 이름을 지정하는 것을 선호합니다.
  • 이것은 주로 편집기 탭에서 파일을 쉽게 찾고 파일 이름을 읽기 위한 것입니다.
  • 또한 컴포넌트 파일의 이름을 SomeComponent/index.js로 지정하는 대신 고유한 이름을 지정하고 싶습니다
    • modalReducer.js
•  나는 index.js 파일을 사용하여 중첩 폴더에 대한 일종의 "공개 API"로 함수와 구성 요소를 위로 다시 내보내는 실험을 했습니다.
  • 잠시 후에 설명하지만 이 아이디어에 완전히 매료돤 것은 아닙니다.
• 이 폴더를 컨테이너가 아닌 feature라는 폴더 아래에 그룹화했습니다.
• 저는 개인적으로 사이드 이펙트를 위해 썽크와 사가를 혼합하여 사용합니다.
  • 간단한 비동기 및 복잡한 동기 작업에는 썽크를 사용하고
  • 더 복잡한 비동기 또는 분리된 논리에는 saga를 사용합니다.
• 나는 또한 다단계 상대 가져오기보다 "features/someFeature/SomeComponent"와 같은 "절대 가져오기"를 사용하는 것을 선호합니다.
  
• feature 롤더 옆에 있는 소스의 최상위 수준에 common 폴더가 있습니다.
  • 여기에 응용 프로그램 전체의 여러 위치에서 재사용될 수 있는 정말 일반적인 재사용 가능한 구성 요소,
  • 유틸리티 기능 및 기타 논리를 배치합니다.
    

현재의 접근 방식에 100% 만족한다고 말할 수는 없습니다.

특히 "features/featureA/FeatureAList/FeatureAList.jsx"와 같은 경로를 갖는 것은 다소 어리석고 반복적입니다.

반면에 해당 파일이 어디에서 왔는지 매우 명확합니다.

나는 index.js 파일을 사용하여 폴더에 대한 "공개 API"를 다시 내보내는 방벅이 최선인지 확신이 없다고 언급했습니다.

가져오기 경로를 약간 단순화할 수 있지만 추가 종속성 얽힘(additional dependency entanglements)으로 인해

Webpack과 같은 개발 서버에서 더 많은 파일이 영향을 받고 다시 빌드될 수 있음을 의미할 수도 있습니다.

 

어느 시점에서 내 앱의 변경 사항을 핫 리로드하는 데 필요한 시간이 상당히 늘어난 것 같았습니다.

코드가 더 많이 추가되어 얼마나 많은지, 종속성 트리가 더 얽혀서 발생한 비용인지 확실하지 않습니다.

더 많은 파일이 영향을 받습니다.

index.js 파일의 확산과 re export 또한 성가실 수 있습니다.

 

index.js 파일을 사용하는 것은

부모 컴포넌트와 여러 자식 컴포넌트가 동일한 폴더에 별도의 파일로 있고

실제로는 부모 컴포넌트만 앱의 다른 부분에서 가져오기를 원하는 경우에 가장 유용하다고 말하고 싶습니다.

• 이 경우 가져오기 경로를 단축하고
• 앱의 다른 부분이 가져온 컴포넌트가 단일 컴포넌트 파일인지 아니면
• 실제런 같은 폴더 내에 있는 여러 파일인 "컴파운드 컴포넌트"인지 대해 무지하게 유지합니다.

나는 여전히 스스로 해결하려고 노력하고 있음을 자유롭게 인정할 것입니다.

내 React/Redux 링크 목록의 프로젝트 구조 섹션에서 수집한 프로젝트 구조에 대해 작성된 좋은 기사가 꽤 있습니다.

일반적으로 "기능 폴더" 접근 방식을 사용하는 것이 좋지만 Redux 자체는 전혀 신경 쓰지 않습니다.

중요한 것은 당신과 당신의 프로젝트에서 일하는 다른 사람이 주어진 기능에 대한 코드가 실제로 어디에 있는지 이해하고

그 구조가 유지 보수 가능하다는 것을 찾을 수 있어야 한다는 것입니다.

 프로젝트 구조에 대한 논의는 아래에서 더 찾아볼 수 있습니다.

https://github.com/markerikson/react-redux-links/blob/master/project-structure.md

GitHub - markerikson/react-redux-links: Curated tutorial and resource links I've collected on React, Redux, ES6, and more

https://github.com/markerikson/react-redux-links

GitHub - markerikson/react-redux-links: Curated tutorial and resource links I've collected on React, Redux, ES6, and more

참고

레퍼런스 프로젝트

https://github.com/markerikson/project-minimek-educative

GitHub - markerikson/project-minimek-educative: A sample app to demonstrate various useful Redux techniques, accompanying the "P

리덕스 공식 문서

https://redux.js.org/faq/code-structure#:~:text=However%2C%20there%20are%20a%20few,sub%2Dfolders%20per%20file%20type

Code Structure | Redux

 

추가 팁

cra에서 .env에 아래와 같이 설정하면 기본 임포트 모드를 절대 경로로 활성화 한다 합니다.

저는 src 폴더에서 시작하는 "절대 가져오기" 경로를 일관되게 사용하는 것을 선호합니다.
무엇보다도 상대 가져오기 경로에 비해 파일을 쉽게 이동할 수 있습니다.

NODE_PATH=src