소프트웨어를 설계하면서 자주 발생하는 문제에 대한 모범답안을 디자인 패턴 이라고 한다.
모든 복합 패턴의 근간
dark light 모드에서는 view controller 에서만 통신이 일어남
본론으로 돌아가서 결국 양방향 통신 이 일어난다는 것.
하지만 react를 개발한 meta(facebook)에서 MVC 패턴의 문제점이 드러났다.
controller 에서 변경한 view가 다른 데이터와 연결되어있어 (양방향) DM 기능에 문제가 발생.
이로써 페이스북팀 개발자는 새로운 디자인 패턴인 flux패턴을 발표
action - dispatcher - store - view
변화 파악이 쉽고 애플리케이션의 동작을 예측하기 쉬움. 단방향이기 때문에 연쇄수행이 없음.
useDispatch() useReducer()는 완벽히 flux 를 따르고 있다.
Redux 는 flux, CQRS, Event sourcing 의 개념을 사용해서 만든 라이브러리로서 javascript 앱을 위한 예측 가능한 상태 컨테이너 를 핵심 가치로 함.
*CQRS : 쉽게 말해 CRUD
모든 데이터는 하나의 소스로부터 나와야 한다.
redux 내 모든 전역 상태는 하나의 객체 안에 트리구조로 저장되고 이 객체를 store 라고 한다.
redux 의 state는 action 객체를 dispatch 를 통해서 전달하는 방법 뿐.
state 의 변경방법을 제한하여 안정성과 예측 가능성 향상.
dispatch 를 통해 변화를 중앙화 시킴. 또한 action을 통해 변화의도를 표현.action 은 간단한 형태기 때문에 이를 추적 파악하기 편함.
변화는 순수 함수로 제작.
순수함수 : 어떠한 input을 받았을 경우 동일한 output 을 내는것이 보장된 함수.
사이드 이펙트가 없어야함.스코프 외부 값을 사용하면 안됨.store 와 reducer 모두 하나여야 함.
하지면 관심사 분리에 따라 reducer를 분리시켜야 한다.
이를 위해 combinedReducers가 여러가지 reducer를 하나로 합쳐준다.
react 와 redux를 통합하기 위한 복잡한 과정을 수행하는 라이브러리
상태 관리 자체만 보면 context api 추천 상당히 간단.
middle ware 가 추가되거나 복잡한 과정이 있다면 redux.
redux 는 렌더링 최적화가 좀 있다.
selector 의 값이 바뀔 때만 렌더링이 발생.
context 는 store 의 모든 값이 바뀔 때 렌더링 발생..!