MVC 패턴에서 controller
는 model
에 정의된 데이터를 조회하거나 변경하는 역할을 하고 변경된 model의 데이터를 View
에 반영한다.
또한 User는 View를 통해 데이터를 입력하고 Model에 반영되며 View와 Model은 데이터를 양방향으로 주고받는다.
하지만 앱의 크기가 점점 커질수록 View와 Model이 엄청나게 생겨나게 되면 데이터의 흐름을 제대로 파악하기가 어려워진다.
Flux 패턴은 어떤 Action
이 발생하면 dispatcher
에 의해 store
에 변경된 사항이 저장되고 이 데이터들에 의해 View
가 변경되는 이른바 단방향 패턴이다.
(언뜻 보면 리덕스랑 비슷하다.)
양방향으로 흐르던 MVC와는 달리 데이터 흐름을 파악하기가 상대적으로 쉽다.
1 . Hot Reloading
코드가 변경돼도 기존의 상태를 유지할 수 있게 해주는 것이다. Flux의 문제점 중 하나는 Hot Reloading 될 때마다 스토어 안에 있는 상태도 변경되어버리기 때문에 이전에 저장된 정보를 잃어버린다.
그 이유는
이 두가지 때문인데, Redux는 이를 서로 분리하며, store가 애플리케이션의 state를 가지며, state 변환 로직은 reducer가 관리한다.
이름에서 알 수 있듯이 이전의 특정 상태로 돌아갈 수 있게 해주는 것이라고 한다. 이게 가능하려면 상태가 바뀔 때마다 상태 객체의 모든 버전을 기록해둬야 한다.
Redux
에서는 기존의 애플리케이션을 상태를 직접 mutate
하지 않고, 따로 복사본을 만들어서 불변성을 유지한다.
Flux
에서도 가능하긴 하지만 상당히 복잡하다고 한다.
위 그림처럼 최상위 컴포넌트에서 하향식으로 props를 전달해주는 상황이다. 컴포넌트가 몇 개 안된다면 별로 상관없겠지만 애플리케이션이 점점 커지게 되면 props의 흐름을 제대로 파악하기도 어려울 뿐더러 props를 해당 컴포넌트에서 직접 사용하지 않고 단순히 넘겨주는 역할만 한다면 이는 정말 비효율적일 것이다. (이게 바로 props drilling이다.) 그래서 상태관리 라이브러리가 등장한 것이다.
하나의 애플리케이션은 하나의 store만 가진다.
동일한 데이터는 store라는 하나뿐인 데이터 공간에서 관리된다.
state는 읽기 전용이다.
위에서도 잠깐 언급했지만 state를 직접 변경해서는 절대 안되고, reducer가 변경하도록 해야한다.
reducer는 순수함수여야한다.
recuder는 같은 입력값이 들어오면 같은 출력값이 나오도록 해야하며, 오직 새로운 state 객체를 반환해야 한다.
그런데 Action,Dispatch,Reducer..? 이건 무엇인가.. 한번 알아보자.
객체
다. 상태 변경 시 어떤 변화를 줄 지에 해당하는 액션을 발생시킬 수 있다.참고자료: https://tech.osci.kr/2022/06/29/복잡하고-어려운-redux-적응기/
첫날에는 단순히 React Hooks를 이용해서 props를 여기저기 넘겨줘야 하다보니 되게헷갈렸는데 리덕스를 쓰니까 상태관리를 왜 하는지는 어느정도 알 거 같다.
다만 리덕스를 이틀밖에 안하다보니(부트캠프 특성 상 어쩔 수 없는 거 같지만) 찍먹 느낌이 너무 강하게 느껴져서 좀 아쉽다.