1. Redux 에 관하여

0. 상태(State)에 관하여

    1) 로컬 스테이트
        : 하나의 컴포넌트 안에 있는 상태

    2) 크로스-컴포넌트 스테이트
        : 여러개의 컴포넌트에 걸쳐 있는 상태 [props-drilling 을 통해, 여러 컴포넌트에 전달되어있음]

    3) App-Wide 스테이트
        : 앱의 전반에 걸쳐 있는 상태 (useContext 나 useSession 같은것들)

 

1. 왜 Context가 있는데도, Redux 를 사용할까?

 

 :  Context 의 단점을 해결 할 수 있고, 성능을 향싱시킨다.

    1) Context를 사용했을 때의 복잡함
        : 매우 많은 Context가, 매우 많은 ContextProvider 가, 전반적인 App을 덮을 것이다.


    2) 성능

        : 개발자피셜, Theme 처럼 한번만 바뀌는, Context는 괜찮지만, 
            자주 바뀌는 데이터의 경우 적합하지 않다고 경고했다. [Flux-like State] 에 적합하지 않음

 [ 무시무시한 Context Provider 지옥]

 	<xxProvider>
           <yyProvider>
               <zzProvider>
                     ...
                      <App.js>
                     ...
               </zzProvider>
           </yyProvider>
        </xxProvider>

 

 

2. 기본적인 Redux 의 작동 방식에 대해 알아보자.

    1) "하나"의 거대한 "중앙 저장소"
        : 인증, 입력상태, 테마, 데이터 모든 것을 "중앙 저장소 하나에 저장함" 

    2) "컴포넌트"는 "중앙 저장소를 구독(subscribe)"
        : 데이터가 변경되면, 컴포넌트는 중앙 저장소를 구독하고 있기 때문에, "알림이 간다" - [뾰롱. 이 데이터 바뀜!]

    3) 데이터(상태)를 조작 하는 "Reducer Function" 을 설정

        ** 컴포넌트는 "절대로!" "저장된 데이터를 컴포넌트에서 직접 조작하지 않는다." ******
        ** 방향은 항상, "중앙 저장소로" -> "컴포넌트" 방향이다. 반대는 없다.

        리듀서 함수의 사용
            : 입력을 받아, 결과물을 내는. ( useReducer와 개념은 같으나, 같은 것은 아니다.)

    * 리듀서 함수는 "일반적인 프로그래밍의 단어로, (상태를) 변형 해주는 함수이다."

    4) "컴포넌트"는 "Action의 Dispatch"를 통해, "Reducer Function" 에 할 일을 전달(변하는 스테이트)

    5) "Reducer Function"이, "중앙 데이터를 조작" [Reducer가 Action을 받아 뱉어낸 상태를 중앙 데이터에 새로 저장]

    6) "컴포넌트"는 다시 알림을 받고, UI 를 조작