[우아한테크] 그루밍 : 상태관리와 반응형 프로그래밍

 

https://www.youtube.com/watch?v=alsCMx6vpG4 

 

해당 영상을 시청한 후 영상 내용을 정리해보았다.

 

 

---

 

1. 상태관리란?

 

1) 상태(state)

"변화하는 데이터"이며, 풀어서 설명하면 ui에 동적으로 표현되는 데이터(사용자의 action)에 따라서 변경될 수 있는 컴포넌트의 부분을 나타내는 자바스크립트의 객체라고 할 수 있다.

 

2) 상태관리 

여러 컴포넌트 간의 데이터 전달과 이벤트 통신을 한 곳에서 관리하는 것이다. 즉, 데이터들을 알맞게 관리하기 위해 나타난 개념이다. 이전동안에는 한 번에 클릭마다 원하는 값을 찾기 위해 매번 페이지가 변경되는 웹이 사용되고 있었다.

 

이는 로딩의 시간을 길게 하며, 이런 불편함을 해소하기 위해 변화된 부분만 변경되도록 하는 현재의 웹이 많이 사용되고 있다. 어떠한 형식이나하면 페이스북으로 예를 들었을때 사용자가 '좋아요'버튼을 누르면 페이지가 전환되지 않고 실시간으로 action이 반영되는 것이 바로 상태관리를 통한 웹페이지 이다.

 

하나의 페이지에서도 다양한 상태들이 존재하기에 각 상태들이 어떤 상호의존을 하며, 각 페이지웹에서 어떤 흐름으로 흘러가는지, 그에따라 ui의 변화는 어떤지 쉽게 알아차리기 위해 상태의 관리가 필요하다.

 

3) 컴포넌트와 상태

한 웹 페이지에 존재하는 여러개의 컴포넌트들은 서로 데이터를 공유하고는 한다. 상단 검색바에 검색을 하면 하단 컨텐츠바에 검색 내용이 반환되는식으로 말이다. 즉, 컴포넌트는 다르더라도 사용하는 데이터는 연결이 되어있다는 것을 알 수 있다. 이렇게 컴포넌트간의 통신, 상호간의 데이터전달을 더욱 자연스럽게 할 필요성이 대두되면서 상태관리에 대한 중요성도 함께 높아지게 되었다.

 

상태관리는 상태가 많은, 복잡한 웹 애플리케이션에서 빛을 발한다. 규모가 클수록 데이터의 이동이 빈번해지고, 중간에 거쳐야할 컴포넌트들이 많아진다. 또 그렇게 되면 컴포넌트간의 데이터 흐름을 파악하기가 어려워진다. 즉, 이런 문제점들을 해결하기 위해 상태라는 것이 필요하다는 것이다.

 

 

---

 

2. 반응형 프로그래밍

 

1) 반응형 프로그래밍이란?

데이터와 컴포넌트를 연결해주는 자바스크립트언어는 객체지향이기에 상태의 값이 변화하면 그것을 찾아 각 컴포넌트들에게 올바르게 연결해줄 필요성이 있다. 이때, 반응형 프로그래밍은 상태의 즉각적인 변화를 바로바로 반영하는데에 있어 도움이 되는 역할을 한다.

 

즉, 반응형 프로그래밍이란 변화한 데이터에 따라 알아서 반응하는 프로그래밍이다. 이는 1985년도에 처음 나타난 개념이다. 

 

반응형 프로그래밍은 데이터가 변경이 될때마다 이벤트를 발생시켜 바뀐 데이터를 지속적으로 전달해주는 목표를 가진 프로그래밍이다! "데이터 변경됐어? 그럼 이렇게 해!"

 

핵심은 프로그래밍이 외부 환경과 어떻게 communication(교류)하는지이다. 그 방법은 제어권을 가진자의 기준으로 서술될 pull과 push가 있다.

 

1) pull

데이터 소비자인 프로그램은 데이터가 필요하면 데이터 생산자(외부환경)에게 필요한 데이터를 요청하여 받아오는 방식으로 프로그래밍 된다. 이때, 데이터를 당겨온다(pull)이라는 표현을 사용한다. 이때 제어권은 데이터 소비자가 가지고 있게 된다.

 

2) push

위의 방법이 번거로워 나타난 개념이다. 제어권을 데이터 생산자에게 넘겨 데이터가 변경되면 알아서 데이터 생산자가 데이터 소비자에게 (push)알리는 방식으로 이루어진다. 이렇게 되면 데이터 소비자는 데이터의 변화를 신경쓸 필요가 없어지게 된다. 반응형 프로그래밍은 push에 해당한다. 하지만, 개발자들이 반응형 프로그래밍을 하기 위해서 상태와 컴포넌트의 관계와 그 관계의 형성 시점까지 고려해야하므로 번거롭다는 단점이 있다. 

 

 

 

---

 

3. 상태관리와 패턴

상태를 어떻게 관리할 것인지에 대해 고안한 솔루션과 비슷한 맥락으로 상태관리와 관련된 다양한 패턴들을 정리하였다.

 

1) Observer Pattern : 관찰하는 패턴

Observer(관찰자)와 객체/state(관찰대상)이라는 개념이 존재한다. 관찰자들을 객체에 구독하여 객체의 상태변화가 있을때마다 메서드를 통하여 객체가 목록에 등록된 관찰자들에게 통지를 하는 디자인 패턴이다. 이때, 객체는 구독을 요청한 관찰자들을 배열로 가지고 있다. 후에 관찰자들은 전달받은 데이터를 가지고 각자 일 처리를 하게 되는 개념이다.

 

observer pattern은 실시간으로 한 객체의 변경사항을 다른 객체에 전파하여 객체간의 의존성을 제거할 수 있다는 장점이 있다.

 

2) Pub(publish)/Sub(subscribe) Pattern

observer pattern이 기반이 되어 변화한 패턴이다. 차이점은 관찰자와 관찰 대상 사이에 event channel이 존재한다는 것이다. 이는 객체와 구독자가 서로 직접 소통하지 않고 event channel을 거쳐서 소통하게 된다는 의미가 된다. 이렇게 되면 객체와 구독자의 결합도가 낮아지게 되고, 메세지 브로커로 메세징큐를 많이 사용하게 되어 비동기 워크플로우가 된다는 장점이 있다. 관찰자 : "message broker야 데이터 변화 알림 오면 알려줘 난 내 할 일 하고 있을게!"가 된다.

 

3) Proxy Pattern : 대리 패턴

하나의 객체가 proxy역할을 수행하여 상황에 따라 다른 객체에 접근하게 해주거나 다른 함수를 호출하게 해주는 패턴이다. 이때 proxy객체는 proxy pattern을 사용할때 실체 객체를 대신하는 객체라고 정리할 수 있다.

 

proxy는 기존의 객체를 수정하지 않으면서, 그 객체를 감싸서 사용할 수 있다. 상태가 변경되면 그 상태를 반영하기 위해 리렌더링이 필요하다. 이때, 리렌더링할 데이터로 상태를 직접 set할 수도 있겠지만, 그에 동반하는 사이드 이펙트(요구되어지는 이펙트 이외의 다른 이펙트가 발생하는 현상)가 클 것이다. 이를 방지하기 위해 proxy객체를 사용하는 것이다. 즉, state를 변경하지 않으면서도 필요한 값을 구독자에게 연결할 수 있게 된다.

 

 

---