리액트 폴더 구조(Architecture)

시작 전

최초에는 노션으로 작성한 문서인데, 노션이 더 보기에 편한것같기도 하다.

https://enormous-algebra-1c0.notion.site/Architecture-ffea125ae7904d01b609fabd9eafb798

폴더 구조(Architecture)

왜?

• React는 어플리케이션을 구성하고 구조하는 방법을 제공하지 않는다. (그렇기에 정답도 없다.)
• 어플리케이션을 구성하고 구조하는 것은 개발자나 팀이 상호작용하는 방식이다.
• 잘 짜여진 프로젝트는 개발자들이 자신의 구현에 더 깊이 생각하고 정리하도록 요구한다.
• 또한 잘 짜여진 프로젝트는 코드베이스를 쉽게 탐색, 수정 및 확장할 수 있다.
• 조직화된 코드베이스는 팀이 장기적으로 주어진 구조내에서 생산성을 향상시킬수 있다.
  • 작업 중 서로 겹치거나 충돌이 날 경우를 방지한다.
  • 잘 짜여진 폴더 구조는 코드 중복을 방지한다.

현재 프로젝트 구조

📂 폴더 리스트 (only folder)
├── public
├── script
└── src
		├── apis
		├── assets
		├── consts
		├── containers
		├── contexts
		├── lang
		├── model
		├── scss
		├── useHook
		├── utils
		└── views
				├── MainHome
				├── ...
				└── ...-mgmt

제외 항목

공통 폴더 및 반드시 생성되는 폴더, 폴더가 아닌 파일에 대해서는 생략

• build
• cypress
• node_module
• .js / .json … 등

폴더 분석

public

• 특징
  • 파일이 후처리(post-process) 되거나 경량화(minify)되지 않음
  • public 폴더에 접근하기 위해서는 PUBLIC_URL 환경변수를 사용해야한다.
  • 파일 경로를 잘못 입력하거나 해당 파일이 존재하지 않을 경우, 컴파일 단계에서 오류가 발생하지 않고, 404 오류가 발생 ☠️
• public 폴더의 파일은 webpack으로 처리되지 않고, 원본이 build 폴더에 복사된다.
• 언제 사용할까?
  • 특정 이름을 가진 파일이 필요할 때 (manifest.json)
  • 이미지 파일이 수천 개 있어서 경로를 동적으로 참조해야 할 때

function App(){
    const index = 10; 
    return ( 
        <> 
            <h1>동적 이미지 참조</h1> 
            <img src={process.env.PUBLIC_URL + `/red-rose${index}.jpg`} /> 
        </>
    ) 
}

• • 번들링 된 코드 밖에서 pace.js 같은 작은 스크립트를 포함하고 싶을 때
  • webpack과 호환되지 않는 라이브러리를 사용해야 할 때 (<script> 태그로 라이브러리 호출)
• 공통 파일
  • index.html
    • React 는 가상 DOM 을 사용
    • 실제 DOM 이 필요
    • 즉, 가상 DOM 이 들어갈 root HTML 이 필요
    • 바로 그 root 가 존재하는 폴더
  • manifest.json
    • “웹 앱”을 위한 정의 파일 (PWA)
    • 기기에서 페이지가 앱처럼 보여질 때 기타 스타일을 설정
      • 아이콘의 이미지, 이름, 기타 테마 설정 등
      • 설정 가능한 key 목록 Web app manifest 참고
      • 모바일로 웹에 접속하면 “홈 화면에 바로가기 추가” 등의 브라우저 기능을 사용할 수 있다.
    • PWA (Progressive Web App)
      • 웹을 앱처럼 보여주는 하나의 수단/방법
      • PWA 기초 설명 유튜브 참고
      • IOS 에서는 대응이 다소 부족하다는 주의사항이 있다.

src

• React 개발이 이루어지는 메인 폴더

• apis (api 관련 파일)
  • api 호출 목록
  • api error handling 코드
  • api request 코드
• assets(정적 파일)
  • icons
  • images
• consts(프로젝트 전체에 사용하는 상수)
  • 프로젝트가 계속해서 확장될 예정이라면 역할에 따라 파일을 분할하는 것이 좋다.
    • ex) math-const.js, general-const.js, api-const.js … 등
• containers(페이지 레이아웃 파일)
  • Header/Contents/Footer
  • Sidebar
  • Layout
• contexts(AppContext 파일)
• lang(프로젝트의 언어 설정 파일)
  • 언어 설정 함수/파일
• scss
  • coreui 커스텀 스타일, 공통 스타일 설정 scss 파일
• useHook
  • 커스텀훅 파일
• utils(프로젝트 전체에 사용하는 함수)
  • 날짜 변환
  • 모달
  • 쿠키
  • 기타 계산/변환
• views(pages)(페이지를 구성하는 파일, 라우터 기준으로 폴더 분할)
  • 페이지(탭) 당 폴더
  • common 폴더
    • component: 공통 컴포넌트 파일
    • function: 프로젝트에 공통적으로 사용하는 함수
    • styles: styled-components 정의 파일
  • dialog 폴더
    • 모달 컨트롤을 위한 파일

정리

• 현재 우리 프로젝트 구조는 multi-layered architecture 의 방향성과 비슷하다.
• 페이지(라우터)를 기준으로 폴더 구분
  • 각 페이지 폴더에서, 다시 수행하는 기능에 따라 폴더 구분 (Register/Detail)
• 공통 사용하는 파일은 그 사용 의미에 따라 폴더 구분

---

좋았던 점

• 페이지(라우터) 구분/기능별 구분 으로 되어있어서, 수정해야할 위치를 쉽게 찾아갈 수 있었다.
• view의 하위 폴더 구조를 잘 구성했다고 느꼈다.
  • ‘목록조회/상세조회/등록/수정’ 등 기능 별 하위 폴더 분할

// view 하위 폴더 공통 구조
📂 service-mgmt
├── Detail
		└── Components...
├── Register
		└── Components...
└── NewsList.js

아쉬운 점

• 각 폴더마다 비슷한 컴포넌트를 만들어, 컴포넌트의 장점을 활용하지 못했다.
• view 폴더의 파일을 제외한, 프로젝트에서 공통적으로 사용하는 코드를 찾기에는 불편했다. 그 원인은 개인적으로 느끼기에, 비슷한 의미를 갖는 폴더가 많았기 때문이라고 생각한다. utils, common, function…
• 위와 연계하여, 공통 코드를 작성하면 항상 어느 폴더에 넣는게 좋을까 고민했던 기억이 난다…
• view 폴더 내부에는 페이지와 관련된 폴더만 있는게 의미에 맞다는 생각이 든다. (그리고 더 깔끔할 것같다…?)

고민인 것

• routes.js → routes 폴더로 라우터에 따라 파일 분할

개선할 점

• containers 폴더는 layouts 으로 이름을 변경
• view 폴더 내부의 common, dialog 를 외부로 옮긴다.
• common 폴더를 구조분해 한다.
• util 폴더와 function 폴더를 합친다.
• dialog 폴더는 modal 관련 폴더와 함께 위치시킨다.
• model 폴더(미사용 폴더)는 삭제
• 다국어 지원을 위한 번역파일을 담고있는 lang 폴더는 assets 폴더로 이동
• scss 폴더는 style 폴더로 이동

📂 폴더 리스트 (only folder)
├── public
├── script
└── src
		├── apis
		├── assets(+lang)
		├── consts
		├── layouts(container/이동)
		├── components(+layouts)
		├── contexts
		├── lang(이동)
		├── model(삭제)
		├── scss(이동)
		├── style(+scss)
		├── Hooks(useHook)
		├── utils(+function)
		└── views
				├── MainHome(+resetPwModal)
				├── common(이동)
				├── dialog(이동)
				├── dragableDialog(이동)
				├── ...
				├── resetPwModal(이동)
				└── ...-mgmt

---

수정 후 프로젝트 구조

📂 폴더 리스트 (only folder)
├── public
├── script
└── src
		├── apis
		├── assets
		├── const
		├── components
		├── context
		├── style
		├── Hooks
		├── utils
		└── views
				├── MainHome
				├── ...
				└── ...-mgmt

느낀 점

폴더만 옮긴다고 무조건 좋아지는 것은 아니다. 여전히 개선해야할 부분은 많고, 공통 컴포넌트로 재구성해야할 것도 많다. 그럼에도 불구하고 폴더가 몇개 사라지고 위치를 변경한 것 만으로도 프로젝트의 가독성이 더 올라갔다. 협업에 있어서 아키텍처가 중요하다는 생각이 들었다. 다른 사람이 프로젝트를 봐도 이해할 수 있는 구조가 좋은 구조라고 생각한다. 또, 이번 프로젝트에서는 비슷한 컴포넌트들이 여러 페이지에 걸쳐 만들어져 있는데, 다음 프로젝트에서는 공통 컴포넌트를 더 잘 활용해서 더 리액트답게 개발하고 싶다.

참, public 폴더의 manifest 에 대해서 찾아보다가 PWA 에 대해 알게되었다. 간단한 것이 웹을 앱처럼 사용하게 만들어 준다는게 재미있고 신기했다. 조만간 더 공부해보고 사이드 프로젝트에 적용 시켜보고 싶다.

 

참고

https://bokjiho.medium.com/react-%EB%A6%AC%EC%95%A1%ED%8A%B8%EC%97%90%EC%84%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EA%B2%BD%EB%A1%9C-%EC%84%A4%EC%A0%95%ED%95%98%EA%B8%B0-public-src-%EB%94%94%EB%A0%89%ED%86%A0%EB%A6%AC-%EC%B0%A8%EC%9D%B4-fddb4f455c2a

[React] 리액트에서 이미지 경로 설정하기 (public, src 디렉토리 차이)

https://developer.mozilla.org/en-US/docs/Web/Manifest

Web app manifests | MDN

https://blog.openreplay.com/react-architecture-patterns-for-your-projects/

React Architecture Patterns for Your Projects

https://imagineu.tistory.com/82

프론트엔드 아키텍처 다층화구조(layered architecture) (+실제 폴더 구성)