전역 상태 관리 복습

---

React

리렌더링이 되는 상황 세 가지

1. state가 변경될 때 (여기서 말하는 state는 useState의 state만 말하는 게 아님. )
2. 부모 컴포넌트로부터 전달 받은 props가 변경되었을 때
3. 부모 컴포넌트가 리렌더링되면 자식 컴포넌트도 리렌더링

---

Next

• Next.js는 라이브러리가 아니라, 프레임워크라고 부름

• 제어역전이 발생하면 프레임워크라고 볼 수 있다.

• 프레임워크에서는 특히나 약속이 무엇이 있는지를 아는 게 무척 중요해요.

• Next.js에서 딱 하나 알아야 하는 게 있다면,

  1. App 디렉터리 아래에서는 디렉터리 경로가 곧 url 경로가 된다.
  2. 1번의 예외 케이스 두 가지를 알아야 한다.
     1. 디렉터리명에 () 소괄호를 치는 경우 : 여전히 라우팅 시스템의 컨벤션들이 유효한 디렉터리
     2. 디렉터리명 앞에 _ 언더스코어를 치는 경우 : 라우팅 시스템 컨벤션에서 아예 제외되어버림

---

Redux

• 전역 상태 관리 라이브러리
• 리덕스는 의도적으로 복잡하게 구성되어 있는 라이브러리
• why? 데이터의 흐름을 명확하게 하고, 데이터의 변경을 추적 가능하게 만듦으로써, 디버깅을 용이하게 하기 위함.
• 때문에, 리덕스에는 많은 개념과 규칙이 존재합니다.

Redux의 개념과 규칙 이해하기

Redux 개괄

• 전역 상태를 저장하는 저장소 : store
• 전역 상태에 저장되어 있는 상태(값, 데이터) : state - state의 초기값은 공장에서 설정함
• state에 대해서 대개 네 가지 작업을 할 수 있다 : CRUD
• 그런데 이 중에, R(Read, 읽기)은 구현하기가 너무나도 너무나도 쉽다. -> useSelector 쓰면 끝!
• CUD(Create, Update, Delete, 데이터 조작)은 구현이 까다롭다. 알아야 할 개념들과 규칙들이 꽤 있기 때문.
• 그러한 이유로, Redux store내의 state에 대한 CUD와 관련하여서는 공장을 예시로 비유를 함.

공장 비유를 통한 이해

• Redux에는 store의 state를 변경해 주는 공장이 있다.
• 그런데, 이 공장은 매우 까다로운 공장이다.
• 까다롭다고 하는 이유는, 작업지시서가 있어야만 작업을 해주기 때문에.
• 그러면 작업지시서는 누가 언제 어떻게 작성하는가?
• 작업지시서는 상태를 변경하고자 하는 컴포넌트에서 작성한다.
• 작업지시서는 1개의 필수 정보와, 1개의 선택적 정보를 넣어 작성한다.
• 하지만, 작업지시서를 쓰는 것만으로 작업이 진행되는 것은 아니다.
• 작성된 작업지시서를 공장에 전달해 주는 작업이 필요함.
• 이때 공장에 작업지시서를 전달하는 우체부가 있다
• 우체부에게 작업지시서를 넘겨주면 공장이 작업지시서를 받아서 작업이 시작된다.
• (추가) 작업지시서의 내용을 작업지시서를 작성할 필요가 있을 때마다, 개발자가 직접 작성을 매번 하는 것은 휴먼 에러의 위험이 있음. 그래서 작업지시서를 찍어 낼 수 있는 작업지시서 생성기를 만들기도 함.

비유의 내용을 Redux에서 사용되는 개념으로 변환하기

• 공장 : reducer 리듀서
• 작업지시서 : action 액션. 액션의 자료형은? Object(객체)
  • (Required) 작업 종류 : action.type (자료형은 string)
  • (Optional) 작업을 진행할 때에 필요한 정보 : action.payload
• 우체부 또는 전달하는 행위 그 자체 : dispatch (함수)
• 작업지시서 생성기 : action creator (함수)

---

Context API

Context API의 사용법

1. 만든다. -> createContext
2. 사용한다. -> useContext
3. 범위를 지정해서 값을 내려준다. -> Provider, value