수업 여는 글
전역 상태
데이터 전역 상태 관리 필요성의 기준
컴포넌트 내부의 상태른 리렌더링 동반되는 값으로 지정,
이 상태가 자식이 아닌 다른 컴포넌트에 영향을 미쳐야 할 때 전역 상태 관리의 필요성이 생김.
영속성을 지녀야 하는가.
yes or no
yes - 데이터 패칭 라이브러리(사용자 프로필, ...)
no - UI상태나 인터페이스와 밀접한 상호작용을 하는 데이터인가?
yes or no
yes - 전역 상태 라이브러리(...)
no - ...
전역 상태 라이브러리
- 플럭스 아키텍쳐 (중앙 집권형)(탑다운)
redux(2015), zustand(2019) - 아토믹 아키텍쳐 (바텀 업)
recoil(2020), jotai(2021) - 프록시 아키텍쳐 (중개자)
mobx(2016), valtio(2021)
플럭스 아키텍쳐
아토믹 아키텍쳐
프록시 아키텍쳐
어떤 기준으로 라이브러리를 선택할 것인가.
전날의 use-context-jsx 다크모드 예제를 바탕으로 redux를 활용한 구현,
공식 문서를 따라가면서 생각해 봐야 할 것들
next18 과 nextJS
개발자 도구 지원 = 관리의 용이성 = 디버깅
Redux | Redux Essentials, Part 3: Basic Redux Data Flow
데이터 흐름 (Data flow) - 리덕스는 단방향 데이터 흐름으로 구성된다.
처음 만난 리덕스 (Redux) 문서 - 10.5 Redux Async Data Flow
과제 (각 30분)
리액트 디렉토리 구조
중요한가? 그렇기도 아니기도 하다.
(리액트 예전 공식 문서_ 5분 이상 고민하지 마라.)
팀의 규모, 프로젝트 규모에 따라
small : 페이지 2-3개 이하, 컴포넌트 20개 이하, ...
big : assets / components / context / data ...
- assets : 공통으로 사용하는 css 혹은 이미지 등
- components(shared) : 공통으로 사용하는 컴포넌트 내부에 ui, form 디렉토리를 관심사별로 분리
- context : 공통으로 사용하는 컨텍스트
- data : 공통으로 사용하는 데이터 ex)리덕스, 리코일 등의 상태 저장소, json 파일, 상수...
- feature(crews, goals...) : 특정 주제에 관한 컴포넌트, 훅, 서비스 등을 모아둠. 재귀형태로 큰 프로젝트 구조가 각 주제별로 또 디렉토리로 들어가 있다.
- hooks : 공통으로 사용하는 훅들.
- layouts
- pages
- services
- types
- utils
(엔티티와 도메인 개념(차이))
좋은 코드란 무엇인가? 코드 분석.
https://feature-sliced.design/
https://feature-sliced.design/examples
example
http://crypto-light.space/
https://github.com/Yar56/cryptolight
- 클론 후 package.json 으로 구성 라이브러리 파악, 분석 (의존성 / 개발 의존성)
- 파일 구조 파악, 분석 (의도 및 각 파일의 역할)(대략적인 코드 참고)
- index -> app 순으로 컴포넌트가 어떻게 무엇으로 감싸여 있는지 확인.
....
결과물을 통한 역추적
