Home
이렌트로닉 프로젝트의 프론트단을 개발합니다. 기능 구현보다 유지 보수 측면을 고려하며 개발하는 것을 중요시 합니다.
- 팀 회의는 jira confluence를 이용한다.
- 구현 사항은 jira confluence를 이용한다.(storyBook 배포 혹은 사이트 배포로 변경 될 수 있음)
- 프론트 팀은 Discussion을 이용하여 토론을 진행할 수 있다.
-
트러블 슈팅, 학습 관련 내용은 Notion을 통해 기록한다.
-
PR시 팀원이 코드 리뷰를 진행 후 confirm 한다. 이는 리뷰 컨벤션을 따른다.
- 선언형 프로그래밍을 지향한다.
- 추상화 수준을 통일한다. -> page / UI / component 예시로 왼쪽 부터 오른 쪽으로 내려갈수록 추상화 수준이 낮아진다(명령적인 코드로 변환됨).
- 폴더와, 파일 분류 컨벤션을 따른다.
- 함수는 하나의 일만을 책임진다. 고로 if문을 지양한다.
- 반복문을 적극 자양한다.
- 중복 타입을 줄이기 위해 노력한다. -> 라이브러리 혹은 리액트 측에서 제공하는 타입을 적극 활용하고 이를 공유한다.
- 함수 네이밍은 동사 + 명사/ 명확한 네이밍(줄임X, 길더라도 동작 정확히 명시)
- 디자인 시스템 컴포넌트 개발시 기능 구현 뿐만 아닌 팀원과의 사용을 고려한다. -> 라이브러리 개발이라 생각하면 좋다.
- util 함수 개발이 답답하면 아래에서 부터 진행 될 수도 있다. compoent에 사용되는 로직 추상화 service -> service 에 사용되는 로직으로 추상화 util
- !! 중요 한건 컨벤션들을 잘 지켜졌는지와 정말 효율성이 좋은지 의논과 개선이다. 코드 리뷰 및 Discussion을 적극 이용하여 코드 퀄리티의 향상을 지속적으로 추구한다.
- named export를 사용한다.
- index 파일은 내보내기만을 목적으로 한다. (구현부 X export만 가능)
- 폴더/파일 관련 변경이 필요한 경우 Discussion에 아이디어로 제보후 의논 과정을 거쳐 컨벤션으로 통과 한다.
├─.storybook
├─config
├─dist
├─public
└─src
├─apis
├─assets
├─components
│ ├─client
│ ├─common
│ │ ├─Button
│ │ ├─Icon
│ │ ├─Input
│ │ ├─Layout
│ │ ├─Loading
......
│ └─server
│ ├─Filter
│ │ └─SideTab
│ ├─Product
│ │ ├─Card
│ │ └─Label
│ ├─ProductDetail
│ │ └─OrderForm
│ └─Search
.......
├─hooks
├─libs
├─mocks
├─Pages
├─recoils
├─service
├─styles
├─test
├─types
└─utils-
storybook→ 스토리북 설정파일
-
config → 웹팩 설정 파일 (공통, 개발, 배포 목적 별로 분리)
-
dist → 빌드 결과물 보관
-
public(static) → 기본 템플릿(HTML) 보관
-
src → 프로젝트 핵심 소스 코드 보관
-
DEPRECATED_api → 서버 데이터 스킴 별로 분류 해당 데이터 호출 보관
- 데이터 파싱은 service가 담당하고 각 Query마다 custom hook으로 관리하는 방식일 경우 api 폴더가 필요 없음
-
assets → 이미지, 폰트, 아이콘 등 데이터 보관
-
components → 클라이언트, 서버, 커먼으로 세분화 분류
- 분류의 기준 → 커먼: 디자인시스템 컴포넌트/ 클라이언트: 클라이언트 상태 노출 목적 View 컴포넌트/ 서버: 서버 상태 노출 목적 컴포넌트
- components 폴더의 컴포넌트는 주로 가공된 데이터 및 로직(이벤트 핸들러, 콜백함수,,,) 을 전달받기 때문에 View에 대한 순수한 관심사를 가질 수 있음
- 서버와 클라이언트는 데이터의 스키마 별로 폴더를 세부 분류함 이는 차후 변경에 대한 요청에 유리 ex) . 필터 데이터/ 제품 데이터/ 제품 상세 데이터/ …
- server, Client 또한 디자인 시스템과 동일하게 재사용 가능, 분류의 이유는 빠른 탐색을 위해서
-
hooks → 커스텀 훅을 보관
- 커스텀훅은 여러 컴포넌트에서 재사용 되는 목적이 1번째로 중요시하여 작업 권장
- 커스텀 훅은 컴포넌트의 데이터 처리 관심사를 분리하는 목적을 2번째로 중요시하여 작업함(모든 상태 관련, 데이터 처리 로직을 커스텀 훅으로 분류하는것은 지양함)
- 애플리케이션의 복잡성을 올리는 커스텀 훅은 개발을 지양
- ex ). useBoolean은 코드의 복잡성이 거의 없어서 오히려 분리 할경의 의존성 및 코드 복잡도 증가할 우려 있음
- !! page의 template별 hook은 template의 로직을 숨기기 위한 hook이다. template에 종속적이기 때문에 현재 template 내부에 위치 했다. 이는 추상화 수준을 높인다면 다시 hook 폴더로 리팩토링 가능하다.
-
Mock → 목 데이터 코드 보관 및 MSW 관련 코드 위치
-
Page → 페이지 컴포넌트는 템플릿의 조합을 통해 화면단을 노출함 라우팅 처리의 하나의 단위가 되어줌
- DEPRECATED_Template → UI의 한 뭉치, 복합적인 데이터를 관리, Components의 View 로직에 관리된 데이터를 전달하여 노출, 스타일 컴포넌트 사용을 지양(유지보수 악영향)
- Template 내부 구현사항
index -> 템플릿 위치(추상화가 높아서 흐름을 파악하는 목적)
reducer -> 템플릿이 사용하는 상태 관리 함수
action -> 템플릿 상태관리 함수 트리거 값
component -> 템플릿이 사용하는 추상화 되었던 컴포넌트의 구현(레이아웃을 기준으로 나눠짐)- Recoil → 리코일을 이용한 상태 관리 atom, selector 위치
DEPRECATED_리코일 폴더는 atom, selecotor 두가지 분류가 이루어질걸로 예상, 리코일은 클라이언트 상태를 관리하는것을 주사용 목적으로함 , 리코일 내부에서 서버 데이터터 요청은 지양함(리액트 쿼리의 관심) -> selector가 여러 atom을 구독 할 수 있으므로 폴더 분류에 대해서 재 의논 필요
-
Service → 데이터를 원하는 형태로 가공하는 비지니스 로직이 위치 데이터 스킴 단위로 처리
-
Styles → 글로벌 테마, 글로벌 스타일, 폰트페이스 위치함
-
Not Developed_Test → 테스트 코드 위치 !! Not Developed !!
-
Types → 타입 정의 및 확장(라이브러리 및 파일 확장자 관련)
-
Util → 프로젝트 전반적으로 사용가능한 유틸리티 코드 위치