상태 관리는 왜 필요한가?

• 상태 : 상태는 어떤한 의미를 지닌 값이며 애플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값을 의미한다.

  • UI : 상호 작용이 가능한 모든 요소의 현재 값을 의미함.
  • URL : 브라우저에서 관리되고 있는 상태값으로, 우리가 참고할 만한 상태가 존재한다. /rooms/34113796?adult=2 의 URL을 보면, roomId = 34113796 와 adults =2 라는 상태가 존재하며, 이 상태는 사용자의 라우팅에 따라 변한다.
  • FORM
  • 서버에서 가져온값 : 클라이언트에서 서버로 요청을 통해 가져온 값도 상태로 볼 수있다.

• 단순히 서버에서 요청받은 내용을 보여주기만 하던 시대가 아닌,

• 점차 증가하는 상태를 효과적으로 관리하는 방법을 계속해서 고민해야 하는 시대가 도래했다.

<aside> ✅ 이러한 상태를 효율적으로 관리하고, 상태가 필요한 쪽에서는 빠르게 반응할 수 있는 모델에 대한 고민이 본격적으로 시작됬다.

</aside>

리액트 상태 관리의 역사

• 애플리케이션에 모든 것을 제공하는, 이른바 프레임워크를 지향하는 Angular와는 다르게 리액트는 단순히 사용자 인터페이스를 만들기 위한 라이브러리.

Flux 패턴의 등장

• 우리가 흔히 순수하게 리액트에서 할 수 있는 전역 상태 관리 수단이라고 한다면 Context API를 떠올릴 것이다. ⇒ 사실 상은 Context API는 상태관리가 아니라 상태 주입을 도와주는 역할이다.
• 리덕스가 나타나기전까지 리액트 애플리케이션에서 딱히 이름을 널리 알린 상태 관리 라이브러리가 없었음…
• Flux 패턴이 나오기전에, 그 당시 웹 개발상황은 양방향 데이터 바인딩이였다. 모델 ↔ 뷰가 서로 변경가능 했다.
  • 코드를 작성하는 입장에서는 간단하지만, 코드의 양이 많아지고 변경 시나리오가 복잡해질 수록 관리가 어려워졌다.

<aside> ✅ 페이스북팀은 양방향이 아닌 단방향으로 데이터 흐름을 변경하는 것으로 FLUX 패턴을 만들었다.

</aside>

Action ⇒ Dispatcher ⇒ Model ⇒ View

• action : 어떠한 작업을 처리할 액션과 그 액션 발생시 함께 포함시킬 데이터를 의미함. 액션 타입과 데이터를 각각 정의해 이를 디스패처로 보낸다.
• Dispatcher : 액션을 스토어에 보내는 역할을 한다. 콜백 함수 형태로 앞서 액션이 정의한 타입과 데이터를 모두 스토어에 보낸다.